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

[[e-mail]]

Posting again…

From: Chakrabarti, Samita
Sent: Tuesday, July 31, 2018 6:32 PM
To: 'Lijo Thomas' <[e-mail]>; 'Georgios Z. Papadopoulos' <[e-mail]>
Cc: [e-mail]; [e-mail]; 'Malati Hegde' <[e-mail]>; 'Samita Chakrabarti' <[e-mail]>; 'Gabriel Montenegro' <[e-mail]>; 'lo' <[e-mail]>; 'Charlie Perkins' <[e-mail]>; [e-mail]
Subject: RE: [E] Re: [6lo] working group last call (wg lc) on https://datatracker.ietf.org/doc/draft-ietf-6lo-deadline-time/

Hi Lijo and co-authors:

Here are some more comments on the 6lo-deadline draft:


1.       The abstract of this document says :
   “The deadline time enables forwarding and scheduling decisions for time critical
   IoT M2M applications that need deterministic delay guarantees over
   constrained networks and operate within time-synchronized networks.”

However, the document body seems to indicate that the solution works for 6tisch networks.
Could this document clarify  where this scenario be applicable?  Only 6tisch or any other Low-power networks with multiple hops?
6loRH is a requirement here – so please clarify a typical deployment network where this solution will work [ for example, a Low power network running RPL with 6loRH support on 6lo nodes that create the mesh networks.]


2.       Section 3 – Drop this section and refer to RFC8138 section 4.1

3.       Always provide Normative reference to 6rLoRHE as 6LoRHE[RFC8138] when you refer to it

4.       Section 4 : the calculation is not clear to me as to how it relates the new network clock difference (delta) and the delay in the previous network ( at the entry point of the new network). Please draw a time line diagram and explain  each point what this value is for and how the delay experienced is calculated.  If your reference time for first network is T1, and the second network clock is T1+d  and the dealy in T1 is D1, then at T1+D1 time, when the packet enters the 2nd network, it will read T1+D1+d1 as the 2nd network entry time or origination time in 2nd network. Second network may add some delay in processing the packet. So, I am not clear what is the purpose of this section. Please clarify.

5.       Section 6.2 refers to ietf-ippm-ioam-data – does it have dependency on this draft? What if the border router does not support the ippm draft?  Not sure if I understand the assumption that “It encodes the deadline time (and, if available, the origination time) into the In-band OAM header extension and passes the datagram to the IPv6 layer for further routing…”   Please clarify or drop this scenario.

6.       Section 6.3 again refers to ietf-roll-useofrplinfo draft – is this a dependency?  Can you show a simple scenario where there is no dependency on active draft on another WG?

Thanks,
-Samita






From: 6lo [mailto:[e-mail]] On Behalf Of Lijo Thomas
Sent: Tuesday, July 24, 2018 5:05 AM
To: 'Georgios Z. Papadopoulos' <[e-mail]<mailto:[e-mail]>>
Cc: [e-mail]<mailto:[e-mail]>; [e-mail]<mailto:[e-mail]>; 'Malati Hegde' <[e-mail]<mailto:[e-mail]>>; 'Samita Chakrabarti' <[e-mail]<mailto:[e-mail]>>; 'Gabriel Montenegro' <[e-mail]<mailto:[e-mail]>>; 'lo' <[e-mail]<mailto:[e-mail]>>; 'Charlie Perkins' <[e-mail]<mailto:[e-mail]>>; [e-mail]<mailto:[e-mail]>
Subject: [E] Re: [6lo] working group last call (wg lc) on https://datatracker.ietf.org/doc/draft-ietf-6lo-deadline-time/

Dear Georgios,

Thanks for the feedback, responding to your query :

Deadline Time (DT) by itself does not guarantee deterministic behaviour, but its information enables intermediate nodes to implement delay sensitive scheduling and routing algorithms towards achieving deterministic behaviour.

As a use case application of our draft,  we implemented a basic EDF policy in OpenWSN 6tisch stack.

Please find the link for our openwsn implementation

https://github.com/openwsn-berkeley/openwsn-fw/tree/develop/openapps/uexpiration<https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_openwsn-2Dberkeley_openwsn-2Dfw_tree_develop_openapps_uexpiration&d=DwMFaQ&c=udBTRvFvXC5Dhqg7UHpJlPps3mZ3LRxpb6__0PomBTQ&r=pWMzx7FsqijEJPyfMBfn-HJss-wVVTf0K5y-cxCTXL8&m=7e5GkJIcbIxuUVNca7qMqtU6Wk2lwaz89_SQAfJoyPY&s=nQLGDo_AziW1rJsCvm6vG_oKYbP2VwaFiQPYA9NnaR4&e=>


Thanks & Regards,
Lijo Thomas

From: 6lo [mailto:[e-mail]] On Behalf Of Georgios Z. Papadopoulos
Sent: 24 July 2018 13:49
To: Lijo Thomas
Cc: [e-mail]<mailto:[e-mail]>; [e-mail]<mailto:[e-mail]>; Malati Hegde; Samita Chakrabarti; Gabriel Montenegro; lo; Charlie Perkins; [e-mail]<mailto:[e-mail]>
Subject: Re: [6lo] working group last call (wg lc) on https://datatracker.ietf.org/doc/draft-ietf-6lo-deadline-time/<https://urldefense.proofpoint.com/v2/url?u=https-3A__datatracker.ietf.org_doc_draft-2Dietf-2D6lo-2Ddeadline-2Dtime_&d=DwQFaQ&c=udBTRvFvXC5Dhqg7UHpJlPps3mZ3LRxpb6__0PomBTQ&r=pWMzx7FsqijEJPyfMBfn-HJss-wVVTf0K5y-cxCTXL8&m=7e5GkJIcbIxuUVNca7qMqtU6Wk2lwaz89_SQAfJoyPY&s=5HI37bAJ2WXeO55wDC3VhtutrxRLoXJ_sn64hp3EF3M&e=>

Hello Lijo,

Thank you so much for your detailed comments. I appreciate it very much.
I am happy with your response, I just have one last clarification point, see below:


On Jul 24, 2018, at 09:38, Lijo Thomas <[e-mail]<mailto:[e-mail]>> wrote:

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:[e-mail]] On Behalf Of Georgios Z. Papadopoulos
Sent: 17 July 2018 21:40
To: [e-mail]<mailto:[e-mail]>
Cc: [e-mail]<mailto:[e-mail]>; [e-mail]<mailto:[e-mail]>; Malati Hegde; Samita Chakrabarti; Gabriel Montenegro; lo; Charlie Perkins; [e-mail]<mailto:[e-mail]>
Subject: Re: [6lo] working group last call (wg lc) on https://datatracker.ietf.org/doc/draft-ietf-6lo-deadline-time/<https://urldefense.proofpoint.com/v2/url?u=https-3A__datatracker.ietf.org_doc_draft-2Dietf-2D6lo-2Ddeadline-2Dtime_&d=DwMFaQ&c=udBTRvFvXC5Dhqg7UHpJlPps3mZ3LRxpb6__0PomBTQ&r=pWMzx7FsqijEJPyfMBfn-HJss-wVVTf0K5y-cxCTXL8&m=7e5GkJIcbIxuUVNca7qMqtU6Wk2lwaz89_SQAfJoyPY&s=5HI37bAJ2WXeO55wDC3VhtutrxRLoXJ_sn64hp3EF3M&e=>

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] Would you agree that this draft do not guarantees deterministic behavior in terms of delay, but it provides
the information of maximum allowable delay for a packet to be delivered to the destination?

To be more precise, for instance, lets us consider the following multi-hop network A—> B —> C.
According this draft, it will required 2 timeslots (or 20ms) for a packet to be delivered at the DODAG Root C.
However, if there is an external interference from A to B, then A may need to retransmit multiple times
in order the datagram to be received by B. Then there are two options according to the draft:
a) the datagram is dropped, to reduce the traffic, energy consumption.
b) the datagram is delivered even if the deadline time is crossed, i.e., as you said in your e-mail “in some scenarios where the intention is also to know the total delay experienced by the packets in a network”

In both bases, a and b, there is no guarantee that the datagram will be delivered in predefined time, i.e., in deterministic behavior.

— —
Thank you so much,
Georgios

____________________________________

Georgios Z. Papadopoulos, Ph.D.
Associate Professor, IMT Atlantique, Rennes

web:     www.georgiospapadopoulos.com<https://urldefense.proofpoint.com/v2/url?u=http-3A__www.georgiospapadopoulos.com&d=DwMFaQ&c=udBTRvFvXC5Dhqg7UHpJlPps3mZ3LRxpb6__0PomBTQ&r=pWMzx7FsqijEJPyfMBfn-HJss-wVVTf0K5y-cxCTXL8&m=7e5GkJIcbIxuUVNca7qMqtU6Wk2lwaz89_SQAfJoyPY&s=_1Xvis_IS2XJLj901j7We2qqeGomCqtC6KCdIizcBsQ&e=>
twitter:            @gzpapadopoulos<https://urldefense.proofpoint.com/v2/url?u=https-3A__twitter.com_gzpapadopoulos-3Fref-5Fsrc-3Dtwsrc-255Etfw-26ref-5Furl-3Dhttp-3A__georgiospapadopoulos.com_&d=DwMFaQ&c=udBTRvFvXC5Dhqg7UHpJlPps3mZ3LRxpb6__0PomBTQ&r=pWMzx7FsqijEJPyfMBfn-HJss-wVVTf0K5y-cxCTXL8&m=7e5GkJIcbIxuUVNca7qMqtU6Wk2lwaz89_SQAfJoyPY&s=jpu1BQDn6eUhHwMQ_kX4LwHwL_qtu9wlDc-YwyqE6Ig&e=>
____________________________________




-------------------------------------------------------------------------------------------------------------------------------
[ C-DAC is on Social-Media too. Kindly follow us at:
Facebook: https://www.facebook.com/CDACINDIA<https://urldefense.proofpoint.com/v2/url?u=https-3A__www.facebook.com_CDACINDIA&d=DwQFaQ&c=udBTRvFvXC5Dhqg7UHpJlPps3mZ3LRxpb6__0PomBTQ&r=pWMzx7FsqijEJPyfMBfn-HJss-wVVTf0K5y-cxCTXL8&m=7e5GkJIcbIxuUVNca7qMqtU6Wk2lwaz89_SQAfJoyPY&s=qAVDzBnrxBMh4W5vZkkX3lGHT3D8czZnJSW7Z5t93R4&e=> & 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.
-------------------------------------------------------------------------------------------------------------------------------