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 protected]] On Behalf Of Prof. Diego Dujovne
Sent: Friday, November 6, 2015 7:31 PM
To: [email protected]
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
_______________________________________________
6tisch mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/6tisch
