RE: [rohc] Preliminary minutes from San Francisco

[[e-mail]]

Hi,

According to my notes, the following are missing from the minutes.
I would suggest to add them after the text quoted below from the 
preliminary ROHC minutes.

------------------------------------------------------------------
>  - SigComp interoperability report (West)

> The main problem had to do with consumption of decompressor memory
> because bytecode consumes memory in two places, making bootstrapping
> very difficult.

Zhigang Liu pointed out that he had raised the "double counting" issue 
among SigComp authors sometime last year, so it is not a new issue. 

> 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.

Lars-Erik Jonsson then asked who were willing to handle this SigComp-SIP 
binding document. Zhigang Liu volunteered to be the editor.

> - The SigComp binary multiplexing issues (Price)

> 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.

Zhigang Liu pointed out that it seems to be easy to multiplex uncompressed 
application message and SigComp messages on one TCP connection, since
each application message has its own framing. It's a matter spelling
out the requirement and logic.

It looks not everyone has the same understanding of the issue, and further
discussion will continue on the mailing list.
------------------------------------------------------------------

BR,
Zhigang

> -----Original Message-----
> From: ext Lars-Erik Jonsson (EAB)
> [mailto:[e-mail]]
> Sent: April 10, 2003 9:46 AM
> To: Rohc (E-mail)
> Subject: [rohc] Preliminary minutes from San Francisco
> 
> 
> 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
> [e-mail]
> https://www1.ietf.org/mailman/listinfo/rohc
> 
_______________________________________________
Rohc mailing list
[e-mail]
https://www1.ietf.org/mailman/listinfo/rohc