| Hi, Dominique,
Thanks for the explanation.
I still think the phrase “basic UDP headers” isn’t accurate. IMO, the compression for UDP headers needs to recognize the existing reality that the UDP length may not be predictable, i.e.:
Remove “basic”, because the algorithm doesn’t depend on whether UDP options are present or not.
Change the compression to either ignore UDP length OR to compress that field only when “UDPlength = IPlength - IPhdrsize”, i.e., to include the condition WITHIN the provided rule.
Suggested way forward below…
Joe
If
you agree with this premise, here are the proposed changes in
ietf-lpwan-ipv6-static-context-hc
(RFC8724-to-be)
In
a nutshell
-
clean up the “generic SCHC” specification from any hint that UDP Length
can
be recomputed. These hints are not necessary to understand the generic
SCHC
algorithm anyway.
Agreed, including as I proposed before:
- Section 7.5.8 should not include UDP length as an example of compute-*; it might even be useful to include the following as a caveat:
Note that UDP length is not an example of this type of field. In many conventional uses, UDP length is “IP length - IP header length”, but this is not strictly required by RFC 768 and there are emerging uses for cases where the lengths are not related this way [draft-ietf-tsvwg-udp-options].
-
In Section 10 and Appendix A, which are the only ones pertaining to UDP,
specify
that these recommendations/examples only apply when the UPD length
can
be straightforwardly recomputed out of IPv6 length.
...
Proposed
edits, in order of appearance in the draft
Abstract
OLD_TEXT
This
document defines a generic header compression mechanism and its
application
to compress IPv6/UDP headers.
NEW_TEXT
This
document defines a generic header compression mechanism and its
application
to compress basic IPv6/UDP headers.
Leave old text IMO.
Section
7.3.8
OLD_TEXT
Because
the field is uniquely identified by its Field ID (e.g., UDP
length),
NEW_TEXT
Because
the field is uniquely identified by its Field ID (e.g., IPv6
length),
Agreed.
OK
OLD_TEXT
Examples
of fields that know how to recompute themselves are UDP length,
IPv6
length and UDP checksum.
NEW_TEXT
An
example of fields that know how to recompute themselves is IPv6 length.
Grammar suggestion:
An example of a field that knows how to recompute itself is IPv6 length.
[DB] agreed, thanks.
Section
10
OLD_TEXT
10.
SCHC Compression for IPv6 and UDP Headers
NEW_TEXT
10.
SCHC Compression for basic IPv6 and UDP Headers
Again, leave original text IMO.
OLD_TEXT
This
section lists the IPv6 and UDP header fields and describes how
they
can be compressed. An example of a set of Rules for UDP/IPv6
header
compression is provided in Appendix A.
NEW_TEXT
This
section shows an application of the generic SCHC C/D mechanism (see
Section
7)
for
compressing basic IPv6 and UDP headers.
This
section only applies to UDP/IPv6 packets where the UDP length can be
straighforwardly
recomputed from the IPv6 length. An example of such a set
of
Rules is provided in Appendix A.
Sytems
MUST NOT apply compression Rules implemented with the
recommendations
from Section 10 unless they verify that the UDP length can
be
straighforwardly recomputed from the IPv6 length.
Again, unless UDP length can be compressed/not on a per-packet basis, leave as-is.
[DB] given that the answer is yes, I understand that you agree with the proposed change.
[DB] instead of "straightforwardly", I could say "be recomputed as IPv6 length", since we are considering IPv6 packets without extension headers. I could move
the latter statement up here from 10.8.
IMO, the section should include the “conditional compression” mechanism. I would not encourage including a mechanism that might or might not work.
Section
10.10 UDP Length Field
OLD_TEXT
The
UDP length can be computed from the received data. The TV is not
set,
the MO is set to "ignore", and the CDA is set to "compute-*".
NEW_TEXT
Providing
the condition described at the beginning of Section 10 is met,
the
UDP length can be computed from the received data. The TV is not set,
the
MO is set to "ignore", and the CDA is set to "compute-*”.
See my suggestion above.
[DB] given that the answer to the per-packet processing capability is yes, I understand that you agree with the proposed change.
I'd suggest starting with the text I proposed earlier:
- Section 10.10
The UDP length may or may not be related to the IP length, as noted in Section 7.5.8. A currently developing use of UDP options relies on UDP length being shorter than “IP length - IP header length”. In this case, the UDP options might be compressible but the UDP length is not computable from the UDP option fields alone.
If you want to include a rule that shows an example, then the rule itself needs to include the test condition.
Section
12.1.1
OLD_TEXT
This
property is true for IPv6 Length, UDP Length, and UDP Checksum, for
which
the compute-* CDA is recommended by this document.
NEW_TEXT
This
property is true for IPv6 Length, UDP Length, and UDP Checksum, for
which
the compute-* CDA is recommended by this document, under the
conditions
described at the beginning of Section 10.
OK.
Appendix
A
OLD_TEXT
This
section gives some scenarios of the compression mechanism for
IPv6/UDP
headers.
NEW_TEXT
This
section provides an example of a Rule set for compressiing basic
IPv6/UDP
headers, where the UDP length can be straightforwardly recomputed
out
of IPv6 length.
Again, see my caveat.
[DB] given that the answer to the per-packet processing capability is yes, I understand that you agree with the proposed change.
Disagree; IMO, the original text is preferable.
Again, the example should work with current UDP headers, not work “assuming” those headers have compressible lengths. The condition needs to be part of the rule. -- |
