Re: [6tisch] Fwd: I-D Action: draft-ietf-6tisch-6top-protocol-02.txt

[Jiliang Wang <[e-mail]>]

Thanks. please see inline my comments.

On Tue, Aug 2, 2016 at 7:29 PM, Xavier Vilajosana <
[e-mail]> wrote:

> Hi Jiliang,
>
> see inline please,
>
> 2016-07-29 15:33 GMT+02:00 Jiliang Wang <[e-mail]>:
>
>> Thanks very much for your response. My comments are as follows.
>>
>> On Tue, Jul 26, 2016 at 9:14 PM, Xavi Vilajosana Guillén <
>> [e-mail]> wrote:
>>
>>> Dear Jiliang,
>>>
>>> see inline please,
>>>
>>> 2016-07-26 10:05 GMT+02:00 Jiliang Wang <[e-mail]>:
>>>
>>>> Thanks for the great work. This is Jiliang Wang from Tsinghua
>>>> University. I am very interested in this version and I just have several
>>>> questions.
>>>>
>>>> 1.       In 4.3.10, it says “If node A requests more cells than can
>>>> fit in the response, node B MUST return code RC_ERR_NORES and an empty cell
>>>> list.”
>>>>
>>>> 1.- Is there any fragmentation method to transmit all the cells if the
>>>> requested cells cannot be fit in a response?
>>>>
>>> No, we keep it simple. The LIST command supports pagination. You can
>>> retry with a smaller page size if it does not fit in a packet.
>>>
>> Is the pagination decision made by node A? This seems to be not simple
>> since the actual number is not know and thus it is difficult to determine
>> whether to use pagination.
>>
>
> A node knows the bytes it can fit in a packet. This gives an indication to
> the node of what is the number of items that can be requested. When a node
> issues a LIST it starts by offset 0, this returns the first N scheduled
> cells. Then it seems reasonable that the node will indicate offset N and
> request N more cells ...
> If the number of requested cells does not fit in the packet an error is
> returned and the node retries again with a smaller value of N.
> I do not see a big complexity on that. What issues do you see?
>
Then how to deal with the case that a node has cells more than that can be
fitted in a packet. Is there any method to return all those cells?

> 2.       Will the clear command result in inconsistency in current
>>>> design? For example, a clear command is sent from A to B and the response
>>>> from B to A is lost.
>>>>
>>> The CLEAR is not executed until the response is received. B side
>>> executes the CLEAR after receiving the L2 ACK of the response message.
>>>
>> It there any problem when the L2 ACK is lost in which A clears while B
>> does not?
>>
>
> In a TSCH network the probability of losing the ACK is very low. As the
> packet has already been sent the ACK has extremely high chances to pass as
> well (it is shorter in length which still favours the transmission
> success). Of course this can remotely happen and if this happens the system
> should recover from that inconsistency. To do so the generation counters
> will enable the detection of the inconsistency and both nodes schedule will
> be cleared (only cells between them).
> The alternative is to use a 3 step transaction, which requires 33% more
> packets over the air at every transaction. We decided to avoid that. Maybe
> a research question is to evaluate in a real deployment the energy overhead
> of using 3 way transactions vs eventually recovering from a lost ACK during
> a CLEAR. Given the chances of losing an ACK I would bet for the later.
>
Yes, agree. I also agree that the probability should be low and 3-way
handshaking may be overwhelming in this case. As long as clear can be used
to deal with the inconsistency (with low probability), the protocol should
be ok.

>
>
3.       Currently, the add command supports best-effort cell adding, i.e.,
>>>> when the cells is not enough, partial of the cells can be added – if I
>>>> understand correctly.
>>>>
>>>>  –what is the purpose of best-effort adding. Why not just return
>>>> success and fail?
>>>>
>>> Best effort minimizes the amount of data to be sent.
>>>
>> Is it possible that a node needs to issue an all-or-no adding request?
>> For example, a node prefers to transmit all data at once.
>>
> I would separate the data plane from the control plane. For me ADD is an
> operation that deals with the reservation of cells (control plane). If ADD
> does not meet the requirements in a particular moment in time, the SF will
> take care of requesting other cells. If this introduces a delay between
> when the cells are requested and when all of the requested cells can be
> used is something we need to evaluate.  There is always the option that the
> application requesting the bw blocks until all cells have been allocated.
> This is out of the scope in 6top.
>
My question is that A node may want to allocate, say 6 cells, B node should
return 0 or 6 instead of any other number in between. Otherwise, the upper
layer scheduler SF cannot schedule the communication in a fine
 granularity. For example, SF may realized 6 cannot be satisfied and it may
decide to wait instead of using partial of the cells.

>
> kind regards,
> Xavi
>
>>
>>>
>>>
>>>> best,
>>>>
>>>>
>>> Kind regards,
>>> Xavi
>>>
>>>> -------------
>>>> Jiliang Wang
>>>> Assistant Professor
>>>> http://tns.thss.tsinghua.edu.cn/~jiliang/
>>>>
>>>> On Tue, Jul 26, 2016 at 2:32 PM, Xavier Vilajosana <
>>>> [e-mail]> wrote:
>>>>
>>>>> Dear all,
>>>>>
>>>>> we have submitted a revision of the 6top draft. It includes most of
>>>>> the changes proposed in the WG meeting in Berlin.
>>>>>
>>>>> please send us your comments.
>>>>>
>>>>> kind regards,
>>>>> Xavi
>>>>>
>>>>> ---------- Forwarded message ----------
>>>>> From: <[e-mail]>
>>>>> Date: 2016-07-26 8:30 GMT+02:00
>>>>> Subject: [6tisch] I-D Action: draft-ietf-6tisch-6top-protocol-02.txt
>>>>> To: [e-mail]
>>>>> Cc: [e-mail]
>>>>>
>>>>>
>>>>>
>>>>> A New Internet-Draft is available from the on-line Internet-Drafts
>>>>> directories.
>>>>> This draft is a work item of the IPv6 over the TSCH mode of IEEE
>>>>> 802.15.4e of the IETF.
>>>>>
>>>>>         Title           : 6top Protocol (6P)
>>>>>         Authors         : Qin Wang
>>>>>                           Xavier Vilajosana
>>>>>         Filename        : draft-ietf-6tisch-6top-protocol-02.txt
>>>>>         Pages           : 28
>>>>>         Date            : 2016-07-25
>>>>>
>>>>> Abstract:
>>>>>    This document defines the 6top Protocol (6P), which enables
>>>>>    distributed scheduling in 6TiSCH networks.  6P allows neighbor nodes
>>>>>    in a 6TiSCH network to add/delete TSCH cells to one another.  6P is
>>>>>    part of the 6TiSCH Operation Sublayer (6top), the next higher layer
>>>>>    of the IEEE802.15.4 TSCH medium access control layer.  The 6top
>>>>>    Scheduling Function (SF) decides when to add/delete cells, and
>>>>>    triggers 6P Transactions.  Several SFs can be defined, each
>>>>>    identified by a different 6top Scheduling Function Identifier
>>>>> (SFID).
>>>>>    This document lists the requirements for an SF, but leaves the
>>>>>    definition of the SF out of scope.  Different SFs are expected to be
>>>>>    defined in future companion specifications.
>>>>>
>>>>>
>>>>>
>>>>> The IETF datatracker status page for this draft is:
>>>>> https://datatracker.ietf.org/doc/draft-ietf-6tisch-6top-protocol/
>>>>>
>>>>> There's also a htmlized version available at:
>>>>> https://tools.ietf.org/html/draft-ietf-6tisch-6top-protocol-02
>>>>>
>>>>> A diff from the previous version is available at:
>>>>> https://www.ietf.org/rfcdiff?url2=draft-ietf-6tisch-6top-protocol-02
>>>>>
>>>>>
>>>>> Please note that it may take a couple of minutes from the time of
>>>>> submission
>>>>> until the htmlized version and diff are available at tools.ietf.org.
>>>>>
>>>>> Internet-Drafts are also available by anonymous FTP at:
>>>>> ftp://ftp.ietf.org/internet-drafts/
>>>>>
>>>>> _______________________________________________
>>>>> 6tisch mailing list
>>>>> [e-mail]
>>>>> https://www.ietf.org/mailman/listinfo/6tisch
>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> 6tisch mailing list
>>>>> [e-mail]
>>>>> https://www.ietf.org/mailman/listinfo/6tisch
>>>>>
>>>>>
>>>>
>>>> _______________________________________________
>>>> 6tisch mailing list
>>>> [e-mail]
>>>> https://www.ietf.org/mailman/listinfo/6tisch
>>>>
>>>>
>>>
>>>
>>> --
>>> Dr. Xavier Vilajosana Guillén­
>>> Research Professor
>>> Wireless Networks Research Group
>>> Internet Interdisciplinary Institute (IN3)
>>> Universitat Oberta de Catalunya­
>>>
>>> [phone]| [e-mail]­ | Skype­: xvilajosana
>>> http://xvilajosana.org
>>> http://wine.rdi.uoc.edu/
>>>
>>> Parc Mediterrani de la Tecnologia
>>> Av. Carl Friedrich Gauss, 5. Edifici B3
>>> 08860 Castelldefels (Barcelona)
>>>
>>>
>>>
>>> ­
>>>
>>
>>
>