Re: [6lo] working group last call (wg lc) on https://datatracker.ietf.org/doc/draft-ietf-6lo-deadline-time/

"Lijo Thomas" <lijo@cdac.in> Tue, 24 July 2018 06:37 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 EBD2E131038; Mon, 23 Jul 2018 23:37:40 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level:
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=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 muZuWYbICaz4; Mon, 23 Jul 2018 23:37:37 -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 75B2A13103D; Mon, 23 Jul 2018 23:37:35 -0700 (PDT)
Received: from ims.pune.cdac.in (ims.pune.cdac.in [10.208.1.15]) by mailsender.cdac.in (8.14.2/8.14.2) with ESMTP id w6O6alOa009276 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 24 Jul 2018 12:06:53 +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 w6O6aT76006719; Tue, 24 Jul 2018 12:06:29 +0530
X-AuthUser: lijo
Received: from LijoPC (lijo_new_pc.tvm.cdac.in [10.176.10.234]) (authenticated bits=0) by mailgw.pune.cdac.in (8.14.2/8.13.8) with ESMTP id w6O6aPua007084 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NOT); Tue, 24 Jul 2018 12:06:25 +0530
From: Lijo Thomas <lijo@cdac.in>
To: "'Georgios Z. Papadopoulos'" <georgios.papadopoulos@imt-atlantique.fr>
Cc: draft-ietf-6lo-deadline-time@ietf.org, anand@ece.iisc.ernet.in, 'Malati Hegde' <malati@ece.iisc.ernet.in>, 'Samita Chakrabarti' <samitac.ietf@gmail.com>, 'Gabriel Montenegro' <Gabriel.Montenegro@microsoft.com>, 'lo' <6lo@ietf.org>, 'Charlie Perkins' <charles.perkins@earthlink.net>, satishnaidu80@gmail.com
References: <SN4PR2101MB07342E73E66510570E7D306495B60@SN4PR2101MB0734.namprd21.prod.outlook.com> <13FBBD0C-CCF0-4315-B497-E40DEBF4A867@imt-atlantique.fr>
In-Reply-To: <13FBBD0C-CCF0-4315-B497-E40DEBF4A867@imt-atlantique.fr>
Date: Tue, 24 Jul 2018 12:08:49 +0530
Message-ID: <006301d42318$fd3a2320$f7ae6960$@cdac.in>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_NextPart_000_0064_01D42347.16F56C60"
X-Mailer: Microsoft Outlook 15.0
Thread-Index: AQHi7ifeHzwJdAbh3UI9dbovTKK1tgJLIco5pG34aeA=
Content-Language: en-in
X-CDAC-PUNE-MailScanner-ID: w6O6aT76006719
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=-0.198, required 6, autolearn=disabled, ALL_TRUSTED -1.00, BAYES_50 0.80, HTML_MESSAGE 0.00, URIBL_BLOCKED 0.00), not spam, SpamAssassin (not cached, score=-1.798, required 6, autolearn=disabled, ALL_TRUSTED -1.80, BAYES_50 0.00, HTML_MESSAGE 0.00)
X-CDAC-PUNE-MailScanner-Information: Please contact npsfhelp@cdac.in/mailadmin@cdac.in for more information
X-MailScanner-ID: w6O6alOa009276
X-CDAC-PUNE-MailScanner-From: lijo@cdac.in
X-CDAC-MailScanner-Spam-Status: No
Archived-At: <https://mailarchive.ietf.org/arch/msg/6lo/Ex7UWVM-XtFz3ubttARQZqMR-PQ>
Subject: Re: [6lo] working group last call (wg lc) on https://datatracker.ietf.org/doc/draft-ietf-6lo-deadline-time/
X-BeenThere: 6lo@ietf.org
X-Mailman-Version: 2.1.27
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: Tue, 24 Jul 2018 06:37:41 -0000

Dear Georgios,
 
Thanks for your valuable suggestions and we really appreciate for taking your valuable time for the review .
 
Please find our comments inline below marked as (*** [LT]) 
 
We will be happy to receive your further inputs !!!
 
 
Thanks & Regards,
Lijo Thomas 
 
From: 6lo [mailto:6lo-bounces@ietf.org] On Behalf Of Georgios Z. Papadopoulos
Sent: 17 July 2018 21:40
To: lijo@cdac.in
Cc: draft-ietf-6lo-deadline-time@ietf.org; anand@ece.iisc.ernet.in; Malati Hegde; Samita Chakrabarti; Gabriel Montenegro; lo; Charlie Perkins; satishnaidu80@gmail.com
Subject: Re: [6lo] working group last call (wg lc) on https://datatracker.ietf.org/doc/draft-ietf-6lo-deadline-time/
 
Dear Lijo and co-authors,
 
I went through the draft, please find my comments below:
— — 
 
High level comments:
*/ [GP] The draft defines the Deadline Time (DT), but it is not clear to me how the arrival of the datagram within this pre-defined DT period is guaranteed?
Indeed, the draft provides the necessary DT information, however, the only action I could observe is the delay-sensitive datagram to be dropped if the indicated DT is elapsed.
 
 
*** [LT] Yes, the Deadline Time (DT) specifies the maximum allowable delay
before which the packet should be delivered to the destination. The proposed
draft provides a mechanism for transporting the DT information. By incorporating
deadline based scheduling/routing mechanisms within the intermediate nodes
using DT, one could guarantee deterministic behavior in terms of delay.
 
*/ [GP] I noticed that there are two different notations for LBR and 6LBR.
Shouldn’t be always 6LBR (6LBR1 and 6LBR2 when it comes to the use-cases in Section 6), instead of LBR, LBR1, LBR2 or 6LBR?
 
*** [LT] Agreed, we will update the draft.
 
*/ “D flag (1 bit): The 'D' flag, set by the Sender, indicates the action to be taken when a 6LR detects that the deadline time has elapsed. 
If 'D' bit is 1, then the 6LR MUST drop the packet if the deadline time is elapsed. 
If 'D' bit is 0, then the 6LR MAY ignore the deadline time and forward the packet.”
 
[GP] It is not clear to me why the datagram should be dropped, if the 6LR detects that the DL has elapsed? 
To reduce the traffic in the network or ?
 
*** [LT] Yes that was the motivation of having 'D' flag to begin with. We
could save bandwidth, and energy etc., by discarding packets whose deadlines
are crossed when 'D' flag is set to 1.
 
[GP] Then, the main difference in networks where this DRAFT is not considered, is that the packets are not dropped?
Because otherwise the packets are forwarded (when ‘D’ bit is 0).
 
*** [LT] Yes, moreover in some scenarios where the intention is also to know
the total delay experienced by the packets in a network, this could be obtained
by setting 'D' bit set to 0. In such scenarios, we may want to receive the
packets even though the deadline is crossed.
 
Detailed comments:
*/ 5. Deadline-6LoRHE Format
“Deadline-6LoRHE encoding with 'O' flag set to 1 :
 
      DTL = 001, OTL = 001, TU = '10', EXP = 2, DT = 0x22B, OT = 0x22A”
 
[GP] What about the ‘D’ here?
 
*** [LT] We will update the example by putting 'D' bit = 1.
 
*/ 6. Deadline-6LoRHE in Three Network Scenarios
 
[GP] Any router/device may drop the datagram (if it detects that the indicated time has elapsed), both 6LR (Relay devices) and 6LBR (DODAG Root)?
 
 
*/ 6.1. Scenario 1: Endpoints in the same DODAG (N1) in non-storing mode.
“Then 6LR begins hop-by-hop operation to forward the packet towards the 6LBR”
 
[GP] Then 6LR begins or “Then the 6LRs begin”? (not only one 6LR but each 6LR).
OR it should be written as in Scenario 6.3 : “Subsequently, each 6LR will perform hop-by-hop operation to forward the packet towards the 6LBR.”
 
*** [LT] Nice suggestion, will update.
 
*/ 6.2. Scenario 2: Endpoints in Networks with Dissimilar L2 Technologies.
“Subsequently, 6LR will perform hop- by-hop operation to forward the packet towards the 6LBR”
 
[GP] Subsequently, “EACH” 6LR 
OR it should be written as in Scenario 6.3 : “Subsequently, each 6LR will perform hop-by-hop operation to forward the packet towards the 6LBR.”
 
*** [LT] Will modify the draft
 
*/ 6.3. Scenario 3: Packet transmission across different DODAGs (N1 to N2).
“Once the packet reaches LBR2, it updates the Deadline-6LoRHE by adding the current time of DODAG2.”
 
[GP] is not clear to me, why “adding”, why not “subtracting”, as you mention in page 10.
 
*** [LT] Thanks for pointing it out, we will modify the text it as in page 10.
 
[GP] Furthermore, in the example later of 6TiSCH network:
Instead of supposing an example of ASN 20050, would make sense actually to have ASN 20030, based on the topology in Figure 6, that comes with three hops.
Similarly, the rest of the math operations could be more specific, based on the topology in Figure 6.
 
 
*** [LT] Great observation, we will update the example !!
 
*/ In Scenario 2:
[GP] (Optionally) DODAG 1 could be indicated/highlighted in the Figure 5 as well, as it is illustrated in Figure 6 of Scenario 3.
 
*** [LT] Yes we will edit the Figure 5 to incorporate the DODAG 1
 
— — 
Best regards,
Georgios
 
____________________________________
 
Georgios Z. Papadopoulos, Ph.D.
Associate Professor, IMT Atlantique, Rennes
 
web:      <http://www.georgiospapadopoulos.com> www.georgiospapadopoulos.com
twitter:             <https://twitter.com/gzpapadopoulos?ref_src=twsrc%5Etfw&ref_url=http://georgiospapadopoulos.com/> @gzpapadopoulos
____________________________________
 
On Apr 19, 2018, at 02:59, Gabriel Montenegro < <mailto:Gabriel.Montenegro@microsoft.com> Gabriel.Montenegro@microsoft.com> wrote:
 
Hi,
 
I just initiated a WG last call on:
 
               <https://datatracker.ietf.org/doc/draft-ietf-6lo-deadline-time/> https://datatracker.ietf.org/doc/draft-ietf-6lo-deadline-time/
 
The WG last call will finish on Wednesday, May 2, 2018. 
 
Thanks in advance for your comments.
 
Gabriel
 
_______________________________________________
6lo mailing list
 <mailto:6lo@ietf.org> 6lo@ietf.org
 <https://www.ietf.org/mailman/listinfo/6lo> https://www.ietf.org/mailman/listinfo/6lo
 

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