[rohc] UDP-Lite compression

["Lars-Erik Jonsson (EAB)" <Lars-Erik.Jonsson@epl.ericsson.se>]

Richard, Ghyslain, and others,

> > Do you not agree that "random" is the correct classification for the
> > UDP-Lite checksum field?
> 
> I'd like to avoid the term "random", which generally refers to some
> data that has no discernable pattern whatsoever (thus the term is
> inapplicable to the UDP checksum). RFC 3095 coins the more general
> term "irregular" to describe fields "for which no useful change
> pattern can be identified". As well as truly random fields, this
> definition also applies to fields that do have a discernable pattern,
> but which isn't useful for compression (e.g. because it would violate
> end-to-end integrity). How about using this classification instead?

I agree that IRREGULAR might be the right word to use when we discuss
the classification, as that is the classification we used in 3095, and
when we now address the differences in UDP-Lite we should be consistent.

 
> I think it would be helpful to cleanly separate the chapter
> on UDP-Lite behavior from the proposed compression profile.
> The behavior chapter should just describe how we expect UDP-Lite
> to behave, without taking into account how we intend to compress
> it (much like the behavior draft we did for ROHC-TCP). If we
> expect the CC field to exhibit non-random behavior then we
> should say so, even if we then ignore this when actually
> compressing the field.

I agree, and that is what the current draft seems to do by providing
an analysis of the behavior in chapter 3, listing the design rationales
for the profile in chapter 4, and defining the actual profile in
chapter 5.


> The current text makes it clear that support for multiple
> IP headers has been added, but doesn't explain the motivation
> behind this addition. It seems to contradict the goal of
> making as little modifications to RFC 3095 as possible.

Not necessarily. One could actually say that this is a very simple
fix to allow compression of more than 2 IP headers. The profiles in
3095 would be able to handle that in IR/IR-DYN headers, but it has
not been defined how to carry additional information in compressed
headers. The solution (as defined by the IP profile) imposes really
no change to the profiles in 3095, it just requires a minor addition.
The header field structure for the added field is the same as the one
used in IR/IR-DYN headers. The actual compressed header formats are
thus not changed.


In general, it should be noted that UDP-Lite is very similar to UDP, 
and the difference is only about the checksum coverage (the fact that
the checksum can not be disabled does not affect the compression, it 
is already supported by the RTP/UDP and UPD profiles). One of the
reasons UDP-Lite has been defined as it is, is to simplify deployment
by making it implementable through a rather small modification to an
existing UDP implementation, and the same argument apply as well to
the UDP-Lite compression profile. We should make sure to minimize the
effort needed to modify existing ROHC profile 1,2 implementations to
get UDP-Lite compression. This will make life easier for implementers,
as well as it will simplify deployment of UDP-Lite compression. This
way, we should also be able to get interoperability verified easily,
as we already have had several interoperability tests of the current
profiles, and almost all parts have now been tested.

The WG has already completed its UDP and UDP/RTP tasks, and what is
left here is only to address the differences in UDP-Lite. Of course,
we should try to do our best to anticipate how UDP-Lite usage could
have implications for the coverage field behavior, and use this when
we incorporate coverage field handling in the profile(s). The current
draft has the means to exclude the coverage field or include it as a
two-octet field. However, I agree with Richard that it might make 
sense to use some variable length approach so that (when sufficient)
only one byte can be sent as W-LSB coded bits, and we should
investigate how to achieve this. The current draft shows that we can
do this without having to require significant changes to the UDP
profiles, we just have to focus on getting the last bit of the puzzle
right without breaking the rest of it.

Cheers,
/L-E


_______________________________________________
Rohc mailing list
Rohc@ietf.org
https://www1.ietf.org/mailman/listinfo/rohc