[rohc] Minutes from ROHC@IETF63

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

Le Palais des Congress De Paris, Paris, France
Monday Afternoon, 2005-08-01

Chairs: Carsten Bormann & Lars-Erik Jonsson

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

Afternoon session, 16:30-18:00
------------------------------

* WG admonishments (L-E Jonsson)

Meeting time will be used to advance difficult issues, not
for presentation of material that can be read from drafts. We
assume that people have read the drafts, and what we decide 
in meetings must be confirmed on the mailing list. Also, all
contributors must be aware of the IPR principles, as stated by
RFC 3379.

* Agenda bashing (L-E Jonsson)

Lars-Erik presented the proposed agenda, which was accepted without
modifications.

Agenda:
 - Chair admonishments and agenda bashing   
 - WG and document status update
 - SigComp work, status and future
 - ROHC TCP & Formal Notation
 - HC over IPsec Security Associations
 - HC over MPLS (AVT work item)
 - ROHC RTP, time for a second version?

* WG and document status update (L-E Jonsson)

Lars-Erik reviewed WG milestones and document status. The
WG had 13 published RFC's last time we met, and two new publications
have been made since Washington, RFC4019 (the UDP-Lite profiles),
and RFC4077 (SigComp Nack). Three documents are in the RFC editor
queue (Context Replication, ROHC TCP Requirements, ROHC over
Reordering), and one just got approved by the IESG (TCP field
behavior). No ROHC drafts are currently in the IESG approval process,
but the 3242bis draft will soon be submitted as it has passed WGLC.
This leaves us with 8 WG drafts currently being worked on, four
related to SigComp, two for ROHC TCP, as well as the ROHC RTP
implementer's guide and implementation status documents.

Looking at the milestones, we are on track, but the ROHC RTP DS
milestone will probably have to be redefined, as addressed by the
last item on the meeting agenda.

* SigComp work, status and future (Mark West)

Mark went through the four current WG drafts related to SigComp. 

Torture Tests define tests for correct behavior and boundary cases
of the udvm. Recent changes have been minor, and the authors believe
the document is ready to ship. 

The User Guide, which includes mnemonic code, example decompressors,
and other common functions, has been there for a long time and only
some few changes have been made lately. The most recent changes are
the addition of a "read only directive" and a simplified shared mode
example. Some feedback on these parts would be appreciated, but
apart from that authors believe it is ready to ship.

It was agreed to issue WGLC for the Torture Tests and User Guide
documents, after having explicitly asked some known implementers to
comment on the most recent changes to the User Guide.

The Implementer's Guide provides clarifications to rfc3320, and has
been stable for a while as well. It might, however, be nice to keep 
this document open, e.g. to leave time for some nack implementation
experience. Mark asked whether anyone got a nack implementation? 
Adam Roach answered that he has nack working (implemented before it
was documented), but he has not had anyone to interoperate with. It 
was thus agreed to keep the Implementer's Guide open for some more
time.

SigComp for SIP is a currently expired draft. While RFC3486 covers 
SIP-level aspects of sigcomp, this draft discussed sigcomp-level
aspects for SIP, such as minimum SMS/DMS, locally available state, 
and compartment mapping. An update was initiated, but not completed.
The document is in general trivial, but important. The non-trivial 
part is the compartment mapping. To have it per dialog means not 
much state must be kept, which is both good and bad. However, Adam
pointed out that this is catastrophic rather than bad. To have it
per registration means lots of state is to be kept, which can also
be considered both good and bad. Adam meant this isn't that bad, but
rather necessary. Carsten noticed that because memory is cheap, he
also prefer per registration. However, when trying to write this up, 
he found it rather hard, because of relationship between sip 
entities it is not clear how messages relate to a particular 
registration. Adam pointed out that there is relevant work in a sip
draft, registration instances, and we should talk to Cullen Jennings
about this. There might be a solution there, but it might also be a
bad idea, someone has to look at it. Carsten/Mark/Adam should 
cooperate to get this draft finalized, and potentially engage more
people (with good SIP knowledge) in the process.

Gabor Bajko asked about the sip multiplexing that was taken away
according to one of the slides on SigComp for SIP. Mark answered
that it was about how to multiplex sigcomp and non-sigcomp in single
TCP connection, which was agreed not to be needed. Lars-Erik noted
that we had this discussion several times, and always came to same 
conclusion. Mark reminded us of the most important points from the
discussion, and why we came to that conclusion.

SigComp, RFC3320, has been there for some time now, and tested for
interoperability at least at one dedicated event in February 2003.
The specification seems to be solid and stable, with only some few
minor issues identified by the implementer's guide. It should thus
be possible to prepare for Draft Standard advancement. Lars-Erik 
noted that we would need a volunteer for the editorial work for
Draft Standard. Mark asked how much work is required, to which L-E
responded that this is very much up to the editor, but implementer's
guide is fairly short, which suggests it should not require too much
work. Mark said we may have a volunteer, but he could not promise
anything at the meeting.

RFC's:  RFC 3320, RFC 3321
Drafts: draft-ietf-rohc-sigcomp-sip-01.txt (EXPIRED)
        draft-ietf-rohc-sigcomp-impl-guide-05.txt
        draft-ietf-rohc-sigcomp-torture-tests-01.txt
        draft-ietf-rohc-sigcomp-user-guide-02.txt

* ROHC TCP & Formal Notation (Carsten Bormann)

Carsten noted that the current documents are tcp-10 and notation-09,
versions got wrong in early revisions of the agenda. The documents 
are currently in WGLC due to end tomorrow. However, there have not
been any comments on the documents yet, although we have received
comments that doing WGLC at the time of reading lots of drafts
before an IETF was not a good idea. Ted Faber (tcpm chair)said that
he and others from tcpm will read these if they get more time. We
will thus extend the WGLC to the end of August to give reasonable
time for in-depth review. 

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

* HC over IPsec Security Associations (Emre Ertekin)

The objective with this proposal is to reduce the overhead of IP
packets over IPsec Security Associations. IPsec comes at the cost of
increased overhead, and per-link header compression can not compress
the inner headers since these are hidden through encryption. Only if
compression is applied at the tunnel endpoints, this overhead can be
reduced. Although an IPsec tunnel may have intermediate hops, it has
a source/destination association to which HC can be applied. The
order would thus be to; map packets to HC context, compress, encrypt,
and finally add ESP/IP headers for the secured tunnel. These outer
headers may then of course be compressed on a per-link basis

The draft outlines a solution framework by giving work assumptions,
and work items:
- First of all, HC scheme specific extensions may be needed, i.e.
  increased tolerance to reordering, packet loss (solutions based on
  the "rohc over reordering channels" document)
- Secondly, initialization and negotiation of the HC channel as part
  of the IPsec SA. This means leverage IKEv1/IKEv2.
- Finally, we need encapsulation and identification of HC packets,
  which should be straightforward for ROHC, as ROHC identifies its
  own packet types (other HC schemes, e.g. eCRTP, require external
  packet type identification).

There have been some comments and questions raised on the list. The
first was about whether the ROHC uncompressed profile can be used to
multiplex compressed and uncompressed flows. However, access control
enforcement may not allow this proposed resolution. An alternative
could then instead be to establish two SAs, one for compressed, one
for uncompressed. Mark commented that using two SAs seems to be a
warped mapping as it implies IPsec processing knows whether flow is
compressible or not rather than just handing it to HC processing. L-E
reminded us that this would not be the first time ROHC is put on top
of a "multi-channel link", so such a solution is not that warped. On
the other hand, how this is done is out of scope for the actual
standards work, it is an implementation/realization issue.

An other question is how to identify and multiplex traffic, whether
to register new IP protocol numbers. For ROHC, there would be only
one packet type, but for eCRTP and other schemes, multiple types are
needed, and that may consume many protocol numbers. One way could be
to register one protocol number for ROHC and one for "other HC", and
for the latter type there would be one additional byte added to 
indicate packet type. This approach would be similar to how it is
suggested to work for ECRTP over MPLS.

Next steps with this work would be to update the draft based on
feedback and discussions, and to initiate work on a draft detailing
the extension to IKEv2 for HC parameter negotiation (IKEv2 seems to 
be easier than IKEv1).

Hideaki Yoshifuji said he could not understand benefit of this
proposal, and asked how this is different from IPcomp. Emre answered
that IPcomp is a simple per-packet payload compression, which does
not provide much gain when compressing packet headers. Ajoy Singh
asked whether this can be applied to other tunneling, e.g. v6 over
v4. Emre answered that the big issue would be that we are leveraging
IKE for negotiation. L-E pointed out that the thing here is that you
can not compress on a per-link basis, because of encryption. When
there is no encryption, ROHC can already compress tunnel stacks, and
a ROHC implementation must support both IPv4 and IPv6 compression.

L-E observed that the ROHC WG is not chartered to do this work, but
it is something to look at. Negotiation would not be work for rohc,
but rather work for the IPsec WG, monitored by ROHC. Work for us is
to improve the reordering tolerance of ROHC, and packet multiplexing.
It would probably also be useful to have an overview draft, like the
individual one presented, as informational. There were no objections
to the proposal to adopt this as a WG item.

Draft: draft-ertekin-rqts-hcoipsec-01.txt

* HC over MPLS [AVT work item] (Jerry Ash)

L-E explained that this could be seen as a guest presentation from
the AVT WG, but as it includes ROHC we thought it was a good idea to
have it here too, to make people aware of it. Jerry explained that it
outlines a pseudo-wire approach to HC over MPLS, and is not limited
to ECRTP. It is now a work item in the AVT charter, for submission by 
December. Idea is to run HC over an MPLS tunnel, i.e. to leave
headers compressed over multiple hops, and just route on MPLS labels.
This way HC compression/decompression cycles at intermediate routers
can be avoided. Discussions have been cross-posted to AVT, ROHC and
PWE3, as competence is needed from all three WG's. The underlying
approach is to use pseudo wires carrying layer 2 PDUs on an
encapsulated MPLS path. It builds on top of the work defined for 
pseudo wire signaling in PWE3. Pseudo wire type indicates HC scheme,
and these types have already been defined in the PWE3 IANA draft.
Carsten noted that one document mentioned is RFC1144, while RFC1144
does not handle reordering. There should at least be a dire warning
about that. Jerry responded that the goal was to be generic, and
maybe it became too generic. We will have to look at that. L-E
reminded people that this is not an item for ROHC WG work, but it has
many similarities and some same issues as HC over IPsec. ROHC folks
are thus encouraged to keep an eye on and participate in these AVT
discussions.

Draft: draft-ash-avt-hc-over-mpls-protocol-01.txt

* ROHC RTP, time for a second version? (L-E Jonsson)

The following will be a continuation of the discussion we had in 
Washington, and on the list thereafter. Those who were in Washington
will thus recognize some of the initial slides.

Originally, our "Plan A" was to move from framework + profiles
(uncomp, IP/UDP/RTP, IP/UDP, IP/ESP) in one single Proposed Standard 
document, RFC 3095, to separate Draft Standard documents for 
framework and profiles. However, implementation has unveiled lots of
issues in RFC3095, which made us create the "implementer's guide",
and incorporating that material when going to Draft Standard became
our "Plan B". However, considering the significance of the issues
clarified and corrected by the implementer's guide, we have realized 
that going to Draft Standard from RFC 3095 might thus not be 
realistic. Framework could be taken to Draft Standard, but the
profiles would have to be recycled at Proposed Standard. However, the 
sense of the room in Washington, as well as opinions from
implementer's and others on the mailing list, has indicated that we
have a clear consensus to not spend our limited resources on updating
existing profiles. Instead, it would be better to issue new profiles
based on experience, a ROHC version 2. This means we will have two
sets of profiles.

The Implementers guide originally identified problems that had to be
resolved to create interoperable RFC 3095 implementations. Appendix B
now gives also the things we would like to do better, i.e. a summary
of the "lessons learned from RFC 3095", as discussed on the mailing
list. There are a number of more or less significant changes, but all
have been carefully reviewed and agreed on the mailing list before
being added. There is, however, one item that we have not been able
to reach consensus on, yet; whether the CRC should not be split into
static/dynamic, as it is in RFC 3095. We encourage implementers to
speak up and express opinions on this. Mark commented that it should
be fairly easy to do some quick experiments.  According to Carsten,
the original discussion was based on the observation that people were
struggling to make CRTP fast. ROHC/CRTP cost about the same number of
instructions before the CRC calculation, and static/dynamic split
sounded a good idea. Of course, splitting fields also involves
instructions. L-E concluded that we will have to figure out what
to do with this, based on more concrete material.

To sum up, L-E suggested a way forward. We are currently chartered to
do Draft standard of RFC 3095. Since we have WG consensus to better 
spend resources on doing a real update, the proposal is to:
 1) remove RFC 3095 profiles Draft Standard from the milestones 
 2) instead add milestones for revised profiles, which would solve
    current issues and address new requirements (i.e. be based on
    Appendix B of the Implementer's Guide)

One issue would then be what to do with the Implementer's Guide and
the RFC 3095 profiles? The original intention was to never publish
the Implementer's Guide as an RFC, but incorporate its content into
the DS. When we now change our plan for RFC 3095 DS, we should also
reconsider what to do with the Implementer's Guide. The proposal is
therefore to:
 3) publish the implementers guide as a stable reference for
    implementing the RFC 3095 profiles

Question is what sort of RFC this should be? Allison Mankin answered
that we need to make clear in the document what it does for people,
and then worry about category later. We should make clear who is
supposed to reference it, and how. That would probably indicate which
category it should belong in. L-E will revise the Implementer's Guide
to make its purpose clear, and at the same time split out Appendix B.

RFC:   RFC 3095
Draft: draft-ietf-rohc-rtp-impl-guide-13.txt

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