Re: [6tisch] OTF: IP or not IP?

["Wang, Chonggang" <[e-mail]>]

Pascal,

This is the sentence from pp. 24 – section 8.1.4 from architecture draft ver08


“A node can reserve a track to a destination node multiple hops away by installing soft cells at each intermediate node. This forms a track of soft cells.
”

From: Pascal Thubert (pthubert) [mailto:[e-mail]]
Sent: Wednesday, October 14, 2015 6:04 AM
To: Wang, Chonggang <[e-mail]>; [e-mail]
Subject: RE: OTF: IP or not IP?

Hello ChongGang:

Please see below



·         First, in 6tisch architecture draft, it is mentioned that a track can be built on soft cells.


Ø    I do not remember writing or incorporating text that would say that. Please elaborate… There are possibilities to employ soft cells to, say, improve dynamically the ARQ operation, but so far I do not remember that we really made any decision there.


·         Second, if OTF is limited to IP traffic, OTF appears to me a purely layer-3 (or IP layer) mechanism. Then, why 6TiSCH WG handles IP-layer-only mechanism? Should it be beyond the scope of 6TiSCH WG?


Ø   This is not a L3 mechanism. This is a Link Layer operation which aims to provide a variable bandwidth link for IP. The Work Item in the charter is a commitment for people writing the draft that they will cover the subject given. The problem statement for IP (Track0) is well-known because OTF has to work on an IP link. So people may commit to define methods that provide the required service. But they can hardly commit to produce the additional work to cover tracks as well as long as we have not defined tracks more precisely. And waiting for that definition would delay the current OTF work, which is not something we want. We’d rather stage and produce things that we can interop-test in an agile fashion.



·         Third, Charter2.0 implies some work to be done and/or work-in-progress. I feel whether we can use “this work is not fully done” as a reason to exclude it from the charter 2.0.


Ø    We have a very high level concept of track in the architecture but what it is in more details has still to be debated, e.g. for packet replication over multiple paths vs. ARQ. Let us work on  defining that and we’ll see if the OTF work applies. It that is the case, we’ll mention that capability in the track work as an extension to the IP case, giving rules and applicability. If that is not the case, we’ll charter additional work if that appears to be needed. Note that this does not prevent the discussion on OTF for tracks, just that the previous charter did not prevent OTF work to happen. It’s more like we do not commit *yet* to produce a stable specification in a short period of time.

Cheers,

Pascal

Just my 2 cents.

Thanks,
Chonggang


Chonggang Wang
Member Technical Staff
InterDigital Communications, Inc.
781 Third Ave
King of Prussia, PA 19406
T: +1 610.878.5731
[e-mail]<mailto:[e-mail]>
www.InterDigital.com<http://www.interdigital.com>

[cid:image001.png@01D1066A.B208DB80]
This e-mail is intended only for the use of the individual or entity to which it is addressed, and may contain information that is privileged, confidential and/or otherwise protected from disclosure to anyone other than its intended recipient. Unintended transmission shall not constitute waiver of any privilege or confidentiality obligation. If you received this communication in error, please do not review, copy or distribute it, notify me immediately by email, and delete the original message and any attachments. Unless expressly stated in this e-mail, nothing in this message or any attachment should be construed as a digital or electronic signature.


From: 6tisch [mailto:[e-mail]] On Behalf Of Pascal Thubert (pthubert)
Sent: Friday, October 09, 2015 11:49 AM
To: [e-mail]<mailto:[e-mail]>
Subject: [6tisch] OTF: IP or not IP?

Dear all:

Following up on the comments at the interim, My suggestion is to update item 3 as follows:


3. Produce an “On-the-fly" (OTF) specification to enable a distributed dynamic
scheduling of time slots with the capability for IoT routers to appropriate
chunks of the matrix without starving, or interfering with, other 6TiSCH nodes.
This particular work will focus on IP traffic since the work on tracks is not
yet advanced enough to specify their requirements for OTF operations.

I remove the ‘for IP traffic’ within the main text to indicate that the initial focus is
N IP traffic but I hope that now it is more clear that future work on tracks is not precluded.
Does that address the comment?

Cheers,

Pascal