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

Joseph Touch <touch@strayalpha.com> Fri, 20 March 2020 15:23 UTC

Return-Path: <touch@strayalpha.com>
X-Original-To: lp-wan@ietfa.amsl.com
Delivered-To: lp-wan@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E11983A0A53; Fri, 20 Mar 2020 08:23:22 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.318
X-Spam-Level:
X-Spam-Status: No, score=-1.318 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_NEUTRAL=0.779, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=strayalpha.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CjX7od_fDAKn; Fri, 20 Mar 2020 08:23:20 -0700 (PDT)
Received: from server217-3.web-hosting.com (server217-3.web-hosting.com [198.54.115.226]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 80AAA3A0A4A; Fri, 20 Mar 2020 08:23:14 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=strayalpha.com; s=default; h=To:References:Message-Id:Cc:Date:In-Reply-To: From:Subject:Mime-Version:Content-Type:Sender:Reply-To: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=L5ckF/HXgv5KHRrCo2ywQZY3gcP+eqyhPArgRw+i/XI=; b=lT/AxrvPMTBc6ctmrOV5ieIHP Us/OKiMmKjRbqBew9glW5KZ4QhF+jDmKB77HCwWJbIcJnceBBiFUSPKqbPlfRkv/yn1KgXj0BQaKz q9o0sVqQr2ScwI7TrYecu5tMUFRUPjfrIZMIpSS08poF0Vxm6A9awRYySuFiUPwTykRBPf0eZxuEo btdOYp3wPmK6IJbFGXnX7GLZVtLta+C5RmJGKDoTloQA9bkHMsKxtCW/6U8puVT9OrGt6jEVNAB/4 23ZxMoNM1DiOsjTpkL6rsOApTFW8WLxSqmZg7MKvKYUNhhhz9PtV52A/NT+QsaH48b0S/Gk+5j4BX kq9uULvEA==;
Received: from cpe-172-250-225-198.socal.res.rr.com ([172.250.225.198]:53073 helo=[192.168.1.10]) by server217.web-hosting.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.92) (envelope-from <touch@strayalpha.com>) id 1jFJUK-0001oK-Jv; Fri, 20 Mar 2020 11:23:13 -0400
Content-Type: multipart/alternative; boundary="Apple-Mail=_D7D494F4-2BE0-403E-B2F2-334111659C73"
Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\))
From: Joseph Touch <touch@strayalpha.com>
In-Reply-To: <20350_1584600280_5E7314D8_20350_426_1_DA98D1CE.72223%dominique.barthel@orange.com>
Date: Fri, 20 Mar 2020 08:23:07 -0700
Cc: "draft-ietf-lpwan-coap-static-context-hc.all@ietf.org" <draft-ietf-lpwan-coap-static-context-hc.all@ietf.org>, "last-call@ietf.org" <last-call@ietf.org>, Mirja Kuehlewind <ietf@kuehlewind.net>, The IESG <iesg@ietf.org>, "lp-wan@ietf.org" <lp-wan@ietf.org>, "tsv-art@ietf.org" <tsv-art@ietf.org>, "draft-ietf-lpwan-ipv6-static-context-hc@ietf.org" <draft-ietf-lpwan-ipv6-static-context-hc@ietf.org>, Benjamin Kaduk <kaduk@mit.edu>
Message-Id: <2539076A-99CD-44B3-9903-25E42ACB5603@strayalpha.com>
References: <158152010913.17982.18347318138768196852@ietfa.amsl.com> <340_1584143298_5E6C1BC2_340_169_1_DA91D669.71EAC%dominique.barthel@orange.com><20200317211335.GR50174@kduck.mit.edu> <30843_1584487855_5E715DAF_30843_429_4_DA971B0C.72109%dominique.barthel@orange.com> <27E35DC7-C83E-4C6C-984A-3AC1C183BC28@kuehlewind.net> <9DF137B7-2861-4ADA-9C8B-22DFE7022EAD@strayalpha.com> <F3327431-EBBF-450C-802F-E8D0E29F20D5@kuehlewind.net> <20350_1584600280_5E7314D8_20350_426_1_DA98D1CE.72223%dominique.barthel@orange.com>
To: dominique.barthel@orange.com
X-Mailer: Apple Mail (2.3445.9.1)
X-OutGoing-Spam-Status: No, score=-0.5
X-AntiAbuse: This header was added to track abuse, please include it with any abuse report
X-AntiAbuse: Primary Hostname - server217.web-hosting.com
X-AntiAbuse: Original Domain - ietf.org
X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12]
X-AntiAbuse: Sender Address Domain - strayalpha.com
X-Get-Message-Sender-Via: server217.web-hosting.com: authenticated_id: touch@strayalpha.com
X-Authenticated-Sender: server217.web-hosting.com: touch@strayalpha.com
X-Source:
X-Source-Args:
X-Source-Dir:
X-From-Rewrite: unmodified, already matched
Archived-At: <https://mailarchive.ietf.org/arch/msg/lp-wan/1w51oilFtYc1XJk1rolQnAAZynw>
Subject: Re: [lp-wan] [Last-Call] [Tsv-art] Tsvart last call review of draft-ietf-lpwan-coap-static-context-hc-12
X-BeenThere: lp-wan@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "Low-Power Wide Area Networking \(LP-WAN\), also known as LPWA or Low-Rate WAN \(LR-WAN\)" <lp-wan.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/lp-wan>, <mailto:lp-wan-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/lp-wan/>
List-Post: <mailto:lp-wan@ietf.org>
List-Help: <mailto:lp-wan-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/lp-wan>, <mailto:lp-wan-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 20 Mar 2020 15:23:24 -0000

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, dominique.barthel@orange.com wrote:
> 
> 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.

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

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

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

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

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

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

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

> 
> Would this work for you? Comments welcome.
> Thanks
> 
> Dominique
> 
> 
> 
> Le 18/03/20 16:03, « Mirja Kuehlewind » <ietf@kuehlewind.net <mailto:ietf@kuehlewind.net>> a écrit :
> 
>> That’s the better wording!
>> 
>> 
>>> On 18. Mar 2020, at 15:55, Joseph Touch <touch@strayalpha.com> wrote:
>>> 
>>> 
>>> 
>>>> On Mar 18, 2020, at 5:50 AM, Mirja Kuehlewind <ietf@kuehlewind.net>
>>>> 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@ietf.org <mailto:last-call@ietf.org>
> https://www.ietf.org/mailman/listinfo/last-call <https://www.ietf.org/mailman/listinfo/last-call>