Minutes of the ROHC WG session at IETF 55 ========================================= Marriott Marquis, Atlanta, USA Monday morning, 2002-11-18 Chairs: Carsten Bormann & Lars-Erik Jonsson Reported by: Lars-Erik Jonsson Note takers: Pete McCann, Gorry Fairhurst Christian Schmidt & Mark West Slides are available at http://www.dmn.tzi.org/ietf/rohc Morning session, 0900-1130 -------------------------- * WG admonishments (Carsten Bormann) Carsten reviewed the IETF working group principles, the IETF standardization process and the IPR rules defined by RFC 2026. People are encouraged to read RFC 2026 and RFC 2418, which define our processes. We are here to make the internet work, and we use rough consensus and running code instead of voting. The ROHC WG is chaired by Lars-Erik Jonsson and Carsten Bormann, with support from our area directors, Allison Mankin and Scott Bradner. Note that the real work is done on the mailing list, although face-to-face meetings can sometimes help the progress. Meeting time should be used to advance difficult issues, not for presentations. We do assume that people have read the drafts. Finally, Carsten stressed the RFC 2026 IPR policy, which says that any contribution must identify whether the contributor(s) is(are) aware of any IPR issues related to the contribution. * Agenda bashing (Carsten Bormann) Carsten presented the proposed agenda, which was accepted without modifications. Agenda: - Chair admonishments and agenda bashing - WG and document status update - ROHC RTP, Draft Standard preparations update - Signaling compression - ROHC over wireless Ethernet media - TCP profile - Formal header compression notation * WG and document status (Lars-Erik Jonsson) Lars-Erik reviewed WG goals, milestones and document status. The Lower Layer Guidelines document and the LLA R-mode extension are currently in AUTH48 and will thus soon be published. The SigComp documents have passed IANA registration but are still waiting in the RFC Editor's queue. ROHC has currently no documents on the IESG table. At the moment, the WG has 5 documents related to ROHC RTP and the Draft Standard process, 4 documents for the TCP profile work (plus the notation document which is also to some extent part of the TCP work), and one document for SCTP requirements. The SCTP work is currently on hold due to a lack of interest in compression of SCTP. We will be few months late with the ROHC MIB, but that is a minor issue. The LLA mapping examples document and the ROHC RTP Draft Standard documents are not yet available, but will soon be. Lots of preparation work for Draft Standard have been done, but this is a long process. The TCP work is now progressing and is on track, although we will probably have to adjust the finalization date a few months. * ROHC RTP, Draft Standard preparations update (Lars-Erik Jonsson) - MIB & ROHC terminology and mapping examples The MIB is now rather stable and it is thus time to read it and comment. It will be updated once more to include support for the LLA profile. The "Terminology and channel mapping examples" draft provides reference material for the MIB and the goal is to have these two documents last-called in the WG in December. Drafts: draft-ietf-rohc-mib-rtp-04.txt draft-ietf-rohc-terminology-and-examples-00.txt - Implementation status & feature test list Four ROHC interop events have been held so far. At the last interop, "ROHC in the city" in Berlin, there were four implementations present from Effnet, Ericsson, Acticom, and ICR (Singapore). First extensive IPv6 tests were successfully performed by Ericsson and Effnet, and initial testing of list compression was also carried out between Acticom and Ericsson. Preliminary reports on the results point to potential ambiguities in the list compression specification, but this will have to be further studied. A test case document is now available in an initial version. The purpose of this document is to specify a list of feature tests that will have to be carried out to take 3095 further to Draft Standard, and also to document current interoperability test status. This document should be the basis for future interoperability tests. Draft: draft-ietf-rohc-rtp-rfc3095-interoperability-00.txt - Implementer's Guide There have been two additions to the implementer's guide in the new version, based on mailing list discussions. The first clarification is about the interpretation interval for timestamp bits. RFC3095 defines two different interpretation intervals, but it is not clear that both these are used, and which one to use depends on the timestamp encoding mechanism used. Normal W-LSB compression uses one interval and timer-based compression uses the other. The implementer's guide now explains this, and also how to reliably switch between them. The other issue clarified is about profile negotiation. Profile numbers are 16-bit identifiers, while only the 8 LSB's of these are sent when initializing new contexts. This means that the negotiation protocol must ensure that there cannot be two profiles with the same LSB's available after negotiation. Two profiles with the same LSB's are thus not supposed to be concurrently used over a channel. There is no problem with ROHC-over-PPP in this regard. Draft: draft-ietf-rohc-rtp-impl-guide-02.txt - A ROHC profile for IP only, purpose & problem RFC 3095 defines profiles for uncompressed, IP/UDP, IP/UDP/RTP and IP/ESP. The ROHC WG has agreed to define an IP-only profile as a complement to these. The purpose of this profile is to make the RFC 3095 profile suite complete, to allow one with an RFC 3095 implementation to easily modify that for IP-only compression, as a mechanisms to use for e.g. transport protocols not yet supported by a ROHC profile. The intent is thus not to define a ROHC-lite profile, that would be a different work item. The main issue that has been identified for the definition of the IP profile is the question of how to terminate the static chain when there is no single protocol that would end the chain, as it is for the case of UDP. The proposed solution is to terminate the chain when there is anything other than IP/IPv6 in the Protocol/Next Header field. One thing that complicates the issue is the potential presence of more than 2 IP headers. The profiles defined in 3095 can compress one or two IP headers, but since the UDP header must terminate the chain, compression would be totally disabled if there are more than two IP headers. This is a non desirable limitation for the IP profile. However, since the IP profile does not require one specific header to terminate the static chain, a rule saying that the static chain is implicitly terminated after a second IP header portion would ensure that the two initial IP headers can always be compressed. The question is whether it would be easy to provide the means to compress an arbitrary IP header chain. Two potential solutions for this were presented. One way could be to handle additional IP headers with list compression. Another way could be to allow the static chain to be of arbitrary length and add a dynamic header portion to compressed headers for all IP headers but the first two. The latter was suggested as the preferred choice because it would be a minor modification, require no new data structures and mean that the dynamic header portion would be the same for IR, IR-DYN and Compressed packets. Draft: draft-ietf-rohc-ip-only-00.txt - Next steps The work for taking RFC 3095 further has started, but there are lots of things to do to make this happen. The MIB will be updated and last-called in the WG during December. The IP profile will be updated to address the issues previously discussed and last-called in the WG. The test list document must be improved and we should start collecting status on interoperability. Potential findings from the Berlin interop must further be evaluated, and the implementer's guide updated, if necessary. Finally, an initial version of the "3095 surgery plan" must be produced. Richard Price asked whether it would make sense to define an IP profile also as part of the TCP work, which would probably be a simpler profile. L-E responded that there might be different reasons for having an IP profile, and nothing prevents us from having more than one. The profile currently being defined would be an obvious choice with 3095, but there could be another one that is easy to implement with TCP. This is something we should consider later on. * Signaling compression - SigComp User Guide and testing (Richard Price) Richard covered two documents, the SigComp User Guide and a new individual submission with SigComp torture tests. The User Guide is an informational companion to SigComp, providing a UDVM assembly language and bytecode for well-known decompression algorithms. The last update included an enhanced assembly language, "raw" bytecode for each decompressor, and examples of compressed messages. It has been proposed to add an other decompression algorithm, TCCB, to the user guide. One problem with that algorithm is that the TCCB compressor is not defined in any referable documentation. Carsten made clear that it is not part of our work to publish compression algorithms, and the authors should consider publishing it elsewhere. Other items that are under consideration for the next version of the draft are error recovery considerations and explanations of resource management issues. It might also be useful to add more detailed message flows. The torture test draft provides tests for each UDVM instruction, focuses on boundary and error cases, and covers issues not typically found in well-behaved code but that might be exploited by malicious users. The current version only tests the UDVM, and further tests are needed to test other SigComp entities, such as the state handler and the dispatcher. Richard asked for additional suggestions, but did not get any. Finally, Richard announced that SigComp will be tested at the next SIPit event in Stockholm, February 24-28. Drafts: draft-price-rohc-sigcomp-user-guide-01.txt draft-price-rohc-sigcomp-torture-tests-00.txt - SigComp Feedback (Adam Roach) Adam gave an overview presentation of the problem addressed by the SigComp NACK and SigComp recovery drafts, as well as the potential solutions proposed. The problem could in general be expressed as "when a SigComp message cannot be decoded by the recipient (for whatever reason), the sender needs to learn of such a failure". A couple of error scenarios where this would become an issue were also presented. Three potential approaches to the problem were then proposed. The first solution would be to stay with what we already have in SigComp and use application timeouts or signal by implicit means, by setting the state memory size to zero. This approach requires no additional standardization, but is not very efficient and requires additional messages in the reverse direction and would add delay. Carsten noted that there has been some experience that timeouts are a problem, and given that we have two drafts might be an indication there is a need to do something. Richard commented that the number of drafts is not necessarily enough to prove there is a problem. This might be tightly coupled to the actual environment, because one might have different mechanisms available for solving this problem. Keith Drage noted that this has been discussed also in 3GPP, with the conclusion that it is not a 3GPP specific issue and should thus be handled as part of our SigComp work in ROHC. Richard claimed that at least the original problem statements can be solved by existing SigComp mechanisms. It may be that we need new error codes to recover more quickly, but we need error cases where partial failure will happen. Adam commented that losing partial state in handsets may not be likely, but in 3G architectures compartments might be discarded in servers even if they are still needed. Keith suggested that we should do some documentation, independent of the outcome of these discussions. Richard and Adam argued whether current SigComp would be good enough to solve the problems or not. Carsten noted that some form of diagnostics mechanisms would be a useful addition to SigComp in any case. Lars-Erik then asked the room whether there were any real objections to do work in this area, with no response. Richard wondered is this assumed additional standardization, to which Carsten responded that this is something we will have to figure out. Adam continued with more material on the potential approaches. The second solution would be to add a reset message to reset one or all compartments. This approach is good because it should be easy to implement and provide immediate recovery. On the other hand is it a kind of "sledge hammer" solution, and there might be IPR concerns to consider. It also only works if the recipient can identify the compartment to which the message belongs. The third approach is to define specific error messages indicating the cause of failure, allowing the compressor to do fine-grained adjustments. With this approach, error recovery will not be more costly than necessary, various error cases can be handled, and we would also get a debugging and diagnostics mechanism. Disadvantages may be more complicated standardization and implementation, and a need for stand-alone feedback messages. Interesting side effects of this are the possibility to implement an optimistic compression approach, and network diagnostics abilities. Adam then presented some performance examples to compare the three different approaches, and that was followed by a long discussion about the error scenarios and the actual motivation for doing work on this. There was no clear outcome, more than that the usefulness for diagnostics might itself be a sufficient motivation. Carsten noted that we will have to come up with specific examples, based on clear assumptions, then we can take a decision. Drafts: draft-roach-sigcomp-nack-00.txt draft-liu-sigcomp-recovery-01.txt - Static Dictionary for SIP/SDP (Carsten Bormann) Carsten reported about the SIP/SDP static dictionary status. For version -04, the IETF last-call ended on November 15. There have been some positive signals from the IESG, but no formal approval yet. The problem with this document is that it tries to petrify a snapshot of the SIP/SDP protocol development, and we really need to decide on when is the right time to do this petrification. A version -05 is already available with some minor changes. Unfortunately, as soon as we tweak anything, the dictionary changes significantly - about half the text of the document. Carsten asked for comments on when to finally freeze this. Adam Roach answered that the best time would have been last March, and now we should freeze it as soon as possible. Zhigang Liu commented that 3GPP would like this by end of this year, which Carsten concluded means as soon as possible, and that is now. Draft: draft-ietf-sipping-sigcomp-sip-dictionary-05.txt * ROHC over Wireless Ethernet Media - Motivation and possible approaches (Kris Fleming) Kris Fleming gave a presentation of the motivation for and high level technical content of the "ROHC over Wireless Ethernet Media" draft. WLAN and WPAN links are often bandwidth limited and would therefore benefit from header compression. They have also typical loss and delay patterns that would motivate the use of ROHC in such scenarios. Since voice over IP is and will be commonly used in these networks, header compression will continue to be useful. If a generic solution for applying ROHC in these environments could be defined independent of the physical layer technology, that would simplify both standardization and implementation. Such a generic solution should in that case be defined by the IETF. Solutions that have been considered are ROHC over PPP over Ethernet, since both ROHC-over-PPP and PPP-over-Ethernet already exist. The drawbacks of combining these two into a complete solution are the unnecessary overhead, and the unnecessary complexity. The advantage is of course that all components already exist. Another potential approach that has been considered is to reuse an existing protocol for negotiation, but define something new for encapsulation. For IPv6, neighbor discovery could potentially be used for negotiation, but it is not really intended to discover link layer capabilities. The proposed "ROHC over WEM" defines a simple negotiation protocol, and an encapsulation. Kris gave a quick overview, and then asked whether there was any interest in doing this in ROHC. Carsten commented that a key question is where in the protocol stack it would make sense to do this. In the original ROHC work, Ethernet was completely ignored since adding header compression to it was considered to be of less value, e.g. due to the minimal frame size. In 802.11, the headers are rather large and are sent at a lower rate than the data. The gain from header compression could then be questioned. Greg Daley noted that with Mobile IP we might get lots of tunneling headers, and that would increase the gain from header compression. Draft: draft-fleming-rohc-wireless-ethernet-med-01.txt - ROHC over Ethernet issues (Carsten Bormann) Carsten had prepared some discussion material on this issue. We have a pretty large design space here, and before we do anything we must explore it so that we know what we are trying to invent. First of all, there is the issue about which negotiation protocol to use, if we would have to invent a new one. For IPv6, neighbor discovery (ND) seems to be an obvious choice. For IPv4, one could think of using ARP, but that sounds difficult at this point in the evolution of this protocol. If PPPoE was used, we would get lots of unnecessary things and still have to invent a new encapsulation. One could also potentially think of using ND also for IPv4. Secondly, we have the encapsulation issue. Ethernet requires padding, which is neither needed nor desired over the wireless links. If we do compression over the whole Ethernet, bridges between the wired and wireless parts must know about the padding scheme and translate or strip padding. This will easily get complicated. It might make sense to do this in the wireless access points instead, but then we would not get a generic scheme and it would be very unclear whether this would be a ROHC WG issue. A long discussion about the architectural placement of compression in these scenarios followed. Pat Calhoun suggested that this should be done by other bodies, for the links that would really benefit from header compression. Kris argued for doing a general solution and avoid having to do the work over and over again, while others then noticed that link specific solutions would probably give better gain, and we should remember that not all link layers would at all benefit from using compression. Carsten concluded that all comments just indicate that we do not have a clear architectural choice, there are several possible options. It is also very unclear whether this is appropriate work for the IETF and the ROHC WG. We will have to continue these discussions on the mailing list. * TCP profile (Ghyslain Pelletier) Ghyslain gave a short overview of the changes and next issues for the ROHC TCP profile. With a new editor, the document now looks completely different, although the technical content has not at all changed very much. The structure is now better aligned with 3095, and various redundancies have been removed. The mode concept has also been removed to reflect previous consensus to make modes a pure implicit thing for ROHC TCP. Compression always starts in a unidirectional manner, and switches to a bi-directional operation once a first feedback packet is received. This has simplified the document significantly. States and state transitions have also been clarified. The next step will be to define the inner workings of the context replication mechanism. We have an understanding and agreement about the concept, but there are much work left on the details. The goal is to have most of this nailed down in the next version. Remaining issues are then packet formats, and minor details in the compressor and decompressor logic. Carsten asked whether we any quantitative measure on the size of TCP flows that we are optimizing for with context replication. Mark West commented that the requirements are rather short on this, we have just agreed broadly what we mean, but we have not put numbers to it. Carsten noted that we should remember to stop tweaking when the impact is not significant anymore, and Mark agreed that the important gain will probably be from saving IP address overhead. Drafts: draft-ietf-rohc-tcp-requirements-05.txt draft-ietf-rohc-tcp-field-behavior-01.txt draft-ietf-rohc-tcp-03.txt draft-ietf-rohc-tcp-enhancement-00.txt * Formal header compression notation issues (Mark West) Mark gave an update on the formal notation work, there have just been some minor changes since Yokohama. An alternative way of defining the mappings and a more implementation neutral definition. The key goal has been to define reversible mappings between the uncompressed and compressed field values. The pseudo-code has been removed because it became too implementation specific. Pre- and post-conditions are now used to capture mapping behavior. Mappings are now composed from other mappings, which makes documentation more compact and new mappings are easier to define. A mapping example was presented. The questions raised were mainly the same as last time in Yokohama. Are we happy with the combined notation, is identification and generation of meta-data part of the "grammar", and is there an issue with the interface to the (unspecified) coding rules? There were no comments from the room. The way forward would now be to try to define the minimum needed for interoperability, and then figure out how to make use of this for compression of TCP. Lars-Erik noted that there has not been much activity on the mailing list, and asked whether there have been any inputs from others. Mark answered that this there have really not been any. Lars-Erik then pointed out that if we do this, it should be good enough so that we do not have to change it every time we apply it. Those who think it is a good idea are therefore encouraged to contribute to the mailing list discussions. Carsten agree that we need a bigger group to work on this draft, so interested people will have to speak up. Draft: draft-ietf-rohc-formal-notation-00.txt * Summing up (Lars-Erik Jonsson) We thus have two new issues that we will have to discuss further, SigComp Feedback/Recovery and ROHC over Wireless Ethernet Media. We have agreed to do something to the former, while we still do not have enough background material to decide exactly what to do. For the latter issue, we will have to figure out whether it is possible for us to do anything that makes sense and can be justified. Thanks for today!