Last Modified: 2003-01-27
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.|
|NOV 02||ROHC MIB submitted to IESG for publication as Proposed Standard.|
|NOV 02||I-Ds of ROHC IP/UDP/RTP bis, framework and profiles separated.|
|JAN 03||LLA mapping examples submitted to IESG for publication as Informational.|
|FEB 03||Requirements for IP/TCP header compression submitted to IESG for publication as Informational.|
|FEB 03||IP/TCP compression scheme submitted to IESG for publication as Proposed Standard|
|MAR 03||ROHC framework submitted to IESG for publication as Draft Standard.|
|MAR 03||ROHC IP/UDP/RTP schemes submitted to IESG for publication as Draft Standard.|
|APR 03||ROHC UDP Lite schemes submitted to IESG for publication as Proposed Standard.|
|JUN 03||IP/SCTP compression scheme submitted to IESG for publication as Proposed Standard.|
|AUG 03||Possible recharter of WG to develop additional compression schemes|
|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|
|RFC3321||I||SigComp - Extended Operations|
|RFC3322||I||Signaling Compression Requirements & Assumptions|
Minutes of the ROHC WG session at IETF 56 ========================================= Hilton San Francisco, San Francisco, USA Monday evening, 2003-03-17 Chairs: Carsten Bormann & Lars-Erik Jonsson Reported by: Lars-Erik Jonsson Note takers: Stephen Casner, Christian Schmidt & Mark West Slides are available at http://www.dmn.tzi.org/ietf/rohc Evening session, 19:30-22:00 ---------------------------- * WG admonishments (Jonsson) Lars-Erik reviewed the IETF working group principles, the IETF standardization process and the IPR rules defined by RFC 2026. 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. * 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 - ROHC RTP DS preparations update - Formal header compression notation * WG and document status (Jonsson) Lars-Erik reviewed WG goals, milestones and document status. Five new ROHC RFC's have been published since November, three SigComp documents, the LLA R-mode extension, and the RTP lower layer guidelines. Currently, we have no documents in the RFC editor's queue, but we have two that were just submitted to the IESG, the ROHC MIB and its companion document with terminology and channel mapping examples. The working group is progressing, but slowly. A milestone update was planned after Atlanta, but has not yet happen for various reasons. However, we should be able to do this rather soon. A new document review concept is to be implemented, where each document is required to have "committed reviewers". These reviewers are designated as such by the chairs, preferably on an early stage, and must have agreed to follow the document evolution, to carefully review the whole document, and to respond openly to working group last-call. Committed reviewers should be non-authors, and will be separately acknowledged in documents. The work items not covered by the agenda of this meeting were: - ROHC TCP, which has not progressed as planned due to editor illness, but an update is expected within a few weeks. - Modified RTP/UDP profiles for UDP-Lite compression, where the current individual draft will be resubmitted as a WG draft. - SCTP compression, which is still on hold. The chairs have asked for interest, motivation, industry support, and commitments for doing the actual work, but answers have not really provided that. Carsten noted that we might not understand future usage of SCTP at this point, so attempting a solution now might produce a result that is not really useful. * Signaling compression issues - SigComp Feedback (Roach) Adam Roach gave a quick summary of the changes in the updated draft. Nack information is now at the end of the messages, and can therefore be distinguished from standalone feedback. The TCP behavior has been changed, and a NACK detection mechanisms has been added. There was a question raised whether we should create an IANA registry for the first 32 bytes of UDVM memory space, but the question was never answered or discussed. More people have to look at this, so far the input has been limited. The meeting suggested that the document should be adopted as a WG document, if we get a few committed draft reviewers, and Mark West and Carsten Bormann volunteered for this. Draft: draft-roach-sigcomp-nack-01.txt - SigComp interoperability report (West) Mark West gave a report from the first SigComp interoperability testing, conducted at SIPit. The point was primarily to test SigComp, with or without SIP, trying to verify that all decompressor/UDVM endpoints behave consistently. Six implementations were present, which was more than expected, and the overall result was good, things mainly worked. The main problem had to do with consumption of decompressor memory because bytecode consumes memory in two places, making bootstrapping very difficult. Zhigang Liu noted that this is not a new issue, as it was discussed among SigComp authors during last year, but then it was seen as a non-problem. Adam Roach pointed out that this currently makes SigComp unusable for SIP in 3GPP, and described three potential solutions. It was agreed that the desirable approach would be to increase the UDVM memory size, but there were various opinions on how to achieve that, from a standards point of view. Richard noted that this is an application specific issue, and a larger UDVM memory size should be mandated for SIP. Carsten agreed, but RFC 3486 does not say so, and there are other things missing as well. Carsten suggested that SigComp should not be changed, but that this should be left to each signaling protocol to specify. We should then not consider RFC 3486 as binding SIP to SigComp, but only defining how an application finds out if SigComp is being used. This means that we need a new document to specify other SIP specifics for SigComp. Zhigang volunteered to serve as editor for such a document. There were a few more issues identified at SIPit, but these were minor, although we should provide some clarifications. To do that, it was agreed to create a SigComp implementer's guide, and Mark agreed to write up an initial version with the current findings. - The SigComp binary multiplexing issues (Price) Richard Price initiated a follow-up to the SigComp multiplexing discussion from the Sipping list. Although SigComp offers an alternative transport service to applications, using SigComp requires more than just an on/off switch. Applications using SigComp must provide mechanisms for SigComp discovery, methods for recognizing SigComp messages, define compartment handling, clarifying whether "continuous mode" can be used, and potentially increase the minimal memory size and/or the maximal number of UDVM cycles. The mixing problem raised was triggered by the requirement that SIP messages may contain binary data. In UDP, framing comes from the packet, but for TCP there are both application and SigComp delimiters. Problems would then arise if uncompressed application messages are multiplexed with SigComp messages. Carsten noted that for TCP, the first byte would indicate whether SigComp is used or not, and there seems to be something wrong with the layering here. If there is a problem, it is probably because of misuse of SigComp. Richard agreed, what should be made clear is that SigComp should not be switched on/off within a connection. If someone wants to send some messages uncompressed, that can be handled within SigComp. Zhigang argued that we should still define how to do multiplexing of raw application messages and SigComp messages, and this discussion will probably continue on the mailing list. Whether to allow "continuous mode" at all must further be specified per application, so we need the SIP-SigComp binding document also for that. * ROHC RTP, Draft Standard preparations status (Jonsson) The MIB draft has been submitted to the IESG, and so has the channel mapping examples document. The feature test document has been updated with additional tests, as well as some initial status figures. Reports are currently being collected, and the next update will be available within a month. An update of the IP profile has also been available for some time, but more feedback would be appreciated before we issue WG last-call. Finally, some minor clarifications have been added to the implementer's guide. Stephen Casner asked whether ROHC RTP Draft Standard advancement is dependent on DS for RTP itself. Although this will probably not be an issue since RTP will soon be published as Draft Standard, Carsten noted that ROHC RTP is not dependent on RTP itself because compression is speculative. Drafts: draft-ietf-rohc-rtp-impl-guide-03.txt draft-ietf-rohc-rtp-rfc3095-interoperability-01.txt draft-ietf-rohc-ip-only-01.txt * Formal header compression notation (Bormann, Ozegovic, Price) Carsten introduced the formal header compression notation, initially answering the question why this work is needed. The lesson we have learned from RFC 3095 is that compressed packet formats easily gets non-trivial, overstressing the RFC box notation. It is not always clear what goes where, since labeling a field in box notation does not necessary mean you know how to interpret it. With a formal notation, the uncompressed data is described, as well as which compression mechanisms that is applied to each field. ROHC formal notation (ROHC-FN) is inspired by BNF, ROHC packet classifications, Huffman probabilities, etc. ROHC-FN is something that needs to get done and out of the way to return to working on profiles, which is what we are really chartered to do. Julije Ozegovic gave a quick presentation of an initial attempt to define a profile for DCCP using a formal notation approach. The purpose of this work was to investigate the usefulness of a formal notation, as well as studying DCCP for compression purposes. DCCP has a fixed header and various options, so the compression must handle the variability. Carsten noted that to use the notation, we will have to nail it down formally in a standardized way. It is easy to do something "wishy-washy", but it is hard to do it clearly. We need to get a common understanding in the WG as to how the notation works. This is not easy, and semantics have to be very clear. Further, we have to find a proper trade-off between top-down and bottom-up design. If we focus too much on specific applications of the notation in a top-down design we will get a smaller set of tools, which would be a good thing, but the solution will probably be inflexible for new uses. With a bottom-up design, we could on the other hand get something too flexible and far from actual application requirements. We need to find a proper middle-way. An idea is to define the notation using a high level programming language, and two examples were given by Carsten (Prolog) and Richard (Haskell). Prolog is a well-known logical programming language, while Haskell is a functional language. As shown by the examples, both provide means to get a rather human-readable notation result, and the difference is minimal, at least on the surface. Carsten finally raised some issues on the way forward. We will have to balance specification/implementation, as it is a danger that we write the whole implementation into the specification. There will have to be "oracle" functions, which are left for implementers to define. Another issue is the actual bits-on-the wire encoding, when there are alternatives in the encoding. To handle alternatives, some discriminators are needed, but it is not obvious how to create these. There have been discussions on the mailing list, but we have not totally converged towards an agreement. This was discussed also at the meeting, but the conclusion was that an agreement should not be difficult to reach, we just have to get a clearer and common picture of what people really mean. One thing is to agree on some terminology for discriminator functions, i.e. Huffman and Hierarchical Huffman. Julije noted that we have two phases, encoding and how to arrange the bits on the wire, i.e. field encoding and discriminators. Carsten clarified that there are really not two phases, just two primitives in the notation, Fields and Discriminators. Another high level question is how complete we want to make the notation. With an academic approach, one would let this take three or four years to get a complete solution, but that is really not the IETF way. Since new stuff can easily be added, if needed for another compression profile, we do not really have to create a complete solution, although we should have a good feeling about future enhancements. There was a strong agreement in the room to go for the proposed approach. One major open issue is about interaction between the formal notation and contexts, which is something that is not well understood at this point. Since contexts may not be the same at compressor and decompressor, due to loss, this must be covered for. We have feedback for context repair, but that is not covered by the notation. We also need to have means to handle things that are optionally present, e.g. list elements in IPv6. Richard noted that we currently do not support unbounded (recursive) encoding, and we have to carefully consider whether we should do that. Julije asked whether we have a problem with contexts and packet classification, i.e. which fields to check to see how to handle the packet and find the right context for it. Carsten commented that this would be a typical oracle function, i.e. an implementation issue, and Lars-Erik agreed that there should not be any difference to RFC 3095 in this respect. Zhigang pointed out that one must be confident that the decompressor has the correct context present. Carsten responded that in 3095 this is handled by the sequence number, which gives the context (or candidate contexts) to be used for decompression. That is an issue for profile specification, nothing to be captured by the notation. Carsten then outlined a direction for moving forward. We should write down both requirements and non-requirements for the notation, and work from those. To get some more bandwidth and get this work going, we may need to consider having an interim meeting, as we had when we created RFC 3095. But first we should continue with the current discussions on the mailing list, which so far have been really helpful for bringing people forward towards a common understanding of concepts and principles. Drafts: draft-ietf-rohc-formal-notation-01.txt draft-ozegovic-mornar-dccp-epic-00.txt * Summing up (Bormann / Jonsson) Let's continue the discussions that we are now having on the mailing list. People who have not been involved are encouraged to read the notation draft, as well as the mail discussions from the last 2 weeks. See you in Vienna, at the