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