[rohc] ROHC Minutes, IETF 55

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

Marriott Marquis, Atlanta, USA
Monday morning, 2002-11-18

Chairs: Carsten Bormann & Lars-Erik Jonsson

Reported by: Lars-Erik Jonsson
Note takers: Pete McCann, Gorry Fairhurst
             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. Meeting time should
be used to advance difficult issues, not for presentations. We do
assume that people have read the drafts.

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.

Agenda:
 - Chair admonishments and agenda bashing   
 - WG and document status update
 - ROHC RTP, Draft Standard preparations update
 - Signaling compression
 - ROHC over wireless Ethernet media
 - TCP profile
 - Formal header compression notation

* WG and document status (Lars-Erik Jonsson)

Lars-Erik reviewed WG goals, milestones and document status.  The
Lower Layer Guidelines document and the LLA R-mode extension are
currently in AUTH48 and will thus soon be published. The SigComp
documents have passed IANA registration but are still waiting in
the RFC Editor's queue. ROHC has currently no documents on the
IESG table. At the moment, the WG has 5 documents related to ROHC
RTP and the Draft Standard process, 4 documents for the TCP profile
work (plus the notation document which is also to some extent part
of the TCP work), and one document for SCTP requirements. The SCTP
work is currently on hold due to a lack of interest in compression
of SCTP.

We will be few months late with the ROHC MIB, but that is a minor
issue. The LLA mapping examples document and the ROHC RTP Draft
Standard documents are not yet available, but will soon be. Lots
of preparation work for Draft Standard have been done, but this is
a long process. The TCP work is now progressing and is on track,
although we will probably have to adjust the finalization date a few
months. 

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

 - MIB & ROHC terminology and mapping examples

The MIB is now rather stable and it is thus time to read it and
comment. It will be updated once more to include support for the
LLA profile. The "Terminology and channel mapping examples" draft
provides reference material for the MIB and the goal is to have
these two documents last-called in the WG in December.

Drafts: draft-ietf-rohc-mib-rtp-04.txt
        draft-ietf-rohc-terminology-and-examples-00.txt

 - Implementation status & feature test list

Four ROHC interop events have been held so far. At the last
interop, "ROHC in the city" in Berlin, there were four
implementations present from Effnet, Ericsson, Acticom, and
ICR (Singapore). First extensive IPv6 tests were successfully
performed by Ericsson and Effnet, and initial testing of list
compression was also carried out between Acticom and Ericsson.
Preliminary reports on the results point to potential ambiguities in
the list compression specification, but this will have to be further
studied.

A test case document is now available in an initial version. The
purpose of this document is to specify a list of feature tests that
will have to be carried out to take 3095 further to Draft Standard,
and also to document current interoperability test status. This
document should be the basis for future interoperability tests.

Draft:  draft-ietf-rohc-rtp-rfc3095-interoperability-00.txt

 - Implementer's Guide

There have been two additions to the implementer's guide in the new
version, based on mailing list discussions. The first clarification is
about the interpretation interval for timestamp bits. RFC3095 defines
two different interpretation intervals, but it is not clear that
both these are used, and which one to use depends on the timestamp
encoding mechanism used. Normal W-LSB compression uses one interval
and timer-based compression uses the other. The implementer's guide
now explains this, and also how to reliably switch between them.

The other issue clarified is about profile negotiation. Profile
numbers are 16-bit identifiers, while only the 8 LSB's of these are
sent when initializing new contexts. This means that the negotiation
protocol must ensure that there cannot be two profiles with the
same LSB's available after negotiation. Two profiles with the same
LSB's are thus not supposed to be concurrently used over a channel.
There is no problem with ROHC-over-PPP in this regard. 

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

 - A ROHC profile for IP only, purpose & problem

RFC 3095 defines profiles for uncompressed, IP/UDP, IP/UDP/RTP and
IP/ESP. The ROHC WG has agreed to define an IP-only profile as a
complement to these. The purpose of this profile is to make the
RFC 3095 profile suite complete, to allow one with an RFC 3095
implementation to easily modify that for IP-only compression,
as a mechanisms to use for e.g. transport protocols not yet
supported by a ROHC profile. The intent is thus not to define a
ROHC-lite profile, that would be a different work item.

The main issue that has been identified for the definition of the
IP profile is the question of how to terminate the static chain
when there is no single protocol that would end the chain, as it
is for the case of UDP. The proposed solution is to terminate the
chain when there is anything other than IP/IPv6 in the Protocol/Next
Header field.

One thing that complicates the issue is the potential presence of
more than 2 IP headers. The profiles defined in 3095 can compress
one or two IP headers, but since the UDP header must terminate the
chain, compression would be totally disabled if there are more than
two IP headers. This is a non desirable limitation for the IP
profile. However, since the IP profile does not require one specific
header to terminate the static chain, a rule saying that the static
chain is implicitly terminated after a second IP header portion
would ensure that the two initial IP headers can always be
compressed. The question is whether it would be easy to provide
the means to compress an arbitrary IP header chain. Two potential
solutions for this were presented. One way could be to handle
additional IP headers with list compression. Another way could be
to allow the static chain to be of arbitrary length and add a
dynamic header portion to compressed headers for all IP headers
but the first two. The latter was suggested as the preferred choice
because it would be a minor modification, require no new data
structures and mean that the dynamic header portion would be
the same for IR, IR-DYN and Compressed packets.

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

 - Next steps

The work for taking RFC 3095 further has started, but there are
lots of things to do to make this happen. The MIB will be updated
and last-called in the WG during December. The IP profile will
be updated to address the issues previously discussed and last-
called in the WG. The test list document must be improved and
we should start collecting status on interoperability. Potential
findings from the Berlin interop must further be evaluated, and
the implementer's guide updated, if necessary. Finally, an initial
version of the "3095 surgery plan" must be produced.

Richard Price asked whether it would make sense to define an IP
profile also as part of the TCP work, which would probably be a
simpler profile. L-E responded that there might be different
reasons for having an IP profile, and nothing prevents us from
having more than one. The profile currently being defined would
be an obvious choice with 3095, but there could be another one
that is easy to implement with TCP. This is something we should
consider later on.

* Signaling compression

 - SigComp User Guide and testing (Richard Price)

Richard covered two documents, the SigComp User Guide and a new
individual submission with SigComp torture tests. The User Guide
is an informational companion to SigComp, providing a UDVM
assembly language and bytecode for well-known decompression
algorithms. The last update included an enhanced assembly
language, "raw" bytecode for each decompressor, and examples
of compressed messages. It has been proposed to add an
other decompression algorithm, TCCB, to the user guide. One
problem with that algorithm is that the TCCB compressor is not
defined in any referable documentation. Carsten made clear that
it is not part of our work to publish compression algorithms, and
the authors should consider publishing it elsewhere. Other items
that are under consideration for the next version of the draft are
error recovery considerations and explanations of resource
management issues. It might also be useful to add more detailed
message flows.

The torture test draft provides tests for each UDVM instruction,
focuses on boundary and error cases, and covers issues not
typically found in well-behaved code but that might be exploited
by malicious users. The current version only tests the UDVM, and
further tests are needed to test other SigComp entities, such as
the state handler and the dispatcher. Richard asked for additional
suggestions, but did not get any.

Finally, Richard announced that SigComp will be tested at the next
SIPit event in Stockholm, February 24-28. 

Drafts: draft-price-rohc-sigcomp-user-guide-01.txt
        draft-price-rohc-sigcomp-torture-tests-00.txt

 - SigComp Feedback (Adam Roach)

Adam gave an overview presentation of the problem addressed by the
SigComp NACK and SigComp recovery drafts, as well as the potential
solutions proposed. The problem could in general be expressed as
"when a SigComp message cannot be decoded by the recipient (for
whatever reason), the sender needs to learn of such a failure".
A couple of error scenarios where this would become an issue were
also presented.

Three potential approaches to the problem were then proposed.

The first solution would be to stay with what we already have in
SigComp and use application timeouts or signal by implicit means,
by setting the state memory size to zero. This approach requires no
additional standardization, but is not very efficient and requires
additional messages in the reverse direction and would add delay.
Carsten noted that there has been some experience that timeouts are
a problem, and given that we have two drafts might be an indication
there is a need to do something. Richard commented that the number
of drafts is not necessarily enough to prove there is a problem.
This might be tightly coupled to the actual environment, because one
might have different mechanisms available for solving this problem.
Keith Drage noted that this has been discussed also in 3GPP, with
the conclusion that it is not a 3GPP specific issue and should thus
be handled as part of our SigComp work in ROHC. Richard claimed that
at least the original problem statements can be solved by existing
SigComp mechanisms. It may be that we need new error codes to
recover more quickly, but we need error cases where partial failure
will happen. Adam commented that losing partial state in handsets
may not be likely, but in 3G architectures compartments might be
discarded in servers even if they are still needed. Keith suggested
that we should do some documentation, independent of the outcome of
these discussions. Richard and Adam argued whether current SigComp
would be good enough to solve the problems or not. Carsten noted
that some form of diagnostics mechanisms would be a useful addition
to SigComp in any case. Lars-Erik then asked the room whether there
were any real objections to do work in this area, with no response.
Richard wondered is this assumed additional standardization, to
which Carsten responded that this is something we will have to
figure out.

Adam continued with more material on the potential approaches. The
second solution would be to add a reset message to reset one or
all compartments. This approach is good because it should be easy
to implement and provide immediate recovery. On the other hand is
it a kind of "sledge hammer" solution, and there might be IPR
concerns to consider. It also only works if the recipient can
identify the compartment to which the message belongs.

The third approach is to define specific error messages indicating
the cause of failure, allowing the compressor to do fine-grained
adjustments. With this approach, error recovery will not be more
costly than necessary, various error cases can be handled, and we
would also get a debugging and diagnostics mechanism. Disadvantages
may be more complicated standardization and implementation, and a need
for stand-alone feedback messages. Interesting side effects of this
are the possibility to implement an optimistic compression approach,
and network diagnostics abilities.

Adam then presented some performance examples to compare the three
different approaches, and that was followed by a long discussion
about the error scenarios and the actual motivation for doing work
on this. There was no clear outcome, more than that the usefulness
for diagnostics might itself be a sufficient motivation. Carsten
noted that we will have to come up with specific examples, based
on clear assumptions, then we can take a decision.  

Drafts: draft-roach-sigcomp-nack-00.txt
        draft-liu-sigcomp-recovery-01.txt

 - Static Dictionary for SIP/SDP (Carsten Bormann)

Carsten reported about the SIP/SDP static dictionary status. For
version -04, the IETF last-call ended on November 15. There have
been some positive signals from the IESG, but no formal approval
yet. The problem with this document is that it tries to petrify
a snapshot of the SIP/SDP protocol development, and we really need
to decide on when is the right time to do this petrification. A
version -05 is already available with some minor changes.
Unfortunately, as soon as we tweak anything, the dictionary changes
significantly - about half the text of the document. Carsten asked
for comments on when to finally freeze this. Adam Roach answered
that the best time would have been last March, and now we should
freeze it as soon as possible. Zhigang Liu commented that 3GPP
would like this by end of this year, which Carsten concluded means
as soon as possible, and that is now.

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

* ROHC over Wireless Ethernet Media 

 - Motivation and possible approaches (Kris Fleming) 

Kris Fleming gave a presentation of the motivation for and high
level technical content of the "ROHC over Wireless Ethernet Media"
draft. WLAN and WPAN links are often bandwidth limited and would
therefore benefit from header compression. They have also typical
loss and delay patterns that would motivate the use of ROHC in
such scenarios. Since voice over IP is and will be commonly used in
these networks, header compression will continue to be useful. If a
generic solution for applying ROHC in these environments could be
defined independent of the physical layer technology, that would
simplify both standardization and implementation. Such a generic
solution should in that case be defined by the IETF.

Solutions that have been considered are ROHC over PPP over Ethernet,
since both ROHC-over-PPP and PPP-over-Ethernet already exist. The
drawbacks of combining these two into a complete solution are the
unnecessary overhead, and the unnecessary complexity. The advantage
is of course that all components already exist. Another potential
approach that has been considered is to reuse an existing protocol
for negotiation, but define something new for encapsulation. For
IPv6, neighbor discovery could potentially be used for negotiation,
but it is not really intended to discover link layer capabilities.

The proposed "ROHC over WEM" defines a simple negotiation protocol,
and an encapsulation. Kris gave a quick overview, and then asked
whether there was any interest in doing this in ROHC.

Carsten commented that a key question is where in the protocol stack
it would make sense to do this. In the original ROHC work, Ethernet
was completely ignored since adding header compression to it was
considered to be of less value, e.g. due to the minimal frame size.
In 802.11, the headers are rather large and are sent at a lower rate
than the data. The gain from header compression could then be
questioned. Greg Daley noted that with Mobile IP we might get lots of
tunneling headers, and that would increase the gain from header
compression.

Draft: draft-fleming-rohc-wireless-ethernet-med-01.txt

 - ROHC over Ethernet issues (Carsten Bormann)

Carsten had prepared some discussion material on this issue. We have
a pretty large design space here, and before we do anything we must
explore it so that we know what we are trying to invent.

First of all, there is the issue about which negotiation protocol
to use, if we would have to invent a new one. For IPv6, neighbor
discovery (ND) seems to be an obvious choice. For IPv4, one could
think of using ARP, but that sounds difficult at this point in the
evolution of this protocol. If PPPoE was used, we would get lots of
unnecessary things and still have to invent a new encapsulation. One
could also potentially think of using ND also for IPv4.

Secondly, we have the encapsulation issue. Ethernet requires padding,
which is neither needed nor desired over the wireless links. If we
do compression over the whole Ethernet, bridges between the wired
and wireless parts must know about the padding scheme and translate
or strip padding. This will easily get complicated. It might make
sense to do this in the wireless access points instead, but then we
would not get a generic scheme and it would be very unclear whether
this would be a ROHC WG issue.

A long discussion about the architectural placement of compression
in these scenarios followed. Pat Calhoun suggested that this should
be done by other bodies, for the links that would really benefit
from header compression. Kris argued for doing a general solution
and avoid having to do the work over and over again, while others
then noticed that link specific solutions would probably give
better gain, and we should remember that not all link layers would
at all benefit from using compression. Carsten concluded that all
comments just indicate that we do not have a clear architectural
choice, there are several possible options. It is also very unclear
whether this is appropriate work for the IETF and the ROHC WG. We
will have to continue these discussions on the mailing list.

* TCP profile (Ghyslain Pelletier)

Ghyslain gave a short overview of the changes and next issues for
the ROHC TCP profile. With a new editor, the document now looks
completely different, although the technical content has not at all
changed very much. The structure is now better aligned with 3095, 
and various redundancies have been removed. The mode concept has
also been removed to reflect previous consensus to make modes a
pure implicit thing for ROHC TCP. Compression always starts in 
a unidirectional manner, and switches to a bi-directional operation
once a first feedback packet is received. This has simplified the
document significantly. States and state transitions have also been
clarified.

The next step will be to define the inner workings of the context
replication mechanism. We have an understanding and agreement about
the concept, but there are much work left on the details. The goal
is to have most of this nailed down in the next version. Remaining
issues are then packet formats, and minor details in the compressor
and decompressor logic. Carsten asked whether we any quantitative
measure on the size of TCP flows that we are optimizing for with
context replication. Mark West commented that the requirements are
rather short on this, we have just agreed broadly what we mean, but
we have not put numbers to it. Carsten noted that we should remember
to stop tweaking when the impact is not significant anymore, and
Mark agreed that the important gain will probably be from saving
IP address overhead.

Drafts: draft-ietf-rohc-tcp-requirements-05.txt
        draft-ietf-rohc-tcp-field-behavior-01.txt
        draft-ietf-rohc-tcp-03.txt
        draft-ietf-rohc-tcp-enhancement-00.txt

* Formal header compression notation issues (Mark West)

Mark gave an update on the formal notation work, there have just
been some minor changes since Yokohama. An alternative way of
defining the mappings and a more implementation neutral definition.
The key goal has been to define reversible mappings between the
uncompressed and compressed field values. The pseudo-code has been
removed because it became too implementation specific. Pre- and
post-conditions are now used to capture mapping behavior. Mappings
are now composed from other mappings, which makes documentation
more compact and new mappings are easier to define. A mapping
example was presented.

The questions raised were mainly the same as last time in Yokohama.
Are we happy with the combined notation, is identification and
generation of meta-data part of the "grammar", and is there an issue
with the interface to the (unspecified) coding rules? There were
no comments from the room.

The way forward would now be to try to define the minimum needed
for interoperability, and then figure out how to make use of this
for compression of TCP.

Lars-Erik noted that there has not been much activity on the mailing
list, and asked whether there have been any inputs from others. Mark
answered that this there have really not been any. Lars-Erik then
pointed out that if we do this, it should be good enough so that we
do not have to change it every time we apply it. Those who think it
is a good idea are therefore encouraged to contribute to the mailing
list discussions. Carsten agree that we need a bigger group to work
on this draft, so interested people will have to speak up.

Draft: draft-ietf-rohc-formal-notation-00.txt

* Summing up (Lars-Erik Jonsson)

We thus have two new issues that we will have to discuss further,
SigComp Feedback/Recovery and ROHC over Wireless Ethernet Media.
We have agreed to do something to the former, while we still do not
have enough background material to decide exactly what to do. For
the latter issue, we will have to figure out whether it is possible
for us to do anything that makes sense and can be justified.

Thanks for today!
_______________________________________________
Rohc mailing list
Rohc@ietf.org
https://www1.ietf.org/mailman/listinfo/rohc