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

[[e-mail]]

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

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