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. Zhigang Liu noted that this is not a new 
issue, as it was discussed among SigComp authors during last year, but then 
it was seen as a non-problem. Adam Roach pointed out that this 
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.  Zhigang volunteered to serve as editor for such a 
document.

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.  Zhigang argued that we should still define how to do 
multiplexing of raw application messages and SigComp messages, and this 
discussion will probably continue on the mailing list.

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