Re: [Tsv-art] [Last-Call] [lp-wan] Tsvart last call review of draft-ietf-lpwan-coap-static-context-hc-12

[[e-mail]]

Hello Joe,

See my responses to your points, inlined.

In addition, one comment:
This draft describes the generic SCHC mechanism.
Section 10 describes how SCHC can be applied to compress UDP/IPv6 headers in their simplest form.
Please note Section 10.8 that says "This document does not provide recommendations on how to compress IPv6 extension headers".
I could easily add a Section 10.12 to say "This document only describes how to compress UDP headers without options".
Would that work?

Dominique

De : Joseph Touch <[e-mail]<mailto:[e-mail]>>
Date : Tuesday 17 March 2020 23:06
À : Benjamin Kaduk <[e-mail]<mailto:[e-mail]>>
Cc : Dominique Barthel <[e-mail]<mailto:[e-mail]>>, "[e-mail]<mailto:[e-mail]>" <[e-mail]<mailto:[e-mail]>>, The IESG <[e-mail]<mailto:[e-mail]>>, "[e-mail]<mailto:[e-mail]>" <[e-mail]<mailto:[e-mail]>>, "[e-mail]<mailto:[e-mail]>" <[e-mail]<mailto:[e-mail]>>, "[e-mail]<mailto:[e-mail]>" <[e-mail]<mailto:[e-mail]>>, "[e-mail]<mailto:[e-mail]>" <[e-mail]<mailto:[e-mail]>>
Objet : Re: [Last-Call] [lp-wan] Tsvart last call review of draft-ietf-lpwan-coap-static-context-hc-12

> My concern is Section 7.5.8.  How can both the IP and UDP lengths both be computed unless both depend directly on the link packet size?
[DB] they obviously can if the UDP packet at hand has no options (that's the "directly" part of your question). If the UDP header includes TLVs, things get trickier. Read next.

> AFAICT, With UDP options, the UDP length cannot be computed that way. The default rules need to take that into account.
[DB] In the example I showed in my other mail, I dealt with the UDP Length by sending the length in extenso over the wire. This example was meant to show that there is a way to handle UDP headers that include options.
There might be better ways, which compress better than this one, but at least I showed a correct one.

> I.e., you don’t need the UDP option TLVs if you don’t compress that area, but compression definitely needs to restore the UDP length as distinct from and unrelated to the IP length.
[DB] Yes, and I showed a way of achieving this.
[DB] Teaser:  Depending on the options present in the UDP header, a Rule night be able to do better than just sending the UDP length over the wire (or simple variations like sending a few least significant bits of the length, etc).
For example, if a UDP header only contains TLV-type of options, a CDA could rebuild the UDP length using the length of the options themselves and IPv6.Length.
Whether the compression gain is worth the code complexity remains to be seen, but the generic SCHC mechanism does not prevent one from doing that.
This is left for the "a-better-SCHC-compression-of-UDP-with-options" draft.

Joe

On Mar 17, 2020, at 2:13 PM, Benjamin Kaduk <[e-mail]<mailto:[e-mail]>> wrote:

In conclusion, the SCHC compression mechanism, if properly implemented, is
fully compatible with draft-tsvwg-udp-options.

This "if properly implemented" seems pretty critical.  Do we need to leave
a reminder that implementations have to know about UDP TLVs in order to
properly identify all fields in the headers to be compressed?

-Ben


_________________________________________________________________________________________________________________________

Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.

This message and its attachments may contain confidential or privileged information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.
Thank you.