[rohc] ROHC Minutes, IETF 53

["Lars-Erik Jonsson (EPL)" <[e-mail]>]

Minutes of the ROHC WG sessions at IETF 53
==========================================

Hilton and Towers Hotel, Minneapolis,MN
Tuesday morning and afternoon, 2002-03-19

Reported by: Lars-Erik Jonsson
Note takers: Christian Schmidt, Hans Hannu, Mark West
             and Jonathan Rosenberg

Slides are available at http://www.dmn.tzi.org/ietf/rohc


Morning session, 0900-1130
--------------------------

* WG admonishments (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 (Bormann)

Carsten presented the proposed agenda, which was accepted without
modifications.


* WG status (Jonsson)

Lars-Erik reviewed WG goals and milestones. The RTP part is done,
while most of the other work is started, although we do not yet
have WG documents for all items (SCTP profile, UDP-Lite profiles,
and LLA implementation examples are so far only discussed in 
individual Internet Drafts). SigComp was due in January, according
to the milestones, and is thus late. However, the work is now
progressing quickly, and should soon be finalized. The SigComp
security evaluation, currently listed as a separate WG document,
will go into the base SigComp document. Finally, the preparation
for RFC 3095 draft standard has not yet started.


* Document status (Jonsson)

RFC 3095 and RFC 3096 are the only WG RFC's published, so far.
Three more documents, "ROHC over PPP", "0-byte requirements", and
"LLA RTP profile", have been approved and are currently in the
RFC-editor's queue. Two documents, "RTP lower layer guidelines",
and "LLA RTP R-mode", have been submitted to the IESG, passed
IETF last-call, and are now awaiting IESG approval.

Drafts: draft-ietf-rohc-over-ppp-04.txt
        draft-ietf-rohc-rtp-0-byte-requirements-02.txt
        draft-ietf-rohc-rtp-lla-03.txt
        draft-ietf-rohc-rtp-lower-layer-guidelines-03.txt
        draft-ietf-rohc-rtp-lla-r-mode-02.txt


* New mailing list (Jonsson)
 
The ROHC mailing list had lots of spam, and in the process of 
taking actions against that, it was decided to move the list to
"ietf.org". The old list, [e-mail], is now closed, and
all subscribers have been moved to the new list, [e-mail].
The new list is subscriber-post, with other messages moderated 
by Lars-Erik, who checks incoming mails and filter Spam. This was
applauded by the working group!
 

* Signaling compression

 - Introduction (Bormann)

Carsten reported that there had been an ad-hoc meeting on Sunday
evening with SigComp authors, ROHC chairs, and various 3GPP people.
The intention with that meeting was to exchange information, and
make sure we have not missed anything or made assumptions that are
not valid. The material presented there has been updated with
inputs from that meeting, and will be the basis for the following 
meeting discussions at this session. 

We are doing this work mainly to minimize connection setup delay,
and that is different from previous work, which was motivated by
bandwidth saving needs. To deal with middle call interrupts is a
secondary goal. Focus is on compression of SIP and SDP, but the
solution should be generic so that it can be used for e.g. RTSP,
and possibly also for DNS and RSVP. Details may of course be
different when considering new protocols. Motivations and
objectives for the work are discussed in the requirements document.

When we started to look at this issue, we found that it would not
be a simple task to choose a compression algorithm, since there are
hundreds of them and they are all different. To select one or two
standard algorithms had been one way, but especially IPR issues
would make that a hard thing to do. Therefore, we started to look
at the possibilities to let the compressor completely control the
decompressor. We have designed a universal decompressor virtual
machine (UDVM), which gets an executable decompressor uploaded from
the compressor. There are therefore no compression schemes in the
standard and any compression algorithm can be implemented by a
compressor. The UDVM can be visualized in two ways - like an
adaptive version of Deflate, or like a Java virtual machine, but
much simpler and optimized for compression. The available
instruction set is designed for its specific purpose, and selected
for minimum code size. Simple algorithms would require about 50-70
bytes, while more complex ones gets slightly bigger. In general,
an algorithm should require 50-200 bytes to be uploaded from
compressor to UDVM.

 - Overview (Bormann)
 
SigComp has been envisioned as a shim layer between the application
layer and the transport layer. However, although this is where it
is located in the architecture, to call it a shim layer might not 
be quite correct, since the interface from SigComp towards the
application is more complicated than with a normal shim. Anyway, it
is independent from the underlying transport protocol, and therefore
supports arbitrary transports, such as per packet compression for
e.g. UDP, and per-stream compression for e.g. TCP. Compression is
either done per-message, or by using state references, and the 
decompression algorithm to use is either uploaded by the compressor,
or an already present one is referenced. 

Since stateless, per-message, compression is not as efficient as
dynamic compression, it is beneficial if previously established
state can be referenced for improved compression. There are
several ways to know which states have been established at the
decompressor. A compressor can utilize application knowledge,
usually referred to as implicit acknowledgements, or rely on
explicit acknowledgements, state announcements, sent from the 
decompressor for each state established. Further compressed
messages can then refer to these established states. A compressor
can thus itself decide if dynamic compression should be implemented,
and in such case also which mechanisms for dynamic compression to
use, which seems to be a useful flexibility since there is potential 
IPR concerns with these mechanisms. For various reasons, including
security aspects, state identifiers are cryptographic hashes over
the state information. To reference a state, the compressor thus
needs to be able to build a crypto hash over the state, which is
equivalent to saying the state must be known by the compressor.
Further, state must never be saved by a decompressor without 
permission from the application to do so.

The UDVM approach with possible state references means that there
is no need to negotiate anything. A sender must know that the other
end supports compression, but the rest of the information used to
optimize things comes in the ways of announcements of additional
capabilities, and/or available states. One end can tell the other
end that it has the Deflate algorithm, and that would be done with
a state announcement. It should be noted that the usefulness of
such state announcements is questionable, since it is very efficient
to upload an algorithm. As an example, Deflate requires about 66
bytes to be uploaded, so considering also the additional rtt 
required for announcements, announcements may cost more bandwidth
than what they can save.

The initial compression ratio can be significantly improved with
a mandatory, application-specific, state. Such a mandatory static
dictionary should be defined, initially for sip. This predefined
sip dictionary would be selected and basically fixed forever,
otherwise we would be back to the negotiation issue. Note however
that this is an application specific item, and outside of scope
for the SigComp protocol. It had been suggested to do this
work within the sipping wg, with a small design team of sip, rohc,
and 3GPP aware participants. Goal should be a small but useful and
reasonably future-proof dictionary for sip/sdp.

 - SigComp documents (Bormann)
 
Currently, we have five WG SigComp documents available from the ID
archives, but two of them, sigcomp-udvm and SigComp-algorithm are
old. Requirements are in draft-ietf-rohc-signaling-req-assump.
The base SigComp document is now draft-ietf-rohc-SigComp, which
defines framework and UDVM, transport plus per-message compression.
A second document, draft-ietf-rohc-sigcomp-extended, describes in
more detail how to implement enhanced mechanisms, such as stateful
compression based on sharing and reusing state in each direction.
This latter document is informative, since implementation is done
in the compressor only, so the material has been kept out of the
base SigComp. Also, there are known IPR concerns with these enhanced
implementation mechanisms, so it is nice to have it in a separate
document. In this way, we get a basic solution which is, to our
knowledge, IPR free, and an enhanced version which has known IPR
claims, especially covering implicit and explicit acks. Note that
although we are currently not aware of any IPR on the base solution,
we can not know if there are IPR's anyway. The extended operations
is only informative, but we need to finish it together with the
baseline SigComp, to make sure the base specification has everything
to make the extended operations implementable.

A forth document is planned, but does not yet exist as an Internet
Draft. The document is intended to be an informative user guide, 
making life easier for implementers of SigComp. There are already 
many ideas for what should be in this document. One is an assembly
language for interchanging UDVM code. It could further include some
example decompressors, such as lz77 simple, deflate, lqx, etc. Other
items that have been brought up as potential content for this 
document are text on what needs to be done to put SigComp in a
new environment, for RTSP guys when they come along, and various
hints for UDVM implementors. There have been many good mails on
the list regarding efficiency, and these should be captured. 

Drafts: draft-ietf-rohc-signaling-req-assump-02.txt
        draft-ietf-rohc-sigcomp-05.txt
        draft-ietf-rohc-sigcomp-extended-02.txt

 - SigComp architecture issues (Bormann)
 
Four different, but to some extent related, architectural SigComp
issues have been under discussion, and are more or less solved. 
     1) Discovery vs. SigComp 
     2)	Multiplexing (compressed vs. Uncompressed)
     3) Integration into an application protocol
     4) What is needed to interface with an application

  (1) SigComp discovery

The issue of how to invoke the SigComp shim, including how to
discover that the other end supports SigComp and how to indicate
that messages are compressed, has been discussed several times
before. We started out waving our hands, and the issue has been
"solved" many times. However, this turns out to be much harder than
we have thought. We must find a solution that fits into the existing
application discovery architecture, this is not only about SigComp.
The old tricks may not work that well anymore. We used to overload
schemes, http port 80 became overloaded by https by assigning a new
port 443. Different ports have been used for different things, but
we are now running into a combinatorial explosion, and there are
many things you may want to do. There might be many versions of
both security and compression, and other shim layers may turn up.
Since there is only 2^16 ports, one can not get a port for each, so
a new architecture is thus needed, says the IESG. We cannot go
ahead with a scheme that tries to perpetuate this. This is hard,
and there really are no pre-cooked answers. 

For the immediate pressing issue, SigComp in 3GPP release 5, this
should not be a big issue, since they have discovery for pcscf
already, and it should be quite easy to put SigComp in there as
another item to discover. To get done in time for 3GPP, and since
the general issue is hard to solve, the proposal is to not at all
solve the discovery issue in SigComp. Keith Drage pointed out that
in 3GPP, both UE and proxy will simply have to support it, and thus
its not even needed in discovery. Carsten responded that using 0
bit discovery is ok, thus mandating SigComp. Lars-Erik pointed out
that it still does not mean the use of SigComp is mandated in 3GPP,
only the support for it in all entities.

  (2) Multiplexing mechanisms

When leaving discovery out of SigComp, and especially when it
might be avoided by making SigComp support mandatory in certain
environments, we need a way to distinguish compressed messages from
uncompressed messages, which works independent of whether external
multiplexing mechanisms are present or not. Current text says you
can use different ports, but that assumes an external mechanism we
can not expect to have available. We have therefore discussed to
make SigComp messages self-describing. So, if there is no port or
other external multiplexing mechanism, one can look at the message
itself and figure out if it is a compressed message or not. It has
been proposed to use the initial 5 bits for this, with 11111xxx for
SigComp compressed messages. Ascii start with zero, and this also
works for utf-8. Further, it will make sure underlying RTP rohc can
distinguish SigComp messages from RTP when initiating compression
profile (10xxxxxx is normally treated as potential RTP). 

The proposal is thus to provide the above multiplexing mechanism
within SigComp, but also allow other external mechanisms to be
used, such as port multiplexing, since its related to discovery.

  (3) Integration into an application protocol

SigComp currently has a number of application dependent parameters,
to be defined for each application of SigComp, e.g. for SIP over
SigComp. However, we expect to be able to reduce the number of
parameters significantly by coupling them together, and/or by
defining default values or default minimal values for them on a
general SigComp level. If there are any parameters left after that,
we must now at least define values for them for the SIP case. More
discussions on this followed when the UDVM was discussed.

One application-specific parameter that we should define for the
combination of SIP and SDP is a static dictionary, since that would
significantly improve the compression efficiency, at least for the
initial messages. However, this should really be static, and must
not be changed every week. It should thus be about as static as
port numbers. Although the compression efficiency might deteriorate
over time as new things are added, this should be a negligible
problem. Questions were raised about various upcoming or future
additions that we might want to include. Carsten responded that
if sip uses FLOP in two years, we should add that now. But, we
do want to keep the dictionary small. If it is too large, we would
increase minimum size of certain parameters. When talking about 2kb
UDVM implementations and a 1500 byte mtu, dictionary more than 1500
bytes would be a problem. Jonathan Rosenberg proposed to have
dynamic dictionaries, but that is still possible to have in
addition to the static dictionary. The point with a static 
dictionary is that it does not have to be uploaded over the air,
and it can be used immediately, without any announcement. 

Carsten concluded that we will build a design team to define a
static dictionary for SIP/SDP, and the AD's have suggested to do
this within the Sipping WG. Richard and Carsten will participate
from the ROHC side, and we will figure out who to get from the 
sip/sdp side. 

  (4) Interfacing the application

The state management assumes that for each incoming message with
state creation, the application will be able to tell if message
had enough merits to allow creation of state. This implies a
stronger coupling between application and compression than we
initially had envisioned, and it gets worse. When the application
allows a state to be saved, it must provide an endpoint identifier
for the sender of the message, which can be used by the SigComp 
entities to control state memory allocations. How to find unique
identifiers is a difficult issue, although it is outside the scope
of SigComp itself. Further discussions were deferred to the mailing
list.

 - Timeline and document dependencies (Bormann)
 
3GPP is urgently waiting for this work to finalized, so important
questions are when we expect to be done and which document 
dependencies we have. Although it is only informational, the
extended operations document must be available at same time as base
draft, since that is the only way to verify completeness of the
base draft. The requirements document should also be simultaneously
published. but the user guide will wait for various reasons. First
of all, it is not yet started, further it will benefit from more
implementation experience and become more useful when more complete,
but will take some time to grow. As an informative document, it will
also be useful already while its an Internet Draft, since there is
no need for last call before you can use it. It is thus ok to leave
it for much later, and have it live as a Internet Draft for a while. 

The authors believe we can have an updated (-06) version of SigComp
on April 5, along with an updated (-03) version of the extended
operations document. Hopefully, the documents are then ready for
WG last call. Keith asked when this means we can see a last call,
and Carsten deferred that question to Lars-Erik's summary of the
procedural issues, to follow in the end of the SigComp session. 

 - The universal decompressor and the state handler (Price)

Richard went through the changes since Salt Lake City, and the open
issues identified on the base SigComp draft. Basic SigComp is 
really about three things, the compressor, the decompressor (UDVM),
and state handling. The compressor basically does not need to be
covered, since its implementation is a local decision. Simple
compression algorithms can be programmed directly, while more
complex ones would require a compiler to generate the byte code,
to be uploaded to the decompressor (UDVM). Byte code compilers may
be subject to IPR, as well as the algorithms themselves might be.

News in SigComp -05 were then discussed. Variable length encoding
for operands has been added, and this resulted in a reduction on
the byte code size, e.g. from 96 to 47 for lz77, and from 132 to 66
for lzw. The ability to decompress stream data has also been added,
and a number of new UDVM instructions have been included, such as
instructions for saving and retrieving state, for bit manipulations,
and for initialization. 

To simply the scheme, it would be desirable to fix several of the
application dependent parameters currently listed, and there is 
probably no need to specify most of those on a per-application
basis. Richard suggested to remove the max-expansion-size parameter,
since the first message might possibly be expanded a lot. The buffer-
size and udvm-memory-size parameters are correlated, and the minimum
values for compressed and uncompressed data should be based on the
udvm-memory-size parameter, which will then be the only of those
parameters left. Further, we should remove minimum-hash-size, and
make it be a decision made by the compressor. Cycles-per-message
could also be removed by fixing it to 1000 for all SigComp usages.
Carsten suggested to change some fields in the decompressor
announcements so that maximum-state-size could be announced. In case
an endpoint can not save state, it would announce it is stateless.
The cycles-per-message parameter should also be fixed for SigComp.

Further, Richard wondered whether any UDVM instructions should be
added. Carsten proposed to add SHIFT and MODULO, since if we do not
do it now, it will never happen. Jonathan pointed out that the UDVM
could be upgraded later, but it was agreed that upgrading the UDVM
is undesirable since it requires announcements of enhanced versions.
It would thus be great if we could include full instruction set
already in the initial version of the UDVM. Richard asked if more
CRC's should be added, and Carsten proposed to add a UDVM parameter
for the CRC polynomial. Finally, it was discussed how many values
there should be for UDVM parameters. The proposal was to fix e.g.
six or seven values for UDVM memory size, which was also agreed.
Overall, the impression was that the open UDVM issues are minor,
so we could consider that part as more or less finished. 

The second part covered by Richard was the state handler, which is
a new functionality added after the Salt Lake City meeting. State
can be saved, but only with permission from the application. State
is saved and referenced using a hash, so a malicious user cannot
access state without knowing it. It was proposed to make state
identifiers flexible in size when referencing them. A decompressor
would always save them as 16 byte hashes, but a compressor could
choose to reference with any size between 6 and 12 bytes, depending
on collision probability.

Currently there is a minor problem with the acknowledgement schemes
defined in the extended operations document, which are caused by
the way the base SigComp/UDVM works. The problem is that if e.g. sip
messages are used as implicit acknowledgements, it is the compressor
that decides to initiate it, but with explicit acknowledgements, the
decompressor decides. This can be solved by letting the compressor
initiate also explicit acknowledgements by combining appropriate UDVM 
instructions, and such a solution should be possible to allow for in 
the base SigComp without stepping on any known IPR. There were
therefore no objections to do so.

Some additional issues were then discussed. The first one was 
whether it should be possible for the compressor to choose which
hash to use. UDVM instructions could be provided for md5 and sha1,
and since there seems to be no security risks with that approach,
this was agreed to be a useful feature. The rest of the discussions
were about state creation, state deletion and priorities for states.
There were some questions on whether state-free can be made secure,
and Jonathan suggested to keep things simple and leave things out
that are not obviously needed. Carsten responded that we have done
a lot of trimming from -04 to -05, and that was the major difference
between the two versions. It was then agreed to add the above
mechanisms for state control. 

 - SigComp extended operations (Hannu)

Hans Hannu gave a quick update and status presentation for the
SigComp extended operations document, which is an informational
document describing how various enhancements can be implemented
based on the mechanisms provided by the basic SigComp and the UDVM.
This material has been placed in a separate document because it
is pure informal, describing special implementation tricks, but
also because there seems to be potential IPR's associated with
these implementation tricks.

The most important mechanisms described in the document are explicit
acknowledgements, which enables dynamic compression based on
previously compressed messages, shared compression, making it 
possible to share compression states between compressor and
decompressor, and state management methods, such as state rollback.

Since Salt Lake City, the document has been synchronized with the
SigComp document, and they do now fit together. An architectural
description of explicit acking has been included, and some
additional mechanisms have been added. Since the current draft was
announced, some modifications have been agreed, such as the way
explicit acking is enabled, which now does not require extensions
to the announcement format of SigComp. The code for enabling these
mechanisms are now fully controlled by the compressor. The open
issues with this document were previously discussed as UDVM issues,
since most of them relates to which instructions are needed to
implement these mechanisms. UDVM byte code for implementing extended
operations was shown, and is rather short, although it has not yet
been fully verified.

 - Security aspects (Bormann)

Carsten gave a presentation on the security concerns with SigComp,
and how these issues have been addressed. The security goals are
simply to not create any new risks, worsen security of existing
application protocols, or hinder deployment of application security.

For confidentiality, i.e. snooping into state of ther users, the
use of cryptographic hashes as state identifiers with a minimum 
length of 6 bytes is expected to provide a sufficient protection.
Longer identifiers of up to 12 bytes are recommended, depending
on the risk of state collision for each specific environment.
Snooping of state identifiers should not at all be a problem, since
one could not get any more knowledge from that than by looking at
the message itself.

For integrity of messages, SigComp itself will not help, but might
jeopardize it. An obvious attack would be to fake state or make
unauthorized changes to state. However, state can not be destroyed
or changed by a malicious sender, it can only add new state. Fake
state should only be a problem if memory limitations would cause
losses from FIFO, making this a DoS problem rather than an integrity
problem, and we rely on endpoint identifications provided by the
application to avoid this.

When considering other DoS attacks, there are a number of aspects
to consider. SigComp only generates one decompressed message for
each incoming message, so the usage of SigComp does not change the
vulnerability of the application in that regard. SigComp could 
potentially make messages larger and an attacker could then send
small packets that are decompressed to large ones, which is a risk
the application must be aware of. Considering attacks on SigComp
itself, the obvious attack would be to fill it with state, but that
can only be done with consent of the application. SigComp should
therefore not add any such vulnerabilities, compared to those
present for the application itself. Finally, another potential
attack on SigComp itself would be to send messages with "looping
code". To avoid this, we will define an upper limit for the number
of "CPU cycles" that can be used, e.g. 4 cycles per bit plus 1000
cycles per compressed message. The problem would still be there,
but be limited, and this is true for any decompressor that can
receive packets from anywhere.

Carsten concluded that we are in rather good shape regarding the
security aspects. We have gotten special competence involved to
look at this, and no missing pieces have been identified so far.

 - Implementation status (Bormann)

Carsten reported that there are currently three implementations in
progress at Dynamicsoft, Roke Manor Research, and TZI:
(www.dmn.tzi.org/ietf/rohc/UDVM).

The assembler is 205 lines, and the UDVM currently about 520 lines
of perl code (estimated to be around 750 lines when completed).
Implementers have started to interchange code, to verify correct
decompresses, which so far has been successfully done for lz77,
deflate, and lzw. What has not been done so far is testing of
state management interoperability, and testing in real setting. 

This is still just the start of the story. However, the UDVM seems
to work and it is worth the effort. Carsten's perl implementations,
although not complete, were written within one day.

- What now? (Jonsson)

Lars-Erik summarized the status based on previous discussions and
issues raised. Discovery is left outside of SigComp, and we only
provide methods to multiplex compressed and non-compressed messages.
In 3G systems, that should be enough for now if they mandate
support for SigComp. The discussion of a static dictionary for
SigComp concluded that this will be defined for SIP in a cooperation
between ROHC and SIPPING, and will be done quickly to meet the 3GPP
release 5 together with SigComp. However, this is independent of
SigComp itself and does not affect our progress in ROHC.

To summarize, there seems to be only cosmetic discussions left
for the UDVM, the security issues have all been addressed and we do
have running code. If all issues raised on the list can be tracked,
solutions provided and agreed, and updated drafts submitted on April
5th, it would potentially be possible to issue a WG last-call for 
these documents on April 8th. This would be a normal 2-week WG 
last-call, which, if successful, would be followed by the normal 
IESG process, including a 2-week IETF last-call. 


Afternoon session, 1545-1800
----------------------------

* Role of EPIC-Lite in the ROHC work

 - Architectural role and naming (Jonsson)
 
Lars-Erik summarized previous conclusions and agreements about what
EPIC is. As pointed out by Mark West in his Salt Lake City
presentation, EPIC is not a complete compression scheme, but a
compressed header format generator, making it possible to avoid the
hard work of creating the compressed header formats by hand. We
have previously agreed to look at EPIC for this purpose, but it has
not been completely clear exactly how to use it in the WG, or how
it would fit together with the ROHC framework. The intention is now
to not only summarize the current status, but also to outline a way
forward with this work.

 - A simple RTP profile example (West)

As suggested in Salt Lake City, an EPIC-based RTP profile has been
defined to provide an understandable example. This way, we might 
get a better understanding of EPIC Lite, and even of the TCP-work.
This is not a complete solution, only a limited example, but it
does define mechanisms such as CSRC-list compression, for comparison
with the RFC 3095 RTP profile. The profile is not compatible with
the one in RFC3095, but provides similar performance. With this
profile, it has been shown that it is possible to write an RTP
profile based on the EPIC tools, which is essentially equal to
ROHC RTP. This is useful for further discussions, and to tune the
tradeoff between efficiency and complexity.

Draft: draft-surtees-rtp-epic-00.txt

 - EPIC-Lite, news & open issues (West)
 
Mark gave a quick update on the EPIC-Lite draft. The core concept,
definition and pseudo code are stable, and there are now more than
one implementation coming up. One important issue that is currently
being addressed is the complexity of profiles, and also they are
trying to get the whole thing more easy to understand through an
improved structure and comments in the pseudo code. One thing that
should be removed is the stack manipulation approach, which is 
a little bit strange, and unnecessary complicated.

Draft: draft-ietf-rohc-epic-lite-01.txt

 - Way forward (Jonsson)

Lars-Erik finally summarized the EPIC issues on a high level,
explained how the chairs see this as part of the ROHC work, and
outlined their proposal for how to progress. There have not been
much discussion about EPIC on the mailing list, and there seem to
be difficult for people to get involved, which is an essential key
to be able to go further. To both simplify discussions and clarify
how this fits into the ROHC work, we should take it into pieces,
since there are more than one component in this. It is a tool for
compressed header format generation in profile standardization, but
it consists of at least two parts. First, it has a generic notation
language to describe the header fields that are compressed, and how
to compress each fields. Secondly, there are one or several encoding
methods that can be used to generate the actual compressed header
formats. Any such encoding would take as input the compression 
description for a profile, based on the generic notation language,
and generate compressed header formats, which would differ depending
on the encoding method used.

The proposal is to write a new working group document, covering
only the generic notation language. This is completely independent
of the encodings, and should for completeness be evolved concurrent
with various profile standardizations. Mark West has agreed to
serve as editor for this document, and we should be able to see a 
first embryo within about one month. Encoding methods should be 
discussed first later on. In the end, this will give us a toolbox
to use when we standardize future ROHC profiles.

Qian asked whether this might delay the TCP work, or if we should
reconsider using this toolbox for the TCP profile. Lars-Erik
responded that we are not really in any urgent hurry to finalize
the TCP profile, and Carsten further pointed out that this might
instead accelerate the progress, since we can now focus on each
separate part, and only the notation is relevant for the profile
work. Further, if we get this tool right, we would simplify the 
profile development work by avoiding hand-made compressed header
formats, which would be much more complicated for TCP than it was
for RTP.


* TCP profile

 - Requirements and field behavior (West)
 
Mark gave a quick review of the TCP requirements and field behavior
documents. Requirements are rather stable and will finally be called
for freeze. As usual, we will keep the requirements in the WG until
we have a solution ready. The field behavior draft, currently an
individual draft, will be re-submitted as a WG document when the
internet-drafts open after Minneapolis. Also the behavior document
seems to be stable, although it would probably benefit from more
review by TCP experts. 

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

 - News & open issues (Qian)

Lately, there have been some constructive discussions about the TCP
profile on the mail list. Qian summarized the outcome from those
discussions, of which the most important conclusion probably is to
make the window estimation an implementation issue only, and not
build the TCP profile on it. When talking about modes for TCP,
Lars-Erik asked whether there are different packet formats for U
and B modes. Qian answered that this is currently the case, because
the Master Sequence Number (MSN) not needed in both modes. 
Lars-Erik explained that this means we need four-way handshakes as
in the RTP profile, and expressed concerns about this unnecessary
complexity of mode transitions. It was agreed to use the same
formats U and B mode to keep the uni-/bi-directionality aspects as
simple as possible.

Currently, there is a non-official draft update for the TCP profile
circulating out there. Lars-Erik asked Qian to submit the draft now
without editing, to avoid confusion of which draft that is "valid".  
Then we should be able to continue the work.

Draft: draft-ietf-rohc-tcp-00.txt


* SCTP profile

 - Requirements, news & open issues (Schmidt)
 
Christian gave a short update on the SCTP compression requirements,
but there have been no major changes. Lars-Erik asked whether there
had been any comments on the list, but unfortunately not. People
are therefore encouraged to send comments to the list, if they are 
interested in SCTP compression. Lars-Erik further pointed out that
the requirements will stay in the WG until we have a scheme ready,
and we can not consider it ready either, without more discussions
and comments.

Draft: draft-ietf-rohc-sctp-requirements-00.txt

 - A first profile attempt (West)

Mark continued with a few words about his first SCTP profile attempt.
It is a starting point, showing that it is possible to compress SCTP,
but currently not much more. Lars-Erik asked if he had any ideas how
much we could potentially reuse from TCP when we do SCTP. Mark
answered that he has not yet looked at that, but most likely there
will be at least something that can be reused. However, SCTP has
quite a different structure than TCP and RTP, so there is probably
a need to invent some completely new mechanisms. Carsten finally
asked if anyone in the room cares about SCTP compression? The
audience answered with silence.

Draft: draft-west-sctp-epic-00.txt


* RTP issues

 - Implementation & impl. guide (Jonsson)
 
The implementers guide for ROHC RTP has been updated with new stuff,
corrections, and improved clarifications. The improved procedure for
mode transitions has been corrected, and is also both better 
described and motivated. Further has it been clarified what is
initially needed before mode transition (to O or R mode) can be
initiated. RFC 3095 has some unclear words about this only in the
R-mode section, but this is a general thing. Mode transition can
never be initiated before the decompressor has received and
correctly decompressed at least one packet. This should be obvious
if one consider that modes is a per-profile thing, and so are the
feedback packet bits that are used to signal mode transition. First
when a packet has been correctly decompressed and the context has
been established, the decompressor knows which profile it is
operating according to, and thus which modes are available. 

Lars-Erik further raised a question about a statement in the draft
concerning the use of Extension-3 with UO-1* packets. The statement
says that "it might not make sense to use these packets", and the
point was that such statements should not be made if we do not have
specific reasons to do so. Mark agreed that the implementers guide
should not make moral judgements, and it was decided to keep the
clarification, but not say whether use of UO-1* with Extension-3 is
a good or bad idea.

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

The next RFC 3095 interoperability test will take place in Lulea
Sweden, April 17-23, hosted by Ericsson. Lars-Erik pointed out that
newcomers are more than welcome, since it would be useful to get
some fresh code and new problems to play with.

 - MIB, news & open issues (Quittek)

Juergen reported on the MIB progress, which unfortunately has been
less than we expected in December. One difficult thing is that the
architecture of ROHC is not on solid ground, and this complicates
the MIB development. Changes from the first version is mainly a new
chapter stating architectural assumptions, a merge of the interface 
and header groups, and some new basic properties, such as version
and manufacturer. The statistics group must be considered further
to find out what things are useful there. Carsten pointed out that
header types might not be a very good measure, since with TCP we
might have hundreds of header types, and even with RTP the same
header could be used with various options. It was suggested to have
this as an action point for the next ROHC interop. Implementers 
should report what counters and information they collect in their
implementations. There was a question about the grouping of the
statistic counters. Juergen answered that this is due to
restrictions from the MIB structure, one cannot put everything in
the same table. Some statistics are outside of the statistics group,
which only holds sophisticated counters.

Regarding the architectural assumptions, Lars-Erik pointed out that
a minimal instance is a compressor or a decompressor, which is not
obvious from the current MIB. Juergen answered that an instance
could be either a compressor, a decompressor, or both, and this
will be made clearer in the next version. Lars-Erik is planning to
write an architectural document for ROHC, and that might simplify
these discussions.

The next question was whether we plan to have MIBs for TCP or other
compression protocols as well. The answer is yes, but we have to
start with RTP. However, it would probably be a good time to start
discussing a possible MIB structure and prepare for integration of
other protocols as well. Carsten noted that understanding of the
ROHC standard increases when doing the MIB, and the understanding
will also increase when RFC 3095 is divided.

Finally, Juergen asked if anyone is planning to implement the MIB,
but there were no answers from the room. Carsten pointed out that
someone will have to implement this, and encouraged people to go
home and see who needs a MIB. Network builders will most likely
need the MIB.

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

 - LLA, implementation examples (Pelletier)
 
During the LLA development, a draft was written to illustrate how
the LLA profile could be implemented in a typical environment, such
as CDMA2000. It was then agreed to produce an Informational RFC 
based on this material, enhanced with more examples. Currently,
the original draft has expired and we still have no WG draft for
this, basically because the LLA incorporation in CDMA2000 has not
yet been finalized. However, that work is now almost completed and
we should soon expect to get a first version of this draft as a WG
document.
 
 - UDP-Lite profiles, initial discussions (Pelletier)

Ghyslain Pelletier held an initial discussion about profiles for
UDP-Lite, based on his new draft. The current draft does not provide
a complete solution, but is more about motivating and suggesting a
direction for the work. There are no profile details, such as packet
structures, included yet.

The difference between UDP and UDP-Lite is that the length field of
UDP has been replaced with a checksum coverage field, indicating
how much of the payload has been covered by the checksum. It thus
affects both the length/coverage field and the checksum field. For
header compression, this means we get a new field that can not be
inferred (length could be inferred from link layer, coverage could
probably not). UDP-Lite has been defined to provide more flexibility
to choose the level of protection provided by the transport layer,
which is often desirable for applications such as conversational
audio/video. In IPv4, the UDP checksum can be disabled, but that is
not the case for IPv6. The reason for that is to guarantee protection
for the headers, and therefore UDP Lite require, as a minimum, the
header part of the packet to always be covered by the checksum. 
Depending on how the coverage field is set, one can identify typical
scenarios for UDP-Lite usage, and the basic idea is to provide
different compression approaches for different usage scenarios,
making it possible to optimize compression for certain cases.

A discussion followed about the possible common coverage for codec
payloads such as AMR and EVRC, whether the payload header will be
covered, and maybe even parts of the payload itself. Another
question was whether this can change on a per-packet basis, and in
such case how frequently? There was no real conclusion, more than
that the coverage might vary on a short term basis, and that it is
reasonable to believe one wants to protect at least the payload 
header. This should be subject for further investigation.

The UDP-Lite profile will of course have to handle all possible
UDP-Lite usage scenarios, but the proposal is to optimize for some
cases that can be optimized for. The suggestion is to allow removal
of the UDP-lite checksum at the compressor, with recalculation at
the decompressor, for these specific cases. The use of this
optimization would be limited to e.g. when only the packet headers
were covered by the checksum, but could give a substantial
performance gain. This would allow us to potentially compress as
efficient in IPv6 as in IPv4 (where the checksum might be disabled).
A discussion followed about the end-to-end consequences of this
approach, how useful this would be since normally also the payload
will be covered, etc. Stephen Casner argued that this breaks the
end-2-end meaning of the UDP checksum, while Ghyslain answered that
this is not completely true and the draft motivates why. There were
no real conclusions, but more discussions and explanations were
requested.

Carsten Bormann said he wanted to explain why he allowed this to be
brought up at all. UDP-Lite is not UDP, but was created with the
purpose of playing with checksums. UDP-lite is necessary, because
of the defect of IPv6 not allowing the UDP checksum to be disabled,
and UDP-lite exists to fix this. Therefore it is good to look at
options in the compression of UDP-lite.

There was a question on what the minimal compressed header size
would be, which Ghyslain answered would depend on the size of the
CRC used, and so on. Another question asked about the relationship
to 0-byte compression, which we already have. Why do we need this?
Ghyslain answered that LLA doesn't work with v6, and this is
targeting a different particular need - dealing with UDP-lite.

Lars-Erik suggested there should be comparisons to the IPv4 case,
where the header checksum is taken away in ROHC. The IPv6 header
has no checksum, instead the UDP checksum is mandated. What would
be the difference between these cases? This is an interesting
analogy, and Carsten suggested it should be taken up in the draft.
Lars-Erik pointed out that independent of which approach we
finally go for, with or without certain optimizations, we are
chartered to do profiles for UDP-Lite. This is therefore a good
starting point for discussions.

Finally, Stephen Casner suggested to investigate whether the
coverage field could potentially be inferred from the link layer.
To make a difference with UDP-Lite, link layers would also have
to provide for partial protection, and that should then be
utilized.

Draft: draft-pelletier-rohc-rtp-udp-lite-00.txt



--------------------------------------
Lars-Erik Jonsson
IETF ROHC WG Chair
E-mail: [e-mail]
Phone: [phone]
Home: [phone]

My opinions are my personal opinions and should not be considered
as the opinions of my employer, if not explicitly stated. 


_______________________________________________
Rohc mailing list
[e-mail]
https://www1.ietf.org/mailman/listinfo/rohc