Subject: [rohc] ROHC minutes from IETF 66

From: "Lars-Erik Jonsson \(LU/EAB\)" <[email-masked]>
Date: Tue, 22 Aug 2006 10:46:18 +0200

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 (present 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
behavior, 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
flavor 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
[email-masked]
https://www1.ietf.org/mailman/listinfo/rohc

---

From: "Lars-Erik Jonsson \(LU/EAB\)" <[email-masked]>
Date: Tue, 22 Aug 2006 16:14:00 +0200

>From the ROHC IETF 66 minutes:

>From the comments received at the meeting and on the list,
I conclude that draft-pelletier-rohc-rohcv2-profiles-00.txt
is pretty much completely in line with the v2 goals settled
by draft-ietf-rohc-rfc3095bis-improvements-02.txt. The only
clear deviation is the removal of support for timer-based
compression, which should be further discussed (those who
believe it should be removed have to defend and argue for
that approach, otherwise it should be reintroduced in the
v2 draft, according to previous consensus around the
improvements draft).

In any case, I will ask the initial contributors to 
resubmit the draft as a WG draft, which will be titled:
draft-ietf-rohc-rfc3095bis-rohcv2-profiles-00.txt

Further development should then continue on the list based
on this initial WG draft.

BR
/L-E

---

From: [email-masked]
Date: Tue, 22 Aug 2006 17:04:17 +0200

Lars-Erik,

Thanks, I will resubmit the draft as a WG draft soon.

There is one precision I would like to make however regarding "deviation" and 
timer-based compression. My opinion is that it is rather the opposite - to have 
a specific feature or function put into RoHCv2 profiles, proponents have to 
motivate it. We have consciously not included timer-based compression in our 
initial submission because we simply could not motivate it. In this respect, I 
believe that there should be a clear motivation in order to add it to the 
RoHCv2 profiles.

In any case, I have tried to summarize both views regarding this in my 
presentation in Montreal, see my slides at:

http://www3.ietf.org/proceedings/06jul/slides/rohc-2/sld41.htm

I suggest we should use this as a basis for further discussions on this topic. 

Currently, we still do not plan to add support for timer-based compression in 
the next submission either, as we believe that the "cons" are still more 
compelling than the "pros". But I welcome any technical comment that would 
succeed convincing me to do otherwise, I am simply very reluctant to add 
complexity without _knowing_ that we _need_ to have it!

/Ghyslain

---

From: "Lars-Erik Jonsson \(LU/EAB\)" <[email-masked]>
Date: Wed, 23 Aug 2006 08:50:40 +0200

> There is one precision I would like to make however regarding
> "deviation" and timer-based compression. My opinion is that it is
> rather the opposite - to have a specific feature or function put
> into ROHCv2 profiles, proponents have to motivate it.

We have had a long process for establishing consensus about
what ROHCv2 should be, and this is captured in the improvements
draft, as a diff-list compared to RFC 3095. You claim that your
proposal is in line with what the improvements draft says, and
both me and others seem to generally agree with that. The only
real deviation that people have noticed is the removal of TBC.
Therefore, when making you the editor of the v2 WG document, I
also make you responsible for driving a discussion and make sure
consensus is established for dropping/keeping TBC.

> Currently, we still do not plan to add support for timer-based
> compression in the next submission either, as we believe that
> the "cons" are still more compelling than the "pros". But I
> welcome any technical comment that would succeed convincing me
> to do otherwise, I am simply very reluctant to add complexity
> without _knowing_ that we _need_ to have it!

This now becomes a WG draft, which means you are not allowed to
make such decisions. You do not have to be convinced, but to make
sure the draft reflects WG consensus. At this point I do not ask
you to add it to the -00 draft, but as I said above, I expect you
(as a WG draft editor) to get this issue resolved on the list and
make sure consensus is established before -01.

BR
/L-E

---

From: "Lars-Erik Jonsson \(LU/EAB\)" <[email-masked]>
Date: Wed, 23 Aug 2006 09:22:20 +0200

To respond also to the technical issue...

> In any case, I have tried to summarize both views regarding
> this in my presentation in Montreal, see my slides at:
> 

I tend to agree with you that the PROs of TBC are questionable,
and, even though it is an optional feature, it adds complexity.

Therefore, I also support the idea of not keeping TBC when we
do ROHCv2.

Rgds,
/L-E

---

From: "Ghyslain Pelletier \(LU/EAB\)" <[email-masked]>
Date: Wed, 23 Aug 2006 13:01:36 +0200

Hi,

Thanks for the minutes. I have reviewed those.

I would like a clarification regarding one comment I made and that is
found in the minutes. See inline.

/Ghyslain

Lars-Erik Jonsson (LU/EAB) wrote:
> 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.

I am in fact questionning the fact that IETF maintains two header
compression "paths" in parallel, eg the eCRTP and the RoHC paths.

The "which he believes is strange" actually stands for the following
points:

o I see no motivation for RoHC to "save the day" for eCRTP, simply
because having a solution for both makes it more difficult for eCRTP to
have its own solution.

o I see no motivation to make new RoHC profiles of older compression
algorithm

RoHC already compresses robustly and efficiently the same type of
headers ( ... not comparing here ... ). The always recurring argument on
deployment and simplicity does not convince me either, as the RoHC WG
has already committed to work on simpler profiles with RoHCv2.

o RoHC profiles meet certain design criterion

Would we do this I am not sure that such profiles would meet the usual
robustness vs compression eficiency requirements that the RoHC WG
normally uses when specifying its technical solutions, without some
changes with also require some cycles from the WG.
 
o I see no motivation for this WG to work on multiple solutions to the
same problem
One solution based on RoHCv2 profiles is a sufficient solution. It
should also thus be enough. If someone wants to do it for eCRTP, then
they can do it outside the RoHC framework.

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

---

From: "Ghyslain Pelletier \(LU/EAB\)" <[email-masked]>
Date: Thu, 24 Aug 2006 11:03:57 +0200

Hi Carsten,

See inline!

/Ghyslain

Carsten Bormann wrote:

>> because having a solution for both makes it more difficult for eCRTP
>> to have its own solution.
> 
> (I can't parse that sentence.)

Sorry about this - it was either that or french ; )

I meant that the RoHC framework provides its own packet types; it does
not rely on the lower layer to identify different RoHC packet types. The
argument I am seeing is that it would require too many IANA registry
entries to support IPHC/CRTP/eCRTP, and thus the proposal is then to
"hide" those within RoHC profiles.

Well, I think it's too bad for IPHC/CRTP/eCRTP ... but I don't see it as
a motivation to encapsulate those in RoHC. I actually think this is a
very poor argument.
 
>> headers ( ... not comparing here ... ). The always recurring argument
>> on deployment and simplicity does not convince me either, as the RoHC
>> WG has already committed to work on simpler profiles with RoHCv2.
> 
> I believe there are vendors that have considerable investment
> in implementing those technologies (i.e., debugging,
> performance, management functions, training).
> This may not be a purely technical argument, but it is
> important from a deployment perspective.
> 
> The new ROHCv2 profiles will be great, but they are not here
> today (and it will take a couple of years to have them out there).

I know this, I just don't understand why we still entertain this
consideration in the RoHC WG. This is in fact no argument to do with
RoHC imho.

Beside, I don't see the rationale being this? If vendors that are having
current deployment for other HC algorithms don't want to move over to
RoHC anyway, then why should they have a solution that mandates them to
deploy a RoHC channel??? Give them something only for their purpose,
independently of RoHC, if possible. If it is too difficult for another
solution specific to IPHC/CRTP/eCRTP to get an IANA registry, then they
can use RoHC profiles if they have to have the RoHC channel anyway. 

My second point is that someone has to draw the line if RoHC is to get
wider deployment.

<I hear you thinking out loud - making encapsulation for older HC
algorithms is a great way to get there, don't you get it Ghyslain?>

I would disagree to this reasoning; vendors using IPHC/CRTP/eCRTP have
not moved to RoHC, which makes me think that the opposite is just as
likely: we would be fixing a "problem" (in this case a single IANA entry
and a mechanism for HCoverIPSec) that would rather make this duality
last much longer. But any opinion on this is pure guessing I suppose.
 
>> Would we do this I am not sure that such profiles would meet the
>> usual robustness vs compression eficiency requirements that the RoHC
>> WG normally uses when specifying its technical solutions, without
>> some changes with also require some cycles from the WG.
> 
> I don't think we should try to make those changes.
> Having a ROHC profile number is not a seal of performance
> (the IETF is not in the certfication business...).

IETF is not a certification business, but it is not either a political
business. I still lack a technical motivation for this proposal. And on
a technical level I would be compelled to suggest that any proposal for
new profiles within this WG (based on IPHC/CRTP/eCRTP or not) be
motivated using a problem statement and clear requirements similar to
requirements we've had for all the profiles this WG has developped, just
like any other work we do.

>> o I see no motivation for this WG to work on multiple solutions to
>> the same problem One solution based on RoHCv2 profiles is a
>> sufficient solution. It should also thus be enough. If someone wants
>> to do it for eCRTP, then they can do it outside the RoHC framework.
> 
> That, I think, is the interesting question: Does this WG want
> to invest energy here to save other groups integration effort?
> This probably does hinge a bit on the available amount of
> energy, and I understand your concern.
> A related perception question is whether eCRTP is considered
> "competition" for ROHC. 

Not drawing the line sure does not help making this perception any
clearer ; )

> My personal point of view is that it is a historical artifact
> that the work on upgrading CRTP to eCRTP remained in the AVT
> group, and that the IETF should integrate all the related
> work on stateful header compression in one WG (no longer
> being a chair of that group liberates me a bit to state that opinion
> more openly). But that would imply we actually have to care for our
> adopted children as well as for our biological ones.

I entirely understand this point of view (arguments using "children" are
difficult to oppose to). Yet, I would not suggest "integration", rather
"maintenance" in the sense that if the old ones represent a solution to
something for which another solution already exists, then we should
stick to bug fixes ; )

> Gruesse, Carsten

---

From: Carsten Bormann <[email-masked]>
Date: Wed, 23 Aug 2006 22:50:12 +0200

Ghyslain,

thanks for clarifying your point of view on this.
Let me comment by giving my own point of view.

> has already committed to work on simpler profiles with RoHCv2.

I believe there are vendors that have considerable investment in  
implementing those technologies (i.e., debugging, performance,  
management functions, training).
This may not be a purely technical argument, but it is important from  
a deployment perspective.

The new ROHCv2 profiles will be great, but they are not here today  
(and it will take a couple of years to have them out there).

I don't think we should try to make those changes.
Having a ROHC profile number is not a seal of performance (the IETF  
is not in the certfication business...).

> they can do it outside the RoHC framework.

That, I think, is the interesting question: Does this WG want to  
invest energy here to save other groups integration effort?
This probably does hinge a bit on the available amount of energy, and  
I understand your concern.
A related perception question is whether eCRTP is considered  
"competition" for ROHC.

My personal point of view is that it is a historical artifact that  
the work on upgrading CRTP to eCRTP remained in the AVT group, and  
that the IETF should integrate all the related work on stateful  
header compression in one WG (no longer being a chair of that group  
liberates me a bit to state that opinion more openly).
But that would imply we actually have to care for our adopted  
children as well as for our biological ones.

Gruesse, Carsten