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

[Samita Chakrabarti <[e-mail]>]

Hi Lijo,

Thanks for your response and clarifications. Will wait for your new
revision of the draft.
Please see in-line.

On Sat, Aug 4, 2018 at 6:07 PM Lijo Thomas <[e-mail]> wrote:

>
> Hi Samita,
>
> Thanks for your valuable comments. Please find our replies  (***[LT]  ) inline to your queries (below mail).
>
> Happy to receive your further inputs.
>
> Thanks & Regards
> Lijo Thomas
>
>
> Posting again…
>
> From: Chakrabarti, Samita
> Sent: Tuesday, July 31, 2018 6:32 PM
> To: 'Lijo Thomas' <[e-mail]> <[e-mail]&gt>;; 'Georgios Z. Papadopoulos' <[e-mail]> <[e-mail]&gt>;
> Cc: [e-mail]; [e-mail]; 'Malati Hegde' <[e-mail]> <[e-mail]&gt>;; 'Samita Chakrabarti' <[e-mail]> <[e-mail]&gt>;; 'Gabriel Montenegro' <[e-mail]> <[e-mail]&gt>;; 'lo' <[e-mail]> <[e-mail]&gt>;; 'Charlie Perkins' <[e-mail]> <[e-mail]&gt>;; [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.]
>
> ***[LT] : The scope of the draft is generic so that it can be used in any
> time synchronized 6Lo network, not restricted to 6TiSCH alone. 6TiSCH has
> been used to describe the implementation aspects of the draft as it is
> indeed an instantiation of such a time synchronized 6lo network.
>
>  The draft does not preclude its use in scenarios other than 6TiSCH - for
> instance, 6lo over a BLE mesh network, where there is a growing interest in
> using this technology in industrial IoT. From the academic research side, a
> recent publication titled "Multi-Hop Real-Time Communications Over
> Bluetooth Low Energy Industrial Wireless Mesh Networks" (
> https://ieeexplore.ieee.org/abstract/document/8355905/) indicates the
> interest in this topic. BLE mesh time synchronization is also being
> recently explored by the community. We can also consider using the
> time-zone procedures described to meet packet deadlines.
>
>  Given the above use cases, 6lo for BLE and in particular BLE mesh are
> potential customers of our draft.  But there are other cases under
> consideration in, for instance, Wi-SUN.
>

Samita>  OK please clarify the scope in the abstract and introduction
sections.

>
> 2.       Section 3 – Drop this section and refer to RFC8138 section 4.1
> ***[LT] :  We will remove it.
>
>
> 3.       Always provide Normative reference to 6rLoRHE as 6LoRHE[RFC8138] when you refer to it
>
> ***[LT] :  Yes we agree, will do in the next revision.
>
>
> 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.
> ***[LT] : Great suggestion, we will try to put a graph and probably an example to provide more clarity.
>
> Thanks!

>
> 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.
>
> ***[LT] :Our draft is not depending on the ioam draft, we will try to remove the dependency and state the packets forwarding in the IPv6 network is beyond the scope of our draft.
>
>
>
>  Will the below new text be okay, after removing the ippm dependency?
>
>
>
>  "Once the DT information reaches the border router, the packet will be
> encoded as per the mechanism prescribed in the new time synchronized
> network. The specific data encapsulation mechanisms followed in this
> network is beyond the scope of this document.
>
> For instance, the mechanisms specified in the In-band OAM header extension,
> [I-D.ietf-ippm-ioam-data] could be used."
>
>
>
Samita>  You can keep the last line as an example and let us wait for AD
recommendation. The rest of the paragraph is ok w/me.

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?
>
> ***[LT] : We will remove this dependency, and our draft will be applicable to any network that follows 6lo;
> thanks for pointing this out.
>
>
> 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:     *MailScanner has detected a possible fraud attempt from "www.georgiospapadopoulos.com* 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=> <http://www.georgiospapadopoulos.com%3Chttps//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=%3E>
> 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.
> -------------------------------------------------------------------------------------------------------------------------------
>
>
> -------------------------------------------------------------------------------------------------------------------------------
>
> [ 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.
> -------------------------------------------------------------------------------------------------------------------------------
>
>