Subject: Re: [6tisch] Comments on the 6top-sublayer and 6top-sf0 drafts

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Mon, 9 Nov 2015 13:21:36 +0000

Dear all:

(ccing the 6TiSCH Interest group at IEEE IG6T since this is related to the 6top protocol)

For 1 a), I’d add that optionally the child could indicate/suggest some time offsets where it does not have scheduled transmissions with its own children. This way, the parent will not present cells that collision with time slots already used by the child.

For 2) I think we need a transaction number, be it only at the 6top protocol level. Say A (parent) asks B for some slots but never gets a response. It might be that B did not get the request, in which case A can retry later, no harm done. Or it might be that the response from B was lost, in which case the slots were allocated and A does not know. When A retries, B needs to be able to figure out that it is the same request as the previous one and send the same reply without allocating new slots. The transaction (sequence) number can be a good vector for that purpose.

Also I think the container of interest in the 6top signaling is not the chunk but the bundle. The chunk is a resource that the parent owns (it may own a number of them actually) and from which it will pick a free cell. From which chunk the cell is taken is irrelevant to the child. That cell will be placed in a bundle which is associated at L3 with one direction of the link between adjacent routers. The bundle must be identified by 6topP to indicate which resource gets the cell.

The ID used for the bundle must point to the link and the direction is an unequivocal manner in both A and B. The way we do that will have to be extended in the future for tracks. How do you see that ID exchange happening?

Finally I do not believe that we can say definitively that we can avoid concurrent transactions. We can avoid concurrency for a same bundle but maybe not for different bundles. In the future, multiple request may arrive for different tracks from the PCE, RSVP, etc… Indicating the bundle ID and the transaction number should enable that concurrency if we need it in the future.

Cheers,

Pascal

From: 6tisch [mailto:[email-masked]] On Behalf Of Maria Rita PALATTELLA
Sent: lundi 9 novembre 2015 13:33
To: Prof. Diego Dujovne <[email-masked]>; [email-masked]
Subject: Re: [6tisch] Comments on the 6top-sublayer and 6top-sf0 drafts

Diego,

Thanks for raising this discussion. About:

1)        If we assume the cells should belong to a given container, for instance a chunk (owned by a parent node), it makes sense it is always the parent to suggest the list of candidate cells. This implies we need to re-define better the transaction/negotiation between two neighbors:
a)      Upstream traffic. We will have a 3phases negotiation: the child asks for more cells, the parent suggests the list of cells, the child checks the list and pick the ones suitable.
          b)      Downstream traffic: 2 phases - the parent asks and proposes the list of cells, the child checks the list and picks the ones suitable.

2)   I remember we discussed about sequence number for tracking the transaction already. But while updating the draft, we did not include/consider it. Of course, we have to take into account overhead produced and thus, scalability of the solution.

Best Regards,
Maria Rita

From: 6tisch [mailto:[email-masked]] On Behalf Of Prof. Diego Dujovne
Sent: Friday, November 6, 2015 7:31 PM
To: [email-masked]<mailto:[email-masked]>
Subject: [6tisch] Comments on the 6top-sublayer and 6top-sf0 drafts

Dear all,
           Regarding the discussion on the 6top-sublayer and the
6top-sf0 drafts, I would like to point out two items:

- First, If there is a preference for the parent's
schedule over the child, I think the transaction should be started
always from the parent side, but requested (maybe) from the child node.
The problem I see there is that we must define a cell direction indicator
to allocate the cells. Until now, we were managing allocation in a
neighbour-to-neighbour basis, so the one requesting allocation defined
the direction, as Thomas pointed out.
Example: Given two nodes, A and B, neighbours:
If A starts an allocation request towards B, then, it is expected that A wants
to send traffic to B, so the direction is implicit.
Now, If A is the child and B the parent, A requires cells in the A->B direction:
A asks B to allocate cells, in the A->B direction; then B starts an allocation
request to A asking for cells in the A->B direction.
If we do not specify the direction, then, the cell will be allocated in the opposite
direction. (B->A).
One further item: I assume that we must always use RPL for 6tisch, and that
the RPL DODAG is already formed before SF0 starts sending requests to 6top.

- Second: I agree with Pascal on adding a sequence number to keep
track of transactions. This increases reliability on top of the already
established non-concurrent transactions+timeout philosophy.
I'm only worried about the overhead of this approach (longer
packet and transaction sequence number storage and verification)

What do you think on the former comments?
Thank you.
Regards,
                                        Diego

--
DIEGO DUJOVNE
Académico Escuela de Ingeniería en Informática y Telecomunicaciones
Facultad de Ingeniería UDP
www.ingenieria.udp.cl<http://www.ingenieria.udp.cl>
(56 2) 676 8125