Subject: [rohc] ROHC feedback

From: Biplab Sarkar <[email-masked]>
Date: Tue, 03 Apr 2007 10:40:10 +0530

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
++++++++++++++++++++++++++

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

---

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

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

---

From: Biplab Sarkar <[email-masked]>
Date: Tue, 03 Apr 2007 13:57:24 +0530

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

---

From: Carsten Bormann <[email-masked]>
Date: Tue, 3 Apr 2007 12:31:33 +0200

On Apr 03 2007, at 10:27, Biplab Sarkar wrote:

> One should be discouraged to use MAX_CID=0

Indeed (why would one want to do this?).

Of course, the interesting thing with starting a new CID for a new  
call that immediately follows a preceding call is that you are then  
stuck with that (non-zero) CID for the duration of that flow (or  
until you IR context CID=0 with the same flow, which also is a bit  
inefficient).  CR would help a bit here (but the CR packets still  
aren't second order).

All quality of implementation issues, nothing to standardize here.
(Except that the full-byte penalty for CID≠0 is somewhat unfortunate,  
but we didn't have a way to come up with a smaller penalty.)

Gruesse, Carsten

---

From: Biplab Sarkar <[email-masked]>
Date: Tue, 03 Apr 2007 16:39:27 +0530

Carsten,

People seems to like the idea of MAX_CID=0 just for avoiding the
one-byte overhead.  For VoIP traffic people are to picky about it. I was
thinking of allocating CIDs efficiently by giving CID=0 to the packets
which are highly probable.

Thanks
Biplab