Subject: [rohc] Preliminary minutes from ROHC@IETF61, Part 1

From: "Lars-Erik Jonsson (LU/EAB)" <[email-masked]>
Date: Fri, 12 Nov 2004 17:42:39 +0100

ROHCers,

Here is a preliminary version of the minutes from the first
half of the ROHC session in Washington DC. Feedback is as
always appreciated.

BR
/L-E

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 mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/rohc