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

Joseph Touch <touch@strayalpha.com> Mon, 30 March 2020 14:28 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 9F0C13A16A5; Mon, 30 Mar 2020 07:28:10 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.455
X-Spam-Level:
X-Spam-Status: No, score=0.455 tagged_above=-999 required=5 tests=[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.652, 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 f_BFk2Nf7qaq; Mon, 30 Mar 2020 07:28:08 -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 C54043A16A4; Mon, 30 Mar 2020 07:28:07 -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=/qMWt8OQAYqo94m4aJhfh2SPjPd4ODVaC0lb4MkYAgk=; b=mBgaQNdEnZIr5slSH31/wKdSB ApVA8suiWssQhCcYcWFmP/ezi2e/wIA8xcVIdXjAgqJdunJIr9h+Iiy9kGlm5F1uGw3xMn2bQRJWP jluON+ROff+F3cu30BKqg0BUmrCLDPcpK36y6DuTlKGzXfNUA2aIBVkZHHbcqBu1Cx3OnksgYtBtM FHMqOHB9pA73qZdY4AT2PP+JDww6QQdMZNptmbChagBPCHQaF0+3sxOFV6JzgkR3eS6ALSo7/Ha1x kV1qlkSXI2TU/jNeoxOYDQCSytAH7Io6+EzkAFwE434Iv04aFY/mDNEzcXWAG5Q3KQeZAwPswDtyj R+hmzj+/Q==;
Received: from cpe-172-250-225-198.socal.res.rr.com ([172.250.225.198]:49330 helo=[192.168.1.10]) by server217.web-hosting.com with esmtpsa (TLS1.2) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.93) (envelope-from <touch@strayalpha.com>) id 1jIvOT-000Icv-Bh; Mon, 30 Mar 2020 10:28:06 -0400
Content-Type: multipart/alternative; boundary="Apple-Mail=_0786A46C-FA46-4D6D-9651-F61915917330"
Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.5\))
From: Joseph Touch <touch@strayalpha.com>
In-Reply-To: <E1A83D07-1BAC-436D-BB4F-D6B44FB24DB4@kaloom.com>
Date: Mon, 30 Mar 2020 07:27:58 -0700
Cc: "draft-ietf-lpwan-coap-static-context-hc.all@ietf.org" <draft-ietf-lpwan-coap-static-context-hc.all@ietf.org>, "dominique.barthel@orange.com" <dominique.barthel@orange.com>, "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: <C6F077B3-75BB-4214-AC03-36D07649F442@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> <2539076A-99CD-44B3-9903-25E42ACB5603@strayalpha.com> <14010_1584722167_5E74F0F7_14010_126_1_DA9AA5F1.723F4%dominique.barthel@orange.com> <9A747D6C-A8B5-4AE4-961A-A3977BAE32E0@strayalpha.com> <E1A83D07-1BAC-436D-BB4F-D6B44FB24DB4@kaloom.com>
To: Suresh Krishnan <suresh@kaloom.com>
X-Mailer: Apple Mail (2.3445.9.5)
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/VDzpg9MgV-SLldbfK9xmjREDTWo>
X-Mailman-Approved-At: Mon, 30 Mar 2020 08:01:55 -0700
Subject: Re: [lp-wan] [Tsv-art] [Last-Call] 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: Mon, 30 Mar 2020 14:28:11 -0000

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 <suresh@kaloom.com> wrote:
> 
> 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 <touch@strayalpha.com <mailto:touch@strayalpha.com>> wrote:
>> 
>> 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.
>> 
>> --
> 
> _______________________________________________
> Tsv-art mailing list
> Tsv-art@ietf.org
> https://www.ietf.org/mailman/listinfo/tsv-art