Download
enhancements to crtp n.
Skip this Video
Loading SlideShow in 5 Seconds..
Enhancements to CRTP PowerPoint Presentation
Download Presentation
Enhancements to CRTP

Enhancements to CRTP

185 Views Download Presentation
Download Presentation

Enhancements to CRTP

- - - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - - -
Presentation Transcript

  1. Enhancements to CRTP draft-koren-avt-crtp-enhance-01.txt T. Koren, S. Casner, P. Ruddy, B. Thompson, A. Tweedly, D. Wing Cisco Systems John Geevarghese Motorola India

  2. CRTP does not perform well on links with packet loss and long round trip delays Packet loss causes context invalidation CRTP error recovery mechanism using CONTEXT_STATE messages is not efficient due to the long round trip delay. The suggested enhancements make CRTP more robust and resilient to packet loss, which in turn will reduce context invalidation. Why Enhance CRTP

  3. When will a lost packet cause context invalidation? Packet includes changes to context state fields New delta value Significant packet: its loss causes context invalidation Packet Loss andContext Invalidation

  4. Sample sent every 10 ms The first talk spurt is 1 second long. Then there are 2 seconds silence Then another talk spurt. Example Audio Stream

  5. FH - FULL_HEADER CR - COMPRESSED_RTP CU - COMPRESSED_UDP CS - CONTEXT_STATE T, dT - RTP timestamp (absolute and delta) S, dS - RTP seq# (absolute and delta) I, dI - IP ID (absolute and delta) pt - RTP payload type CC - Number of CSRC identifiers Shortcuts

  6. seq# Time pkt type 1 10 FH x 2 20 CR+ dI dT=10 x 3 30 CR 4 40 CR ... 100 1000 CR 101 3010 CR+ dT=2010 x 102 3020 CR+ dT=10 x 103 3030 CR 104 3040 CR ... ‘Classic’ CRTP Sequence

  7. seq# Time pkt type 100 1000 CR 101 3010 CR+ dT=2010 x 102 3020 CR+ dT=10 x 103 3030 CR Replace 101, 102 100 1000 CR 101 3010 ??T=3010 dT=2010 102 3020 ??T=3020 dT=10 x 103 3030 CR Remove Dependency

  8. seq# Time pkt type 100 1000 CR 101 3010 CR+ dT=2010 x 102 3020 CR+ dT=10 x 103 3030 CR Replace 101, 102 100 1000 CR 101 3010 ??T=3010 x 102 3020 CR Express change in one packet

  9. Enhanced CU: CU+ CU CU+ msb of context ID msb of context ID lsb of context ID lsb of context ID 0 0 0 dI CRTP seq # 0 I dT dI CRTP seq # UDP Checksum UDP Checksum “RANDOM” fields “RANDOM” fields Delta IPv4 ID Delta IPv4 ID UDP data (uncompressed RTP header) Delta RTP timestamp IP ID UDP data (uncompressed RTP header)

  10. Enhanced CU: CU* (CR style) msb of context ID RTP Timestamp lsb of context ID 1 I dT dI CRTP seq # M S T pt CC UDP Checksum RTP Payload Type CSRC List “RANDOM” fields Delta IPv4 ID RTP Header Extension Delta RTP timestamp RTP Data IP ID RTP Seq#

  11. seq# Time pkt type 100 1000 CR 101 3010 CR+ dT=2010 x 102 3020 CR+ dT=10 x 103 3030 CR Replace 101, 102 100 1000 CR 101 3010 CU*T=3010 dT=2010 102 3020 CU*T=3020 dT=10 x 103 3030 CR Using CU* with ‘T’ and ‘dT’

  12. seq# Time pkt type 100 1000 CR 101 3010 CR+ dT=2010 x 102 3020 CR+ dT=10 x 103 3030 CR Replace 101, 102 100 1000 CR 101 3010 CU* T=3010 x 102 3020 CR Using CU* with flag ‘T’

  13. When to use: At most N adjacent packets may get lost How to use Repeat change N+1 times The N Scheme:Repeat

  14. seq# Time pkt type 100 1000 CR 101 3010 CU*T=3010 dT=2010 102 3020 CU*T=3020 dT=10 x 103 3030 CR N=1 100 1000 CR 101 3010 CU*T=3010 dT=2010 102 3020 CU*T=3020 dT=10 b 103 3030 CU*T=3030 dT=10 b 104 3040 CR Using the N scheme (T, dT)

  15. seq# Time pkt type 100 1000 CR 101 3010 CU* T=3010 x 102 3020 CR N=1 100 1000 CR 101 3010 CU* T=3010 b 102 3020 CU* T=3020 b 103 3030 CR Using the N scheme (T)

  16. Increase / decrease N according to the number of invalidated contexts N Can Be Learned

  17. When to use: Avoid context invalidation How to use Repeat change until ACK’d The ACK Scheme:Repeat until ACK’d

  18. ACK Packet Format Type code=4: ACK, 8-bit CID Context Count Session Context ID RTP Sequence # ... Session Context ID RTP Sequence #

  19. ACK Packet Format Type code=5: ACK, 16-bit CID Context Count Session Context ID RTP Sequence # ... Session Context ID RTP Sequence #

  20. seq# Time pkt type 100 1000 CR 101 3010 CU*T=3010 dT=2010 102 3020 CU*T=3020 dT=10 x 103 3030 CR ACK Scheme 100 1000 CR 101 3010 CU* T=3010 dT=2010 102 3020 CU* T=3020 dT=10 Receive: ACK 101 103 3030 CU* T=3030 dT=10 Receive: ACK 102 104 3040 CR Using the ACK Scheme (T,dT)

  21. seq# Time pkt type 100 1000 CR 101 3010 CU* T=3010 x 102 3020 CR ACK Scheme 100 1000 CR 101 3010 CU* T=3010 102 3020 CU* T=3020 Receive: ACK 101 103 3030 CR Using the ACK Scheme (T)

  22. ‘Classic’ : 3 101 3010 CR+ dT=2010 x 102 3020 CR+ dT=10 x Enhanced with (T, dT) : 2*5 + N*6 overhead 101 3010 CU*T=3010 dT=2010 102 3020 CU*T=3020 dT=10 b 103 3030 CU*T=3030 dT=10 b Enhanced with (T) : 5 + N*5 overhead 101 3010 CU* T=3010 b 102 3020 CU* T=3020 b Bandwidth Overhead when using the N scheme

  23. Enhanced CRTP with N scheme (T, dT) transition: 10 + N*6 bytes (T) transition: 5 + N*5 bytes Average talk spurt length: 1 second Bandwidth Overhead when using the N scheme

  24. Calculate same as in N scheme, select:N = round trip delay (ms) / sample length (ms) ACK packet size: 6 bytes Bandwidth Overhead when using the ACK scheme

  25. seq# Time pkt type N=1 100 1000 CR 101 3010 CU*T=3010 dT=2010 102 3020 CU*T=3020 dT=10 b 103 3030 CU*T=3030 dT=10 b 104 3040 CR … 108 3080 CU+ I dI dT=10 <-- refresh all context state parameters Refresher Packet(CU+ Usage)

  26. dI is not constant Either dI or I must be included in each packet If dI is included in each packet, each lost packet invalidates the context Conclusion: it’s better to include I Use CU* with I flag instead of CR+ The Random IP ID(CU* Usage)

  27. seq# Time pkt type 1 10 FH x 2 20 CR+ dI dT=10 x 3 30 CR+ dI x 4 40 CR+ dI x ... Enhanced sequence: 1 10 FH x 2 20 CU* I dT=10 x 3 30 CU* I 4 40 CU* I Sequence with changing dI

  28. UDP checksum is used to verify validity of reconstructed packets Reconstructed IP ID cannot be verified Include IP ID in UDP checksum Including IP ID in the UDP Checksum

  29. When UDP checksum is present (nonzero) The compressor will 1's complement subtract the IP ID value from the UDP checksum before compression The decompressor will 1's complement add the IP ID value to the UDP checksum after any validation operations and before delivering the packet further downstream. Including IP ID in the UDP Checksum (cont.)

  30. UDP Checksum used to validate reconstructed packets, especially when ‘twice’ was used When UDP checksum is not present, CRTP may add Headers Checksum (HDRCKSUM) Headers Checksum

  31. HDRCKSUM includes: Pseudo-IP Header UDP Header Fixed part of RTP Header (first 12 bytes) IP ID Does not include: The extended part of the RTP header RTP data HDRCKSUM

  32. Calculated in the same way as a UDP checksum Placed in the COMPRESSED_UDP or COMPRESSED_RTP packets where a UDP checksum would have been The decompressor MUST zero out the UDP checksum field in the reconstructed packets HDRCKSUM (cont.)

  33. Notifies the decompressor that this stream is not an RTP stream Decompressor can enter flow in negative cache without RTP compression attempts Less CID thrashing Useful for application nodes where compressor has hints from application layer. NON-RTP stream flag

  34. NON-RTP stream flag in the FULL_HEADER packet New FULL_HEADER length fields format: For 8-bit context ID: 0 1 Generation CID 0 U Seq # For 16-bit context ID: 1 1 Generation 0 U Seq # CID Set U = 1 to indicate a non-RTP stream

  35. Decompressor implementations may share resources across multiple links Decompressor may over commit decompression resources in RFC 2509 negotiation Decompressor may REJECT a compressed steam when out of resources Rejecting a new compressed stream

  36. Reject packet (Using CONTEXT_STATE opcode) 1=CS, Reject 8-bit CID 2=CS, Reject 16-bit CID context count context count session context ID session context ID 1 1 0 0 CRTP seq# 0 0 generation 1 1 0 0 CRTP seq # 0 0 generation CID, CRTP sequence# and generation are taken from the FULL_HEADER

  37. RFC 2509 specifies how the use of CRTP is negotiated on PPP links using the IP Compression Protocol option of IPCP: IPCP option 2: IP compression protocol protocol 0x61 indicates RFC 2507 header compression sub-option 1 enables use of COMPRESSED_RTP, COMPRESSED_UDP and CONTEXT_STATE as specified in RFC 2508 Negotiating usage of enhanced-CRTP andACK scheme

  38. For the enhancements defined in this document, two new sub-options are added: sub-option 2 (length=2) : enables use of all CRTP enhancements except for the ACK scheme sub-option 3 (length=2) : enables use of all CRTP enhancements including the ACK scheme Negotiating usage of enhanced-CRTP andACK scheme (cont.)

  39. END