[rohc] Minutes of the ROHC WG session at IETF 56

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 latest...
_______________________________________________
Rohc mailing list
Rohc@ietf.org
https://www1.ietf.org/mailman/listinfo/rohc