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

[Xavier Vilajosana <[e-mail]>]

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?

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.

> 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.

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)
>>
>>
>>
>> ­
>>
>
>