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

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

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

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

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