Subject: RE: [rohc] ROHC feedback

From: "Kristofer Sandlund \(LU/EAB\)" <[email-masked]>
Date: Tue, 3 Apr 2007 11:02:29 +0200

Hi Biplab,

what you're describing is not a problem with any of the ROHC
specifications.
If this is something that happens frequently, then you have configured
your deployment with a MAX_CID lower than the number of flows that are
active on the channel (this is what rfc2507 refers to as CID thrashing).

So, I don't think there's anything to be said within this WG other than
that depoyments should be configured with a "large enough" MAX_CID to
handle
the expected number of paralell flows (then if that means MAX_CID=0 or
if
it means MAX_CID=10000, that's up to the deployment to decide).

BR,
   Kristofer

Biplab Sarkar <mailto:[email-masked]> wrote on den 3 april
2007 10:27 :

> Hi Kristofer,
> 
> The problem that I see is for U/O mode. The NACK comes for a
> SN of the previous profile. Since the profile was reused, it
> matched to some thing else and gave an in-efficient
> compression. Its really not dangerous, rather in-efficient.
> The transit delay of packets adds more to it. One should be
> discouraged to use MAX_CID=0 to avoid these type of problems.
> 
> Thanks
> Biplan
> 
> 
> On Tue, 2007-04-03 at 08:34 +0200, Kristofer Sandlund (LU/EAB) wrote:
> 
> 
> 	Hi Biplab,
> 
> 	first of all, do you think the provisions in section 7
> of rfc4815 are
> 	insufficient for context reuse? I think there are
> already quite a bit of
> 	restrictions that handle the harmful cases (and the
> only cases where
> 	there
> 	is ever any "danger" would be R-mode related and I
> think that's covered
> 	by 4815).
> 
> 	For U/O-mode:
> 	- Getting a NACK that was meant for the "old" context doesn't
> 	do any damage, it just decreases the compression
> efficiency for a
> 	short while.
> 	- A compressor is never *required* to do anything with
> ACKs, and they
> 	are
> 	only there in order to give guidance to the compressor so it
> 	*can* try to improve its compression efficiency.
> Getting an ACK for the
> 	old context *can* of course be a bit more dangerous if
> the compressor
> 	uses ACKs to move to a higher compression state (but
> see also section
> 	8.10
> 	of rfc4815). But since the compressor can know that it
> has recently been
> 	re-used it should just decide to not use the ACKs for
> that purpose.
> 
> 	If you don't agree with the above, could you describe
> in what situation
> 	you think that misinterpreted feedback actually breaks
> the compression
> 	or where the provisions of rfc4815 are insufficient.
> 
> 	BR,
> 	    Kristofer
> 
> 
> 	Biplab Sarkar <mailto:[email-masked]>
> wrote on den 3 april
> 	2007 07:10 :
> 
> 	> All,
> 	>
> 	> I believe one of the short comings of the ROHC feedback
> 	> mechanism is that it might get wrongly interpreted at the
> 	> other end. Since the CID might get reused because of the
> 	> limitation imposed my MAX_CID. And I have seen a roundabout
> 	> delay of about 4-5 packets typically. So, its very likely
> 	> going to get mis-interpreted. There should be some
> 	> restrictions on the re-use of CID.
> 	>
> 	> Thanks
> 	> Biplab
> 	>
> 	>
> 	>
> 	> ++++++++++++++++++++++++++
> 	> Starent Networks India Pvt Ltd.
> 	> 5th Floor,Surya Chambers, No 124
> 	> Murgeshpalya, Airport Road
> 	> Bangalore, 560017
> 	> Ph: +91-80-40109512
> 	> ++++++++++++++++++++++++++
> 
> ++++++++++++++++++++++++++
> Starent Networks India Pvt Ltd.
> 5th Floor,Surya Chambers, No 124
> Murgeshpalya, Airport Road
> Bangalore, 560017
> Ph: +91-80-40109512
> ++++++++++++++++++++++++++
> 
> 
> 
> 
> "This email message and any attachments are confidential
> information of Starent Networks, Corp. The information
> transmitted may not be used to create or change any
> contractual obligations of Starent Networks, Corp. Any
> review, retransmission, dissemination or other use of, or
> taking of any action in reliance upon this e-mail and its
> attachments by persons or entities other than the intended
> recipient is prohibited. If you are not the intended
> recipient, please notify the sender immediately -- by
> replying to this message or by sending an email to
> [email-masked] -- and destroy all copies of
> this message and any attachments without reading or
> disclosing their contents. Thank you."

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