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

From: "Lars-Erik Jonsson (EAB)" <[email-masked]>
Date: Thu, 3 Oct 2002 08:56:12 +0200

Hi all,

I totally agree with Micke here, i.e. to preserve the profile
numbering approach outlined in 3095, and make sure negotiations
are made correctly. As previously clarified on this list, this
is not a problem in the case of PPP. The reason I brought up
this issue was that problems were identified in the 3GPP ROHC
negotiation, but it is not too late to fix those. 

As Micke stated, this is the right time to make sure
negotiations are correctly defined for the link layers where
ROHC is implemented, rather than to create new ROHC protocol
problems for the future (through changes in the profile 
numbering).

Rgds,
/L-E

> -----Original Message-----
> From: Mikael Degermark [mailto:[email-masked]]
> Sent: den 3 oktober 2002 08:21
> To: [email-masked]; [email-masked]
> Cc: [email-masked]; [email-masked]
> Subject: Re: [rohc] PROFILES negotiation and profile "versions"
> 
> 
> Zhigang, 
> 
> I thought you asked about the rationale/history for the
> current state of affairs. That is what I explained.
> 
> I guess this thread has to do with what profile id to give to 
> 0-byte for R-mode.
>  
> I am of the opinion that assinging a version, rather than
> a new profile, now would force implementations to get
> this negotiation right at this early stage. We would
> thus avoid future problems. 
> 
> Therefore I would argue that it would be good engineering 
> to bite the bullet now, rather than later, and assign profile 
> id 0x0105 to 0-byte for R-mode. 
> 
> Getting this right now is much less of an effort than fixing
> future negotiation incompatibility problems would be. 
> I cast my vote is for making our lives easier down the road
> rather than right now. 
> 
> Cheers, 
> 
> Micke
_______________________________________________
Rohc mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/rohc

---

From: [email-masked]
Date: Thu, 3 Oct 2002 19:14:02 -0500

Mikael,

When Lars-Erik started the thread, I had the same guess as you that
it was probably triggered by the profile ID for 0-byte R-mode. 

Anyway, let's assume that 0-byte R-mode is given profile ID 0x0105, 
is my understanding below correct? (Just to make sure I get the 
right idea. I'm also trying to summarize the discussion so far.)

a) That means the new profile "is intended to supersede" (RFC 3095, 
section 8) profile 0x0005 as defined in RFC 3242. I.e., an implementation
should implement profile 0x0105 if it has not implemented 0x0005.
If it has, it should upgrade to 0x0105 (but see below).

b) However, as Carsten pointed out (and I agree), "the negotiation 
protocol must cope with any feature combination" of 0x0005 and 0x0105,
and "its results never may punish the upgrade".

c) In particular, if both decompressor and compressor support 0x0105,
then compressor can send 0x05 in IR header and decompressor should 
select profile 0x0105 (RFC 3095, section 5.2.3). No extra step of 
negotiation is needed.

d) If decompressor supports both 0x0005 and 0x0105 but compressor 
has NOT upgraded to 0x0105 (i.e. supports only 0x0005), then the 
negotiation protocol must take an extra step to tell decompressor: 
if you see 0x05 in IR header, it means 0x0005, not 0x0105.

BR,
Zhigang

> From: ext Mikael Degermark [mailto:[email-masked]]
> Sent: October 03, 2002 1:21 AM
> To: Liu Zhigang.C (NRC/Dallas); [email-masked]
> ----- Original Message ----- 
> From: <[email-masked]>
> To: <[email-masked]>; <[email-masked]>
> Cc: <[email-masked]>; <[email-masked]>
> Sent: Wednesday, October 02, 2002 10:52 AM
> Subject: RE: [rohc] PROFILES negotiation and profile "versions"
> 
> 
> > Hi Mikael,
> > 
> > Thanks for the clarifications. However, the issue here is 
> > multiple "versions" of the same profile, not that we have 
> > more than 256 active profiles. 
> > 
> > For example, LLA profile as defined in RFC3242 has profile
> > number 0x0005. Then, if the new profile with 0-byte support
> > for R-mode (see rohc-rtp-lla-r-mode-03.txt) is assigned 
> > with profile number 0x0105, we will have to handle two
> > "versions" of LLA profile although we only have 6 profiles
> > in total (0x0000, 0x0001, 0x0002, 0x0003, 0x0005, 0x0105).
> > 
> > One quick solution is to assign profile numbers in sequence
> > (i.e. differs in LSB) if a new profile is incompatible with
> > existing profile even though it is a new "version". (To me, 
> > two versions of incompatible profiles *are* two different 
> > profiles from protocol point of view.) This simplifies negotiation 
> > for the first 256 profiles: decompressor announces, compressor 
> > selects one and signal it in IR header. Of course, even with
> > this assignment policy, any negotiation still needs to define
> > extra steps for profile numbers > 0x00FF. But I think it will 
> > take a *long* time before this WG generates more than 256 
> > profiles, if ever. So, it's reasonable to make our life easier
> > for the use of the first 256 profiles. 
> > 
> > BR,
> > Zhigang
> 
> 
>

---

From: "Lars-Erik Jonsson (EAB)" <[email-masked]>
Date: Fri, 4 Oct 2002 08:45:24 +0200

Zhigang,

> if you see 0x05 in IR header, it means 0x0005, not 0x0105.

Yes, this was basically the original question I asked, which I think
has been clarified by now. The compressor must thus acknowledge the
profiles announced by the decompressor, as described in Micke's
original answer (see below). The decompressor will then know which
"version" is used by the compressor. 

Rgds,
/L-E 

> Sent: den 16 september 2002 13:01
> To: Lars-Erik Jonsson (EAB); [email-masked]; Carsten Bormann (E-mail)
> Hmm. Isn't it the sequence of events the following (for
> ROHC over PPP):
> 
> 1) Decompressor side sends to compressor side a list of
> supported profiles (16 bit numbers). This can include several
> profile numbers that only differ in the upper 8 bits, i.e.,
> are really variants of the same profile.
> 
> 2) Compressor side sees which of these it can do, and
> Configure-Acks those. It may not Configure-Ack two profile
> numbers that differ only in the upper 8 bits.
> 
> 3) Both sides now know what 8-bit profile numbers used in
> IRs and IR-DYNs mean: The corresponding 16-bit number, of
> which there may be at most one.

---

From: [email-masked]
Date: Fri, 4 Oct 2002 14:21:17 -0500

Lars-Erik,

Just to be sure everyone has the same interpretation, do you 
agree with c)? Note that c) includes the case where decompressor
supports both 0x0105 and 0x0005, while compressor supports only
0x0105.

-------------
-------------

BR,
Zhigang

---

From: "Lars-Erik Jonsson (EAB)" <[email-masked]>
Date: Mon, 7 Oct 2002 10:03:27 +0200

Zhigang,

> c) In particular, if both decompressor and compressor
>    support 0x0105, then compressor can send 0x05 in IR
>    header and decompressor should select profile 0x0105
>    (RFC 3095, section 5.2.3). No extra step of negotiation
>    is needed.
> -------------

If the decompressor supports 0x0005 AND 0x0105, while the
compressor supports only 0x0105, the only possible choice is
0x0105. But even if both sides support both 0x0005 and
0x0105, 0x0105 should be the obvious choice. 

However, c) above is not a sufficient requirement. Both sides
must also KNOW about the capabilities of the other side, i.e.
the decompressor must in the above example know that the
compressor only supports 0x0105, then the decompressor can
assume 0x05==0x0105.

Note also that it is probably a bad idea not to include
pre-version support when installing new versions, i.e. if
0x0105 is supported, also 0x0005 should be announced. This
guarantees that a "new" installation can communicate also
with hosts that have not been upgraded (the young ones should
respect the old ones). In most cases, the "old" version 
should basically come for free in implementation.

My answer to your question is therefore yes if c) was meant
to include that both sides know the capabilities of each other
after negotiation, otherwise I would not agree with c).

If the negotiation protocol is based on pure capability
announcements, the capabilities must be announced from 
both sides, and the newest version available at both sides
must be used. If the negotiation protocol is based on
configuration with acknowledgements (as in the case of PPP),
only one version of each profile must be acknowledged.

Rgds,
/L-E

---

From: [email-masked]
Date: Tue, 8 Oct 2002 22:18:39 -0500

Lars-Erik,

Below is exactly what I mean. For purpose of clarification, I made it 
overly redundant. I hope it's clear enough. So do you agree this time? 
If not, why do you think it does not work?

Case c1.

1) decompressor sends profile capability information 0x0105 and 0x0005
to compressor;

2) compressor supports only 0x0105, then the compressor does NOT need 
to inform the decompressor that 0x05 in IR or IR-DYNs mean 0x0105;

3) when decompressor sees 0x05 in IR or IR-DYNs, according to [RFC 3095, 
section 5.2.3], it "selects the highest-number profile", i.e. 0x0105.

Case c2. (only differs from c1 in that compressor supports both 0105 and
0005)

1) decompressor sends profile capability information 0x0105 and 0x0005
to compressor;

2) compressor supports both 0x0105 and 0x0005, and for obvious reasons
it chooses to use 0x0105. Then, the compressor does NOT need to inform the 
decompressor that 0x05 in IR or IR-DYNs mean 0x0105;

3) when decompressor sees 0x05 in IR or IR-DYNs, according to [RFC 3095, 
section 5.2.3], it "selects the highest-number profile", i.e. 0x0105.

BR,
Zhigang

> From: ext Lars-Erik Jonsson (EAB)
> [mailto:[email-masked]]
> Sent: October 07, 2002 3:03 AM
> To: [email-masked]

---

From: "Lars-Erik Jonsson (EAB)" <[email-masked]>
Date: Wed, 9 Oct 2002 09:15:48 +0200

Zhigang,

Please re-read previous messages from this thread. The discussion 
has shown that what is not clear in 3095 is that the PROFILES
channel state set must be the set of profiles supported by both
the compressor and the decompressor. 3095 says that the compressor
should pick the highest numbered profile, i.e. the newest "version"
available at both ends, and the decompressor should of course do
the same thing, but to do that it must then have the same PROFILES
set as the compressor.

> Case c1.
> 
> 1) decompressor sends profile capability information 0x0105
>    and 0x0005 to compressor;
> 
> 2) compressor supports only 0x0105, then the compressor does
>    NOT need to inform the decompressor that 0x05 in IR or
>    IR-DYNs mean 0x0105;

The compressor will have to tell the decompressor which profiles
are supported, otherwise the decompressor can not know whether
0x05 means e.g. 0x0005 or 0x0105. For PPP, we got this for free
since all configuration requests must be acked, we just have to
make sure other negotiation protocols incorporating ROHC implement
a similar capability.

Cheers,
/L-E

---

From: [email-masked]
Date: Wed, 9 Oct 2002 10:48:12 -0500

Lars-Erik,

> 0x05 means e.g. 0x0005 or 0x0105.

Why do you say that? Decompressor knows because following RFC3095
(see text quoted below), it selects max(0x0005, 0x0105) = 0x0105, 
which is exactly what compressor means by 0x05. 

-------------------------
[section 5.1.1, Per-channel parameters]

   PROFILES: Set of nonnegative integers, each integer indicating a
   profile supported by the decompressor.  The compressor MUST NOT
   compress using a profile not in PROFILES

[section 5.2.3, ROHC IR packet type]

   Profile: The profile to be associated with the CID.  In the IR
      packet, the profile identifier is abbreviated to the 8 least
      significant bits.  It selects the highest-number profile in the
      channel state parameter PROFILES that matches the 8 LSBs given.
---------------------------

As to the definition of PROFILES in the channel state, it is as clear
as shown above. There is nothing ambiguous about it.

Now, your concern is what if compressor does not support 0x0105?
That is case d. I think we already agreed on a simple solution: 
compressor *in-that-case* must explicitly signal it to decompressor
in the negotiation protocol. However, for case c), such explicit 
signal is NOT needed as I explained above. That's all I'm trying
to say. Does this make sense to you?

To summarize, my view is that we do not need to change the definition
of PROFILES. (Changes should be avoided whenever possible.) But we do 
need to say it explicitly somewhere that if the compressor uses a 
profile version that is not the highest-number profile announced by 
decompressor, compressor must explicitly signal that during negotiation
and any negotiation protocol (ROHC-over-xxx) must support this.

Zhigang

---

From: "Lars-Erik Jonsson (EAB)" <[email-masked]>
Date: Thu, 10 Oct 2002 00:04:27 +0200

Zhigang,

> and any negotiation protocol (ROHC-over-xxx) must support this.

OK, then we do agree that something is missing in 3095 in this regard.
I would also say that we are in practice proposing the same correction,
since both solutions do change the definition of PROFILES to mean "the set of profiles supported by both compressor and decompressor, where only one version of the same profile can be included". Also your approach assumes
that the decompressor knows which profiles are available for use at the
compressor side, it just differs in the way the information is
negotiated.

The difference is that the way Micke, Carsten and I saw this was that it
would be solved as in PPP, i.e. with a negotiation of "configure-ack"
type, where the common profile set is established by acknowledgements
for each decompressor profile supported also by the compressor. What your
proposal means is that the common profile set could also be established
with a negotiation of "configure-nack" type, where the compressor would
have to nack non-supported profiles (with an exception for the case when
a higher profile version is present and automatically disables the lower
version). 

I guess both "configure-ack" and configure-nack" could be ok, although
"configure-nack" would require more strict timing rules and negotiation
reliability to ensure nacks are not lost or significantly delayed. I
personally do not know whether such negotiation schemes are common.

Rgds,
/L-E

---

From: [email-masked]
Date: Wed, 9 Oct 2002 19:15:27 -0500

Lars-Erik,

Sorry about insisting on this, but I couldn't find answer to my question 
below regarding your previous claim (also copied). Could you give a 
direct answer? That would help a lot. Thanks.

Zhigang

----------------------

[Lars-Erik wrote:]
> > > 0x05 means e.g. 0x0005 or 0x0105.

[Zhigang wrote:]

---

From: "Lars-Erik Jonsson (EAB)" <[email-masked]>
Date: Thu, 10 Oct 2002 21:33:13 +0200

Zhigang,

I think my previous reply did answer this, but I will try to
explain further.

> Sorry about insisting on this, but I couldn't find answer to 
> my question below regarding your previous claim (also copied).
> Could you give a direct answer? That would help a lot. Thanks.
> 
> ----------------------
> 
> [Lars-Erik wrote:]
 
The above statements indicate that we seem to agree that the decompressor
will have to know. To do that, I assumed an acknowledging approach in the
negotiation, where either both sides tell the other side, or one side tell
the other and the other side acknowledges the profiles supported by both.

However, you propose to use a "nacknowledging" approach, where the
compressor sends a nack for profiles it does not support (with an
exception for "old versions" that might be automatically removed if
"newer versions" of the same profile are announced and not nacked).
I do agree that this would also be a possible negotiation approach,
although one have to be careful when designing it to make it reliable.

We should of course not limit the negotiation possibilities, but we must
clearer explain what a ROHC-negotiation must provide when it comes to
profile support. It is not enough that the compressor knows which 
profiles are supported by the decompressor. The decompressor must also
know (either through acks or lack of nacks). The PPP negotiation uses the
former approach, others might use the latter (or even some other way). If
the "nacknowledging"-approach is used, the negotiation protocol must 
carefully define how that should be carried out, including how the active
profile set is determined by the decompressor (e.g. that old versions are
not used if newer versions have been announced but not nacked).

BR
/L-E

---

From: [email-masked]
Date: Tue, 15 Oct 2002 11:41:38 -0500

[Lars-Erik wrote:]
> will have to know. 

Please, Lars-Erik, you know that was not my question. My question was why 
did you say "the compressor will have to tell the decompressor which 
profiles are supported"? It DOES NOT have to in *the* case we are 
discussing here, right?

1) decompressor announces profile 0x0005 and 0x0105 to compressor
2) compressor supports profile 0x0105 and 0x0005; it decides to use 0x0105
3) compressor sends 0x05 in IR packet. 
4) decompressor maps 0x05 in IR packet to 0x0105, following rules in RFC 3095.

So, the compressor does NOT have to tell decompressor that "I support both 
0x0005 and 0x0105". It's not needed for decompressor to derive the right 
meaning of 0x05, right?

In addition, it seems we have deviated from the original goal here. The goal
is how we can ensure that decompressor derives the correct meaning of 1-byte profile
abbreviation in an IR packet. That is NOT the same thing as determining
what profiles are supported by compressor. Because of the rules in RFC 3095, 
the former requires less information than the latter in the above case. For example,
it won't make any difference if compressor supports only 0x0105, instead of both 
0105 and 0005. Decompressor does not need to know that in order to get the
what compressor means by 0x05..

Zhigang

---

From: "Lars-Erik Jonsson (EAB)" <[email-masked]>
Date: Tue, 15 Oct 2002 22:54:02 +0200

Zhigang,

> My question was why did you say "the compressor will have to
> tell the decompressor which profiles are supported"? It DOES
> NOT have to in *the* case we are discussing here, right?

Not right, it will have to tell, implicitly or explicitly,
depending on how the negotiation is defined. It does not
necessarily have to tell all profiles supported, but at least
which version it will use of a profile for which the 
decompressor has announced support for multiple versions. In
the case of PPP, this is done explicitly, while one can think
of a more implicit approach (lack of nack), which seems to be
what you suggest. In any case, it must be explained somewhere
that this is needed from the negotiation, and that is what is
not clear from 3095.

> 4) decompressor maps 0x05 in IR packet to 0x0105, following 

First of all, 3095 does not state any clear rule for 4), as
discussed below. Secondly, if one interprets 3095 in that way,
one still have to accept the FACT that such an approach would 
only work if one have based the negotiation on the specific
assumption that the compressor would have to tell the 
decompressor which new profile versions it does not support
(from the announced set).

> it won't make any difference if compressor supports only 
> 0x0105, instead of both 0105 and 0005. Decompressor does
> not need to know that in order to get the what compressor
> means by 0x05.

Well, you have to pick an example that tests the logic. If
the compressor only supports 0x0005, your reasoning does 
not work. The compressor will in that case have to tell
the decompressor that it does not support 0x0105, which is
something that 3095 absolutely not talks about.

3095 defines says in section 5.2.3 that "In the IR packet,
the profile identifier is abbreviated to the 8 least
significant bits. It selects the highest-number profile in
the channel state parameter PROFILES that matches the 8 
LSBs given."

This is the section that you refer to as the rule for the
decompressor. However, it is far from clear whether it is
the decompressor that is addressed here as "It". Further,
if that was the case, the logic would still not work. 

As this thread quickly concluded in a few mails, it is
not clear in 3095 how the negotiation of PROFILES must be
done when it comes to multiple versions of the same profile,
i.e. profiles with the same 8 LSBs. Both compressor and
decompressor can not simply pick the highest number version
available. In the case of PPP, there is no problem since
all configuration parameters are acked, but other
negotiation schemes might fail in this regard if one has
just followed what is said in 3095.

I do agree that it is not necessary with an ack-based
negotiation, but something more is needed from the
negotiation than what 3095 states. 

/L-E

---

From: [email-masked]
Date: Tue, 15 Oct 2002 18:39:13 -0500

Lars-Erik,

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. You agreed on the logic in case d). 
You disagreed with logic in case c). I'm trying to find why.

However, some of your comments seem to jump between case c) 
and d), which make this discussion difficult to continue.
So, let me try another way to explain my points. I hope this
is easier for our discussion. 

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.

Zhigang