ROHC WG Interim Meeting Notes Stockholm, SE, 2000-05-29 and 2000-05-30 Reported by: Carsten Bormann based on notes from Tmima Koren and Andrew Allen Slides are at http://www.dmn.tzi.org/ietf/rohc/ The chairs opened the meeting by thanking Nokia for hosting this interim meeting. Bormann gave a quick re-cap of the operations of an IETF WG, similar to the one presented in Adelaide, stressing the IPR provisions in section 10 of RFC 2026, followed by a re-cap of the WG charter and milestones and the goals set on the mailing list for the interim meeting. * draft-ietf-rohc-lower-layer-guidelines-00.txt Svanbro presented the lower layer guidelines document. There were few changes from draft-svanbro-rohc-lower-layer-guidelines-00.txt, the main one being the change to a WG document (draft-ietf-*). This document was discussed in the light of a message sent by Kalliokulju on the mailing list on May 25 that summarized a number of questions from 3GPP TSG RAN WG2. 3.1.4 Handling of header size variations Discussion revealed that the requirement to control the header size variation repeatedly expressed by the groups working on lower layers really was about the variation of packet sizes -- L2 can be optimized if it knows them ahead of time and the number of them is limited. However, with issues such as varying sizes of CSRC lists, strict control of the sizes seems impossible. There was a suggestion that L2 notify ROHC about "good" sizes. ROHC can then e.g. utilize more bits if it must use a larger size header. However, if ROHC had to produce headers of 'good' sizes only, this would in all likelihood require padding at the ROHC level. Padding is best performed at lower layers, however ROHC may have the bits needed (for efficient indication whether padding is present) available in its header coding scheme. More discussion is required on this matter. For the large headers typical of the "full-header" phase (~40 bytes for IPv4, ~60 for IPv6), one issue also seems to be whether these headers are sent as separate initialization packets or combined with their payload. In addition, small stand-alone feedback packets may be required on the return-channel. (Later on, consensus developed that it is a good idea to have a format for the initialization packets that allows sending the static part of the header as a separate packet.) There was agreement that the distribution (both in terms of probabilities and in terms of the temporal sequence) of packet sizes to be sent by ROHC schemes should be documented and be made available to the cellular working groups. 3.2.1 Handover procedures There was agreement the WG need not be concerned with soft handover. For hard handover, two issues need to be clearly separated: 1) good performance in the presence of handover-induced breaks in connectivity ("speech gaps"). It was not clear to the WG how long these gaps were likely to last -- Svanbro cited the 3GPP spec which calls for at most 150 ms, but said that realistic systems would have values around 80 ms. A ball-park value of 100 ms seems a good bet, but this requires further study. One interesting issue is whether ROHC can obtain advance or post-facto notice from the lower layers that hard handover is occurring. In a handset, this information may (but will not always) be available in advance; at the infrastructure side, often only post-facto information will be available, if at all. Also, if available, ROHC could use a-priori information about what is the longest handover gap to be assumed likely (in number of packets and/or in real time). 2) state transfer during "handover" between header compressors or decompressors (which may or may not be related to radio handover). It is clear that the means of this state transfer is out of scope for ROHC (part of the handover protocol). However, *if* the means are present in a radio access network, it may be beneficial for ROHC to support the state transfer. If not, or if there are timing issues with the state transfer, compression may be resumed by going through reinitialization (full headers). The WG then discussed Kalliokulju's questions: There was agreement that ROHC compression efficiency can benefit from unequal error protection (UEP) and/or unequal error detection (UED), but that ROHC can work without these lower layer functions. It remains for the ROHC WG to evaluate the benefits of UEP/UED for ROHC and for the cellular working groups to evaluate the benefits/costs for the radio layer. 3GPP does not currently have UEP/UED. Bormann asked how likely UEP/UED was to become available in 3G standards if we "asked" for it; there was no clear answer, so UEP/UED cannot be assumed present. A long discussion of residual bit error rates followed. There was consensus that, when good spectrum efficiency is desired, it is counterproductive to require very good residual bit error rates from the lower layers. For 3GPP, TS 23.107 version 3.1.0 (QoS concept and architecture) has defined residual bit error rates for different traffic classes. For the conversational class, it lists 5E-2, 1E-2, 1E-3, to 1E-4. Version 3.2.0 (March 2000) adds 5E-3 and 1E-6. Obviously, the higher error rates are less useful in a ROHC environment -- there is a need for a defined highest bit error rate at which ROHC is expected to be efficient (but it should not break spectacularly when that happens to be exceeded). Svanbro reminded the WG that, for mass-market speech applications, good spectrum efficiency implies a significant residual bit error rate. While there was agreement that ROHC should not itself attempt to provide error protection, the attendees were divided on whether detection of bit errors in headers should always be left to the lower layers or was, depending on lower layer error rates, a legitimate function of ROHC (but see discussion later). In the discussion that followed, the issue of how to define the interfaces to other documents came up, including the set of parameters that need to be negotiated for ROHC. Bormann explained that with RFC2507, the separate RFC2509 that defined the PPP negotiation came about for purely procedural reasons. Koren mentioned that it might take some time to get PPP numbers for ROHC, which Bormann took as a good reason to have a separate document for ROHC as well. * Requirements for RTP ROHC The goal of this section of the meeting was to "sign off" the RTP requirements draft to make it ready for WG last call. The changes to the current version of the document (that should have been the -01 version, but apparently again did not make it into the archives) were discussed first. The document now has "robust" in the title. 2.1.2 now requires support for efficiently compressing Mobile IP, in particular the Home Address Option. 2.3.3 now makes clear that the Handover procedure itself is outside the scope of ROHC. One of the modes in which the ROHC scheme should support handover is minimal state transfer, e.g. by having the new compressor/decompressor pair simply start again in initialization state. For the case that ROHC state transfer is desired, ROHC will outline handover schemes and pitfalls, and in particular define the information set to be transferred. Le initiated some discussion on the more explicit 3G.IP requirement that handover should not cause additional packet loss in ROHC. There was agreement that the ROHC scheme should provide a way to minimize the loss of compression efficiency during handover. 2.3.7 now explains the term "moderate packet misordering" as up to two or three misordered packets, based on the observation that the Internet is engineered to run TCP well (which does not handle additional misordering very well). The wording "tolerate" was clarified as "works with any misordering" (i.e., never breaks by generating incorrect packets at the decompressor just because of misordering on the path to the compressor), in combination with "works well with moderate misordering" (may require moderation in misordering to maintain good efficiency). After some discussion, there was consensus that we continue to assume there is no misordering on the way from compressor to decompressor. While 3GPP lower layers can be configured to allow out-of-order delivery, this only applies in retransmission mode, which is not the likely lower layer mode for ROHC. 2.3.10 has a new requirement on delay. After some discussion, it became clear that it is not reasonable to entirely exclude the ROHC scheme ever buffering a packet (e.g., if a packet becomes decompressable only after feedback), but that schemes that achieve robustness at the expense of consistent delay (e.g. by interleaving) are out. It was noted that a ROHC implementation might use information available from RTP (timestamps, sequence number) to decide whether a packet is buffered (e.g., buffering only "early" packets). There was an interesting discussion on where the queue forms in case of congestion. Bormann indicated that his system model had a tight coupling both between compressor and (radio) link and between (radio) link and decompressor, so that there would be no queues between these tightly coupled pairs. If queues are allowed to form, the ROHC scheme cannot fully exploit the controlled timing afforded by the radio schemes. Also, Kullander has research results that show a compressor might use information from a queue in front of it. However, there was no agreement that this system model was universally applicable. After the changes were discussed, the WG had a second round through the entire document. 2.1.1 Transparency continues to stipulate "semantically identical" results after decompression. There is no change required, but the clarification can be added that the ROHC WG has not found a place where "semantically identical" is not identical to "bitwise identical". If absolutely required for maximum compression efficiency, transparency can be reduced by a component outside (above) ROHC, which was fondly referred to as "header stomping" in previous mailing list discussions. Bormann volunteered to draft a "packet mangler negotiation protocol" for cases when this needs to be negotiated, with the understanding that this is informational and clearly outside the scope of the WG. 2.1.2 It was clarified that while there will be no requirement to change existing stacks, the WG may recommend changes (such as consecutive IP ID assignment) to optimize compression efficiency (but cannot rely on such changes being deployed). 2.1.3 Svanbro mentioned that 3GPP has decided to focus on IPv6 in the multimedia domain, amplifying this requirement. 2.2.2 Add AH, ESP to the list of headers supported (obviously, we cannot efficiently compress *inside* an ESP). Attendees perceived a need to discuss the implications of security with cellular working groups, in particular that good header compression will only be possible if a security scheme restricts itself to compressing just RTP payloads. Full IPSEC will still be possible, but at a considerable price. In 3GPP, S3 was identified as a group to talk to about this. 2.3.2 Discussion separated out two possible reasons for error propagation: First, the decompressor may be out of sync due to loss: it cannot decompress good packets arriving after the lost packets until the context state is refreshed. This was called "loss propagation". A second form of error propagation may be due to residual bit errors: if the decompressor got an erroneous packet, the context state at the decompressor could be corrupted without its knowledge. As a result, a long sequence of good packets following could be decompressed incorrectly. This was called "damage propagation". After further discussion, we agreed that both kinds of error propagation must be kept to a minimum. 2.3.3 The WG agreed that there was no need to specify a separate error propagation requirement for handover: handover is treated as extended loss. 2.3.9 This prompted a continuation of the discussion of section 3.1.4 of the lower layer guidelines. Kalliokulju explained TFCIs: a small number of bits may be available for indicating the frame size at the lower layers. The alternatives include: 1) adding a padding header (inefficient) 2) using self-expanding headers that transport as much information as possible; if the largest header available is not sufficient, padding can be added. There seems to be a need for an interface between ROHC and lower layers to negotiate "good" frame sizes. There is definitely a requirement for the lower layers to maintain the frame length. For 3GPP, one goal would be to be able to use the transparent RLC, which has to know in advance what packet sizes are used. For further exploration, Svanbro will send pointers to transparent RLC and L1 documents to the mailing list. Finally, Degermark proposed two new requirements: First, the issue of residual errors was revisited. Bormann proposed that the requirement on limiting damage propagation should be phrased such that the residual bit error rate with ROHC should be equal or better to the residual bit error rate that would have been provided without ROHC. (This is relatively easy to achieve, as ROHC reduces the number of bits transmitted and can add its own error detection.) After discussion, the consensus was that we will pick a suitable "worst-case" residual bit-error rate X (probably in the range 1e-4 to 1e-5). If the residual bit error rate from the lower layer is better than X, the residual bit error rate will not increase with ROHC. Second, the complexity of the specification should be controlled. As this is hard to measure, we agreed a metric of a maximum size of the specification of 100 pages. * RTP ROHC Schemes: Similarities and Differences (Degermark) There are now five documents with proposals for RTP ROHC schemes, three of which were explicitly marked as submissions to this interim meeting (draft-ietf-rohc-rtp-XX-00.txt, where XX is ACE, KW, or ROCCO), one is further work on CRTP (draft-ietf-avt-tcrtp-00.txt), and one is an individual submission (draft-tran-rohc-upd-packets-00.txt). The chairs proposed not to have detailed presentations on the changes made to the specific schemes since the last meeting -- this was presumed to be well-known from the drafts and from the mailing list discussion. Instead, Degermark presented a summary of similarities and differences between the three schemes, proposing some common terminology for similar features. All schemes have states that can be termed Initialization (full-header, STATIC), first-order (DYNAMIC, update, basic-compressed), and second-order (COMPRESSED, non-updating). It was noted that there is little difference between ACE and ROCCO in uni-directional mode. The main difference is in the detection of being out of sync: ACE in bidirectional mode never gets out of sync (by relying on ACK to move the common state forward), KW uses a generation identifier, and ROCCO (as well as ACE in "sparse mode") uses a checksum. Degermark identified as issues: state transitions, dynamicity (what can change for a compressed stream), and modes/mode transitions. * RTP ROHC Schemes: Ways Forward Degermark presented a proposal on moving forward. The development of separate documents had been a good way of exploring the solution space, now there was a need to pool resources and converge. The chairs proposed to pick the editorially most mature document as the base document and add functionality from the other documents. Bormann, one of the chairs, will serve as the overall editor, fanning out work to subpart authors. The authors of the contributions will appear as authors of the resulting RTP ROHC document. After discussion, there was consensus on moving forward in this way. Further discussion revealed that there was a consensus that the ROCCO document probably was the editorially most advanced document at this point. It was again noted by Bormann that the selection of a document to work from did not imply selection of technology. A number of items were identified that need work beyond the existing contribution documents. (See discussion of "Holes" on day 2.) * IPR approach Bormann proposed the following approach to the IPR issue: The WG should design the specification such that there is a reasonable assumption that its basic mode of operation is unencumbered by IPR. To this end, the IETF will ask the contributing companies who have made IPR claims to waive the requirement for licensing the IPR for standard-conforming implementations, most likely under a condition of reciprocity of this waiver. If such waivers cannot be secured for technology the WG decides we do want to use, having an unencumbered basic mode of operation can only be enabled by adding options for the encumbered technology -- there was strong consensus to minimize the number of these options. The details of who makes the request for waivers and how it is worded need to be defined, but it was agreed that the attendees would make IPR people in their respective companies aware of this issue and start the ball rolling on getting these waivers. Before the final document is submitted to the IESG in September, the status of the IPR issues needs to be understood by the WG. There was no disagreement to proceeding in this way. * Subgroups Degermark proposed to split up the meeting into three subgroups: 1) Dynamicity -- which parameters are established in per-channel negotiation vs. per-stream (context) vs. changeable during lifetime of the stream? 2) What are the methods for switching between having a larger sequence number and having a checksum in the minimal second-order header? 3) What are the detailed states and modes? Group 1 discussed the profile concept (as proposed by ROCCO) and proposed to have to compressor indicate which profiles it supports to the decompressor. Bormann argued that an option negotiation process about allocating bits in headers could easily evolve into solving a set of Diophantine equations, he argued about minimizing the number of "options" as implementing the option negotiation may be more expensive that implementing the "option" in the first place. Le noted his concern about a proliferation of profiles. A discussion ensued how many bits should be used for the context ID -- existing proposals only support 0 or 8 bits. There was some consensus that many applications could benefit from around 3 to 5 CID bits. Also the number of CIDs may have to change during the lifetime of a channel. Group 2 described a process for switching that is based on sending first-order headers with an indication of the intended switch until receiving an acknowledgement. A more complicated process requiring the decompressor to ask for a switch, and then the sender to only send SO headers that would violate the CRC, until finally receiving an acknowledgement, was considered too complex and needed only when the switch was frequent. Group 3 provided an elaborate diagram that became the basis for much of the discussion during the rest of the meeting. Starting from a common initialization state for all three modes (unidirectional, NACK-based, ACK-based), there were distinct first-order and second-order states for the modes. Switching modes required going through the first-order states. The main difference between the NACK-based and uni-directional modes is the presence of timers to refresh state repeatedly. Going back from NACK to unidirectional mode was considered problematic as the absence of NACKs may indicate either that the return channel failed or that the forward channel is perfect. Jonsson volunteered to write up the results from this subgroup. * Loss detection vs. residual bit error detection The morning of Tuesday started with a discussion about the role of checksums (CRCs) initiated by Burmeister, who argued that space left by e.g. a 4-bit CID could be used for a 4-bit CRC of the compressed header. Having a CRC of the compressed header (as opposed to a CRC of the uncompressed header) would allow to differentiate bit errors in the current header from context damage due to the loss of previous context-updating packets. While being able to make this distinction is useful, the discussion resulted in consensus that the bits in the most-compressed header are too precious to have error detection on both levels. The group focused on checksums of the uncompressed header from that point on. One problem that needs to be solved in an optimistic scheme is that after a long period of silence on the link, an SO header is dubious: Was the period of silence a result of a new talkspurt, the first FO packets of which were lost, or did we have an extended link outage ("long-loss event") that wrapped the SO sequence number? Bormann proposed a wall-clock based validation of SO headers -- if decompressing an SO header would result in a timestamp value that is unlikely at the current wall-clock time, we have lost synchronization. The ability to use this scheme requires knowledge about clock precision, queueing/jitter in lower layers, and the timestamp-to-realtime mapping, so its usefulness may be limited to specific cases. It was noted that the clock-based scheme might reduce or almost eliminate the need to send FO headers at the beginning of talkspurts, if the compressor is aware that the decompressor uses a clock-based scheme. Degermark remarked that the decompressor uses a kind of sliding window when it maps the modulo of the RTP sequence number to the full-length RTP sequence number, and the modulo of the RTP timestamp to the full-length RTP timestamp. A clock based scheme as outlined by Bormann can be used in two ways: 1) when the the decompressed RTP timestamp value is unrealistic when compared to the real wallclock time, it is clear that synchronization is lost. 2) The windows used for interpreting modulos can be moved with time (as in the timer-based compression scheme in ACE). The group decided to examine the wall-clock based validation scheme some more. With respect to 3-bit CRCs, Svanbro remarked that his group had run extensive simulations with high-BER links and not experienced a loss that resulted in context damage undetected by the 3-bit CRC. Other attendees noted that "elevator-type" long-loss events had not been part of the simulations. Degermark remarked that using checksums like the one proposed in the ACE draft had a significant problem compared to CRCs: A context damage caused by residual bit errors that escapes a checksum once (e.g., two opposite lsb bit errors in some IP address) will escape the checksum consistently, while with a CRC most follow-on packets will have an incorrect CRC of the uncompressed packet, eventually triggering a context update request. After some discussion, the group decided to focus on CRC-style error detection. Bormann asked the group to start looking for good CRC polynomials for the various lengths of CRC that may be required (not just 3 and 10), where "good" includes not clashing with the CRC polynomials used by lower-layer error detection; Degermark remarked that since the CRC on the lower layers and the ROHC CRCs do not cover the same data, it is not immediately clear that having similar CRCs will cause a problem. Nonetheless, Svanbro volunteered to do some work here. Bormann summarized the decisions of the morning session: we will examine wall-clock based validation; look at 4-bit CIDs; we favor CRCs over checksums; we aim to use the same packet types for all modes with the exception of the minimum-length second order headers; Svanbro to examine the influence of "elevator events" on 3-bit CRCs to assess the likelihood of generating false headers; Svanbro to look for good CRC polynomials. * Holes The following assignments were made for new parts that are needed in the document: -- security considerations (probably covered in part by ROCCO, though) -- IPSEC -- Degermark -- Tunneling -- Le -- IPv6 options -- Le -- RTCP -- Svanbro -- CSRC list -- Liu * Editing groups The meeting then split up into "cut-out" editing subgroups that examined two documents each: 1) ROCCO/ROCCO Video, focusing on a new table of contents 2) ACE, update 3) KW, CRTP enhancements Afterwards, each group briefly presented their results. The group 1 did not finish their work, it was decided to have them continue offline (after the end of the Interim Meeting). A discussion about packet formats ensued. In particular, so far it had been overlooked to add a third type of SO header for the generation (KW) approach. No clear consensus on packet formats resulted. * Milestones for further work The "cut-outs" of the contributions (as discussed in the editing subgroups) are to be sent to the list by June 13, followed by discussion to June 20. Bormann to integrate the results by June 22. June 2nd -- cutout groups to send their results to the list June 2nd -- Degermark to send table of contents to the list June 5th -- Jonsson to send the state diagrams to the list June 13th -- cutouts to the list June 14th -- Le to provide a draft with test scenarios June 20th -- end of discussion June 22nd -- Bormann to send draft-ietf-rohc-rtp-00 to the list With respect to the RTP ROHC requirements: June 5th -- Degermark to post revised draft June 20th -- end of discussion June 22nd -- Degermark to post next draft The week of July 3rd to July 7th was marked as a good time to meet with 3GPP in Paris. We are generally in good shape with respect to RTP ROHC milestones. Not so for TCP (see discussion below). * Miscellaneous Koren gave a quick review of issues she had taken down during the two days. Results from discussion are: The goal to limit header size variations would have to be re-examined between revision -00 and -01 of the ROHC RTP draft. Various types of handover events will be covered in Le's test case draft. L2 notifications of handover and the discussion of unequal error protection will be handled by Svanbro in the layer 2 guidelines document. A 2509 equivalent will be generated by Bormann. There is a need to alert both the cellular community and the security community that good performance of header compression requires encrypting the RTP payload only. This should be added to security considerations. Misordering on the link -- the assumption is to configure the link not to misorder (i.e, any misordering on the link is to be dealt with below ROHC, and not by ROHC). * TCP ROHC requirements The discussion of TCP requirements was moved to the end as some people had to catch flights who were more interested to finish RTP. Degermark gave a quick review of TCP ROHC requirements: -- Compress correctly in the presence of TCP options such as large windows -- Compress timestamp and SACK options well -- Compress initial exchange [[Insert results of discussion of TCP deadlines here!]] * Attendees: Akihiro Miyazaki akihiro@isl.mei.co.jp Andrew Allen CAA019@email.mot.com Carsten Bormann cabo@tzi.org Carsten Burmeister burmeister@panasonic.de Christian Schmidt christian.schmidt@icn.siemens.de Hans Hannu hans.hannu@lu.erisoft.se Harri Honkasalo harri.honkasalo@nokia.com Jan Kullander Jan.Kullander@erv.ericsson.com Jonas Wiorek jonas.wiorek@era.ericsson.se Juha Kalliokulju juha.kalliokulju@nokia.com Khiem Le khiem.le@nokia.com Krister Svanbro krister.svanbro@ericsson.com Lars-Erik Jonsson lars-erik.jonsson@ericsson.com Mikael Degermark micke@cs.arizona.edu Mikael Gudmundson mikael.gudmundson@era.ericsson.se Takeshi Yoshimura yoshi@spg.yrp.nttdocomo.co.jp Tmima Koren tmima@cisco.com Zhigang Liu zhigang.liu@nokia.com