Subject: [rohc] doubt

From: "Sarkar, Biplab" <[email-masked]>
Date: Wed, 22 Nov 2006 19:44:00 +0530

All,

I have a doubt on the concept of "re-ordering" and "updation" properties
of ROHC packets.

I think all "non-updating" packets are immune to "re-ordering". Is the
assumption correct?

Since we send all information with reference to a value that was already
send across reliably, any subsequent packets that are dependant upon
that reference can be received in any order. So in that case our
re-ordering depth becomes same as the "interpretation-interval".  Am I
correct?

But at the boundaries things will change. So one has to regularly send
across the "updating" packets but try to keep the frequency low.

Thanks

Biplab

+++++++++++++++++++++++++++++++++

Starent Networks India Pvt Ltd.

5th Floor,Surya Chambers, No 124

Murgeshpalya, Airport Road

Bangalore, 560017

Ph: +91-80-25221047/48/49

Ext:9512

+++++++++++++++++++++++++++++++++

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

---

From: "Ghyslain Pelletier \(LU/EAB\)" <[email-masked]>
Date: Wed, 22 Nov 2006 15:41:34 +0100

Personally, I am convinced that a reference-based approach for header
compression with reordering is a flawed idea. I think that this is well
documented in RFC4224, especially:
http://tools.ietf.org/html/rfc4224#section-5.1.2.1
http://tools.ietf.org/html/rfc4224#section-5.1.2.2
http://tools.ietf.org/html/rfc4224#section-6.1.1.2

... but I am including some more comments inline,

///Ghyslain

Sarkar, Biplab wrote:
> All,
> 
> I have a doubt on the concept of "re-ordering" and "updation"
> properties of ROHC packets. 
> 
> I think all "non-updating" packets are immune to
> "re-ordering". Is the assumption correct?

It depends what you mean by "immune".

If a reordered packet does not update the context, than it cannot damage
the context. But the reordered packet itself may fail; the issue here is
if this failure is detected or not.

But there are a number of performance tradeoffs and other undesirable
properties associated to this.

> Since we send all information with reference to a value that
> was already send across reliably, any subsequent packets that
> are dependant upon that reference can be received in any
> order. So in that case our re-ordering depth becomes same as
> the "interpretation-interval".  Am I correct?

An algorithm based on a reference normally requires feedback, and is
normally ACK-based. This means a more intensive use of the feedback
channel, and is not suitable for unidirectional operation (as opposed to
an optimistic approach, which is NACK-based).

Also, an increased amount of non-updating packets in a sequence of
compressed header means increasing frequency of updating the reference.
Alternatively, allowing less frequent updates to the reference requires
more MSN bits in every non-updating packet formats that are used
frequently, at least to palliate for the encoding of the sequentially
changing fields; updating the reference is still necessary when
semi-static patterns are changing.

So IMHO the most practical and most performant is to have all packet
being contetxt updating, to use a NACK-based feedback logic, and the
combination of the lsb coding for sequentially changing fields with the
use of the optimistic approach to update change patterns when needed.

> But at the boundaries things will change. So one has to
> regularly send across the "updating" packets but try to keep the
> frequency low. 

The frequency of update also depends on the behavior of the flow, and
this cannot be predicted, so it is not sufficient to think only in terms
of lsb (which is the usual misconception when discussing reordering
impairments).