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

From: "Price, Richard" <[email-masked]>
Date: Tue, 4 Feb 2003 16:54:38 -0000

Hi,

Some comments on draft-pelletier-rohc-udplite-01.txt:

General:

UDP-Lite is still given as an Internet Draft - any ideas
on whether it is stable or likely to change in the future?

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.

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.

Page 6: "the field is CHANGING and the value must be sent
along with every packet."

CHANGING doesn't necessarily imply that the field value
must be sent in full (e.g. LSB encoding will often be
sufficient to reconstruct the field at the decompressor).

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?

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.

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.

Regards,

Richard

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

---

From: Ghyslain Pelletier <[email-masked]>
Date: Tue, 04 Feb 2003 18:53:29 +0100

Hi Richard,

Thanks for your review and comments, that's certainly appreciated. Some
thoughts inline.

/Ghyslain

> on whether it is stable or likely to change in the future?

My understanding is that the UDP-Lite draft was recently edited with
minor modifications, and is now very stable. I expect it to be published
without any substancial modifications.
 
> 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?

> 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.
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).

> sufficient to reconstruct the field at the decompressor).

Agreed. But see above.
 
> 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]."

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

> 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.
_______________________________________________
Rohc mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/rohc