|
Hello Joe,
Indeed, the SCHC compression happens on a per-packet basis.
Incoming packets are broken into individual fields by the protocol analyser, then SCHC browses the rule store to find a rule that matches the fields that are being handed to it. If a rule matches (per the algorithm described in 7.3 of draft-ietf-lpwan-ipv6-static-context-hc-24),
then that rule is applied to compress the packet. The next packet with a difference in any field, no matter how slight, might be compressed by a different rule, which may handle UDP.Length differently. One rule may elide and recompute UDP length, the next
rule may send it in extenso (or only send a few lsbs, etc).
With SCHC, there is no notion of packet flow, nor any dynamic state built during a session. Each individual packet is pattern-matched and processed independently, using the static set of rules.
Based on this, I guess I can resolve your conditional answers below, inline.
Please let me know if they work for you.
Thanks
Dominique
Hi, Dominique,
See below.
My concern is whether UDP length can be compressed or not on a per-packet basis in SCHC.
Joe
Hello
Joe, all,
...
Second,
let me be transparent.
My
goal is to publish the specification of the * generic * SCHC mechanism
as
soon as possible.
Frankly,
I wish Section 10 (the application of the generic SCHC mechanism
to
UDP/IPv6) were a separate draft, so I would not have to worry about it
*
right now *.
Since
Section 10 shall remain a part of the generic SCHC draft, I’m trying
to
find the quickest exit route from the issues the draft currently has.
I’d
rather not being dragged into specifying the details of what SCHC must
do
in the presence of a UDP Length that cannot be straightforwardly
recomputed
out of the IPv6 Length.
That’s actually quite easy and thus it should not delay anything.
I’d
rather just state clearly that Section 10, as currently written,
*only*
applies to the case where the UDP Length can be straightforwardly
recomputed
out of the IPv6 Length, and leave for another draft to deal
with
the opposite case.
- 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].
- 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.
(Why
am I saying this? I’m guessing that there are situations where a
protocol
analyser understands all the fields/options/bytes between the
IPv6.Length
pointer and the UDP.Length pointer and SCHC conveys all these
fields/options/bytes
to the receiver. Then, UDP.Length might still be
recomputed,
admitedly not straightforwardly, out of IPv6.Length and the
received
fields/options/bytes.)
That’s not the case for UDP options.
[DB] discussing this is not on my shortest path to exit, but I love to take the time to understand this fully. At your leisure, and probably with a smaller CC list, would you mind pointing me at an example?
Therefore,
I would rather not write in this draft that “it MUST NOT be
compressed
as computable otherwise”, as Joe suggests in his email March
18th
14:6 UTC, included below.
See above; it doesn't need to say MUST NOT. It can leave the door open to alternatives, but I’d at suggest at least hinting that they might not exist.
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, e.g., esp. for 7.5.8
-
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.
OK, so this depends on how the compression works - which I need your help with.
Is it possible to compress when they “match” and not compress when they don’t? If so, then sure - say that. If not, then I would suggest erring on the side of assuming that UDP length cannot be compressed in any examples given - even perhaps adding a note
to explain why.
[DB] as said at the top of this email, the answer is yes, this is possible.
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.
That depends on whether or not you can do as I note above, i.e., compress or not compress that one field on a per-packet basis.
If not, then leave the original text and simply don’t compress the UDP length field.
[DB] given that the answer is yes, I understand that you agree with the proposed change.
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),
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, 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.
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.
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.
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.
Would
this work for you? Comments welcome.
Thanks
Dominique
Le
18/03/20 16:03, « Mirja Kuehlewind » <ietf@xxxxxxxxxxxxxx>
a écrit :
That’s the better wording!
On 18. Mar 2020, at 15:55, Joseph Touch <touch@xxxxxxxxxxxxxx> wrote:
On Mar 18, 2020, at 5:50 AM, Mirja Kuehlewind <ietf@xxxxxxxxxxxxxx>
wrote:
Indeed, the protocol parser and the SCHC rules need to know about the
UDP
TLVs if one wants to compress them.
But the same is true of all the other fields. I don't think this one
warrants a special notice.
What I insist on is that, if an implementation does not know of the
UDP
TLVs, it will not reconstruct an erroneous UDP Length, even for a
packet
that contains these TLVs, assuming that the protocol parser checks
the UDP
and IPv6 lengths for consistency.
I think this last statement (“protocol parser checks the UDP
and IPv6 lengths for consistency”) is the important point that needs
to be explicitly mention in the document!
That way of phrasing it is dangerous - it implies that when the values
differ there is some sort of error.
It would be more in line with current TSV efforts to standardize UDP
options to say “UDP length can be compressed when it *can* be computed
from the IP length” and that “it MUST NOT be compressed as computable
otherwise”.
Joe
_________________________________________________________________________________________________________________________
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.
--
last-call
mailing list
last-call@xxxxxxxx
https://www.ietf.org/mailman/listinfo/last-call
_________________________________________________________________________________________________________________________
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.
|
