[rohc] Preliminary minutes from ROHC@IETF61

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

Hilton Washington, Washington DC, USA
Monday Morning, 2004-11-08

Chairs: Carsten Bormann & Lars-Erik Jonsson

Reported by: Lars-Erik Jonsson
Note taker: Christian Schmidt
Jabber scribe: Gorry Fairhurst

Morning session, 09:00-11:30
----------------------------

* WG admonishments (Jonsson)

Meeting time will 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. Also, all
contributors must be aware of the IPR principles, as stated by
RFC 3668.

* 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 towards Draft Standard
 - ROHC TCP and Formal Notation
 - ROHC RTP towards Draft Standard
    + Various ways to go forward
    + ROHC implementer's guide 
    + RFC 3095 in Formal Notation
 - LLA ROHC RTP Implementer's guide
 - ROHC over channels that can reorder packets
 - ROHC over 802 networks

* WG and document status (Jonsson)

Lars-Erik reviewed WG goals, milestones and document status. The
WG has 13 published RFC's, but no new publications have been made
since San Diego. The UDP-Lite profiles draft has passed IANA and
is expected to be published within a month or two. Four drafts
have been submitted to the IESG, the SigComp NACK draft and three
drafts related to ROHC-TCP. In San Diego, we said that we were 
about to update the milestones, but we had hoped to get the TCP
profile completed and submitted first, which we have still not
managed to do. The milestone update is thus still pending.

* Signaling compression issues

 - Applying SigComp to SIP (Bormann)

Carsten gave a summary of the three open issues for SIP over
SigComp. SigComp defines a default state memory size of 0, while it
has been suggested to mandate more for SIP, as it has been observed
that stateless compression for SIP/SDP does not give much gain. The
current proposal is thus to have 2K per state compartment, and 
require NACK support for a compressor that wants to make use of the
state memory. There were no SIP implementers in the room that had
any comments on this proposal.

Second issue is about the definition of compartments, as they need
to be well-defined to avoid accidental push-outs. The original
proposal was to use SIP dialogs, but another idea is to have three
different compartments for; registration related messages (R),
dialog-related messages (D), and subscription-related messages (S).
Question is, can this be clearly defined, and is (nr*R+nd*D+ns*S) in
any way worse than (n*D)? No comments were received from the 
audience.

Third issue left is the question on "TCP step-up", i.e. whether it
should be possible to start SigComp compression in the middle of a
SIP TCP connection? In many architectures, this requires a SigComp
shim layer to add SIP parser, which is a non-desirable requirement.
The solution would thus be to open another TCP connection to start
SigComp.

There is a pressing need to make this document available to 3GPP in
an updated form, and Carsten promised to make sure an update will
be available by the middle of next week, at latest.

Draft: draft-ietf-rohc-sigcomp-sip-01.txt

 - SigComp towards Draft Standard (Bormann)

Interoperability test events for SigComp have been held at SIPit.
Now we need to collect interoperability test status and create a
matrix document with all "features" we can identify, and endure 
there are at least two independent interoperable implementations for 
every feature. After that, we are ready to bring SigComp, RFC 3320,
forward to Draft Standard. An ancillary document that might go with
this is of course the implementer's guide, but potentially also the
User Guide (draft-ietf-rohc-sigcomp-user-guide-00), as well as the
Torture Test Guide (draft-price-rohc-sigcomp-torture-tests-02),
which are both expired individual drafts, expected to provide useful
material for implementers. These two should thus be resurrected, if
we find people interested, as original author is not active in the
WG anymore. Mark West expressed potential interest in doing this,
and we should continue discussion on the list.

RFC: RFC 3320
Draft: draft-ietf-rohc-sigcomp-impl-guide-03.txt

* ROHC TCP & Formal Notation (Pelletier)

Three of our five drafts related to ROHC TCP, requirements, TCP
behavior, and Context Replication, have been submitted to the IESG.
However, the actual specification, consisting of the TCP profile
draft and the Formal Notation, are still not finalized, although we
are getting closer to completion. In latest update, packet formats
have been redefined based on an updated and simplified FN. We need
somewhat to start doing a thorough review of the packet formats 
themselves. In the FN, external coding methods (using underscore 
syntax) are gone and Profile Specific Encoding Methods are instead
defined. Further has the formal meaning of annotations been removed
and replaced by a note in the ROHC-TCP profile. The encoding methods
for crc's have also been combined into one general method with
arguments, and the environment of the let statement has been
clarified. There are now mainly two issues left, about the 
definition and use of control fields, and how to completely capture
list encoding in FN.

The problem with list compression as it currently stands is that if
one option is not present the entire list compression fails. Carsten
noted that there are many ways to solve this, and suggested to try
to keep the mechanisms simple. Ghyslain asked whether we should
simply use English language, as we do for header chaining, although
that is not formal notation. The concern with this approach is that
we seem to be removing many things from the FN just because we can
not manage to make it work, which makes the value of the FN clearly
questionable. Carsten suggested that we could make use of the 
recursion we have in the FN, which Ghyslain commented would not look
very good. Carsten agreed but thought it might be a fast way to get
to a resolution.

The control field concept currently used in the FN and TCP profile
has been questioned. Carsten means this goes against the core FN
principle of only defining packet formats and encoding between
uncompressed and compressed values, as control fields are rather 
functionality for interacting with the contexts. The alternative
approach suggested is to provide control field data to packet
formats as parameters. Others argued that control fields are very
similar to other fields, it is just that they do not appear in any
uncompressed header. Carsten went through an example with the two
different approaches, and the conclusion was that the current way
with control fields should be kept, but their meaning must be more
precisely defined. 

Ghyslain then talked about the way forward with ROHC-TCP. Work on
the FN has kept us away from the actual work on TCP compression, and
still do. WG resources are also at a minimal level to get any work
at all done. We should ask ourselves whether we really think we can
manage to get a workable FN-based solution, and how much time we can
spend before we start reconsidering Box Notation. Anyway, in any
case we still need 2 committed reviewers for each document. We hope
it is still possible to issue WGLC by the end of November. Carsten
raised a couple of issues that he believed might still lack complete
resolutions. Ghyslain answered that these should all be resolved by
the latest update, but encouraged review of the details.

Drafts: draft-ietf-rohc-tcp-08.txt
        draft-ietf-rohc-formal-notation-04.txt

* ROHC RTP towards Draft Standard

 - Introduction (Jonsson)

Lars-Erik gave an overview of the various approaches available for
taking RFC 3095 further to Draft Standard. At an early point we saw
that it would be a good idea to split the current document into two
separate parts, framework and profiles, and this was thus our
original plan. However, during implementation we have identified a
number of more or less complicated ambiguities, which so far have
been documented in the implementer's guide. These issues will have
to be incorporated when going through the update process for 3095,
and it is then not clear whether we can go directly to DS, as the
changes might be seen as non-trivial. We also know that implementers
have expressed real concerns about the complexity of RFC 3095, and 
we know by now that if we had done it today we would simplify things
significantly. When discussing the way forward with 3095, another
potential option is to actually redefine the 3095 profiles based on
our experience and standardise simplified profiles, which will then
be given new profile numbers. If we go this path, there are several
aspects to consider. Will we be able to go to DS with these new
profiles? What happens with the current profiles, which are used by
other bodies like 3GPP. With this approach, we will actually produce
a new standard set that is not interoperable with the current one. 
Carsten noted that if we only use existing solutions from 3095, i.e.
stick to simplifications, we should be able to get to DS as we will
have tested interoperability for all features. There was a comment 
from the audience that the 3GPP reference to 3095 would not be a
problem as 3095 will stay as it is. Lars-Erik noted that 3095 do has
errors, which means we should ensure we provide error-fix documents
for 3095. It was suggested that could be done as an appendix to the
new profiles, but after discussion it was agreed it would make more
sense to keep that as a separate document. Lars-Erik concluded that
the sense of the room was to focus our effort on getting things
right and say this is what goes to DS, instead of spending resources
on fixing the old stuff. Someone in the audience asked for examples
of what can be simplified. Examples mentioned were list compression,
some other rather complex packet type combinations, and other 
redundancy in functionality that only gives minimal compression 
gains. The concept of modes could potentially also be simplified.
Many of these simplified solutions are currently being used for the
TCP profile, which means we have a rather good knowledge of both 
what should be made simpler and how it can be achieved.

RFC: RFC 3095
Drafts: draft-ietf-rohc-rtp-rfc3095-interoperability-03.txt

 - Implementer's Guide (Jonsson)

The implementer's guide has been updated three times since the last
IETF. A new chapter 7 has been added on Context management and CID
re-use, as discussed and agreed on the mail list. A new section 8.12
on ack usage in O-mode has also been added as a response to 
questions from implementers, based on the outcome of the discussions
that followed from that question. 

There is still no conclusion on the question about the potential use
of an implicit slope to compress and decompress timestamps. This is
an important issue that must be resolved to ensure interoperability.
Ghyslain noted that RFC 3095 does not define the concept of slopes,
one has to really over-interpret the document to get to this. Carsten
asked whether anyone believes we have enough material in 3095 to
even get slopes working, and expressed some doubts. Ghyslain asked
for more chair support in this discussion, as we should ask the list
to prove both that the slope concept exists in 3094, that it in 
needed, and that it works. We could of course spend significant
efforts on writing a document to summarize all aspects of slope
versus non-slope operation, but Ghyslain suggested we might not have
to do that if chairs get more involved in the discussion.

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

 - RFC 3095 in Formal Notation (Bormann)

Carsten gave a quick presentation on an ongoing work he is doing on
defining packet formats for the profiles in RFC 3095 with formal
notation. The goal is to get semantic checker for ROHC-FN to find
typos, inconsistencies, and missing pieces, as well having a more
formalized and consistent way of defining packet formats. Ghyslain
commented that although this effort is good, it has a tendency to
take focus away from the actual work, and so far formal notation has
mainly made the work harder. Carsten responded that 3095 took a lot
of work to complete too, and box notation is not always very
accessible either. Existing implementers are comfortable with box
notation, but new and simpler profiles could attract new
implementers. This is work that is currently done outside of the
ROHC WG, we will consider it when there is more results to look at.

Draft: draft-brinkmann-rohc-3095-fn-00.txt

* LLA ROHC RTP Implementer's guide (Sandlund)

During implementation, a bug was identified in RFC 3242 that makes
the CSP packet interoperable. The ROHC CRC is calculated over the
whole uncompressed packet, including length fields, which are 
normally inferred from the packet length. However, with CSP the
payload is dropped and the packet length can therefore not be
inferred anymore. Through discussions on the mail list, it was
agreed to add a two-octet payload length field to the CSP, as the
overhead should not be a problem, considering the expected use of
the CSP. This has been described in the new LLA implementer's guide,
along with a clarification that CCP verification needs inferred 
length fields to be stored in context. One additional clarification
should be added in an updated version, correcting a confusing cross-
reference to RFC 3095, which might be interpreted to include more
than was actually intended.

Carsten  asked about the implementation status of LLA, and Kristofer
answered that he has a complete implementation, but he is not aware
of any other implementations. 

Allison Mankin pointed out that this does looks more like a bug fix
than an implementer's guide, and should be published with a proper
label. Chairs will discuss the further handling of this with Allison. 

Draft: draft-ietf-rohc-rtp-lla-impl-guide-00.txt

* ROHC over channels that can reorder packets (Pelletier)

Ghyslain just wanted to remind people of the existence and purpose
of this document. The goal at this point is to produce an
Informational document, not to update any standard. If we want to do
some actual standardization work later on, we will be able to use 
this document as a reference and problem analysis. We know now that
ROHC has good potential to be used also if reordering can happen,
although there are a number of issues to consider. Carsten asked
about how ECRTP differs in its ability to handle reordering. 
Ghyslain answered that the situation is similar for ROHC and ECRTP.
ECRTP can handle some reordering if properly implemented, but there
is nothing in the standard that explains how to do that, and the
compression efficiency will be significantly affected. There is a
master theses to be published at Luleå University on the subject of
ECRTP over reordering channels. Allison reminded people of the
ongoing work on header compression over MPLS, where they are meant
to look at both ROHC and ECRTP. Lars-Erik asked about the status of
that work, and where it is supposed to be carried out. Allison said
it is mainly an AVT activity, with some MPLS involvement. The
requirements are done, and now it is time to start working on
solutions, based on existing IETF solutions. Someone in the audience
asked whether ROHC would be a possible candidate, and Allison 
responded she believed that would be a reasonable assumption. It
could be a good idea to write up a similar document as the ROHC over
reordering analysis also for ECRTP, making it easier to compare the
two and go further. Allison said she will feedback this to AVT, and
she also encouraged people from ROHC to take part in the AVT work on
header compression.

Draft: draft-ietf-rohc-over-reordering-00.txt

* ROHC over 802 networks (Bormann)

Carsten Bormann gave an overview of his individual draft submission
on ROHC over 802 networks. We have seen interest in this before, and
now there are several new forms of 802 networks that could make use
of header compression. In general, being able to do ROHC over any
link technology requires two things to be defined, encapsulation and
negotiation. Carsten claimed that although it is not obvious how to
do negotiation, the challenge is to find a proper encapsulation 
solution, as that is the key both to ensure one can get any gain at
all from header compression, as well as to make the solution 
deployable. A proper encapsulation should provide length information
and try to minimize overhead, and most encapsulations that exist
fail at least when it comes to overhead. In most of these systems, 
there is a little bit over Ethernet, requiring a minimal packet
length of 46 bytes of payload. Considering that we would like to
compress over a chain of bridged links where the bridges are not
aware of compression, we must find a way to get the bridges not to
insert padding, and encapsulation must be robust to padding. To get
length information into the packets, Carsten suggest to use 802.2
LLC, with "Length field" instead of "Ethertype". Demultiplexing must
then be handled in the payload, with an SSAP/DSAP identifier. Gorry
noticed that IEEE claims to control these identifiers. Ghyslain asked
whether this work really belongs in ROHC, which Carsten agreed is a
very good question to ask ourselves. Gabriel Montenegro recommended
interested ROHCers to come to the "IP over low-power WPAN" BOF.

The draft currently focuses on the encapsulation part of the problem,
but will of course have to address also negotiation if we manage to
get a proper encapsulation defined. We also have to consider
multicast and broadcast scenarios, where negotiation could be made
in form of announcements and/or pre-configuration. Gorry asked how 
ROHC itself would work in such scenarios, and Carsten responded that
we already have the U-mode operation.

Draft: draft-bormann-rohc-over-802-00.txt

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