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 <[email protected]> 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' <[email protected]> <[email protected]>>;; 'Georgios Z. > Papadopoulos' <[email protected]> > <[email protected]>>; > Cc: [email protected]; [email protected]; 'Malati > Hegde' <[email protected]> <[email protected]>>;; 'Samita > Chakrabarti' <[email protected]> <[email protected]>>;; 'Gabriel > Montenegro' <[email protected]> > <[email protected]>>;; 'lo' <[email protected]> > <[email protected]>>;; 'Charlie Perkins' <[email protected]> > <[email protected]>>;; [email protected] > 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:[email protected]] On Behalf Of Lijo Thomas > Sent: Tuesday, July 24, 2018 5:05 AM > To: 'Georgios Z. Papadopoulos' > <[email protected]<mailto:[email protected]>> > Cc: > [email protected]<mailto:[email protected]>; > [email protected]<mailto:[email protected]>; 'Malati Hegde' > <[email protected]<mailto:[email protected]>>; 'Samita > Chakrabarti' <[email protected]<mailto:[email protected]>>; > 'Gabriel Montenegro' > <[email protected]<mailto:[email protected]>>; > 'lo' <[email protected]<mailto:[email protected]>>; 'Charlie Perkins' > <[email protected]<mailto:[email protected]>>; > [email protected]<mailto:[email protected]> > 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:[email protected]] On Behalf Of Georgios Z. Papadopoulos > Sent: 24 July 2018 13:49 > To: Lijo Thomas > Cc: > [email protected]<mailto:[email protected]>; > [email protected]<mailto:[email protected]>; Malati Hegde; > Samita Chakrabarti; Gabriel Montenegro; lo; Charlie Perkins; > [email protected]<mailto:[email protected]> > 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 <[email protected]<mailto:[email protected]>> > 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:[email protected]] On Behalf Of Georgios Z. Papadopoulos > Sent: 17 July 2018 21:40 > To: [email protected]<mailto:[email protected]> > Cc: > [email protected]<mailto:[email protected]>; > [email protected]<mailto:[email protected]>; Malati Hegde; > Samita Chakrabarti; Gabriel Montenegro; lo; Charlie Perkins; > [email protected]<mailto:[email protected]> > 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. > ------------------------------------------------------------------------------------------------------------------------------- > >
_______________________________________________ 6lo mailing list [email protected] https://www.ietf.org/mailman/listinfo/6lo
