[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[rohc] Re: Comments on draft-pelletier-rohc-udplite-01.txt
Hi Richard,
Thanks for your review and comments, that's certainly appreciated. Some
thoughts inline.
/Ghyslain
"Price, Richard" wrote:
> UDP-Lite is still given as an Internet Draft - any ideas
> 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.
> 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?
> 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.
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).
> 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).
Agreed. But see above.
> 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]."
> 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.
> 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.
_______________________________________________
Rohc mailing list
Rohc@ietf.org
https://www1.ietf.org/mailman/listinfo/rohc