Current Meeting Report
Slides


2.7.16 Robust Header Compression (rohc)

NOTE: This charter is a snapshot of the 52nd IETF Meeting in Salt Lake City, Utah USA. It may now be out-of-date. Last Modified: 19-Nov-01
Chair(s):
Carsten Bormann <cabo@tzi.org>
Mikael Degermark <micke@sm.luth.se>
Transport Area Director(s):
Scott Bradner <sob@harvard.edu>
Allison Mankin <mankin@isi.edu>
Transport Area Advisor:
Allison Mankin <mankin@isi.edu>
Mailing Lists:
General Discussion:rohc@cdt.luth.se
To Subscribe: majordomo@cdt.luth.se
In Body: subscribe
Archive: http://www.cdt.luth.se/rohc/
Description of Working Group:
Note: Erik Nordmark (nordmark@eng.sun.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.

Goals and Milestones:
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.
May 00   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.
Jul 00   Requirements for IP/TCP header compression submitted to IESG for publication as Informational.
Done   Resolve possibly multiple IP/UDP/RTP compression schemes into a single scheme.
Aug 00   Submit I-D on IP/TCP header compression scheme.
Sep 00   Layer-2 design guidelines submitted to IESG for publication as Informational.
Done   IP/UDP/RTP header compression scheme submitted to IESG for publication as Proposed Standard.
Dec 00   IP/TCP compression scheme submitted to IESG for publication
Jan 01   Possible recharter of WG to develop additional compression schemes.
Internet-Drafts:
Request For Comments:
RFCStatusTitle
RFC3095PSRObust Header Compression (ROHC)
RFC3096 Requirements for robust IP/UDP/RTP header compression

Current Meeting Report

 Minutes of the two ROHC WG sessions at IETF 52
==============================================

Grand America Hotel, Salt Lake City
Thursday morning and afternoon, 2001-12-13

Reported by: Lars-Erik Jonsson
Note takers: Christian Schmidt, Mark West, Lars-Erik Jonsson and Hans Hannu

Slides are available at http://www.dmn.tzi.org/ietf/rohc


First session, 0900-1130
------------------------

* WG admonishments

Bormann quickly reviewed the IETF working group principles, the IETF standardization process and the IPR rules defined by RFC 2026. Notable quote: "If you know of a patent application for a technology you are contributing, you have to tell or shut up entirely."


* WG status

The current charter milestones were quickly reviewed. The current charter only covers RTP and TCP issues, of which the RTP part is done, while the TCP part is still far from complete. However, most important is to get the charter updated, but that discussion was postponed to the end of the meeting.

There was a question from the audience whether a new profile for UDP-Lite compression would be needed. The answer was that it is not yet clear whether UDP-Lite can be covered by the normal UDP profiles, or if separate UDP-Lite profiles are needed. If we go with the first case, updated versions of current UDP profiles (incremented profile version numbers) would be able to support both UDP and UDP-Lite. The work for UDP-Lite is included in the proposed new WG charter.


* Agenda bashing

Bormann presented an agenda proposal for the two sessions, slightly modified from the original agenda so that the Signaling Compression issues could be discussed in the morning session, since the second session collided with a SIP session. There were no comments to the proposed agenda.


* Document status: Carsten Bormann

- draft-ietf-rohc-rtp-lower-layer-guidelines-02.txt

The RTP lower layer guidelines document originally completed WG last-call in December 2000 (sic!), together with the other RTP documents. However, the document bounced back from the IESG at the time because it included prescriptive text, which is only allowed in standards-track documents. After various discussions on how to handle this document, the prescriptive text was rewritten in non-normative form and an updated draft is now available. To cover for some minor comments on the language, the document will be cycled once more and then a second WG last-call can be initiated, hopefully during December.

- draft-ietf-rohc-over-ppp-04.txt

ROHC-over-PPP completed WG last-call on August 31, and an updated version is now available that includes some minor clarifications requested during last-call. The document was submitted to the IESG on the 17th of November, for publication as Proposed Standard. This document is needed for ROHC to be used in 3GPP2.

- LLA drafts

Requirements: draft-ietf-rohc-rtp-0-byte-requirements-01.txt
LLA profile: draft-ietf-rohc-rtp-lla-03.txt

The requirements document passed WG last-call on August 30, while the LLA profile has been revised several times during the last months to reflect the ongoing discussions on R-mode support. The last version, which does not allow NHP transmission in R-mode, completed WG last-call on December 6, and has now been submitted to the IESG together with the requirements document. Work goes on with a separate document for 0-byte support in R-mode, and a first draft on that should be available shortly.


* Input from "ROHC in the desert": Peter Kremer

A second bake-off, ROHC in the Desert, was held 13th to 20th of November in Tucson, Arizona, hosted by Effnet. Three implementations were available from Effnet, Ericsson and Siemens. Unfortunately, Nokia could not participate due to visa problems.

ROHC over PPP (without negotiation) and ROHC over UDP where tested. For profile 1, basic communication with various mode transitions where tested (with the corrected CRCs), and focus was further on robustness aspects. The packet streams used forced the compressor to handle changes in IP-ID, TS_STRIDE, TTL, TOS, etc. Also profile 0 (uncompressed) was tested. In all cases, IPv4 was used, which means that we still have not tested compression of IPv6. Some minor additional issues were found, but the overall conclusion was that RFC 3095 appears to be a solid specification.

Lars-Erik expressed doubt that the modification to the mode transition procedure, proposed in London and now part of the implementors' guide, will work in case of losses. Micke argued that this optimization should be done, but there might be things missing in the current proposal. The discussion will be taken to the list. The implementors' guide will continue to collect issues and clarifications from the interoperability tests. Comments and inputs are welcome.

Ericsson offered to host a third interop, either in Sweden or in Hungary. The time has not been set, but April 2002 seems to be reasonable. The intent would be to test all four profiles in both IPv4 and IPv6, including currently missing compression mechanisms, such as list compression. For ROHC-over-PPP, also the negotiation part will be tested, and of course all robustness aspects will be further tested and evaluated. It was noted that the pace of the testing so far might not be as fast as had originally been hoped, but things are moving along and good progress is being made.


* Signaling compression

- Introduction

Carsten Bormann gave a background and introduction to the issue of signaling compression. The motivation is to reduce connection setup delays for e.g. SIP setup over low bandwidth links (setup of a SIP call takes e.g. about 8 seconds in 3GPP networks), and also minimize bandwidth stealing for in-call usage of e.g. SIP. The point is NOT to save raw bandwidth, even though this is a welcome side effect. It is noted that whilst SIP is the current target for compression there are other text-based protocols (SDP) and other signaling protocols (e.g. RTSP, DNS, RSVP) that could be compressed. Some of the contents of these messages may also be encrypted, which would have implications for compression.

The ROHC WG has so far identified at least two components that together will constitute a complete solution, one protocol part and one compression algorithm part, but the boundary between these two is rather movable. One thing that makes this work difficult is that the kind of compression methods we are using here constitute an IPR rathole, and this must be considered when defining a solution.

Carsten further outlined a proposed solution approach, based on previous discussions on the mailing list and available proposals. The basic idea is to define a "universal" decompressor as a virtual machine, and let the compressor tell the decompressor how to perform decompression, based on a pre-defined set of decompressor instructions. It would then not be necessary to standardize any specific compression algorithm, and all decompressors would be able to interoperate with any compressor. Around the universal decompressor, a simple minimal protocol is defined to support per-packet compression over UDP and per-stream (dynamic) compression for TCP connections. Extensions to allow dynamic compression also for UDP and compressor-decompressor state sharing would be defined separately since these are probably covered by IPR. Jonathan Rosenberg proposed to use the name "decompressor virtual machine" instead of "universal decompressor", and there was agreement to call it UDVM (Universal Decompressor Virtual Machine).

- The universal decompressor

Richard Price held a short presentation about the Universal Decompressor, now known as UDVM. The UDVM is comparable to a Java Virtual Machine, but optimized specifically for decompression algorithms, which makes the UDVM very compression efficient while still not requiring much working memory (typically about 8 kilobyte). The decompression algorithm may be downloaded to the decompressor during negotiation of compression, sent as a standalone packet before first compressed message, or appended to the front of the first compressed message. Price stated that the current UDVM has been proven to be compatible at least with the LZ77, LZSS, LZW, DEFLATE, LZJH and EPIC algorithms. The presenter asked whether more tokens, for e.g. bit manipulations, should be added, and it was agreed to do so for increased flexibility and generality, since the price of more tokens is neglegible.

More information about performance of the UDVM was requested, and Price answered that there is not much available at the moment, but they are currently working with this and the results will be published.

Degermark brought up the issue of whether we need to have some kind of version number for the UDVM, and it was agreed that versioning should be provided, but there was no conclusion on how to do that.

The rest of the UDVM discussion was about how to negotiate usage of compression. Rosenberg claimed that this should be done by SRV records indicating support for compression. However, this is a separate issue that requires some additional standardization to be done. Rosenberg further insisted on not attempting to use SIP REGISTER for negotiation, which has been proposed by some parties.

- Logical SigComp overview and extended operations

Hans Hannu briefly outlined the logical structure of the envisioned SigComp solution, based on the UDVM approach. An architecture was presented, showing the modularity of the solution based on a simple core that can be extended with additional mechanisms for improved compression efficiency. Hannu further explained in more detail the extended operation, shared compression, implicit acknowledgements, and explicit acknowledgements. Rosenberg questioned whether dynamic compression could at all work over an unreliable channel, because it would not be enough to know that a message has been received by the decompressor. The compressor would also have to know what has not been received, since the state would change when a message is received, independent of whether the message is really used for compression or not. Bormann answered that this must be handled by the compressor, which controls how the decompressor works. The compression algorithm must be able to handle this, which should be simple if each message is preceded by a state reference, and the compressor can not use state that has not been acknowledged.

Other questions that were briefly discussed where how to enable the use of extended operations, which is something that has to be further investigated, and whether we need some decompressor failure feedback, which was strongly supported to have.

- The IPR strategy

Bormann further elaborated on the IPR strategy previously outlined. It is obvious that there are lots of patents out there that might have relevance to this work and we do not know about all potential patents, but we should still do our best to avoid making a solution dependent on the patents or potential patents we do know about. The strategy for this would be the following:

1) The UDVM goes into one draft ("IPR free") for Proposed Standard
2) A SigComp framework draft with simple protocol ("IPR free") for PS
3) An extended operations draft for Informational
4) Additional UDVM decompressor drafts for Informational

There were discussions on whether 3) would have to be a Standards Track document. Degermark suggested that we should try to design the universal decompressor in such a way that an extended solution should not require additional standardization. Bormann agreed that our initial assumption should be that it is possible to provide hooks in the base protocol and UDVM to support this, but if we fail to do that we will have to reconsider and make also 3) a Proposed Standard document.

Richard Price is editor for 1) and 4), while Hans Hannu is editor for 2) and 3).

- Requirements

Our requirements for SigComp were discussed, and Bormann pointed out that we have no clear numbers for what is good enough. Hard figures are difficult to get and we should just do as good as we can. People notice delays, so we should keep them down.

The figures presented by Richard were called into question and it was agreed to define a common call sequence and static dictionary to test. Lawrence Conroy noted that we already have a call sequence defined in our requirements document, and it was agreed to add also a static dictionary to that document. Hannu promised to submit an updated version of the draft by Christmas.

- Security issues

The UDVM imposes a number of security issues to be considered. Compared to header compression, there are two key differences that make the security aspects more demanding. First, we are basically downloading a program to the decompressor, instead of having a standardized decompressor. Further, we are operating end-to-end instead of hop-by-hop, and malicious messages can much easier be inserted between compressor and decompressor.

Bormann outlined the various security requirements that will have to be fulfilled. The first issue is to secure the decompressor state, avoiding snooping into state of other users, and prevent unauthorized changes to the decompressor state. Authentication at the SIP layer will catch bogus messages, but that would still not protect the decompressor state. One possibility could be to have feedback to the decompressor to indicate invalid messages, and the decompressor could then do a state "rollback". Other aspects that must be considered are denial of service attacks, using the decompressor as amplifier and filling it with useless state, and possible halting problems. We will probably have to limit the number of instructions allowed for each decompression.

It was pointed out that the security issues might not be relevant for 3GPP, but that statement can probably by questioned. However, Bormann pointed out that this is the IETF and it is not sufficient to consider just what 3GPP thinks or needs in this regard. We will still have to handle all the security aspects properly.

Bormann will write an additional document to discuss the security issues and outline how these aspects should be handled.


Second session, 1530-1730
-------------------------

* Organizational announcement from the AD

Scott Bradner announced that Mikael Degermark is stepping down as a ROHC WG co-chair. Lars-Erik Jonsson is the new co-chair together with Carsten Bormann. Degermark transferred his blue dot to Lars-Erik and promised to continue being an active member of the WG.


* TCP requirements and scheme

- TCP behavior document

Mark West presented a first attempt to analyze the behavior of the various fields in TCP, which has been provided in a new draft. Most issues are straightforward, but some are more tricky. The TCP checksum could be used to verify correct decompression, but the checksum is not that strong, it must be calculated also over the payload (CPU load!), and it does not verify all IP fields. Degermark argued for an additional checksum within the header compression scheme, not necessary covering the uncompressed header, which would be a solution that might be covered by IPR. One other issue is that the type of sequence number mapping used with RTP can not as easily be used for TCP, since we do not know in general how much the numbers change. Further, we have the issue of how to handle new extensions to TCP, e.g. how to compress currently unused TCP fields, different behavior for different ECN implementations, and aspects related to advantages of implementing shared compression between a co-locatedcompressor-decompressor pair. Finally, we have the issue about context re-use and context sharing, to boost performance for short-lived TCP transfers. This might easily become very messy.

- TCP requirements document

Jonsson quickly recapitulated the TCP requirements. In the more recent version, the requirements for robustness have been clarified, but the draft should be cycled one more time to become even clearer. Discussions took place about reordering between compressor and decompressor, which basically is a ROHC framework issue. Bormann pointed out that it is important for tunnels to allow reordering, but it could be made a requirement for the channel to provide an indication of reordering, since that would make things much easier for the compression protocol, and tunneling protocols usually provide this. There was agreement on adding words about this to the draft. Gorry Fairhurst requested clarifications regarding what are musts and what are shoulds. Jonsson agreed to look at that, and Fairhurst promised to provide some concrete inputs. The room agreed to issue a call-for-freeze for this document after next update. The freeze call will be issued to ROHC, TSVWG, and PILC.

- Role of EPIC

West gave his view of EPIC (Lite) and how this should be used for future ROHC profiles. The presentation seemed to remove several question marks among the audience, but there are still issues that require further clarifications. Degermark asked how e.g. RFC3095 list compression can be handled by EPIC, and West answered that this should be possible. West further referred to the available pseudo-code. Jonsson requested a clearer view of how EPIC relates to the ROHC framework, and Bormann concluded that there seems to be an uneasy feeling in the WG whether we can control the interface between EPIC and other parts of the protocol. We have to make sure that this interface is clear and simple, and we have to evaluate if the gain from this is worth the work. Bormann therefore requested better descriptive text and encouraged further discussions on the mailing list. The EPIC authors have also been asked to make a simple RTP profile with EPIC, as an example. This will be used for further evaluation of the usability of EPIC.

- Merging of TCP proposals

Qian Zhang gave a status update for the merging process of the TCP proposals. Two drafts are still available, but these will soon be merged completely. In both drafts, EPIC Lite is used for the compressed header formats. Both drafts also pay much attention to the window estimation mechanism. Jonsson noted that this must not (and should therefore not) be defined as a mandatory part of the protocol, but could be an implementation optimization. Zhang pointed out that there are no known IPR considerations for the current proposals.

- Requirements unmet so far

The most important requirement not addressed so far is the issue of context sharing and/or context re-use to boost performance for short-lived TCP transfers. The room agreed that this must be addressed, but it is not a simple issue. Current solutions do not support compression of TCP options (SACK, timestamp), but West promised to have this included very soon. Jonsson further addressed the issue of modes for TCP compression. RTP ROHC needs modes to control the decoding of the most compressed header, UO-0/R-0, which has no space to convey additional information. TCP ROHC will not compress the header down that much. We should consider what modes mean for TCP compression, and which are useful. Price noted that there are some IPR issues related to the 3095 modes, which also motivates an investigation of this. Qian noted that the current TCP drafts assume the same modes as in RFC 3095.


* SCTP requirements

Christian Schmidt presented some initial material on SCTP compression requirements, of which much has been inherited from the TCP requirements. Compression of SCTP is motivated by the future use of SCTP in mobile environments, the inefficient protocol headers used, and the TCP-like characteristics of SCTP, which should make it easier to define when we are already doing TCP. Difficult items with SCTP are the extensibility, the multi-streaming aspects, and of course the SCTP specific protocol structure.

Bormann suggested that we should start working with SCTP to have more material for evaluating EPIC as a tool for future ROHC profile definitions. The room agreed and also agreed on appointing Schmidt as requirements editor.


* ROHC RTP MIB

Juergen Quittek introduced the first version of the ROHC MIB. As was intended, the presentation raised a number of questions, e.g. what is meant with supported headers table, what an interface is, etc. It is clear that the MIB would benefit from more discussions about the ROHC architecture, and from technical feedback from the ROHC WG. This should be taken to the mailing list.

Mark West was appointed as technical expert for the ROHC issues in MIB development.


* ROHC RTP - The way to draft standard

Bormann explained that the chairs suggest writing a new document to define how the content of RFC 3095 be split in framework and profiles, which is a separation that has already been agreed should be done before going to draft standard. This document can then be discussed and agreed upon before we start the real surgery for Draft Standard.


* Rechartering

Bormann presented the content of a proposed charter update, to be discussed with the AD's. The proposed charter includes a ROHC SCTP profile, signaling compression, and UDP Lite support (see slides). There was general agreement in the room that the proposed charter was a reasonable work plan. The complete charter proposal with all goals and milestones can be found at:
http://www.cdt.luth.se/rohc/msg03182.html

Slides

Agenda
TCP Work Items