[rohc] Preliminary ROHC minutes from IETF 66

Please review and send comments to me!

Thanks!
/L-E

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

Tuesday evening, 2006-07-11, 17:40-19:50

Meeting Chair: Carsten Bormann
WG Chair: Lars-Erik Jonsson (on Jabber)

Reported by: Lars-Erik Jonsson
Note taker: Andrew McDonald

* WG admonishments and agenda (Carsten Bormann)

Carsten serves as chair for the meeting since L-E is not present.

Agenda (accepted as is):
  1740  Chair admonishments and agenda bashing
  1745  WG and document status update
  1800  Corrections and Clarifications to RFC 3095
  1810  ROHC Framework and ROHCv2
  1900  HC over IPsec Security Associations
  1940  ROHC TCP & Formal Notation

* WG and document status update (Carsten Bormann)

Since the last ROHC meeting (IETF63) some new ROHC RFCs have been
published, more specifically the ROHC TCP requirements, TCP field
behaviour, Context replication, ROHC over reordering channels, the
corrected RTP LLA profile, and the SigComp users guide and torture
tests.

Currently, there are no ROHC documents in the publication pipe,
neither in the RFC editor queue nor among the IESG. However, there
are several documents that should soon be ready to leave the WG.

A charter update proposal was sent out on June 22. The whole 
charter has been rewritten, making the background and history short
while focus is on current aims, i.e. ROHCv2, RFC3095 clarifications
and corrections, ROHC over IPsec, and the remaining SigComp work.
There are quite a few milestones, but a lot of work is already done.

Carsten asked for comments on the milestones, and Magnus answered
that the text should make clear that the framework is backwards
compatible with RFC 3095, that was the only comment from the IESG
review. L-E noted (via Jabber) that one must remember that
ROHCv2 will provide a new set of profiles, and these will be
different than the v1 profiles. Since we do not intend to enforce
implementation of the v1 profiles, ROHCv2 as a whole will not be
backwards compatible with ROHC as given by RFC 3095.

* Corrections and Clarifications to RFC 3095 (Ghyslain Pelletier)

This document started as collection of guidelines from interop tests,
the goal with it has changed during its lifetime. It includes
corrections, clarifications and guidelines to RFC 3095 and profiles
based on RFC 3095. It does not change profile version numbers, but
actually says how the RFC 3095 profiles must be implemented. Between
-18 and -19, the draft has been rewritten to be clearer on what is
corrected/invalidated/added to RFC 3095. Target is to publish it as
a Standards Track RFC (PS).

There are still some open items about context repair, TS_STRIDE,
TIME_STRIDE, updating properties of ext-3 with UO-1ID, and possibly
a rewrite of section 3.3 to make its content clearer.

We want to proceed carefully to get careful review, but the goal is
to send this draft to the IESG around September/October.

RFC's:  RFC 3095
Draft: draft-ietf-rohc-rtp-impl-guide-19.txt

* ROHC Framework and ROHCv2 (Ghyslain Pelletier)

 - The ROHC Framework

The idea is to split out common part from profile specific parts.
The ROHC framework describes core definitions and parts common to
all profiles, it existed in RFC 3095 but it was not explicitly
separated from the profiles. The ROHC framework is not changed from
RFC 3095, which means there is only one single ROHC basis and
backwards compatibility is guaranteed.

Recent changes to the draft include text to clarify what sort of
channels rohc is applicable to, explicit identification of all
packet type identifiers which are unused by the framework,
clarifying text on the roles of the three different CRCs (which have
different purposes), and  the uncompressed profile is now defined by
the framework.

The updated draft also includes a proposed new channel parameter,
"maximum reordering depth", intended to be used to better adjust
tolerance to reordering in v2 profiles. It is optional to negotiate
and may be used by a profile. Another option was to have a feedback
option. Carsten questioned whether this is something the network
can know proper values for, i.e. if the parameter really makes sense.
L-E said he would like to avoid adding things in the negotiation,
and he wants alternatives to be carefully investigated and presented
to the WG before we settle on including this new negotiation
parameter. Carsten strongly agreed on that.

Emre noted that at least from an HCoverIPsec point of view, this
parameter seems useless since you do not know what the reordering
characteristics are as the number of hops may change over time.
Ghyslain responded that it is supposed to be optional, one do not
have to negotiate it.

There was a discussion about target document class for this draft,
but the idea is clearly to make it PS, anything else would be hard
to defend.

We should try to freeze this document and focus on rohcv2 profiles,
although we should probably publish them in parallel. Two
committed reviewers are needed, it is only 30 pages and should not
be hard to review.

 - 3095-based profiles and reordering

Reordering of packets before the compression point can be handled by
RFC 3095, but RFC 3095 assumes there is no reordering of packets
between compressor and decompressor. Not having a CRC on all packets
(e.g. R-mode) also complicates things if there can be reordering. 
RFC 4224 covers most problems with 3095 and reordering. There have
been comments on list that there are lots of changes to the profiles
in the v2 profile proposal. These mainly based on the problems
identified by RFC 4224. If you read 4224 you will see that there is
much more to consider than just the interpretation interval.

Carsten noted that there is a difference between reordering and
undetected reordering. If there is something in the channel that
tell the decompressor when packets have been reordered, life gets
easier. Ghyslain responded that this is a strong assumption, but
Carsten pointed out that there are channels that have this property,
and Ghyslain agreed it is much easier if you know this.

 - ROHCv2 profiles

Ghyslain presented the proposed new profile set for ROHCv2. New
profile numbers will of course be assigned, since these profiles
are different and are supposed to coexist side by side with the
old profiles defined by RFC 3095. There is not a requirement for
backward compatibility with the RFC 3095 profiles, and it would be
wrong to have such a requirement, with v2 we want to open up for
simpler ROHC implementations

One can summarize the goals with the v2 profiles as; simpler to
implement, improved clarity and conciseness, existing features
updated based on experience, new features added (e.g. robustness to
reordering), errors corrected, and previous "mistakes" avoided.

The draft is written to meet what is in the improvements draft, it
does not go much longer than that.

Design currently uses formal notation, while the encoding methods
are the same as 3095. The aim is to under the same operating
conditions have at least similar efficiency and robustness as with
the 3095 profiles.

One issue for discussion is timer-based compression, which is not
included in the initial draft, although the improvements draft does
not suggest this. 

Ghyslain asked whether this draft can be adopted as WG document.
Carsten asked how many people have looked at the draft, and got a
few hands as a response.

Drafts: draft-ietf-rohc-rfc3095bis-framework-01.txt
        draft-ietf-rohc-rfc3095bis-improvements-02.txt
        draft-pelletier-rohc-rohcv2-profiles-00.txt

* HC over IPsec Security Associations (Emre Ertekin)

The latest draft has number of updates. Draft now takes a framework
flavour rather than a work proposal, based on previous discussion on
alternative solution approaches. The idea is to use the next header
field to multiplex/demultiplex compressed and uncompressed packets
in an SA, i.e. to get a protocol number for ROHC/HC. This means one
would have a single SA for both compressed/uncompressed traffic and
no HC overhead for uncompressed packets. The downside is that it
requires the reservation of a protocol number from the IANA, but
this should be viable if its definition and potential use is rather
general (not specific to the SA case).

Documents needed for this work, as reflected in the ROHC milestones:
- extensions for reordering - work on RoHCv2 and ECRTP cover this
- initialization and negotiation of HC parameters with IKEv2
- allocation of next header value for ROHC packets

Currently we have envisioned requesting one single protocol number,
but we may need more than one, this depends on if we can unify ROHC
and other HC protocols (most specifically eCRTP). The suggested
unification approach makes ECRTP/CRTP/IPHC effectively become new
ROHC profiles, thus a protocol number is needed only for ROHC.

Ghyslain questioned why we need to support anything but ROHC. The
answer was (as always) that *some* people want this, based on the
regular fuzzy arguments about ROHC complexity. The discussion also
ended as always (faded out), but Ghyslain made clear that his point
was really to question the unification approach, which he believes
is strange.

Magnus asked more than one level of demultiplexing is needed, and
Carsten responded that older schemes use PPP for packet type
identification, so these schemes need something for this purpose,
and incorporating them into ROHC through the proposed unification
would solve that problem. One could then also replace their CID
schemes with the ROHC CID mechanism, which is more flexible. 

Having a dynamic protocol number ("Compressed header") value is
also an alternative, where e.g. IKE negotiation would indicate the
actual HC scheme. L-E dislikes this approach since the protocol type
would not be self-describing. Carsten also pointed out that IPsec
says that next header field must identify the format of the header.

There was clearly no conclusion (or consensus) on these issues, the
discussions will have to continue on the list.

Draft: draft-ietf-rohc-hcoipsec-02.txt

* ROHC TCP & Formal Notation (Ghyslain Pelletier)

The formal notation is a documentation tool, and we have tried to
make it readable. There have therefore been many changes based on
the comments we got from the WGLC, and it took some time to make
this update happen. We should now send it back to the committed
reviewers, and aim for a second WGLC in August or September.

The ROHC TCP draft has also been significantly updated with various
editorial changes, some minor technical changes, and the descriptive
box notation has been removed. It would really be useful if someone
could verify the ROHC TCP packet formats, but we know this is hard
to do without actually implementing and testing the protocol. This
draft should soon be ready for a second WGLC, the work has a five
year history and we are getting there.

Carsten noted that we had two in-depth reviews from Joe Touch and
Ted Faber on previous version. We should get similar detailed
reviews on this version, then we are hopefully done.

Drafts: draft-ietf-rohc-tcp-12.txt
        draft-ietf-rohc-formal-notation-10.txt

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