Last Modified: 2004-06-14
Another consequence of low bandwidth links is long session setup delays when text-based signaling protocols, such as SIP and SDP, are used. These delays can be significantly reduced by compressing not only the headers, but also the signaling information.
The goal of ROHC is to develop generic header compression schemes that perform well over links with high error rates and long roundtrip times, as well as related signaling compression schemes. The schemes must perform well for cellular links built using technologies such as WCDMA, EDGE, and CDMA-2000. However, the schemes should also be applicable to other future link technologies with high loss and long roundtrip times. Ideally, it should be possible to compress over unidirectional links.
Good performance includes both minimal loss propagation and minimal added delay. In addition to generic TCP and UDP/RTP compression, applications of particular interest are voice and low-bandwidth video.
ROHC may develop multiple compression schemes, for example, some that are particularly suited to specific link layer technologies. Schemes in addition to those listed in the milestones below may be added in consultation with the area directors.
A robust compression scheme must:
* assure that the result after decompression is semantically identical to the uncompressed original;
* perform well when the end-to-end path involves more than one cellular link;
* support IPv4 and IPv6.
* provide benefit in the presence of IPSEC.
Creating more thorough requirements documents will be the first task of the WG for each of its specific areas of work, which are:
* 0-byte improvements to RTP header compression
* TCP header compression
* Signaling compression
* SCTP header compression
In addition, the WG will work on MIBs for its compression schemes, as well as the sheperding of RFC3095 to draft standard.
The working group shall maintain connections with other standardization organizations developing cellular technology for IP, such as 3GPP and 3GPP-2, to ensure that its output fulfills their requirements and will be put to good use.
In addition, the WG should develop a solid understanding of the impact that specific error patterns have on the compression schemes, and document guidelines to Layer 2 designers regarding what Layer 2 features work best to assist Layer 3 and Layer 4 header compression. This work is in coordination with the PILC WG.
Some of the schemes developed in ROHC will be used in wider contexts than just the specific link technologies discussed. The working group will ensure the applicability in particular of the TCP and signaling compression schemes to the general Internet. This includes considering the applicability of the technologies under consideration to open-source implementations.
Finally, working group documents will address interactions with IPSEC and other security implications.
| Done | Submit I-D on Requirements for IP/UDP/RTP header compression. | |
| Done | Submit I-D of layer-2 design guidelines. | |
| Done | Submit I-D(s) proposing IP/UDP/RTP header compression schemes. | |
| Done | Submit I-D of Requirements for IP/TCP header compression. | |
| Done | Requirements for IP/UDP/RTP header compression submitted to IESG for publication as Informational. | |
| Done | Resolve possibly multiple IP/UDP/RTP compression schemes into a single scheme. | |
| Done | Submit I-D on IP/TCP header compression scheme. | |
| Done | IP/UDP/RTP header compression scheme submitted to IESG for publication as Proposed Standard. | |
| Done | Layer-2 design guidelines submitted to IESG for publication as Informational. | |
| Done | Initial draft on general signaling compression security analysis. | |
| Done | Requirements and assumptions for signaling compression | |
| Done | Signaling compression scheme submitted to IESG for publication as Proposed Standard, including security approach for SIP compression usage. | |
| Done | General signaling compression security analysis submitted to IESG for publication as Informational. | |
| Done | ROHC MIB submitted to IESG for publication as Proposed Standard. | |
| Done | ROHC IP-only profile submitted to IESG for publication as Proposed Standard | |
| Mar 04 | I-Ds of ROHC IP/UDP/RTP bis, framework and profiles separated. | |
| Apr 04 | ROHC UDP Lite schemes submitted to IESG for publication as Proposed Standard. | |
| May 04 | ROHC framework submitted to IESG for publication as Draft Standard. | |
| Jun 04 | Requirements for IP/TCP header compression submitted to IESG for publication as Informational. | |
| Jun 04 | IP/TCP compression scheme submitted to IESG for publication as Proposed Standard | |
| Aug 04 | ROHC IP/UDP/RTP schemes submitted to IESG for publication as Draft Standard. | |
| Aug 04 | Possible recharter of WG to develop additional compression schemes |
| RFC | Status | Title |
|---|---|---|
| RFC3095 | PS | RObust Header Compression (ROHC) |
| RFC3096 | I | Requirements for robust IP/UDP/RTP header compression |
| RFC3242 | PS | A Link-Layer Assisted ROHC Profile for IP/UDP/RTP |
| RFC3243 | I | Requirements and assumptions for ROHC 0-byte IP/UDP/RTP compression |
| RFC3241 | PS | ROHC over PPP |
| RFC3408 | PS | Zero-byte Support for Reliable Bidirectional Mode (R-mode) in Extended Link-Layer Assisted RObust Header Compression (ROHC) Profile |
| RFC3409 | I | Lower Layer Guidelines for Robust RTP/UDP/IP Header Compression |
| RFC3320 | PS | Signaling Compression |
| RFC3321 | I | SigComp - Extended Operations |
| RFC3322 | I | Signaling Compression Requirements & Assumptions |
| RFC3759 | I | RObust Header Compression (ROHC):Terminology and Channel Mapping Examples |
| RFC3816 | Standard | Definitions of Managed Objects for Robus Header Compression |
| RFC3843 | Standard | RObust Header Compression (ROHC): A Compression Profile for IP |
|
Minutes of the ROHC WG session at IETF 60
========================================= Sheraton San Diego Hotel & Marina, San Diego, USA Tuesday afternoon, 2004-08-03 Chairs: Carsten Bormann & Lars-Erik Jonsson Reported by: Lars-Erik Jonsson Note takers: Christian Schmidt, Kristofer Sandlund, Carsten Bormann & Andrew McDonald Afternoon session, 15:45-18:00 ------------------------------ * WG admonishments (Jonsson) Meeting time should be used to advance difficult issues, not for presentation of material that can be read from drafts. We assume that people have read the drafts, and what we decide in meetings must be confirmed on the mailing list. Also, all contributors must be aware of the IPR principles, as stated by RFC 3668. * Agenda bashing (Jonsson) Lars-Erik presented the proposed agenda, which was accepted without modifications. Agenda: - Chair admonishments and agenda bashing - WG and document status update - Signaling compression issues + SigComp implementer's guide + Applying SigComp to SIP - ROHC RTP update + ROHC implementer's guide + RFC 3095 implementation status - ROHC over channels that can reorder packets - ROHC TCP * WG and document status (Jonsson) Lars-Erik reviewed WG goals, milestones and document status. The WG has had ten published RFC's, and since the last time we met another three ROHC RFC's have been added to that list. These are - RFC 3759, ROHC Terminology & channel mapping examples - RFC 3816, Definitions of managed objects for ROHC - RFC 3843, A ROHC profile for IP Currently, we have no documents in the RFC editor's queue. One document, the ROHC UDP-Lite profiles draft, has been submitted to the IESG and is currently subject to AD review. The SigComp NACK draft has passed WG last-call but has not yet been submitted to the IESG, as we are awaiting CDR comments and another update to address what has been observed during WG last-call. We currently have nine WG drafts in progress, two related to SigComp, two related to ROHC RTP, and five drafts for the ROHC TCP profile. We are few active people in the WG, but we are making progress, although we have to take things one at a time. The current milestones will have to be updated, as some items have been completed, while we have missed the date for the rest. The intention is to discuss an update of these as soon as the TCP profile now is completed, which is our current focus, while we have put the ROHC RTP DS advancement on hold. The concept of having "committed document reviewers" (CDR's) on all drafts, as introduced as the San Francisco meeting last year, has been proven to work well, and we will continue to follow that. It simply means we will require at least two committed non-authors to agree to follow the work, as well as to review and provide comments publicly during WG-last call. * Signaling compression issues - SigComp implementer's guide (West) Mark summarized the few changes made to the implementer's guide as a result of mail list discussions. Byte copying rules have been clarified, as well as state duplication and STATE-CREATE. The DAP (Dummy Application Protocol) used at the first SigComp interop test has also been added as an appendix. In the next revision, discussions related to the static dictionary will be added, as there are some "slightly broken" references. A compressor should not use references that are inconsistent if it would cause a problem, but it should be made clear that this is a compressor-local issue. One issue has been identified that must be subject for further discussions and a resolution. There is a potential risk of state inconsistency when using shared mode operation, as losses might result in missing states, meaning that an old shared state might be pushed out at one peer but not at the other. Mark's suggestion to resolve this was to allow shared mode to attempt creation of at most one piece of shared state. Carsten commented that the sender is actually pushing out state belonging to the receiver's domain, so this should not happen. Mark disagreed and noted that the behavior is 3220 compliant, as the sender does not know which state to throw away, and Carsten returned to his cup of coffee. Draft: draft-ietf-rohc-sigcomp-impl-guide-03.txt - Applying SigComp to SIP (Liu) Zhigang went through the various SigComp/SIP issues that have been under discussion. DMS (decompression memory size) seems to be settled at 8, while the SMS (state memory size) probably should be set to 2. CPB (cycles per bit) has been suggested to be 16, but there have been no comments on that. Mark agreed that this sounds to be a proper choice as it has not been exceeded in tests, but no measurements have been done. The most controversial question discussed was the issue about potential multiplexing of SigComp and plain SIP messages on the same TCP connection. This has been discussed on the mail list for more than a year, and Zhigang explained why this could be a useful feature to have. One argument is to avoid having to set up another TCP connection if the other end appears to support/not support SigComp. Keith Drage commented that this is not an issue in 3GPP, where SigComp is mandated, to which Zhigang responded that there are proposals to relax that requirement. Another argument for adding mutiplexing is the 64 kb limit, but Mark pointed out that there is a simple solution for that, as previously explained on the mail list. Other arguments were to allow a compressor to switch between compressed and non-compressed to save CPU/memory, and to allow a sender to simply bypass SigComp if there is a failure. There was some further discussions but no new arguments were identified, apart from what has already been discussed on the mail list. Further discussions will be needed to settle this. Finally, Carsten noted that there have been requests to finish this document, and the open issues will be discussed with some more SIP people later during the week. Draft: draft-ietf-rohc-sigcomp-sip-01.txt * ROHC RTP update - ROHC implementer's guide (Jonsson) Lars-Erik gave a brief update on the ROHC RTP implementer's guide. Only a few minor changes have been made in the new version, but an appendix has been added with two identified but unresolved issues. The first issue is the problem with whether a re-used context would keep its operational mode or not. In March, it was proposed that a re-used context would keep its operational mode if it was re-used for a context with the same profile, while mode would have to be set to "initial mode" if re-used for a context with a different profile. Unfortunately, problems with this were identified in a mail sent to the list in June (titled "Context reuse revisited"), and this is thus still not resolved. The second and most critical issue is the question about "slopes" used to compress and decompress fields that are expressed as a function of the RTP SN, basically the RTP TS. RFC 3095 touches upon a slope that should be implicitly communicated between compressor and decompressor, but how this is supposed to work is not at all defined in the RFC. Discussions have clearly indicated that this is a tricky issue, and we will certainly have to pay some attention to it. Stephen Casner asked who wrote the words initially, and Lars-Erik answered that there were a number of authors who wrote this in a short time frame, which explains why it got inconsistent and incomplete. Draft: draft-ietf-rohc-rtp-impl-guide-05.txt - RFC 3095 implementation status (Sandlund) Kristofer reported from the 5th RFC 3095 interop test, held in Stockholm in the beginning of June with participants from Ericsson and Effnet. The goal was to focus on testing the whole UDP profile, the missing packet types from ROHC RTP, segmentation and feedback. The test was successful in such that no new problems with the specification were encountered and all goals were reached, except for list compression and related parts. Untested features are thus now CSRC list compression, extension header list compression, timer-based compression, the ESP profile, some of the feedback options, and CID re-use as per previous discussions. Draft: draft-ietf-rohc-rtp-rfc3095-interoperability-03.txt * ROHC over channels that can reorder packets (Jonsson) A new individual draft has been submitted by Ghyslain, Lars-Erik and Kristofer, addressing the subject of how to apply ROHC over channels that can reorder packets. Questions about ROHC and reordering channels pops up every now and then, and the intention with this document is to create a reference for such questions and discussions. As ROHC explicitly states that it has been designed with in-order delivery as a core assumption, people tend to think that ROHC is particularly unsuitable (compared to other HC alternatives) for scenarios where this requirement can not be met, which is not true. The draft consists generally of three parts. First, it provides a problem description for ROHC (and header compression in general) over channels where packets can be reordered. Secondly, it suggests how to implement existing RFC 3095-based profiles over reordering channels. Finally, there are ideas and recommendations for how existing profiles could be updated and how new profiles can be defined to efficiently cope with reordering. Lars-Erik asked people to read it and help improving it, and asked whether people think it would make sense to adopt it as a WG draft. Carsten noted that this is currently not in our charter, but could make sense to add. Ghyslain said the draft was triggered by the AVT discussions on header compression over MPLS, and asked whether the goal should be just an informational document or if we should indeed start work on new or modified profiles, if adopted by the WG. Lars-Erik believed it would be a useful informational document as a reference, while doing actual new profile work would be a much bigger question. Mark agreed that this would be a good document to have, and noted that ROHC TCP is supposed to tolerate reordering to some degree. Zhigang also supported making this a WG document for publication as Informational. Draft: draft-pelletier-rohc-over-reordering-00.txt * ROHC TCP - Overview (Pelletier) Ghyslain gave an overview of the five drafts that are part of the ROHC TCP profile work. Requirements, Field Behavior and Context Replication are stable and should be ready for WG last-call, while the Notation and TCP profile drafts have evolved significantly lately and are getting close to being a complete solution. The packet formats are now quite complete, but must be adjusted based on recent changes to the formal notation. Irregular chains have been defined in addition to static and dynamic chains to handle fields that must be included as-is in all packets. List encoding has been clarified and Item Table mappings defined for TCP options. Replication has also been added for TCP options, MSN initialization and re-initialization has been defined, and there is a general format for the compressed TCP header. Gorry Fairhurst asked where the TCP checksum is sent, and Mark answered that it is part of the irregular chain, as it has to be sent in every packet. Committed document reviewers are needed for all five drafts, please volunteer. The goal is to have these ready in September so that we can meet the 3GPP R6 deadline. - Packet format overview (Sandlund) Kristofer gave an overview of the packet format design used in the TCP profile. As in RFC 3095, static and dynamic are used, but a new concept called "irregular chains" has been introduced in addition to these. Irregular chains are used for fields that must always be sent uncompressed. Handling of multiple IP headers is simplified by the use of irregular chains so that only the innermost IP header and the TCP header must be included in the base format of compressed headers. IP-ID compression is also simplified so that the IP-ID must be sent uncompressed for all but the innermost IP header. List compression is also significantly simplified compared to RFC 3095, and extension headers are not at all compressed with list compression. - TCP compressed packet formats (West) Mark continued with more details of the actual ROHC TCP packet formats. There are two sets of CO (compressed) formats, one for sequential IP-ID and one for Non-sequential (random or zero), and then there is one common format. There are currently 18 formats for sequential and 12 for non-sequential IP-ID and these should capture all most common change patterns efficiently, but the target is to reduce these to about 12 formats for each set. It should be noted that there are no "extension headers" to these, as in RFC 3095. Compared to RFC 3095, there is also a slight change in the static chain representation, as one single bit is used to represent IPv4/v6, which frees up some other bits. For context replication, the design principle has been simplicity, as more complex ideas have not given much gain compared to the complexity added. For TCP options, there is a special handling of SYN options by "pre-loading" of the list table entries. Most options can be compressed, specifically SACK permitted, SACK, WScale, Timestamp and MSS. Lars-Erik asked for a clarification about the dual sets of packet formats, especially compared to RFC 3095 where we have two sets for two different modes. Mark explained that the difference is for IP-ID only and is not really a status change like the 3095 modes. Ghyslain asked why there is a difference in the number of formats for the two sets, and Mark explained that for the random/zero formats, IP-ID has no impact on the actual formats so these can be fewer than if the IP-ID is compressed. Ghyslain further asked how we make sure to get the "right" formats, and it was agreed that we can never get it "totally right" as there is no such thing, but "good enough" should be sufficient. This can be achieved by ensuring a good review of the behavior document. Drafts: draft-ietf-rohc-tcp-07.txt draft-ietf-rohc-formal-notation-03.txt draft-ietf-rohc-context-replication-03.txt draft-ietf-rohc-tcp-requirements-07.txt draft-ietf-rohc-tcp-field-behavior-03.txt (expired) |