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

From: Xavier Vilajosana <[email-masked]>
Date: Tue, 2 Aug 2016 13:02:09 +0200

Hi Lijo,

see inline please

2016-07-29 15:08 GMT+02:00 Lijo Thomas <[email-masked]>:

> Hi Xavi,
>
>
>
> I observed a small typo in section 4.2.10 instead of *node* it is written
> as *note*
>
>
>

thanks I correct that!

> I am bit confused with  Consitency description in 4.1
>
>
>
> You mean to say that the nodes should keep the count for each ADD/DELETE
> with the neighbor, does it create problem when a node has multiple neighbors
>

there is a counter per neighbor. ADD  and DELETE modify the counter for
that particular neighbor. Do you see any problem?

>
> Is this used for cross checking the schedules after the cell
> allocation/deletion process.
>

Yes this is used at every transaction to verify the consistency of the
schedule.

kind regards!
X

>
>
> *Thanks & Regards,*
>
> *Lijo Thomas *
>
>
>
>
>
> *From:* 6tisch [mailto:[email-masked]] *On Behalf Of *Xavier
> Vilajosana
> *Sent:* 26 July 2016 12:02
> *To:* [email-masked]
> *Subject:* [6tisch] Fwd: I-D Action:
> draft-ietf-6tisch-6top-protocol-02.txt
>
>
>
> 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: <[email-masked]>
> Date: 2016-07-26 8:30 GMT+02:00
> Subject: [6tisch] I-D Action: draft-ietf-6tisch-6top-protocol-02.txt
> To: [email-masked]
> Cc: [email-masked]
>
>
>
> 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
> [email-masked]
> https://www.ietf.org/mailman/listinfo/6tisch
>
>
>
> -------------------------------------------------------------------------------------------------------------------------------
>
> [ 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.
> -------------------------------------------------------------------------------------------------------------------------------
>
>

---

From: Xavier Vilajosana <[email-masked]>
Date: Tue, 2 Aug 2016 13:29:05 +0200

Hi Jiliang,

see inline please,

2016-07-29 15:33 GMT+02:00 Jiliang Wang <[email-masked]>:

> Thanks very much for your response. My comments are as follows.
>
> On Tue, Jul 26, 2016 at 9:14 PM, Xavi Vilajosana Guillén <
> [email-masked]> wrote:
>
>> Dear Jiliang,
>>
>> see inline please,
>>
>> 2016-07-26 10:05 GMT+02:00 Jiliang Wang <[email-masked]>:
>>
>>> 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 <
>>> [email-masked]> wrote:
>>>
>>>> Dear all,
>>>>
>>>> This draft is a work item of the IPv6 over the TSCH mode of IEEE
>>>> 802.15.4e of the IETF.
>>>>
>> --
>> Dr. Xavier Vilajosana Guillén
>> Research Professor
>> Wireless Networks Research Group
>> Internet Interdisciplinary Institute (IN3)
>> Universitat Oberta de Catalunya
>>
>> +34 646 633 681| [email-masked] | 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)
>>
>>
>>
>> 
>>
>
>

---

From: Jiliang Wang <[email-masked]>
Date: Tue, 2 Aug 2016 19:58:12 +0800

Thanks. please see inline my comments.

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

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

>>>>> we have submitted a revision of the 6top draft. It includes most of
>>>>> the changes proposed in the WG meeting in Berlin.
>>>>>

---

From: Xavier Vilajosana <[email-masked]>
Date: Tue, 2 Aug 2016 14:31:33 +0200

Hi Jiliang,

inline again :)

2016-08-02 13:58 GMT+02:00 Jiliang Wang <[email-masked]>:

>>>>> 1.- Is there any fragmentation method to transmit all the cells if
>>>>> the requested cells cannot be fit in a response?
>>>>>
>> 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 ...

that is why we use pagination. Assume the command LIST_AB issued by node A
to node B. Assume B has 10 cells in its schedule being
(1,3,5,7,9,11,13,15,17,19), assume also that a packet can only transport 4
cells.

Node A can issue STATUS to Node B. B will respond ti has 10 cells.
then
Node A will issue
LIST_AB offset=0 num cells=4
Node B will respond
1,3,5,7

Node A then will issue
LIST_AB offset=4 num cells=4
Node B will respond
9,11,13,15

Node A then will issue
LIST_AB offset=8 num cells=2
Node B will respond
17,19

> to deal with the inconsistency (with low probability), the protocol should
:)

> 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

I see. I wonder if this case is something we should worry. Usually the
schedules are sparse in these networks. If this eventually happen maybe we
can tolerate the SF to delete the cells and wait. What alternative would
you propose? and what would be the benefit vs overhead/drawback vs a
best-effort approach in the most common cases?

---

From: Tero Kivinen <[email-masked]>
Date: Tue, 2 Aug 2016 15:37:40 +0300

Xavier Vilajosana writes:
> 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 ...  

Note, that in 15.4 network some othe frames might also include other
information elements, which might consume some of the space available
for the actual data. I.e., even the upperlayer of the sending device
might not know how many bytes it can send at given moment, as MAC
layer might add some extra overhead without telling that to the upper
layer.

I think it would be better to make protocol so that sender will send
as many items it can fit, and indicates whether there is more and
responder will just give offset where the next request starts. Or just
use the numCells as a max size, but make it so that sender can also
send less if it cannot fit that many in response. This would require
some way to tell how many cells there are so requested will know when
to stop. 

>             design? For example, a clear command is sent from A to B and the
>             response from B to A is lost.
>            
> 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).

Loosing ACK might be low probability and that does not usually even
cause issues, as L2 will simply retransmit the frame. The bigger issue
is that L2 ACK just indicates that FCS check was correct and frame was
received by the other end, it DOES NOT mean that frame will be
delivered to the upper layer.

It is completely possible that MAC runs out of buffer space after
receiving the frame and sending ACK, but before sending the received
frame to upper layer.

I.e. L2 ACK only means that I got the frame, no need to do
retransmission anymore. It does not mean that frame will be delivered
to the upper layer, or that upper layer will be able to parse and
process the frame.

So using L2 ACK for any kind of application level acknowledgement is
bad idea.

Also with 6tisch L2 ACK is alreayd quite large (frame control (2
octets), seq number (1), addressing fields (0-20), auxiliary security
header (1-10), Time correction IE (2), MIC (4-16), FSC (2-4)).

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

I think using protocol defined on the 6top layer is better. It is bad
idea to rely on L2 ACKs for anything else than information that there
no need to retransmit this frame again...
-- 
[email-masked]

---

From: Tero Kivinen <[email-masked]>
Date: Tue, 2 Aug 2016 15:45:43 +0300

Xavier Vilajosana writes:
> that is why we use pagination. Assume the command LIST_AB issued by node A to
> node B. Assume B has 10 cells in its schedule being

Ah missed the status command, so other end has already way of telling
the number of cells, so why does the Node B need to respond with full
list of frame every time? Wouldn't it be better to allow Node B return
as many frame it can starting from offset:

Node A issue STATUS -> Node B replies with 10
Node A issues LIST_AB offset=0, num_cells_max=4 ->
     Node B respondes 1, 3, 5, 7
Node A issues LIST_AB offset=4, num_cells_max=4 ->
     Node B respondes 9, 11, 13 (+ some other IEs which consumed space
     from frame, so there was no space for 4 cells)
Node A issues LIST_AB offset=7, num_cells_max=4 ->
     Node B respondes 15, 17, 19

I.e. the num cells would just limit the number of cells other end can
respond, but other end can also sent less if it does not have space
for them in the frame (or if for some other reason it thinks it it is
better to send them in smaller chunks).      
-- 
[email-masked]

---

From: Jiliang Wang <[email-masked]>
Date: Tue, 2 Aug 2016 21:15:13 +0800

On Tue, Aug 2, 2016 at 8:31 PM, Xavier Vilajosana <
[email-masked]> wrote:

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

Then why node A should request 3 times? Should node B respond with all
those cells in 3 packets after receiving one request? This makes the
operation easier and more clear.
Semantically,  this means that A should not care about how many times
should request to return all cells.

> best-effort approach in the most common cases?
This may depends on the normal upper layer  operations. Is satisfying
partial requests the common case?

---

From: Xavier Vilajosana <[email-masked]>
Date: Fri, 5 Aug 2016 09:00:42 +0200

Hi Tero,

thanks for your comments. They are valuable. See inline.

2016-08-02 14:37 GMT+02:00 Tero Kivinen <[email-masked]>:

> to the
> XV> I will study your proposal (also the example you point in the next
email you had sent). it seems more flexible but still simple.

> packet
> XV: so you suggest 3 way (request-response-confirmation) for all cmds.. It
is energy-wise costly. What others think?

> no need to retransmit this frame again...
XV: idem as before, doable but consumes more energy. let's reach consensus
so we can progress.

---

From: Tero Kivinen <[email-masked]>
Date: Fri, 5 Aug 2016 14:53:39 +0300

Xavier Vilajosana writes:
> XV: so you suggest 3 way (request-response-confirmation) for all cmds.. It is
> energy-wise costly. What others think?

That might not be needed, depending how the protocol is used. We do
not do that in UDP based protocols, we usually assume that requested
will retransmit request until it gets response back, and if it does
not get response back ever, it assumes the other end is dead, and does
something else (like reconnect).

You can do similar things here. I.e., initiator sends request and
waits for response. If it does not get response (to the application
level) in specified time, it will retransmit its application level
message (which will be sent as new L2 frame), and it will continue
retransmit until it gets response, or it times out.

This will require the protocol to be made in such way that responder
is able to recognize the retransmissions, and send same responses to
them as it sent first time.

This does not require separate confirmation message. If responder
requires confirmation it can also use the fact that other end started
using newly allocated resources as a confirmation that initiator has
received the response...

> XV: idem as before, doable but consumes more energy. let's reach consensus so
> we can progress. 

TSCH network use lots of energy anyways, as they cannot be sleeping
for long time. Every node in the network needs to be sending packets
every now and then to keep synchorinized in the network time, thus
adding one or two packets to be sent during the setup phase is not
really that big difference compared to the mandatory timekeeping
frames that needs to be sent during normal operation.
-- 
[email-masked]