Subject: Re: [rohc] [Fwd: Re: incompatible feedback type 2 causes problems in reusing the context for profile change]

From: "Carl Knutsson" <[email-masked]>
Date: Mon, 8 Sep 2008 15:06:28 +0200

Suneeta, Biplab,

Suneeta, thank you for bringing this issue to our attention. The different
modes in RFC3095 have always been a bit of a pain. I am not however
convinced that this issue is a very big problem in ROHC. It will only affect
the compression efficiency. The compressor will stay in the current mode
 (U-mode in this case) until the feedback for IR/IR-DYN/UOR-2-Ext3 is
recieved with a mode field that acknowledge the mode transfer.

The compressor could probably figure out that it received feedback
from another "context". The sequence number may give a clue or
mode-bits in the following feedback. The CRC in the feedback is not
bullet-proof and there is always a possibillity of bit-errors in
feedback.

Biplab, I am not aware of any backward compatibility issues between
RFC3095 and RFC5225 profiles. If you have found any such issues,
please send details to the rohc-list.

Best Regards,
Carl Knutsson, ROHC WG Chair

On Mon, Sep 8, 2008 at 2:40 PM, Carl Knutsson <[email-masked]> wrote:
>
>
> -------- Original Message --------
> Subject:        Re: [rohc] incompatible feedback type 2 causes problems in
> reusing the context for profile change
> Date:   Mon, 08 Sep 2008 17:49:32 +0530
> From:   Sarkar Biplab <[email-masked]>
> Reply-To:       [email-masked]
> To:     Suneeta Rao <[email-masked]>
> CC:     [email-masked]
> References:     <[email-masked]>
>
>
>
> Hi Suneeta,
>
> I believe you can't have direct backward compatibility between ROHCv1
> and ROHCv2. Only one should exists. This problem will not exist between
> feedbacks from different protocols in the same version of the ROHC
> specification.
>
> Thanks & Regards,
> Biplab
>
>
> On Mon, 2008-09-08 at 04:16 -0700, Suneeta Rao wrote:
>>
>> Hello ROHCers,
>>
>> I have a question on changing profile from ROHCv2 to RFC3095 and vice
>> versa. Please note that I only have a basic simulation environment.
>>
>> When I change from ROHCv2 to RFC3095 in compressor, I am getting some
>> stale feedback from the peer decompressor which was for ROHCv2.
>> However, because of incompatible formats between ROHCv2 and RFC3095,
>> compressor is interpreting parts of Ack no as "mode bits" of RFC 3095.
>> This is being treated as a mode transition.
>>
>> I'm pointing this out as this looks like a ROHC specification issue.
>> In general, what is the expected behaviour if profile change is done
>> from ROHCv2 to ROHCv1? How are stale packets to be handled? I haven't
>> looked at other profiles, but I guess the issue might be there for TCP
>> profile also.
>>
>> Regards,
>> Suneeta.
>>
>>
>> _______________________________________________
>> Rohc mailing list
>> [email-masked] <mailto:[email-masked]>
>> https://www.ietf.org/mailman/listinfo/rohc
>
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.6 (GNU/Linux)
>
> iD8DBQBIxRhU3rQBTW1UPu4RAr2JAKCmdEeeN9uw/EhDUotjLn3hvpyTUwCgtmse
> WvwudYd9SMChxqZepI5Uiwg=
> =3gms
> -----END PGP SIGNATURE-----
>
>
> _______________________________________________
> Rohc mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/rohc
>
>
>
_______________________________________________
Rohc mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/rohc

---

From: Carsten Bormann <[email-masked]>
Date: Mon, 8 Sep 2008 15:28:24 +0200

> backward compatibility issues between
> RFC3095 and RFC5225 profiles.

This discussion confuses me.

1) *Why* would you want to switch between RFC 5225 and RFC 3095 on one  
channel?

2) *How* would you do it?  I don't understand how do this with a ROHC- 
over-X protocol like RFC 3241, but maybe you are using something  
different.

(RFC 4995 section 5.1.2 clearly spells out:

       [...] if multiple variants of the same profile are available  
for a
       ROHC channel, the PROFILES set after negotiation MUST NOT include
       more than one variant of the same profile. [...]

Note that the ROHCv2 profiles have been encoded as "variants" of the  
ROHCv1 profiles.)

Gruesse, Carsten

---

From: "Ghyslain Pelletier" <[email-masked]>
Date: Mon, 8 Sep 2008 16:09:25 +0200

> This discussion confuses me.

I was about to write the exact same thing. I agree with Carsten's
comment.

It is not possible configure multiple variants of the _same_ profile for
a ROHC channel, and thus it is not possible to switch between _variants_
without first tearing down the channel (clearing all state). Note
however that it is possible to configure _different_ profiles of
different "variants" (i.e. With some 0x00yy and some 0x01zz as long as
yy!=zz) at the same time for a ROHC channel; however, I see no useful
reason to do this type of combination with currently defined set of
profiles.

Wrt compatibility between profiles and different definitions of feedback
type 2, the feedback element contains CID information indicating what
context the feedback data is for and the context contains the associated
profile by which the format of the feedback data shall be interpreted. A
compressor implementation can manage reuse of CIDs so that no risk for
misinterpretation occurs when reassociating a CID to a different
_profile_. E.g. Either change a CID/profile association only when there
is no risk of receiving any feedback for the old association or stick to
that association and use a different CID as needed.

Cheers,

///Ghyslain

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On 
> Behalf Of Carsten Bormann
> Sent: den 8 september 2008 15:28
> To: Carl Knutsson
> Cc: [email-masked]; Carsten Bormann; 
> [email-masked]; [email-masked]
> Subject: Re: [rohc] [Fwd: Re: incompatible feedback type 2 
> causes problemsin reusing the context for profile change]
> 
> 1) *Why* would you want to switch between RFC 5225 and RFC 
> 3095 on one channel?
> 
> 2) *How* would you do it?  I don't understand how do this 
> with a ROHC- over-X protocol like RFC 3241, but maybe you are 
> using something different.
> 
>        [...] if multiple variants of the same profile are 
> available for a

---

From: "Carl Knutsson" <[email-masked]>
Date: Mon, 8 Sep 2008 16:26:46 +0200

Hi all,

Sorry about repeating some of the things Ghyslain wrote in his email. I am
struggling with the delays and user-interface of gmail:). Below
follows my reply
that I only sent to Carsten (by misstake).

Cheers, Calle

On Mon, Sep 8, 2008 at 4:15 PM, Carl Knutsson <[email-masked]> wrote:
> Carsten,
>
> Please read my comments inline...
>
> On Mon, Sep 8, 2008 at 3:28 PM, Carsten Bormann <[email-masked]> wrote:
> I am not sure I would want to this switch:), or even recommend it, but to my
> knowledge there is nothing in the RFCs that prevents it and I see no reason
> to do so.
>
>>
>> 2) *How* would you do it?  I don't understand how do this with a ROHC-over-X
>> protocol like RFC 3241, but maybe you are using something different.
>
> I cannot see how RFC 3241 prevents any user from using profiles from both
> RFC 5225 and RFC 3095, but I may have missed something. A list of profiles is
> negotiated, by agreeing on a list of 16 bit profile identifiers that
> consist of both
> version and profile. Why can't profiles from both RFC3095 or RFC5225 be
> negotiated?
>
> I haven't read this RFC for a few years, so I may be wrong. I will
> read it again
> today to see if I have missed anything.
>
>>
>>      [...] if multiple variants of the same profile are available for a
>> Note that the ROHCv2 profiles have been encoded as "variants" of the ROHCv1
>> profiles.)
>
> This text is added because of the 8 bit profile field in the IR
> packet. Since we
> don't have a profile version in IR packet, it would be impossible to
> separate for
> example the v2 RTP profile from the v1 RTP profile. Still one could negotiate
> RFC3095 UDP profile and RFC5225 RTP profile. The TCP profile can negotiated
> together with both RFC3095 and RFC5225 profiles.
>
> Cheers, Calle
>

---

From: "Ghyslain Pelletier" <[email-masked]>
Date: Tue, 9 Sep 2008 10:57:56 +0200

Suneeta,

As explained in my previous mail my understanding is that ...

1) the protocol is clearly specified wrt feedback interpretation:
   - feedback element contains CID indicating what context the
     feedback data is for;
   - CID indicates what profile to use to parse the feedback data;

2) having a combination of different profiles configured at the
   same time for a ROHC channel, where some are defined in
   RFC3095 and some in RFC5225, is not expected in a real-life
   deployment.

3) implementations are expected to handle CID/profile associations
   and reuse of CIDs properly, by either:
   - changing an existing CID/profile association only when there
     is no risk of receiving any feedback for the old association; or
   - sticking to that association and use a different CID as needed

Yet, in case the situation that you have depicted still occurs, most
likely the SN in the feedback will not match and this can be detected by
the implementation as well following the change in CID/profile
association.

But in my opinion the most compelling argument is, as also I believe was
pointed out indirectly by Carl, is that it would at worse only lead to a
small and temporary degradation of compression efficiency, i.e. The
protocol would not break.

For all those reasons, my view is that this is not an issue for the
protocol specification, and thus is not a necessary addition for
consideration to RFC4995bis.

Cheers,

///Ghyslain

> Hello Ghyslain / Carl / Carsten,
> 
> To give an example, if we have UDP profile from RFC 3095,
> and RTP profile from RFC 5225, we have this issue of feedback
> mis-interpretation.
> 
> Note that this is not restricted to RFC3095/5225 only. It
> could be a TCP profile (RFC4996) context reused for some other
> profile.
> 
> Since any implementation based on RFC's is likely to face this
> issue, I feel it will be better to highlight this issue in a
> clarification RFC. Maybe the draft RFC being done on RFC 4995
> can be used to add a solution.
> 
> Regards,
> 
> Suneeta
> 
> 
> Behalf Of Ghyslain Pelletier
> Sent: den 8 september 2008 16:09
> To: Carsten Bormann; Carl Knutsson
> Cc: [email-masked]; [email-masked]; [email-masked]
> causes problemsinreusing the context for profile change]
> 
> I was about to write the exact same thing. I agree with 
> Carsten's comment.
> 
> It is not possible configure multiple variants of the _same_ 
> profile for a ROHC channel, and thus it is not possible to 
> switch between _variants_ without first tearing down the 
> channel (clearing all state). Note however that it is 
> possible to configure _different_ profiles of different 
> "variants" (i.e. With some 0x00yy and some 0x01zz as long as
> yy!=zz) at the same time for a ROHC channel; however, I see 
> no useful reason to do this type of combination with 
> currently defined set of profiles.
> 
> Wrt compatibility between profiles and different definitions 
> of feedback type 2, the feedback element contains CID 
> information indicating what context the feedback data is for 
> and the context contains the associated profile by which the 
> format of the feedback data shall be interpreted. A 
> compressor implementation can manage reuse of CIDs so that no 
> risk for misinterpretation occurs when reassociating a CID to 
> a different _profile_. E.g. Either change a CID/profile 
> association only when there is no risk of receiving any 
> feedback for the old association or stick to that association 
> and use a different CID as needed.
> 
> Cheers,
> 
> ///Ghyslain
> 
> > From: [email-masked] [mailto:[email-masked]] 
> On Behalf 
> > Of Carsten Bormann
> > Cc: [email-masked]; Carsten Bormann; [email-masked]; 
> > [email-masked]
> > Subject: Re: [rohc] [Fwd: Re: incompatible feedback type 2 causes 
> > problemsin reusing the context for profile change]
> > 
> with a ROHC-