[rohc] ROHC Minutes, IETF 54

Minutes of the ROHC WG session at IETF 54
=========================================

Pacifico Yokohama, Yokohama, Japan
Wednesday morning, 2002-07-17

Reported by: Lars-Erik Jonsson
Note takers: Pete McCann, Adam Roach,
             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.

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.

* WG and document status (Lars-Erik Jonsson)

Lars-Erik reviewed WG goals, milestones and document status. The
LLA mapping, RTP draft standard and TCP profiles are late, but 
the work is ongoing. SCTP profile development has still not started,
and there seems to be a lack of interest. Since the March meeting,
a number of documents have been approved and/or published. In 
addition to RFC 3095 and RFC 3096, three more documents have now 
been published as RFCs, "ROHC over PPP" (RFC 3241), "0-byte
requirements" (RFC 3243), and "LLA RTP profile" (RFC 3242). Also
the SigComp documents have all been approved for publication and
are currently in the RFC editor's queue. Two documents, "RTP lower
layer guidelines", and "LLA RTP R-mode", have been tentatively 
approved by the IESG with some updates being requested, and are
still awaiting the final IESG approval.

Drafts: draft-ietf-rohc-sigcomp-07.txt
        draft-ietf-rohc-sigcomp-extended-04.txt
        draft-ietf-rohc-signaling-req-assump-06.txt
        draft-ietf-rohc-rtp-lower-layer-guidelines-03.txt
        draft-ietf-rohc-rtp-lla-r-mode-03.txt

* Signaling compression

 - User guide (Richard Price)

Richard gave an overview of the SigComp user guide document
and its purpose. SigComp itself defines a decompressor, while the
intention with the user guide is to provide a companion document
with hints for how to implement SigComp compressors, including
various compression algorithms, optional enhancements (SigComp
extended operations), and corresponding decompressor bytecode for
the algorithms listed. The document further includes test message
sequences, worked examples to clarify SigComp, and sample code.
The user guide also defines a mnemonic language to simplify UDVM
bytecode development, and here there are a few open issues for
further consideration. One question regarding this document that
was raised by Stephen Casner was about the IPR aspects of the
various algorithms described. The conclusion was that all
algorithms might be affected by various IPR claims, and each
implementer will have to consider that. We can still document
them and an IPR section will highlight that we know the
algorithms described might be subject to IPR claims. Finally,
Carsten brought up the question of how to proceed with the
user guide, and people seemed to agree that it would be useful
to keep this document as an Internet Draft for some time while
we test interoperability, and publish it later.

Draft: draft-price-rohc-sigcomp-user-guide-00.txt 

 - Static dictionary for SIP/SDP (Carsten Bormann)

A small design team with members from the SigComp, SIP and
SIPPING communities was formed to create a static dictionary
for SIP/SDP to be used by SigComp. The dictionary contains the 
strings most likely to appear in SIP/SDP exchanges and is
supposed to be useful for LZ77- and LZ78-based compressors, 
which is a majority of the compressors out there). A 3855 byte
string has been created by arranging all original strings and
using any overlap. A problem is the dictionary size, which 
might not be feasible for all SigComp implementations. All
substrings have therefore been given a priority between 1 and 5; a
compressor can instruct the decompressor to load only a subset defined
along these priorities.  The dictionary is still changing due to SIP
changes, and there are still some open issues related to handling of
P-headers. Consequently, the State ID will also continue to change
until the dictionary is frozen for publication.

Draft: draft-ietf-sipping-sigcomp-sip-dictionary-03.txt

 - Next steps (Carsten Bormann)

SigComp itself is done, but we need to do some more work on
integration into e.g. SIP. However, this is as issue that will
be discussed within the SIP/SIPPING groups. Another thing is
to get interoperability testing going. There has been some
initial testing during the UDVM development, but we need a more
complete test set with less likely cases, and we need to test
e.g. SIP integration, not just the UDVM. Carsten proposed to
arrange virtual interops over the Internet to avoid travels,
but a virtual interop host would still be needed to provide
test engines and procedures.

* ROHC RTP, Draft Standard preparations (Lars-Erik Jonsson)

RFC 3095 was published in July 2001, it is thus time to start with
the preparations for Draft Standard. This includes a number of
steps to be taken. The most important is to show interoperability
for all pieces we want to keep, and so far we have not identified
anything we think should be removed. For Draft Standard, we must
also finalize the MIB. Further, there is a significant editorial
work needed since the intention is to separate the framework and
profiles part of RFC 3095.

 - ROHC architecture document (Lars-Erik Jonsson)

A ROHC architecture document has been written to simplify ROHC
understanding, MIB development and implementation. ROHC entities 
and relationships are identified and some additional terminology
is established. One important purpose is also to clarify how ROHC
feedback works and can be implemented, which might be tricky to
figure out from RFC 3095. It is not yet clear whether this should
be published as a separate document, or go into the Draft Standard
framework document. In any case, the MIB will refer to it. People
are encouraged to read and comment, the document will be updated 
and resubmitted as a WG draft.

Draft: draft-jonsson-rohc-architecture-00.txt

 - MIB (Juergen Quittek)

The most important change in the MIB is the new structure with 2
MIB modules, one generic ROHC MIB and one RTP-specific MIB. Some
inconsistencies with the architecture document will be resolved in
the next version, and the cutting line between the generic and
RTP-specific parts will be slightly revised. There was a question
from the MIB author whether ROHC profile identifiers are unique,
and Lars-Erik clarified that this is indeed the case. Juergen
further asked for more input on useful statistics, and once more
asked whether anyone is planning to implement the MIB. No positive
responses this time either.  Carsten remarked that maybe the
question needs to be asked in a different venue as the ROHC
implementers may not be around.

Draft: draft-ietf-rohc-mib-rtp-02.txt 

 - A ROHC profile for IP only (Lars-Erik Jonsson)

RFC 3095 defines profiles for uncompressed, IP/UDP, IP/UDP/RTP and
IP/ESP. People have asked for a profile for compression of IP
only, which sounds like a reasonable request for simplified ROHC
implementations and for use with new transports not supported by
ROHC. The profile is similar to ROHC IP/UDP. There are some issues
for further discussion. One applies also to the IP/UDP profile and
concerns the CRC coverage, but this has already been discussed and
does not seem to be any problem. Lars-Erik asked whether we should
add this to the charter, and there was support from the audience
to do so.

Draft: draft-jonsson-rohc-ip-only-00.txt 

 - Implementer's guide (Lars-Erik Jonsson)

There have been some minor changes to the implementer's guide in
the new version, based on mail list discussions. The scope of the
document has been discussed and is rather clear at this point: it
should supply additional clarifications to RFC 3095 for those
implementing the standard. The enhanced mode transitions proposal
is in some way an exception, but it does not change the standard
and is mainly there to point out that it is ok to do simplified
and enhanced transitions.

Most, or maybe all, content of this document will go into
RFC3095bis, so it will continue to live as an I-D until the Draft
Standard work is completed.

Draft: draft-ietf-rohc-rtp-impl-guide-01.txt

 - Implementation status (Lars-Erik Jonsson)

Three ROHC interop events have been held so far. At the last
interop, "Arctic ROHC" in Luleå, there were five implementations
present from Effnet, Ericsson, Nokia, RokeManor/Siemens and
Panasonic. Tests were carried out between almost all parties,
initial IPv6 tests were successfully performed and even
ROHC-over-PPP was tested. The Arctic ROHC participants suggested
to have another interop in November, but there is no host for that
event yet (Note: A host appeared the day after the meeting). As a
result of discussions at Arctic ROHC, a new mail list has been set
up for those who have participated in an interop. The intention 
with that list is to encourage interop participation and pre-
interop discussions.

One thing that obviously has been missing at previous interops
is an RFC 3095 test document, clearly defining what to test. Such
a document must be created, and should also be used to further 
keep track of the interoperability status for each test item. 

 - Way forward (Lars-Erik Jonsson)

The work for taking RFC 3095 further has started, but there are
lots of things to do to make this happen. The IP profile should be
finalized and brought to Proposed Standard. The architecture
document must be completed as a reference for the MIB, which must
be finalized and brought to Proposed Standard. An initial version
of an RFC 3095 test list document must be written, which should be
used as the basis for the next interop, yet to be scheduled.
Finally, we need to start working on an "RFC 3095 surgery plan,
i.e. outline how to split the document in Framework and Profiles.

Lars-Erik also made a general comment of the way things work in
the ROHC WG. We always seem to be behind schedule according to the
milestones. However, since one can count the number of really
active WG participants on two hands, we cannot handle that many
things at once. We have been focused on SigComp for a while, which
is now done, and now we start to allocate significant resources
for TCP. More active participation in the WG would be appreciated
in any case.

* Generic (Formal) HC notation (Mark West)

Mark gave a first presentation of what we have started to 
refer to as generic or formal header compression notation. The 
idea is to produce generic methods to describe a header
compression process, where the original header is split up in
fields, relationships between fields are identified, and encoding
methods are chosen from an available set of methods. The notation
will thus be a tool that can be used for future profile
developments. After using the formal notation to describe the
compression methods to use, a profile definition would then have
to define how the compressed fields are turned into bits on the
wire, but that encoding issue is not part of the notation.

Based on the current drafts and latest mail list discussions,
there are some issues we will have to discuss further. One is the
question about separate versus combined notation, where the WG
notation draft takes the latter approach and a counter proposal
is based on the former. The other issue is about how much details
should be captured by the notation. Discussions so far suggests 
that the notation should be independent of which bit-encoding is
used, although it should give generally useful "hints" to that
encoding process. A rule of thumb could be: "If a parameter can be
ignored by any set of encoding rules, then it is ok, while if it
is too suggestive or restrictive to a particular way of doing
things, then it should not be used. The more general, the better."

Mark also reported that some tests of the EPIC approach have been
conducted between RokeManor and University of Split, with
implementations based on the EPIC-lite draft. These tests seem to
indicate that this approach is a workable basis for generating
interoperable implementations. Carsten somewhat mellowed that
conclusion by pointing out that there has been extensive
communication between the two implementation groups, going beyond
just exchanging specifications, and Mark confirmed that point.

Lars-Erik noted that the goal is to simplify further work with new
profiles. One of the difficult things with the ROHC RTP
development was the generation of compressed header formats, which
were done by hand without a structured work method. We want to
have a notation so we can use automated encoding of the compressed
fields into compressed headers, or as a structured basis for
manual creation of formats. However, the notation today does much
more than that, and it does not produce an output representation
including only what is needed for compressed header encoding. Mark
commented that this is the question about using a combined
notation or not.  Carsten said that there are both advantages and
disadvantages of having a combined approach, but in this case the
advantages are probably dominating. Qian said that the key
question is that we need to efficiently label each field, which
would motivate a separate uncompressed notation. Mark answered
that it is not really necessary to know what the field is, might
just show up as syntax or a comment. However, as soon as we go for
separate notations, we need to label it to be able to come back to
it. There are some few cases that might benefit from having an
uncompressed notation, but most other cases would just get
messy. There was no clear conclusion, but the next draft version
will probably stick to the combined approach, more discussions
will have to follow on that.

Richard raised a question related to encoding. In EPIC or
EPIC-lite, encoding is a two-stage process. The first stage is the
field notation and compression of each field, and the second 
specifies how to convert these fields into a single compressed
header. Different methods could be used for the second stage, but
the notation must define methods for the first stage. This seemed
to be the common understanding, notation covers encoding of fields,
but not how to further create complete compressed header formats
out of that.

Finally, Carsten had some questions as a WG chair. First he
wondered why we have two notation documents. Mark and Lars-Erik
explained that Mark's document should had been a WG draft, but did
not ask for a WG document name in time for submission. At the same
time, an alternative submission was sent in. What will happen now
is that Mark will incorporate some material from the second draft
and resubmit it as a WG document. Carsten proposed that a small
design team should be set up to finalize this, and asked whether
two months is a reasonable timeframe. Mark answered that a couple
of months sounds plausible ("but don't quote me"). The last
discussion point was about what to do with this document.  After
some discussions, there seemed to be agreement on making this a
standards track document, as previously done with other notations,
such as the ABNF in RFC 2234.

Drafts: draft-west-rohc-formal-notation-00.txt
	  draft-liao-rohc-notation-00.txt

* ROHC TCP profile (Qian Zhang)

Qian gave a quick update on the TCP profile work. The TCP
compression requirements have been frozen, while the TCP behavior
document needs some more work. Currently, it provides an analysis
of the behavior of each field and some reflections regarding
short-lived transfers, implicit acks, the potential use of a
master sequence number, and shared data aspects. What should be
added is an analysis of what fields can potentially be replicated,
and how.

For the actual profile development, there have been extensive
discussions on the mailing list and the core issues have been
resolved. There is now agreement to only allow context replication
based on acknowledged contexts. Further, we have also agreed to
use a master sequence number to reference packet, although there
is no useful field for that purpose in the uncompressed TCP header
itself. The cost of having an MSN is expected to be low,
especially since it would not be required in all compressed
packets. The third core issue that has been discussed and resolved
on the mail list is about mode transitions for TCP. In the TCP
profile, there is no need for a four-way handshake, as in the RTP
case, since the packet formats are the same for the
modes. Lars-Erik pointed out that this means we will not allow
transition back to unidirectional operation, but that should not
be a problem. A single feedback message indicates to the
compressor that a feedback channel is available, and the
compressor can then expect to get nacks in case of failure. For
TCP, the concept of modes is thus not the same as in ROHC RTP, so
we should maybe just talk about Unidirectional and Bidirectional
operation.

There are no significant open issues left to resolve at this stage,
but we will have to wait for the notation work to progress before
the TCP profile can be finalized. Mark said it is important to keep
these two pieces separated, while Richard noted that we still look
at real life protocols like TCP when developing the notation.
Lars-Erik pointed out that the people working on the TCP profile
are the same as those working on the notation, so it should be
easy to keep these parts synchronized.

Drafts: draft-ietf-rohc-tcp-requirements-04.txt
	  draft-west-tcpip-field-behavior-01.txt
	  draft-ietf-rohc-tcp-02.txt

_______________________________________________
Rohc mailing list
Rohc@ietf.org
https://www1.ietf.org/mailman/listinfo/rohc