Enhancements to CRTP draftkorenavtcrtpenhance01 txt T Koren S

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 1

Why Enhance CRTP • 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. 2

Packet Loss and Context Invalidation • 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 3

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

The Random IP ID (CU* Usage) • d. I is not constant • Either d. I or I must be included in each packet – If d. I 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+ 26

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

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

Including IP ID in the UDP Checksum (cont. ) • 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. 29

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

HDRCKSUM • 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 31

HDRCKSUM (cont. ) • 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 32

NON-RTP stream flag • 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. 33

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 0 Generation CID Set U = 1 to indicate a non-RTP stream 34

Rejecting a new compressed stream • 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 35

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

Negotiating usage of enhanced-CRTP and ACK scheme • 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 0 x 61 indicates RFC 2507 header compression – sub-option 1 enables use of COMPRESSED_RTP, COMPRESSED_UDP and CONTEXT_STATE as specified in RFC 2508 37

Negotiating usage of enhanced-CRTP and ACK scheme (cont. ) • 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 38

END 39