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

From: <[email-masked]>
Date: Fri, 13 Mar 2020 23:48:18 +0000

Hello all,

This is the response by the ietf-lpwan-ipv6-static-context-hc co-authors
to the observation below by Joseph Touch.
You are right that Section 10 of ietf-lpwan-ipv6-static-context-hc only
shows how to compress IPv6/UDP packets that have no extensions.

However, the SCHC specification in Section 7.1 states
"It is assumed that
   there is a protocol parser alongside SCHC that is able to identify
   all the fields encountered in the headers to be compressed, and to
   label them with a Field ID."

Furthermore, Section 7.3 states
"If any
         header field of the packet being examined cannot be matched
         with a Field Description with the correct FID, the Rule MUST be
         disregarded.  If any Field Description in the Rule has a FID
         that cannot be matched to one of the header fields of the
         packet being examined, the Rule MUST be disregarded."

It follows that, if an IPv6 packet does contain the new UDP TLVs
introduced by draft-tsvwg-udp-options, it will not match a Rule destined
to compress the IPv6/UDP headers and that does not have these TLVs as part
of the Field Descriptors.
Therefore, it will no be compressed by that Rule and will not be
decompressed with a wrong UDP Length at the receive end.

By contrast, if a Rule destined to compress the IPv6/UDP headers does have
these UDP TLVs as part of the Field Descriptors, it is responsible for
reconstructing the UDP Length properly. This can be achieved by means
already provided by SCHC, such as sending the value over the wire or
matching it to an expected constant, etc.

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

Best regards,

Dominique

Le 12/02/20 16:08, « lp-wan on behalf of Joseph Touch via Datatracker »
<[email-masked] on behalf of [email-masked]> a écrit :

>Reviewer: Joseph Touch
>Review result: Almost Ready
>
>This document has been reviewed as part of the transport area review
>team's
>ongoing effort to review key IETF documents. These comments were written
>primarily for the transport area directors, but are copied to the
>document's
>authors and WG to allow them to address any issues raised and also to the
>IETF
>discussion list for information.
>
>When done at the time of IETF Last Call, the authors should consider this
>review as part of the last-call comments they receive. Please always CC
>[email-masked] if you reply to or forward this review.
>
>I found no transport issues with this document.
>
>However, this document normatively cites
>ietf-lpwan-ipv6-static-context-hc,
>which does have some transport issues of concern. I am listing them here
>because of the dependency between the two documents.
>
>In particular, ietf-lpwan-ipv6-static-context-hc overlooks the case where
>the
>IP header indicates a packet longer than the UDP header, a case that is
>currently being developed for UDP header options in TSVWG. This other
>document
>claims that both UDP and IPv6 length fields can be computed from the
>received
>data, but this is not the case when the IP header indicates a packet end
>after
>that of the UDP header. See draft-tsvwg-udp-options for more information.
>
>There are no changes needed to this document to address this length
>issue, but
>the normative dependency in this doc is the reason for indicatin this
>document
>as "Almost Ready".
>
>_______________________________________________
>lp-wan mailing list
>[email-masked]
>https://www.ietf.org/mailman/listinfo/lp-wan

_________________________________________________________________________________________________________________________

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.

---

From: Benjamin Kaduk <[email-masked]>
Date: Tue, 17 Mar 2020 14:13:35 -0700

> 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

---

From: Joseph Touch <[email-masked]>
Date: Tue, 17 Mar 2020 15:06:06 -0700

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?

AFAICT, With UDP options, the UDP length cannot be computed that way. The default rules need to take that into account.

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.

Joe

> On Mar 17, 2020, at 2:13 PM, Benjamin Kaduk <[email-masked]> wrote:
>

---

From: <[email-masked]>
Date: Tue, 17 Mar 2020 22:53:06 +0000

Hello Joe,

Our mails have crossed.
Content of my previous mail copied here, keeping the original destination list, which I had trimmed down in said mail.

Dominique

Here are some examples to illustrate my answer in the mail below.

We have the following processing chain:
- protocol parser: breaks the headers of incoming packet into itemised fields, each with an identifier that tells what they are. Hands this set of fields to the SCHC compressor.
- SCHC compressor: browses the Rule set to find a Rule that matches the set of fields. Compresses each field per the Rule, sends RuleID + compression residues + payload.
- SCHC decompressor: based on the received RuleID and residues, rebuilds the itemised fields, hands the set of fields to the protocol reconstructor.
- protocol reconstructor: concatenates the itemised fields into protocol headers, concatenates the payload. Hands to the upper layer.

Here, let's assume we intend to compress the UDP/IPv6 headers. The upper layers headers are considered "payload" in our discussion.
For this discussion, I will only consider the Length field of IPv6, ignoring all other IPv6 fields.
Therefore, I will say an old-style UDP/IPv6 packet only has 5 fields:
- IPv6.Length
- UDP.Length
- UDP.Checksum
- UDP.SourcePort
- UDP.DestPort
While a post draft-tsvwg-udp-options UDP/IPv6 packet may have more fields
- UDP.Option1
- UDP.Option2
- etc.

Let's assume ProtocolParserA does not understand draft-tsvwg-udp-options.
Let's assume ProtocolParserB does understand draft-tsvwg-udp-options.
Let's assume PacketU is a well formed old-style UPD/IPv6 packet.
Let's assume PacketV is a post draft-tsvwg-udp-options UPD/IPv6 packet, that includes UDP.Option1 and UDP.Option2.
Let's assume Rule1 only has the old-style 5 field descriptors. In its CDAs, the UDP length is elided at the compressor and reconstructed out of IPv6.Length at the decompressor.
Let's assume Rule2 has the 5 old-style field descriptors plus UDP.Option1 and UDP.Option2. In its CDAs, the UDP length is sent in extenso as a compression residue.

When PacketU or PacketV is submitted to SystemA, which includes ProtocolParserA, or to SystemB, which includes ProtocolParserB, the outcome is described in the following table.

                      PacketU                      PacketV
-----------------------------------------------------------------------------------------------
     | PPA parser   | 5 itemised fields          | incorrect UDP length, nothing handed to SCHC
     | SCHC comp    | Matches Rule1              |
SystA|              | UDP.Length elided          |
     | SCHC decomp  | UDP.Length recomputed      |
     | PPA reconstr | correct UDP header         |
-----------------------------------------------------------------------------------------------
     | PPB parser   | 5 itemised fields          | 7 itemised fields
     | SCHC comp    | Matches Rule1              | Matches Rule2
SystB|              | UDP.Length elided          | UDP.Length sent as a compression residue
     | SCHC decomp  | UDP.Length recomputed      | UDP.Length retrieved from residue
     | PPB reconstr | correct UDP header         | correct UDP header

-----------------------------------------------------------------------------------------------

Further variations:

If a PacketW has 3 options, yielding 8 fields, it does not match Rule2. With SystB, it will be sent uncompressed.
If case SystB does not have a Rule1 in the Rule set, PacketU will be sent uncompressed.
If case SystB does not have a Rule2 in the Rule set, PacketV will be sent uncompressed.
There is no way PacketV will be matched by Rule1, which is the case that was envisaged as problematic by TSV-ART, if I understood correctly.
Now, if ProtocolParserA does not check for consistency between UDP.Length and IPv6.Length, then we have a problem.
But the problem is with the protocol parser, not with SCHC.

Best regards

Dominique

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

Joe

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

-Ben

---

From: <[email-masked]>
Date: Tue, 17 Mar 2020 23:30:54 +0000

Hello Benjamin,

See my comment to your point, inlined.

Dominique 

>properly identify all fields in the headers to be compressed?

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. See my example in a separate mail.

---

From: Joseph Touch <[email-masked]>
Date: Tue, 17 Mar 2020 17:12:21 -0700

> On Mar 17, 2020, at 4:30 PM, [email-masked] wrote:
> 

Agreed. The issue is that UDP length can’t be reconstructed UNLESS it matches the end of packet indicated by the IP length.

In any other case, claiming it can be reconstructed is an error and should not be allowed.

That appears to be a flaw in the claim that UDP length can be computed. It’s just not true in all cases.

Joe

---

From: <[email-masked]>
Date: Wed, 18 Mar 2020 00:15:37 +0000

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

> 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

-Ben

---

From: <[email-masked]>
Date: Wed, 18 Mar 2020 00:22:04 +0000

You are totally right.
I suggest to add that Section 10 only applies to UDP headers without options.
Does that work?

Dominique

De : Joseph Touch <[email-masked]<mailto:[email-masked]>>
Date : Wednesday 18 March 2020 01:12
À : Dominique Barthel <[email-masked]<mailto:[email-masked]>>
Cc : Benjamin Kaduk <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>, The IESG <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Objet : Re: [Tsv-art] [Last-Call] [lp-wan] Tsvart last call review of draft-ietf-lpwan-coap-static-context-hc-12

On Mar 17, 2020, at 4:30 PM, [email-masked]<mailto:[email-masked]> wrote:

Joe

---

From: Joseph Touch <[email-masked]>
Date: Tue, 17 Mar 2020 20:47:38 -0700

Technically, it applies only to UDP headers when the UDP length points to the same location as the IP length when viewed at the compressor.

It doesn’t matter why the UDP length differs or how; UDP options are only a very specific subset of that case.

Joe

> On Mar 17, 2020, at 5:22 PM, <[email-masked]> <[email-masked]> wrote:
> 
> You are totally right.
> De : Joseph Touch <[email-masked] <mailto:[email-masked]>>
> À : Dominique Barthel <[email-masked] <mailto:[email-masked]>>
> Cc : Benjamin Kaduk <[email-masked] <mailto:[email-masked]>>, "[email-masked] <mailto:[email-masked]>" <[email-masked] <mailto:[email-masked]>>, "[email-masked] <mailto:[email-masked]>" <[email-masked] <mailto:[email-masked]>>, The IESG <[email-masked] <mailto:[email-masked]>>, "[email-masked] <mailto:[email-masked]>" <[email-masked] <mailto:[email-masked]>>, "[email-masked] <mailto:[email-masked]>" <[email-masked] <mailto:[email-masked]>>, "[email-masked] <mailto:[email-masked]>" <[email-masked] <mailto:[email-masked]>>
>> On Mar 17, 2020, at 4:30 PM, [email-masked] <mailto:[email-masked]> wrote:
>> 
> Tsv-art mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/tsv-art

---

From: Mirja Kuehlewind <[email-masked]>
Date: Wed, 18 Mar 2020 13:50:02 +0100

Hi Dominique,

Quickly chiming in here. Please see below for one comment.

> On 18. Mar 2020, at 00:30, [email-masked] wrote:
> 
> Hello Benjamin,
> 
> 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!

Thanks!
Mirja

> See my example in a separate mail.
> 
>> 
>> -Ben
> 
>

---

From: Joseph Touch <[email-masked]>
Date: Wed, 18 Mar 2020 07:55:56 -0700

> On Mar 18, 2020, at 5:50 AM, Mirja Kuehlewind <[email-masked]> wrote:
> 

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

---

From: Mirja Kuehlewind <[email-masked]>
Date: Wed, 18 Mar 2020 16:03:19 +0100

That’s the better wording!

> On 18. Mar 2020, at 15:55, Joseph Touch <[email-masked]> wrote:
> 
> 
>

---

From: <[email-masked]>
Date: Thu, 19 Mar 2020 06:44:40 +0000

Hello Joe, all,

First of all, my sincere thanks to Joe and to all who took the time to
read the SCHC drafts and provide comments on them. I mean it.
Through our emails exchanges over the last two days, I think the
co-authors of ietf-lpwan-ipv6-static-context-hc now have a clear
understanding of the potential issues with the UDP length compression with
SCHC.

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

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

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

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.

Section 10
OLD_TEXT
10.  SCHC Compression for IPv6 and UDP Headers
NEW_TEXT
10.  SCHC Compression for basic IPv6 and UDP Headers

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.

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

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.

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.

Would this work for you? Comments welcome.
Thanks

Dominique

Le 18/03/20 16:03, « Mirja Kuehlewind » <[email-masked]> a écrit :

>>> and IPv6 lengths for consistency”) is the important point that needs
>>>to be explicitly mention in the document!
>> 
>> 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
>

---

From: Joseph Touch <[email-masked]>
Date: Fri, 20 Mar 2020 08:23:07 -0700

Hi, Dominique,

See below.

My concern is whether UDP length can be compressed or not on a per-packet basis in SCHC.

Joe

> On Mar 18, 2020, at 11:44 PM, [email-masked] wrote:
> 
> Hello Joe, all,
> ...

That’s actually quite easy and thus it should not delay anything.

> recomputed out of the IPv6 Length, and leave for another draft to deal

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

> received fields/options/bytes.)

That’s not the case for UDP options.

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

> can be recomputed. These hints are not necessary to understand the generic

Agreed, e.g., esp. for 7.5.8

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

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

> Because the field is uniquely identified by its Field ID (e.g., IPv6

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

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

> be straighforwardly recomputed from the IPv6 length.

Again, unless UDP length can be compressed/not on a per-packet basis, leave as-is.

> the MO is set to "ignore", and the CDA is set to "compute-*”.

See my suggestion above.

> conditions described at the beginning of Section 10.

OK.
> IPv6/UDP headers, where the UDP length can be straightforwardly recomputed

Again, see my caveat.

> Le 18/03/20 16:03, « Mirja Kuehlewind » <[email-masked] <mailto:[email-masked]>> a écrit :
> 
> -- 
> last-call mailing list
> [email-masked] <mailto:[email-masked]>
> https://www.ietf.org/mailman/listinfo/last-call <https://www.ietf.org/mailman/listinfo/last-call>

---

From: <[email-masked]>
Date: Fri, 20 Mar 2020 16:36:07 +0000

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

De : Joseph Touch <[email-masked]<mailto:[email-masked]>>
Date : Friday 20 March 2020 16:23
À : Dominique Barthel <[email-masked]<mailto:[email-masked]>>
Cc : "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>, Mirja Kuehlewind <[email-masked]<mailto:[email-masked]>>, The IESG <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>, Benjamin Kaduk <[email-masked]<mailto:[email-masked]>>
Objet : Re: [Last-Call] [Tsv-art] [lp-wan] Tsvart last call review of draft-ietf-lpwan-coap-static-context-hc-12

Hi, Dominique,

See below.

Joe

On Mar 18, 2020, at 11:44 PM, [email-masked]<mailto:[email-masked]> wrote:

Hello Joe, all,
...

- Section 10.10

[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?

In a nutshell

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

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

Grammar suggestion:

[DB] agreed, thanks.

[DB] given that the answer is yes, I understand that you agree with the proposed change.

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.

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

OK.

Appendix A
OLD_TEXT

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.

Dominique

Le 18/03/20 16:03, « Mirja Kuehlewind » <[email-masked]<mailto:[email-masked]>> a écrit :

On 18. Mar 2020, at 15:55, Joseph Touch <[email-masked]<mailto:[email-masked]>> wrote:

On Mar 18, 2020, at 5:50 AM, Mirja Kuehlewind <[email-masked]<mailto:[email-masked]>>
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.

That way of phrasing it is dangerous - it implies that when the values
differ there is some sort of error.

Joe

--
last-call mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/last-call

---

From: Joseph Touch <[email-masked]>
Date: Fri, 20 Mar 2020 13:35:20 -0700

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

...
>> application to compress basic IPv6/UDP headers.

Leave old text IMO.

>> Because the field is uniquely identified by its Field ID (e.g., IPv6

Agreed.

>> 10.  SCHC Compression for basic IPv6 and UDP Headers

Again, leave original text IMO.

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

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

If you want to include a rule that shows an example, then the rule itself needs to include the test condition. 

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

--

---

From: Suresh Krishnan <[email-masked]>
Date: Wed, 25 Mar 2020 19:09:10 +0000

Hi Joe,
  Apologies for top posting. I see your point and I think I see where the disconnect is. There are two independent components that work together to get the packet compressed. There is a parser that goes over the original packet and labels the parsed fields. It then passes the itemized list of fields to the compressor to be compressed based on the rules it has for these fields. So when you say there needs to be a “provided rule" for checking UDP Lengths, the compressor *does not* have a mechanism in place that a rule is matched based on equality between two distinct fields. I personally think the limitation needs to be coded into the parser. I would suggest the following text change (or some similar change) to accommodate this check

* Section 10.10

OLD:

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:

The parser MUST NOT label this field unless the UDP Length value
matches the Payload Length value from the IPv6 header.
The TV is not set, the MO is set to "ignore" and the CDA is set to "compute-*”.

Let me know if this works for you.

Thanks
Suresh

On Mar 20, 2020, at 4:35 PM, Joseph Touch <[email-masked]<mailto:[email-masked]>> wrote:

Hi, Dominique,

Joe

In a nutshell

Abstract
OLD_TEXT

Leave old text IMO.

Section 7.3.8
OLD_TEXT

Agreed.

OK

OLD_TEXT

Grammar suggestion:

Section 10
OLD_TEXT

OLD_TEXT

See my suggestion above.

- Section 10.10

Section 12.1.1
OLD_TEXT

OK.

Appendix A
OLD_TEXT

Again, see my caveat.

--

---

From: Joseph Touch <[email-masked]>
Date: Mon, 30 Mar 2020 07:27:58 -0700

FYI - I think this is OBE; it’s a subset of the mail you sent on Mar 27 that I already responded to.

Joe

> On Mar 25, 2020, at 12:09 PM, Suresh Krishnan <[email-masked]> wrote:
> 
> Hi Joe,
>> On Mar 20, 2020, at 4:35 PM, Joseph Touch <[email-masked] <mailto:[email-masked]>> wrote:
>> 
>> Hi, Dominique,
>>