Re: [Fwd: Re: incompatible feedback type 2 causes problemsinreusing the context for profile change]

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
> 
> 
> -----Original Message-----
> From: [email protected] [mailto:[email protected]] On 
> Behalf Of Ghyslain Pelletier
> Sent: den 8 september 2008 16:09
> To: Carsten Bormann; Carl Knutsson
> Cc: [email protected]; [email protected]; [email protected]
> Subject: Re: [rohc] [Fwd: Re: incompatible feedback type 2 
> causes problemsinreusing the context for profile change]
> 
> > 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 protected] [mailto:[email protected]] 
> On Behalf 
> > Of Carsten Bormann
> > Sent: den 8 september 2008 15:28
> > To: Carl Knutsson
> > Cc: [email protected]; Carsten Bormann; [email protected]; 
> > [email protected]
> > Subject: Re: [rohc] [Fwd: Re: incompatible feedback type 2 causes 
> > problemsin reusing the context for profile change]
> > 
> > > 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
> > 
> > _______________________________________________
> > Rohc mailing list
> > [email protected]
> > https://www.ietf.org/mailman/listinfo/rohc
> > 
> _______________________________________________
> Rohc mailing list
> [email protected]
> https://www.ietf.org/mailman/listinfo/rohc
>