NOTE: This charter is a snapshot of the 50th IETF Meeting in Minneapolis, Minnesota. It may now be out-of-date. Last Modified: 14-Mar-01
Carsten Bormann <email@example.com>
Mikael Degermark <firstname.lastname@example.org>
Scott Bradner <email@example.com>
Allison Mankin <firstname.lastname@example.org>
Allison Mankin <email@example.com>
To Subscribe: firstname.lastname@example.org
In Body: subscribe
Note: Erik Nordmark (email@example.com) is serving as the Technical Advior to the group.
Due to limited bandwidth, IP/UDP/RTP/TCP packets sent over cellular links benefit considerably from header compression. Existing header compression schemes (RFC 1144, RFC 2508) do not perform well over cellular links due to high error rates and long link roundtrip times, particularly as topologies and traffic patterns become more complex. In addition, existing schemes do not compress TCP options such as SACK or Timestamps.
The goal of ROHC is to develop header compression schemes that perform well over links with high error rates and long roundtrip times. 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 header compression scheme must:
* assure that when a header is compressed and then decompressed, the result is semantically identical to the original;
* perform well when the end-to-end path involves more than one cellular link;
* support IPv4 and IPv6.
Creating more thorough requirements documents will be the first task of the WG.
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.
Finally, working group documents will address interactions with IPSEC and other security implications.
Submit I-D on Requirements for IP/UDP/RTP header compression.
Submit I-D of layer-2 design guidelines.
Submit I-D(s) proposing IP/UDP/RTP header compression schemes.
Submit I-D of Requirements for IP/TCP header compression.
Requirements for IP/UDP/RTP header compression submitted to IESG for publication as Informational.
Requirements for IP/TCP header compression submitted to IESG for publication as Informational.
Resolve possibly multiple IP/UDP/RTP compression schemes into a single scheme.
Submit I-D on IP/TCP header compression scheme.
Layer-2 design guidelines submitted to IESG for publication as Informational.
IP/UDP/RTP header compression scheme submitted to IESG for publication as Proposed Standard.
IP/TCP compression scheme submitted to IESG for publication
Possible recharter of WG to develop additional compression schemes.
Minutes of the ROHC working group
Reported by Carsten Bormann
Notes taken by Jon (Taz) Mischo and Christian Schmidt (thanks!)
Slides can be retrieved from:
The ROHC WG met once at the 50th IETF (Friday, March 23 at 0900-1130).
The meeting was chaired by Carsten Bormann and Mikael Degermark.
* Chair admonishments and agenda bashing
Bormann started the meeting by quickly reviewing the IETF working group principles, the IETF standardization process and in particular the IPR rules defined in RFC 2026.
Reviewing the working group charter, he noted that the WG had achieved all of its goals except for the TCP header compression work which is still in its early stages.
No changes were proposed to the agenda (however, the WCDMA trial presentation was struck from the agenda later).
* ROHC RTP status
** Document status
*** In publication:
Bormann reported that draft-ietf-rohc-rtp-09.txt (ROHC framework and four profiles) and draft-ietf-rohc-rtp-requirements-05.txt (RTP ROHC requirements) were approved by the IESG on Feb 23. 3GPP has already incorporated the specification by reference in their Release 4; 3GPP2 does not have a release pending before fall but also has decided to pick up ROHC (see 3GPP2 report below).
*** To be completed:
Bormann reported that the RTP lower layer guidelines document draft-ietf-rohc-rtp-lower-layer-guidelines-01.txt, which completed WG last-call in December 2000, is currently stalled due to AD comments that the prescriptive style of the document does not match its intended publication as informational RFC. Bormann asked for input on whether to request publication as informational nonetheless, request publication as BCP, edit the document to be appropriate as informational, or any other ideas. Jonsson said he is in favor of publication as a BCP; AD Mankin agreed that BCP may be a match.
This will be discussed further after the meeting.
* Early experience with RTP ROHC (20 total)
** Results from an early implementation: Mark West
West reported about an EPIC-based implementation of RTP ROHC, which needs about 0.8 MIPS for ROHC and EPIC processing of a GSM EFR voice stream. The time for compressing a header is between 26 and 41 us, of which about 16 us are spent for actually generating the header, plus 8 us for the header CRC generation (optimized according to the ROHC specification); decompression 56 us (18 us unpacking the data). These numbers are for a 270 MHz Ultra 5. The asymmetry in processing time was described as an implementation issue. West had no comparison to UDP/IP compression.
** Bay-Cough -- When? Mark West
West proposed a Bay-Cough (interoperability test event) for the week before London IETF in Southern England. About 6 parties expressed interest.
* ROHC-over-X documents
Bormann noted that the only ROHC-over-X document under consideration by the WG currently is the ROHC-over-PPP document, which is intended both to make ROHC immediately useful in PPP environments and as a model document for other ROHC-over-X specifications. For the latter purpose, certain considerations have been added that are not strictly necessary for a ROHC-over-PPP document.
** ROHC over PPP (Standards track): Carsten Bormann
Bormann quickly reviewed the changes in draft-ietf-rohc-over-ppp-01.txt (ROHC over PPP): using the two-byte profile identifier introduced recently in RTP ROHC, and using two different protocol identifiers for small-CID and large-CID packets in order to make packets self-describing and avoid the ambiguity the previous version had in case IPCP and IPV6CP negotiated different CID sizes. He noted that, due to the shared (between IPCP and IPV6CP) CID space, there still is an ambiguity on when exactly the context information should be discarded. One solution might be to discard IPv4 contexts only when IPCP goes down and IPv6 contexts when IPV6CP goes down. Apart from this open issue, the room agreed that the document is ready for WG last call.
** 3GPP2 report: Lars-Erik Jonsson
Jonsson reported from the 3GPP2 TSG-P meeting immediately preceding the IETF. 3GPP2 has adopted RTP ROHC as mandatory header compression scheme for multimedia applications. For voice applications, 3GPP2 is looking at 0-byte compression methods. Actually, two models are being envisioned for this: A transparent 0-byte header-compression scheme modelled on ROHC, and what Jonsson termed a "Hybrid" model, where header generation/termination takes place on the fixed network side based on information provided from the wireless side over control channels. The latter approach, which is related to what was previously discussed under the name GEHCO, was deemed as 3GPP2 specific.
** Requirements: Lars-Erik Jonsson
Jonsson explained that due to the short time between meetings, only a non-official document could be made available to the ROHC WG based on 3GPP2 TSG-P input:
[A revised version of this document bas been submitted after the meeting as draft-jonsson-3gpp2-rohc-rtp-0-byte-requirements-00.txt] This document is phrased as a revision of the ROHC RTP requirements document. The main requirement is efficiency: During normal operation, no headers should be sent for a majority of the packets. The delay requirement needs to be clarified into an algorithm delay and possibly an additional buffering delay that is independent from the compression algorithm. A coexistance requirement was added that requires 0-byte to be ROHC compliant. Finally, for CDMA2000, the scheme must be able to optimally support EVRC and SMV. Jonsson added that 3GPP2 also would like to see maximum reuse from the 0-byte scheme in their own Hybrid scheme, so it might be seen as a requirement that 0-byte does not prevent this.
Degermark commented that 0-byte compression requirements might differ for codecs that use silence suppression. Francis argued that there should be no prohibition in the draft against a hybrid model. Jonsson argued that this was not an IETF issue, as the ROHC WG is chartered to do semantically equivalent compression. Francis argued that semantically equivalent does not mean bit-wise identical, and cited a sentence from the RTP ROHC requirements document that indicates that the WG has not found any example where semantically equivalent did not amount to bit-wise identical. Bormann pointed out that this phrase was erroneously left in draft-ietf-rohc-rtp-requirements-05.txt and will be removed before publication. Returning to the issue whether the ROHC WG work on 0-byte should also be made applicable to the hybrid model, Degermark commented that it is hard to know what that actually means without predicting the Hybrid model work. Bormann commented that the WG should make clear that we do not intend to generate an incompatible solution.
Jonsson to revise the requirements document.
** Solutions: Lars-Erik Jonsson
Jonsson very quickly presented draft-jonsson-rohc-lla-rtp-00.txt, A Link-Layer Assisted ROHC Profile for IP/UDP/RTP. This is an extension to RTP ROHC, sending "no-header packets" in most cases. This requires layer 2 information about packet losses and packet type identification.
Degermark asked how this applies to large and small CIDs. Jonsson replied that this does not matter as there is no header in the no-header packets and thus no difference in header format (a no-header packet always belongs to CID 0).
** Should we ask to take up 0-byte as a ROHC WG item?
Bormann asked whether the ROHC WG should take up 0-byte as a WG item. Le, perceiving a lot of fuzziness, proposed to clarify the requirements and assumptions before considering protocols and solutions. It was pointed out that, to meet a 3GPP2 deadline in September 2001, requirements would have to be nailed down before summer and a finished spec would be needed before the I-D deadline in July. Bormann noted that this was an accelerated schedule, as one would normally expect to work a year on such a proposal. Jonsson commented that, as some work was already done, this could go faster.
There was no clear consensus in the room on whether to try for the 3GPP2 timeline or not. Mischo commented that, if the ROHC WG doesn't do it in time, 3GPP2 will do it themselves.
The discussion was deferred to the last point of the meeting, the rechartering discussion.
** requirements: Lars-Erik Jonsson
Jonsson presented draft-ietf-rohc-tcp-requirements-00.txt, Requirements for ROHC IP/TCP Header Compression, as a delta to the RTP ROHC requirements document. In particular, compression should also be possible if SYN and FIN bits are set, and common TCP options should be compressed (SACK, timestamps). The scheme should be efficient for short-lived TCP transfers. It must fit into the ROHC framework.
While robustness is not the primary goal for TCP header compression, the question is how much robustness is needed. Bormann commented that the PILC WG is recommending persistent ARQ only in certain cases, and there are links without persistent ARQ, so some degree of robustness was still required. Degermark argued against trying to optimize running TCP over lousy links; in particular, he stated a requirement for a residual bit error rate close to 0 for TCP, which would allow the compression scheme to focus on packet losses (as opposed to lower layer damage to packets). Degermark pointed out that the requirement not to deliver (undetectably) damaged packets from TCP ROHC is much stronger than for RTP ROHC.
Bormann provided a slide with his own view of the requirements. He pointed out that the TCP work already is in the WG's charter. There is no TCP header compression specification available that efficiently compresses "modern TCP" (i.e., with SACK, ECN, ...). The world is looking at the ROHC to generate this -- this leads to a few high-level requirements. In particular, the scheme must be applicable in the wide area Internet (not just on error-prone radio links) -- it needs to attempt to be as future-proof as possible, and, in particular, only unencumbered solutions will be acceptable to the Internet at large.
Various comments were made that there is no way to actually ensure a solution is patent-free. Bormann agreed, but added that we can spend effort on this goal to achieve a high degree of confidence that there is no IPR covering the solution. There was a rough consensus in the room that this was the right way to proceed.
** TCP solution proposals
Zhang presented the updates in draft-ietf-rohc-tcp-taroc-01.txt. (Bormann noted that, due to a mailer glitch at Microsoft, this draft did not make it to the Internet-Drafts editor in time; it was accepted by the chairs as an input document nonetheless and put on the ROHC WG site http://www.dmn.tzi.org/ietf/rohc/.) Zhang said that the new draft improved the accuracy in tracking the TCP congestion window, increased the efficiency of window based LSB encoding, and provided more realistic simulation conditions (BER 10**-5 to 10**-8; this was later clarified to be the input BER to a BER-based packet loss process).
Tüxen asked whether this solution is IPR free. Zhang repeated from her previous presentation that there is a patent application. She said that the possibility to make it freely available was under investigation. Bormann added that, as long as we don't know whether a technology will be made available unencumbered, we should continue looking at it.
Degermark asked whether the window estimation technique would still work e.g. with TCP Vegas. Zhang answered that this was not tested, but a new window estimation technique could always be added. Degermark clarified that, as it is not known which version of TCP is used at the ends, the question really was whether the window estimation technique would work with any end system TCP implementation, and would not generate bad headers in any such case.
* Encodings for future ROHC profiles
** EPIC update
Price gave examples on the use of EPIC to encode compressed headers for TCP, SCTP and all-layer header compression, as well as a 0-byte solution that is similar to Jonsson's solution.
Le asked how dependent the efficiency of EPIC is on the correct definition of the probabilities. Price answered that, even in case of probabilities that haven't been chosen optimally, the efficiency is still very high.
** Should we ask to take up EPIC as a ROHC WG item?
Bormann gave his view of the advantages and disadvantages of an EPIC-like approach. Among the advantages he counted no longer having to carve out packet headers by hand any more, and the "provably optimal" property of EPIC (if the probabilities are right). Disadvantages could be: implementation complexity, runtime overhead -- the WG is lacking information on this. Also, Bormann said, the WG should learn from the ASN.1 PER fiasco: there is a need for interoperable implementations. Finally, with respect to IPRs, Bormann underlined the importance of having at least a basic scheme that is unencumbered, i.e. which could be used without IPR issues.
In response to the latter, Price indicated, that there might exist a less efficient, more computing intensive EPIC-like solution, which is not covered by the EPIC IPRs. This EPIC-like solution would be compatible with EPIC.
Bormann asked (again, as the audience explained) whether EPIC was to be pursued as a WG item. There was consensus in the room to do this.
* Signalling compression
Hannu presented an update on the signalling compression requirements, draft-hannu-rohc-signaling-cellular-01.txt (Application signaling over cellular links). This is motivated by the observation that call-setup times for all-IP wireless voice can be on the order of multiple seconds. Hannu said that Signalling compression should be transparent, should co-exist with ROHC framework as a new profile, and should work under all link conditions, without adding delay, with minimal error propagation.
Hannu very briefly presented draft-hannu-rohc-roger-00.txt, RObust GEneric message size Reduction (ROGER). This is a dictionary-based binary compression method defined as a profile under ROHC.
** Should we ask to take up signalling compression as a ROHC WG item?
Degermark posed the question whether signalling compression should be done hop-by-hop or end-to-end and said that, if it is done hop-by-hop, this could become an item for the ROHC WG, as it seems to be needed and it would fit well into ROHC. If its end-to-end, other working groups would be more appropriate to do this work. Hop-by-hop compression makes it easier to use redundancy from sharing the dictionary between sessions, but compression might be better done end-to-end (and what about IPCOMP, TCPFILTER and friends?).
It was questioned whether hop-by-hop compression remains useful once SIP gets secure. Price commented that, on the other hand, end-to-end SIP compression is not possible in every case, either.
Other audience comments asked why, if the scheme is generic, the talk is about specific application protocols, and remarked that RSVP is another important protocol to consider in signalling compression.
Finally, the point was made that SIP compression is urgently needed. If it will be not done in ROHC it will be done in another WG or elsewhere. Conroy added that there are a lot of documents in GERAN talking about this. It is quite complicated. You can't do it end-to-end, you can't do it soon, because of ongoing work on SIP.
Bormann summarized the sense of the discussion that the work in signalling compression should focus on the requirements and assumptions now. There was rough consensus in the room for starting work on requirements and assumptions.
The point was made that this work may be out of scope for a header compression WG. This issue will be brought to the ADs by the WG chairs.
The room agreed on the following timelines for a rechartering proposal:
-- Lower-layer Guidelines: submit for ____ RSN
WG last-call April 2001, submit May 2001
-- 0-byte IP/UDP/RTP
Try for 3GPP2 deadline (September 2001)?
Requirements and Assumptions: I-D April 2001
WG last-call July 2001, submit August 2001
-- UDP-lite profile?
Try for 3GPP deadline (December 2001)?
Requirements, Specification: I-Ds April 2001
WG last-call August 2001, submit September 2001
Need to be done before TCP if we want to use it for that
Decide: Interoperable implementations by Dec 2001?
-- TCP (existing item, new dates)
Requirements and assumptions frozen: August 2001 (London)
draft-ietf-rohc-tcp-00.txt: September 2001
WG last-call March 2002, submit April 2002
-- Signaling compression
Focus on call-setup time issue
Requirements and assumptions draft: August 2001
Start protocol work *if* we decide to go on (August 2001)
Initial I-D: October 2001
WG last-call Jan 2002, submit Feb 2002
-- Draft Standard by 1Q2002
Separate documents (Framework, 4 profiles): October 2001
WG last-call Jan 2002, submit Feb 2002
Leave for next rechartering (look again in London)
ROHC Implementation Experience
Zero--byte ROHC RTP
Requirements for ROHC TCP
TAROC: TCP-Aware RObust Header Compression Scheme
Generating New Profiles for ROHC