1 / 28

0-Byte ECRTP Parviz Yegani TSG-P Meeting, Portland, Oregon August 5-9, 2002

0-Byte ECRTP Parviz Yegani TSG-P Meeting, Portland, Oregon August 5-9, 2002. OUTLINE. A quick overview of CRTP ECRTP Enhancements Motivations for ECRTP in 3GPP2 ECRTP Operation 0-Byte ECRTP Operation ECRTP over PPP References. How CRTP Works?.

ban
Download Presentation

0-Byte ECRTP Parviz Yegani TSG-P Meeting, Portland, Oregon August 5-9, 2002

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. 0-Byte ECRTP Parviz Yegani TSG-P Meeting, Portland, Oregon August 5-9, 2002

  2. OUTLINE • A quick overview of CRTP • ECRTP Enhancements • Motivations for ECRTP in 3GPP2 • ECRTP Operation • 0-Byte ECRTP Operation • ECRTP over PPP • References

  3. How CRTP Works? • CRTP uses delta encoding where compressed headers carry differences from the previous header. • The decompressor maintains state, known as context, that represents the current header, how it is expected to change, etc. • When the context is out of sync the decompressor reports its state back to the compressor to bring its context in sync with the compressor. • CRTP uses a link sequence number, incremented by one for each packet with a compressed header, to detect lost packets. • Gaps in the sequence number space triggers the context repair mechanism.

  4. How CRTP Works? … • After a long loss the decompressor should send an advisory CONTEXT_STATE packet to request refreshing of the context. • The TWICE mechanism is used to repair the context locally without having to wait for a round-trip over the link. • This mechanism assumes that the delta of a lost CRTP packet is the same as the subsequent packet. Otherwise, the repair attempt might fail. • When using TWICE for context repair the UDP checksum is normally used to verify whether the attempted repair succeeded.

  5. Why Enhance CRTP? • CRTP does not perform well on links with packet loss and long round trip delays. • The context repair mechanism in CRTP involves feedback from the decompressor, context repair takes at least as much time as the round trip time of the link. • Packet loss causes context invalidation and CRTP error recovery mechanism is not efficient due to the long round trip delay. • The suggested enhancements (i.e. ECRTP) make CRTP more robust and resilient to packet loss, which in turn will reduce context invalidation.

  6. Why Enhance CRTP? … • Enhancements are done by the way the compressor updates the context at the decompressor. • The two main enhancements in ECRTP are: • Repeat updates in several packets - this adds the robustness against loss: if a packet that includes an update is lost, the same update will still be included in the next packet, so the decompressor still stays in sync with the compressor • Updates of absolute values (in addition to updates of differential values as defined in RFC 2508)

  7. ECRTP Is Robust! • Since ECRTP updates absolute values, there is no need to apply the TWICE algorithm after packet loss. • Since the update in the packet following the lost packet includes the absolute value of the updated variable, so there is really no need to check the UDP Checksum or the Header Checksum.

  8. UDP Checksum • When UDP checksum is enabled, both ROHC and ECRTP must send them explicitly. • When UDP checksums are not used then • ROHC uses a CRC over the header that will trigger an update if the context is out of sync. • ECRTP will send a periodic refresh packet. • A 0-byte header ROHC will not require a CRC. A 0-byte RTP packet for LLA ECRTP would not require the checksum either.  • As long as the packet loss is < N (negotiated Max Packet Loss) then the decompressor can confidently decompress the packet.

  9. Segmentation • Packet segmentation is done at the link layer using two new packet types; SEGMENT and END_SEGMENT. • A simple method is used to convey the packet type (Full Header, Compressed UDP, Compressed RTP, etc). • This is done by placing the type in the first byte of the SEGMENT payload. 

  10. Motivation for ECRTP in 3GPP2 • CRTP is widely deployed and ECRTP is a small increment of CRTP, it is fairly easy to enhance a CRTP implementation to become ECRTP • Cap Rock Services • Infosat Communications Note - Both are using the beta code in the production network and have no problems • The number of the CRTP users is growing rapidly. See next page for more details. • It’s simple (only 24 pages).

  11. Motivation for ECRTP in 3GPP2 … • CRTP can be upgraded easily tobecome ECRTP. Also need take into account the fact that • There exist a mature, well tested implementation of CRTP on which one can build a quite reliable ECRTP based HC solution. • RFC 3095, however, is 168 pages long.  It is a very complex method of compression which largely operates at bit level. It will take a lot more code/time/effort to implement. • ROHC implementations would be slower, larger, consume more memory and contain more bugs.  • ROHC has NOT been commercially deployed yet!

  12. Motivation for ECRTP in 3GPP2 … • Known customers who are using CRTP today • ATT • Equant • Telstra • Ibasis • Genuity • World Bank • Sun Microsystems • Sprint • Lucent • Cisco • Many more …

  13. ECRTP Operation 1. FH Packet (Full Header Update) 1 20 8 12 IP Header(CID,Seq #..) UDP Header RTP Header FH

  14. ECRTP Operation… 2. CU Packet (with updates T, dT, I, dI) 1 1 1 1* 1 1 2* 4* n Flags+ CRTP Seq # CU CID Flags dI dT I T data *These are optionally sent (at the discretion of the compressor).

  15. ECRTP Operation… • 3.CR Packet (for normal operation) • (NHP candidate) data

  16. ECRTP Operation… 4.CU Packet ( update dI only) 1 1 1 1 2* n Flags+ CRTP Seq # CU CID dI I data *These are optionally sent (at the discretion of the compressor).

  17. ECRTP Operation… 5.CU Packet (Periodic Update) 1 1 1 1 1* 1* 2* 4* 2 n Flags+ CRTP Seq # data CU CID Flags dI dT I T S *These are optionally sent (at the discretion of the compressor).

  18. ECRTP Operation… 6. ECP (similar to the CCP packet) The periodic update can just update Seq # (dI and dT should not change) 1 1 Leading Sequence CRTP Seq #

  19. Context Invalidation • When will a lost packet cause context invalidation? • Packet includes changes (updates) to context state fields, such as new delta value (dT, dI) • Packet includes the RTP Sequence Number (S)

  20. Repeat N Scheme • When to use: • At most N adjacent packets may get lost • How to use • Repeat the update N+1 times • N can be learned • Increase / decrease N according to the number of invalidated contexts

  21. Example 1: Over-run Case • Seq # RTP TS Packet Type Remarks • 29 1000 CR=NHP • 31 1040 CU(seq_num=31) Over-run case • N=1 • 1060 CU(seq_num=32) Repeat Once • 33 1080 CR=NHP

  22. Example 2: Under-run Case • Seq # RTP TS Packet Type Remarks • 1000 CR=NHP • 1020 ECP(seq_num=30) no packet arrives • 30 1020 CU(seq_num=30) Under-run case • N=1 • 31 1040 CU(seq_num=31) Repeat Once • 32 1060 CR=NHP

  23. 0-Byte ECRTP Operation • A separate service instance could be used to carry the full header initialization packet as a means to avoid delays of the update.  • Or alternatively, could use the synchronous channel to send the FH packet after it is segmented.

  24. 0-Byte ECRTP Operation • No updates during the life of a stream since there is no silence suppression. The decompressor receives either a sample or a loss indication every period, so it can maintain the RTP timestamp and sequence number. No changes are expected in the payload type or in any other RTP header values. • Suggest sending a packet with an update on the RTP Sequence Number (S) once every n seconds, otherwise, send 0-byte samples. • After a long loss (more than N) the decompressor should send an advisory CONTEXT_STATE packet to request refreshing of the context.

  25. Fixed Packet Sizes • The LLA-ECRTP packets would fit into physical layer frames (e.g., Rate Set 1 frames: 171, 80, 40 and 16 bits) with appropriate padding. • Note- The Full Header packet must be segmented as described earlier. Other packets are segmented if necessary. • The details is being worked out.

  26. ECRTP over PPP • 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 (CRTP) • To use the CRTP enhancements, sub-options 2 is added: • sub-option 2 (length=2): enables use of CRTP enhancements (see Cisco’s companion contribution P10-20020708-xxx)

  27. Short Notations FH - FULL_HEADER CR - COMPRESSED_RTP CU - COMPRESSED_UDP CS - CONTEXT_STATE ECP - ECRTP Control Packet T, dT - RTP timestamp (absolute and delta) S, dS - RTP seq. no. (absolute and delta) I, dI - IP ID (absolute and delta) pt - RTP payload type

  28. References • IETF draft draft-ietf-avt-crtp-enhance-04.txt, Feb. 2002 • T. Koren, et. al. Enhancements to CRTP, PPT slides presented at IETF 52nd • IETF draft draft-koren-pppext-rfc2509bis-02.txt, June 2002

More Related