Subject: RE: [rohc] PROFILES negotiation and profile "versions"

From: "Lars-Erik Jonsson (EAB)" <[email-masked]>
Date: Wed, 16 Oct 2002 12:34:32 +0200

Zhigang,

> From your comments, I'm not sure you understand my original email.
> http://www1.ietf.org/mail-archive/working-groups/rohc/current/
> msg00846.html
> 
> First of all, case c) and case d) are just two logic branches in 
> *one* negotiation protocol. 

I absolutely understand what you said in that mail, and I do agree
that the negotiation protocol you outlined would potentially work.
As you now express your proposal as one potential negotiation
protocol (the original mail gave the impression it tried to define
THE solution), I think we are getting the right perspective on this.

My main point was that 3095 is not clear in this regard, which
is something we should capture, e.g. in the impl. guide, and 
clarify what must be provided by the negotiation protocol, without
being too specific when it comes to how negotiation is implemented.

> Let's say we have a negotiation protocol for ROHC as follows.
> My question is simple: does it work? It appears working to me.
> And it is efficient since it avoids the extra step when compressor
> supports the highest version announced by decompressor.
>
> (Note: since the subject is multiple versions of the same
> profile, only that part is covered below.)
> 
> 1) Decompressor announces all versions it supports to compressor
>
> 2) Compressor checks if it supports the highest version announced. 
> If yes, it does not send ACK, and simply sends the LSB of the 
> profile in IR header; Else, compressor ACKs the version it supports 
> to decompressor.
> 
> 3) Decompressor side. If it receives ACKs from compressor, it
> maps a profile LSB in IR header to the ACKed profile; Else,
> it follows the "highest-number" rule as in RFC 3095, i.e.
> maps the LSB in IR header to the highest version it has announced.

The above should be able to work, although it is not as easy to
ensure reliability in the negotiation if acks are not used for
all announced profiles (as we do in e.g. PPP). However, whether this
is a problem or not depends of course on the actual link technology.

To summarize: I do not disagree that your proposed negotiation
protocol could be a potential candidate for some link technologies,
but that is just one example and it is not really our responsibility
to define negotiation protocols. What we should do in ROHC is
to clarify what is really needed from the negotiation protocol, to
ensure that profile identifiers are correctly interpreted when it
comes to the "version" part. 3095 does not discuss this at all.

Cheers,
/L-E 

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

---

From: Carsten Bormann <[email-masked]>
Date: Mon, 21 Oct 2002 06:45:53 +0200

ROHCers,

I had hoped we had laid this one to rest, but then I happened to look 
at the current work on RFC2509bis again, which handles negotiation just 
slightly differently.
It seems we have the following interesting race with RFC3095/RFC3241:

-- Assume there are two profile versions 0153 and 0253, with 
incompatible wire formats.
-- IPCP has just successfully negotiated 0153, and data start to flow 
happily in 0153's wire format.
-- IPV6CP comes up and negotiates 0253.

Oops. RFC 3241 section 3 says:
    When the option has been
    negotiated with different values in IPCP and IPV6CP, the result is
    that the set of parameter values for the entire ROHC channel is the
    logical union of the two values, i.e., the maximum for MAX_CID, MRRU
    or MAX_HEADER, and the logical union of the suboptions.  For the
    PROFILES suboption, the logical union is the union of the two sets of
    profiles.
Result: the in-flight 0153 IPv4 headers are subjected to a race -- once 
the 0253 negotiation sticks, the data are interpreted as 0253 IPv4 
headers. (Even if the wire format is upward compatible, it's not quite 
clear whether/when the compressor can start using 0253 features on the 
CID that started out 0153.  And heaven forbid if the CID is established 
in the period of uncertainty.)

So better don't do that.

I.e., the implementers' guide should contain strong language suggesting 
you don't negotiate different profile versions for IPv4 and IPv6.  This 
also has interesting implications on the evolution of profiles: we 
can't define a new profile version just for IPv4 or for IPv6, we always 
have to do both if previous versions did, or we are asking for the 
above race.

I don't think this is much of a practical problem, just one more little 
thing that implementers have to keep in mind for robustness.

Gruesse, Carsten

---

From: Carsten Bormann <[email-masked]>
Date: Mon, 21 Oct 2002 09:14:02 +0200

ROHCers,

So better don't do that.

Gruesse, Carsten