Subject: RE: [rohc] Reordering Support in RoHC

From: "Lars-Erik Jonsson (LU/EAB)" <[email-masked]>
Date: Thu, 10 Feb 2005 16:33:53 +0100

Hi Rohit,

>  We are interested in adding reordering support to the RTP profile
>  of RoHC.  

That is good news, as similar ideas have lately been expressed by
various parties. Can you elaborate on the actual application you
have in mind, is it multihop scenarios (like tunneling, MPLS, etc),
or normal single link header compression?

> As the reordering draft mentions, there is an inherent trade-off
> between RoHC's ability to handle reordering and consecutive dropped
> packets. Due to this fact, setting 'p' to a very large value to
> support any kind of reordering may not be the best strategy since
> this can affect the ability of RoHC to handle consecutive dropped
> packets.

True, although I would not say it is just a trade-off between loss and
reordering robustness, but it is also a question of what compression
efficiency should/can be offered for improved robustness. However,
considering this from a 3095 point of view, it boils down to picking
a proper value for p.

> It would thus, be of great interest to us if the 'p' value is
> negotiable (similar to the way MAX_CID, PROFILES etc) are
> negotiated. This would allow the compressor/decompressor to use
> the 'p' value most suited to their link characteristics.

Yes, to be able to handle reordering, one have to find a way to
get a ROHC profile operating with a different p value. However,
this can be achieved in several different ways. Link layer 
negotiation is one approach, but I am personally reluctant to
go that way, as that would require a change to ROHC link layer
mappings, which is something I believe should be avoided. If a
link layer supports ROHC negotiation, it should be able to handle
all ROHC profiles, in my mind. Anyway, there are several other
ways to do this. One that still require link-layer changes
without changing the actual link layer negotiation mechanisms is
to require that link layer specifications specify a p value, and
then have a default value to be used if no other value is specified.
Other approaches, which I personally would prefer, are to either
use different profile numbers to distinguish between different
encoding strategies, or to use in band configuration within one
single profile, i.e. explicitly transmit the p value within IR
or IP-DYN headers.

> A second issue that interests us is adding support to the RTP
> profile of RoHC to support constant (read 0) IP-IDs. Note that
> the IP profile of RoHC (RFC 3843) already has support for
> constant IP-IDs. Such functionality should thus be easy to add
> to the RTP profile of RoHC.

See below...

> We would like to get comments from RoHC authors for the best
> way we can support the above two issues. If, for supporting
> the above two issues, we need to define a new profile, then
> that will be our approach. Alternatively, if at some later
> stage, such issues could be incorporated as part of basic RoHC
> profiles (RFC 3095), then that would be useful too.

In any case, we would have to define new profiles, as the 3095
profiles do not have this support. The alternatives are really:
1) Define new 3095-based profiles with this support, and give
   them new profile numbers
2) Incorporate these issues into the 3095bis work that the WG
   is chartered to do, but which is on hold due to resource
   limitations in the WG (focus is currently on finalizing 
   ROHC TCP).

Personally, I would prefer alternative 2), as I believe RFC 
3095 is getting overloaded, and we have learned a lot since it
was published, which means 3095bis will become a much simpler
and more straightforward standard. The question is however when
this will actually be needed, as only doing the tiny little fixes
for reordering, IP-ID=0, etc, purely based on current RFC 3095
will for sure be doable with a much more aggressive time plan.

So, one question in addition to the one about envisioned
applicability is what kind of time plan you have in mind?
 
BR
/Lars-Erik

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

---

From: Carsten Bormann <[email-masked]>
Date: Thu, 10 Feb 2005 16:52:40 +0100

Would you want to set p values for an entire channel (which would be 
easy with a new suboption in RFC3241), or would you want to set it 
differently for each CID?
In the latter case, doing it in the IR sounds like the way to go.

(And, yes, the timeline question is important.)

Gruesse, Carsten