Re: [6lo] Iotdir early review of draft-ietf-6lo-deadline-time-02

Lijo Thomas <lijo@cdac.in> Sat, 22 September 2018 06:33 UTC

Return-Path: <lijo@cdac.in>
X-Original-To: 6lo@ietfa.amsl.com
Delivered-To: 6lo@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A1B91130DCA; Fri, 21 Sep 2018 23:33:05 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
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 ZoaQ9qkYXu5N; Fri, 21 Sep 2018 23:33:03 -0700 (PDT)
Received: from mailsender.cdac.in (mailsender.cdac.in [196.1.113.117]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 935F5128CF2; Fri, 21 Sep 2018 23:33:02 -0700 (PDT)
Received: from ims.pune.cdac.in (ims.pune.cdac.in [10.208.1.15]) by mailsender.cdac.in (8.14.2/8.13.8) with ESMTP id w8M6WlUt005711 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Sat, 22 Sep 2018 12:02:52 +0530
Received: from mailgw.pune.cdac.in ([10.208.1.4]) by ims.pune.cdac.in (8.14.4/8.14.4) with ESMTP id w8M6WdC2002186; Sat, 22 Sep 2018 12:02:39 +0530
Received: from webmail.cdac.in (wbms.pune.cdac.in [10.208.1.9]) by mailgw.pune.cdac.in (8.14.2/8.13.8) with ESMTP id w8M6Wa7c009346 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Sat, 22 Sep 2018 12:02:37 +0530
Date: Sat, 22 Sep 2018 12:02:28 +0530
From: Lijo Thomas <lijo@cdac.in>
Reply-To: Lijo Thomas <lijo@cdac.in>
To: Wesley Eddy <wes@mti-systems.com>, Iot-dir@ietf.org
Cc: draft-ietf-6lo-deadline-time.all@ietf.org, 6lo@ietf.org, ietf@ietf.org, Lijo Thomas <lijo@cdac.in>
Message-ID: <1526080512.1972.1537597948867.JavaMail.open-xchange@webmail.cdac.in>
In-Reply-To: <153733155927.8581.14427223753891419141@ietfa.amsl.com>
References: <153733155927.8581.14427223753891419141@ietfa.amsl.com>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_Part_1971_1759655107.1537597948797"
X-Priority: 3
Importance: Medium
X-Mailer: Open-Xchange Mailer v6.20.7-Rev15
X-CDAC-PUNE-MailScanner-ID: w8M6WdC2002186
X-CDAC-PUNE-MailScanner: Found to be clean, Found to be clean
X-CDAC-PUNE-MailScanner-MCPCheck-IMS: MCP-Clean, MCP-Checker (score=0, required 1)
X-CDAC-PUNE-MailScanner-SpamCheck: not spam, SpamAssassin (not cached, score=-2.899, required 6, autolearn=disabled, ALL_TRUSTED -1.00, BAYES_00 -1.90, HTML_MESSAGE 0.00), not spam, SpamAssassin (not cached, score=-1.984, required 6, autolearn=disabled, ALL_TRUSTED -1.80, BAYES_40 -0.18, HTML_MESSAGE 0.00)
X-CDAC-PUNE-MailScanner-Information: Please contact npsfhelp@cdac.in/mailadmin@cdac.in for more information
X-MailScanner-ID: w8M6WlUt005711
X-CDAC-PUNE-MailScanner-From: lijo@cdac.in
X-CDAC-MailScanner-Spam-Status: No
Archived-At: <https://mailarchive.ietf.org/arch/msg/6lo/Ik4pQ9Ufr04OgVh6fjDXuUsbhpc>
Subject: Re: [6lo] Iotdir early review of draft-ietf-6lo-deadline-time-02
X-BeenThere: 6lo@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "Mailing list for the 6lo WG for Internet Area issues in IPv6 over constrained node networks." <6lo.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/6lo>, <mailto:6lo-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/6lo/>
List-Post: <mailto:6lo@ietf.org>
List-Help: <mailto:6lo-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/6lo>, <mailto:6lo-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sat, 22 Sep 2018 06:33:06 -0000

Dear Wesley,

Thanks for your valuable comments.

Please find the inline answers (marked as LT >>) for your comments in the below
email.

Happy to receiver your further inputs ...

Thanks & Regards
Lijo Thomas


On September 19, 2018 at 10:02 AM Wesley Eddy <wes@mti-systems.com> wrote:
Reviewer: Wesley Eddy
 Review result: Ready with Issues

 The draft is easily readable and can be understood and should be simple to
 implement by someone working in the area.

 I only have one technical issue that I think should definitely need to be
 resolved, and a few small editorial comments.

 Technical issues:

- The point of the D-bit is confusing. It is supposed to indicate whether the
 packet MUST be dropped when the deadline is exceeded. However, if the D-bit is
 zero, the document says that a 6LR "MAY" forward the packet anyways. Since
 this uses MAY rather than "MUST" or "MUST NOT", it seems like there should be
 some example use case, scenario, or rationale for why an implementer would
 choose one way or the other, or how they would include logic to make the
 decision when the D-bit is 0. Fundamentally though, I'm also unsure why a
 sender would include a deadline and then set the D-bit to 0 ... is it maybe
 something like they still want the packet to be delivered so that network
 measurements of current latency or other properties can be measured using the
 packet? If the deadline is missed due to congestion/contention causing
 increased delays, then it seems prudent to always drop the packet, in which
 case the D-bit would not be needed.

>> LT :  As you rightly noted, the primary reason for giving an option 0 for 'D'
>> bit is for making delay measurements,
>>                                                                                                                        and
>> also to perform packet delay analysis on the bottleneck segments that are
>> causing the deadline to exceed and take remedial action if possible.

Will the below additional text substantiate the usage of D bit set to 0 case:

" The usage of D bit set to 0  implies the packet MAY be forwarded on an
exception basis,
                                                                                                                                                      if
the forwarding node is NOT in a situation of constrained resource, and if there
are reasons
                                                                                                                                              to
suspect that downstream nodes might find it useful (delay measurements,
interpolations, etc.) "

Kindly let me know your inputs ..


 Editorial comments:

 - In Section 1, 2nd paragraph, it would probably be good to explain what an
   elective RH is and define 6LoRHE as an elective 6LoRH here, before "6LoRHE"
is
   used in the Deadline-6LoRHE name.

>> LT : Will update the draft with the corrections

 - In Section 1, last paragraph, it would be good to add informative references
   for the last two sentences mentioning Bluetooth and Wi-SUN work in this area.

>> LT :  Will put the informative references.

 - In Section 4, last paragraph, it might be worth mentioning for clarity that
   there are also potentially long serialization delay and MAC layer contention
   delays in some of the relevant network types. These could dominate
propagation
   and queueing that are mentioned, in some feasible cases.

>> LT : Nice suggestion, will update the draft.

- The "Length of DT field" and "Length of OT field" descriptions seem a bit
  light, although from the examples it is clear, but they could be replaced with
  something more clear like "Length of DT field as an unsigned 3-bit integer,
  encoding the length of the field in octets, minus one."


>> LT :  Will modify the draft and make the corrections based on the inputs
>> provided.
------------------------------------------------------------------------------------------------------------
[ C-DAC is on Social-Media too. Kindly follow us at:
Facebook: https://www.facebook.com/CDACINDIA & Twitter: @cdacindia ]

This e-mail is for the sole use of the intended recipient(s) and may
contain confidential and privileged information. If you are not the
intended recipient, please contact the sender by reply e-mail and destroy
all copies and the original message. Any unauthorized review, use,
disclosure, dissemination, forwarding, printing or copying of this email
is strictly prohibited and appropriate legal action will be taken.
------------------------------------------------------------------------------------------------------------