Subject: [rohc] Preliminary minutes from ROHC@IETF63

From: "Lars-Erik Jonsson (LU/EAB)" <[email-masked]>
Date: Thu, 4 Aug 2005 11:54:03 +0200

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 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 document.

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 only 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 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 to fix 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.  Carsten noted that 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
[email-masked]
https://www1.ietf.org/mailman/listinfo/rohc

---

From: Cristian CONSTANTIN <[email-masked]>
Date: Tue, 9 Aug 2005 18:11:34 +0200

> Minutes of the ROHC WG session at IETF 63

cristian: first of all I think there should be a clear distinction btw.
using TCP and UDP for it. for example, when using TCP you can solve a lot 
of problems by "mapping" the compartments to the TCP connection btw. the 
sip proxy and the terminals.

on the other hand, I think there are some problems when using a
one-to-one map btw. compartments and registrations. 

1. you'll fill up a _lot_ of memory on the proxy in a very short time.
and this memory will tend to be always allocated (even though not for
the same states). ex.: 50K users, min. 2k/state, in time you'll fill up
100MB. of course it depends on how much mem. you want to allocate for
such states on the proxy and on whether the terminals using sip+sigcomp
are well-behaved and release state that is not used anylonger; but bottom 
line is that this state memory will more or less always be used. 

2. as far as I have understood a sip terminal does not have to be
registered with some proxy for making calls through that proxy. how is
going this proxy to map the sigcomp compartment in that case?

bye now!
cristian
-- 
 _          | There are many people who use UNIX or Linux  
(_'_        | who IMHO do not understand UNIX.
  (_'rist   |              --David Korn  
GPG public key at wwwkeys.de.pgp.net
_______________________________________________
Rohc mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/rohc

---

From: Adam Roach <[email-masked]>
Date: Tue, 09 Aug 2005 11:42:04 -0500

Cristian CONSTANTIN wrote:

>first of all I think there should be a clear distinction btw.

This doesn't work well unless you can guarantee that the incoming and 
outgoing messages will happen on the same TCP connection. In many SIP 
configurations, this isn't the case.

>the same states).

The distinction you're trying to make doesn't really exist. Any UA that 
uses TCP will have an active TCP connection for the duration of their 
registration. From the perspective of the amount of SigComp state to be 
stored, the cases are identical.

>going this proxy to map the sigcomp compartment in that case?

This is technically true; however, in any case in which SigComp makes 
sense (i.e. mobile terminals with relatively low-bandwidth signaling 
channels), it is unrealistic to expect that terminals will work when 
unregistered.

/a

---

From: Cristian CONSTANTIN <[email-masked]>
Date: Wed, 10 Aug 2005 12:49:45 +0200

> stored, the cases are identical.

cristian: I suppose that keeping the TCP connection open for the whole 
duration of the registration is a suggestion and not something that 
must be implemented. (has to do with nat, right?) 
by doing it you'll run anyway into performance problems on the proxy side. 

bye now!
cristian