[rohc] Preliminary minutes from San Francisco
"Lars-Erik Jonsson (EAB)" <Lars-Erik.Jonsson@epl.ericsson.se> Thu, 10 April 2003 15:01 UTC
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA23125 for <rohc-archive@odin.ietf.org>; Thu, 10 Apr 2003 11:01:23 -0400 (EDT)
Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h3AF76p17313 for rohc-archive@odin.ietf.org; Thu, 10 Apr 2003 11:07:06 -0400
Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3AF76817302 for <rohc-web-archive@optimus.ietf.org>; Thu, 10 Apr 2003 11:07:06 -0400
Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA23098 for <rohc-web-archive@ietf.org>; Thu, 10 Apr 2003 11:00:50 -0400 (EDT)
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3AF3P817065; Thu, 10 Apr 2003 11:03:25 -0400
Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3AF2R817026 for <rohc@optimus.ietf.org>; Thu, 10 Apr 2003 11:02:27 -0400
Received: from penguin.wise.edt.ericsson.se (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA22986 for <rohc@ietf.org>; Thu, 10 Apr 2003 10:56:11 -0400 (EDT)
Received: from esealnt612.al.sw.ericsson.se (alteon-nat1.sw.ericsson.se [153.88.254.118]) by penguin.wise.edt.ericsson.se (8.12.9/8.12.9/WIREfire-1.5.1) with ESMTP id h3AEwiI3016896 for <rohc@ietf.org>; Thu, 10 Apr 2003 16:58:44 +0200 (MEST)
Received: by esealnt612.al.sw.ericsson.se with Internet Mail Service (5.5.2655.55) id <2VDND03N>; Thu, 10 Apr 2003 16:58:45 +0200
Message-ID: <A943FD84BD9ED41193460008C7918050072E90FB@ESEALNT419.al.sw.ericsson.se>
From: "Lars-Erik Jonsson (EAB)" <Lars-Erik.Jonsson@epl.ericsson.se>
To: "Rohc (E-mail)" <rohc@ietf.org>
Date: Thu, 10 Apr 2003 16:46:16 +0200
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2655.55)
Content-Type: text/plain; charset="iso-8859-1"
Subject: [rohc] Preliminary minutes from San Francisco
Sender: rohc-admin@ietf.org
Errors-To: rohc-admin@ietf.org
X-BeenThere: rohc@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/rohc>, <mailto:rohc-request@ietf.org?subject=unsubscribe>
List-Id: Robust Header Compression <rohc.ietf.org>
List-Post: <mailto:rohc@ietf.org>
List-Help: <mailto:rohc-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/rohc>, <mailto:rohc-request@ietf.org?subject=subscribe>
ROHCers, Below are preliminary minutes from IETF 56. Please read them ASAP, and respond about potential corrections or additions. I need to have your comments not later than tomorrow, Friday 11th, at 15:00 GMT. Rgds, /Lars-Erik Preliminary minutes of the ROHC WG session at IETF 56 ===================================================== Hilton San Francisco, San Francisco, USA Monday evening, 2003-03-17 Chairs: Carsten Bormann & Lars-Erik Jonsson Reported by: Lars-Erik Jonsson Note takers: Stephen Casner, Christian Schmidt & Mark West Slides are available at http://www.dmn.tzi.org/ietf/rohc Evening session, 19:30-22:00 ---------------------------- * WG admonishments (Jonsson) Lars-Erik reviewed the IETF working group principles, the IETF standardization process and the IPR rules defined by RFC 2026. Meeting time should be used to advance difficult issues, not for presentation of material that can be read from drafts. We assume that people have read the drafts, and what we decide in meetings must be confirmed on the mailing list. * Agenda bashing (Jonsson) Lars-Erik presented the proposed agenda, which was accepted without modifications. Agenda: - Chair admonishments and agenda bashing - WG and document status update - Signaling compression issues - ROHC RTP DS preparations update - Formal header compression notation * WG and document status (Jonsson) Lars-Erik reviewed WG goals, milestones and document status. Five new ROHC RFC's have been published since November, three SigComp documents, the LLA R-mode extension, and the RTP lower layer guidelines. Currently, we have no documents in the RFC editor's queue, but we have two that were just submitted to the IESG, the ROHC MIB and its companion document with terminology and channel mapping examples. The working group is progressing, but slowly. A milestone update was planned after Atlanta, but has not yet happen for various reasons. However, we should be able to do this rather soon. A new document review concept is to be implemented, where each document is required to have "committed reviewers". These reviewers are designated as such by the chairs, preferably on an early stage, and must have agreed to follow the document evolution, to carefully review the whole document, and to respond openly to working group last-call. Committed reviewers should be non-authors, and will be separately acknowledged in documents. The work items not covered by the agenda of this meeting were: - ROHC TCP, which has not progressed as planned due to editor illness, but an update is expected within a few weeks. - Modified RTP/UDP profiles for UDP-Lite compression, where the current individual draft will be resubmitted as a WG draft. - SCTP compression, which is still on hold. The chairs have asked for interest, motivation, industry support, and commitments for doing the actual work, but answers have not really provided that. Carsten noted that we might not understand future usage of SCTP at this point, so attempting a solution now might produce a result that is not really useful. * Signaling compression issues - SigComp Feedback (Roach) Adam Roach gave a quick summary of the changes in the updated draft. Nack information is now at the end of the messages, and can therefore be distinguished from standalone feedback. The TCP behavior has been changed, and a NACK detection mechanisms has been added. There was a question raised whether we should create an IANA registry for the first 32 bytes of UDVM memory space, but the question was never answered or discussed. More people have to look at this, so far the input has been limited. The meeting suggested that the document should be adopted as a WG document, if we get a few committed draft reviewers, and Mark West and Carsten Bormann volunteered for this. Draft: draft-roach-sigcomp-nack-01.txt - SigComp interoperability report (West) Mark West gave a report from the first SigComp interoperability testing, conducted at SIPit. The point was primarily to test SigComp, with or without SIP, trying to verify that all decompressor/UDVM endpoints behave consistently. Six implementations were present, which was more than expected, and the overall result was good, things mainly worked. The main problem had to do with consumption of decompressor memory because bytecode consumes memory in two places, making bootstrapping very difficult. Adam Roach noted that this problem currently makes SigComp unusable for SIP in 3GPP, and described three potential solutions. It was agreed that the desirable approach would be to increase the UDVM memory size, but there were various opinions on how to achieve that, from a standards point of view. Richard noted that this is an application specific issue, and a larger UDVM memory size should be mandated for SIP. Carsten agreed, but RFC 3486 does not say so, and there are other things missing as well. Carsten suggested that SigComp should not be changed, but that this should be left to each signaling protocol to specify. We should then not consider RFC 3486 as binding SIP to SigComp, but only defining how an application finds out if SigComp is being used. This means that we need a new document to specify other SIP specifics for SigComp. There were a few more issues identified at SIPit, but these were minor, although we should provide some clarifications. To do that, it was agreed to create a SigComp implementer's guide, and Mark agreed to write up an initial version with the current findings. - The SigComp binary multiplexing issues (Price) Richard Price initiated a follow-up to the SigComp multiplexing discussion from the Sipping list. Although SigComp offers an alternative transport service to applications, using SigComp requires more than just an on/off switch. Applications using SigComp must provide mechanisms for SigComp discovery, methods for recognizing SigComp messages, define compartment handling, clarifying whether "continuous mode" can be used, and potentially increase the minimal memory size and/or the maximal number of UDVM cycles. The mixing problem raised was triggered by the requirement that SIP messages may contain binary data. In UDP, framing comes from the packet, but for TCP there are both application and SigComp delimiters. Problems would then arise if uncompressed application messages are multiplexed with SigComp messages. Carsten noted that for TCP, the first byte would indicate whether SigComp is used or not, and there seems to be something wrong with the layering here. If there is a problem, it is probably because of misuse of SigComp. Richard agreed, what should be made clear is that SigComp should not be switched on/off within a connection. If someone wants to send some messages uncompressed, that can be handled within SigComp. Whether to allow "continuous mode" at all must further be specified per application, so we need the SIP-SigComp binding document also for that. * ROHC RTP, Draft Standard preparations status (Jonsson) The MIB draft has been submitted to the IESG, and so has the channel mapping examples document. The feature test document has been updated with additional tests, as well as some initial status figures. Reports are currently being collected, and the next update will be available within a month. An update of the IP profile has also been available for some time, but more feedback would be appreciated before we issue WG last-call. Finally, some minor clarifications have been added to the implementer's guide. Stephen Casner asked whether ROHC RTP Draft Standard advancement is dependent on DS for RTP itself. Although this will probably not be an issue since RTP will soon be published as Draft Standard, Carsten noted that ROHC RTP is not dependent on RTP itself because compression is speculative. Drafts: draft-ietf-rohc-rtp-impl-guide-03.txt draft-ietf-rohc-rtp-rfc3095-interoperability-01.txt draft-ietf-rohc-ip-only-01.txt * Formal header compression notation (Bormann, Ozegovic, Price) Carsten introduced the formal header compression notation, initially answering the question why this work is needed. The lesson we have learned from RFC 3095 is that compressed packet formats easily gets non-trivial, overstressing the RFC box notation. It is not always clear what goes where, since labeling a field in box notation does not necessary mean you know how to interpret it. With a formal notation, the uncompressed data is described, as well as which compression mechanisms that is applied to each field. ROHC formal notation (ROHC-FN) is inspired by BNF, ROHC packet classifications, Huffman probabilities, etc. ROHC-FN is something that needs to get done and out of the way to return to working on profiles, which is what we are really chartered to do. Julije Ozegovic gave a quick presentation of an initial attempt to define a profile for DCCP using a formal notation approach. The purpose of this work was to investigate the usefulness of a formal notation, as well as studying DCCP for compression purposes. DCCP has a fixed header and various options, so the compression must handle the variability. Carsten noted that to use the notation, we will have to nail it down formally in a standardized way. It is easy to do something "wishy- washy", but it is hard to do it clearly. We need to get a common understanding in the WG as to how the notation works. This is not easy, and semantics have to be very clear. Further, we have to find a proper trade-off between top-down and bottom-up design. If we focus too much on specific applications of the notation in a top-down design we will get a smaller set of tools, which would be a good thing, but the solution will probably be inflexible for new uses. With a bottom- up design, we could on the other hand get something too flexible and far from actual application requirements. We need to find a proper middle-way. An idea is to define the notation using a high level programming language, and two examples were given by Carsten (Prolog) and Richard (Haskell). Prolog is a well-known logical programming language, while Haskell is a functional language. As shown by the examples, both provide means to get a rather human-readable notation result, and the difference is minimal, at least on the surface. Carsten finally raised some issues on the way forward. We will have to balance specification/implementation, as it is a danger that we write the whole implementation into the specification. There will have to be "oracle" functions, which are left for implementers to define. Another issue is the actual bits-on-the wire encoding, when there are alternatives in the encoding. To handle alternatives, some discriminators are needed, but it is not obvious how to create these. There have been discussions on the mailing list, but we have not totally converged towards an agreement. This was discussed also at the meeting, but the conclusion was that an agreement should not be difficult to reach, we just have to get a clearer and common picture of what people really mean. One thing is to agree on some terminology for discriminator functions, i.e. Huffman and Hierarchical Huffman. Julije noted that we have two phases, encoding and how to arrange the bits on the wire, i.e. field encoding and discriminators. Carsten clarified that there are really not two phases, just two primitives in the notation, Fields and Discriminators. Another high level question is how complete we want to make the notation. With an academic approach, one would let this take three or four years to get a complete solution, but that is really not the IETF way. Since new stuff can easily be added, if needed for another compression profile, we do not really have to create a complete solution, although we should have a good feeling about future enhancements. There was a strong agreement in the room to go for the proposed approach. One major open issue is about interaction between the formal notation and contexts, which is something that is not well understood at this point. Since contexts may not be the same at compressor and decompressor, due to loss, this must be covered for. We have feedback for context repair, but that is not covered by the notation. We also need to have means to handle things that are optionally present, e.g. list elements in IPv6. Richard noted that we currently do not support unbounded (recursive) encoding, and we have to carefully consider whether we should do that. Julije asked whether we have a problem with contexts and packet classification, i.e. which fields to check to see how to handle the packet and find the right context for it. Carsten commented that this would be a typical oracle function, i.e. an implementation issue, and Lars-Erik agreed that there should not be any difference to RFC 3095 in this respect. Zhigang Liu pointed out that one must be confident that the decompressor has the correct context present. Carsten responded that in 3095 this is handled by the sequence number, which gives the context (or candidate contexts) to be used for decompression. That is an issue for profile specification, nothing to be captured by the notation. Carsten then outlined a direction for moving forward. We should write down both requirements and non-requirements for the notation, and work from those. To get some more bandwidth and get this work going, we may need to consider having an interim meeting, as we had when we created RFC 3095. But first we should continue with the current discussions on the mailing list, which so far have been really helpful for bringing people forward towards a common understanding of concepts and principles. Drafts: draft-ietf-rohc-formal-notation-01.txt draft-ozegovic-mornar-dccp-epic-00.txt * Summing up (Bormann / Jonsson) Let's continue the discussions that we are now having on the mailing list. People who have not been involved are encouraged to read the notation draft, as well as the mail discussions from the last 2 weeks. See you in Vienna, at the latest... _______________________________________________ Rohc mailing list Rohc@ietf.org https://www1.ietf.org/mailman/listinfo/rohc
- [rohc] Preliminary minutes from San Francisco Lars-Erik Jonsson (EAB)
- RE: [rohc] Preliminary minutes from San Francisco zhigang.c.liu
- RE: [rohc] Preliminary minutes from San Francisco Lars-Erik Jonsson (EAB)