Subject: [rohc] RE: Comments on draft-pelletier-rohc-udplite-01.txt

From: "Price, Richard" <[email-masked]>
Date: Wed, 5 Feb 2003 13:31:06 -0000

Hi Ghyslain,

Many thanks for your reply. I've added some further thoughts inline:

> > Page 4: "For UDP-Lite, the checksum has also completely
> > random values"
> > 
> > The checksum doesn't take random values (in fact its value
> > could be inferred from the uncompressed packet). We do
> > however need to transmit it "as-is" to avoid breaking the
> > end-to-end error protection.
> 
> I used the term "random" from a header compression perspective, in the
> sense that it cannot be compressed once one does not find acceptable to
> break its end-to-end nature using a recomputation of its value at the
> decompressor. The end-to-end nature of the checksum is mentionned two
> paragraphs above the quoted text, thus leading to this classification.
> 
> 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?

> > Page 5: Inter-packet behavior
> > 
> > Can we say more about the behaviour of the Checksum
> > Coverage field than the three cases given? For example,
> > even in behaviour pattern 3 (changing, but does not follow
> > any specific pattern) the checksum will almost certainly
> > cover far fewer than the maximum of 65535 bytes. So a
> > version of LSB encoding will get a higher compression
> > ratio than just sending the field in full.
> 
> I did consider this before, but my understanding is that this would
> require more changes to packets formats as defined for UDP than might be
> desirable, due to the more extreme cases. One objective with the
> definition of profiles for UDP-Lite as stated in the draft is to deviate
> as little as possible from what's already specified for UDP in RFC-3095.

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

> However I am certainly open into exploring this possibility once more. I
> would however appreciate if you could elaborate on this (i.e.
> motivations, expected behavior of the CC field, what is needed/tradeoffs
> of including LSB encoding for this field, mainly with respect to the
> resulting packet format).

Ok. I think the first step is to have a look at the three
behaviour patterns for UDP-Lite in more detail:

Behaviour pattern 1 occurs when UDP-Lite is used in the same
way as vanilla UDP. As stated in the draft, this behaviour
allows the CC field to be inferred from the overall packet
length.

Behaviour pattern 2 occurs when the UDP-Lite checksum covers
a simple fixed-length header (e.g. RTP/UDP-Lite only). In this
case the CC field is static relative to the context, just as
is stated in the draft.

Behaviour pattern 3 occurs when the UDP-Lite checksum covers
a more complex variable-length portion of the packet (e.g.
the RTP/UDP-Lite header and also the error-sensitive part
of the payload). The draft states that the CC field has
completely random behaviour in this case, but I disagree
with this - there's a lot we can say about the CC field even
if we can't predict its behaviour exactly. For example, it
will typically be much smaller than the maximum value of
65535 bytes, and only the last few LSBs are likely to change
relative to the previous packet.

So a more complex encoding for the CC field will save 1-2
bytes per header whenever behaviour pattern 3 occurs. I
think that this saving is well worth making: UDP-Lite is
a new protocol and we can't predict exactly how it will be
used, so we need to make sure we efficiently support all
three behaviour patterns.

The tradeoff is that the packet formats will need to be
different from those in RFC 3095. However I believe that
the increased efficiency and future-proofing outweighs
this drawback (see below).

> > Page 6: "Simplicity is a strong motivation for the design
> > of the UDP-Lite header compression profiles."
> > 
> > I'd like to clarify what is meant by the above sentence.
> > Are we looking for a profile that's simple in general, or
> > one that's simple given a full implementation of RFC 3095?
> 
> Simple, given an existing implementation of profiles 1 and 2.
> 
> If I reword section 4.1 as follow:
> 
> "A strong motivation for the design of a header compression
> scheme for UDP-Lite based on ROHC is to define profiles that
> entail only a few simple modifications to the corresponding
> profiles defined for UDP in [RFC-3095]."

Ok, I understand the design goal but I'm not sure I agree
with it ;-)

For the original RTP/UDP/IP profile, compression efficiency
was a much more important goal than simplicity (as anyone
who's read RFC 3095 will no doubt be aware!). For UDP-Lite
the efficiency of the solution should be equally important,
because the lossy, bandwidth-poor links where efficiency is
paramount are exactly the kind of links where UDP-Lite is
expected to be used in preference to regular UDP.

> > Page 7: "These profiles build on the specifications found
> > in [RFC-3095] with as little modifications as possible."
> > 
> > I think that the proposed profile contains at least one
> > enhancement that isn't strictly related to UDP-Lite,
> > namely the support for multiple IP headers. Whilst I
> > think this is a good idea, we should probably state
> > explicitly when enhancements of this nature are made.
> 
> The next sentence after the text quoted above begins with "unless stated
> otherwise". The addition of support for multiple IP headers is stated in
> the introduction (informative) and in section 5.3.1 (normative). It is
> possible that the way the text is written it might still be useful to
> bring the specific mention of that addition in Section 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.

From my perspective I'd like the final solution to be as
good as possible, so I strongly support making improvements
of this nature. However we might need to rewrite the
original sentence to clarify that RFC 3095 can be modified
if we believe the performance gain to be worthwhile.

> > Page 9: Packet formats
> > 
> > I'd recommend nailing down the behaviour of UDP-Lite more
> > precisely before defining the packet formats. This will
> > save time in the long run, because a small change to our
> > understanding of UDP-Lite may require the packet formats
> > to be completely rewritten. In particular I'd like to
> > investigate whether we can get more aggressive compression
> > of the Checksum Coverage field in behaviour pattern 3.
> 
> As said earlier, I will appreciate any input you can provide me on the
> expected behaviour of UDP-Lite from your perspective. I think that
> draft-pelletier-rohc-udplite-01.txt already provides a rather detailed
> discussion on this which should hopefully be at least a good basis.
> Also, I would definitely prefer that the profiles for UDP-Lite not
> require the packet formats to be completely rewritten.

In general I'm a big fan of reusing our existing work as far as
possible (in fact the whole purpose of the Formal Notation draft
is to provide a library of encoding methods that can be reused
between profiles). However I'd never do this at the expense of
a key goal like compression efficiency or future-proofing.

Also, I suspect that rewriting the packet formats wouldn't be
too difficult in practice. The hard part is defining the
encoding methods that compress each field, and we can reuse
what's been done in RFC 3095 for this. Once we know how to
compress each field the packet formats are basically trivial.

Regards,

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