Nicola,
I would try to focus on the draft, however, let me answer
briefly
the shared/dedicated point of view below.
Regards,
Diego
2016-10-31 15:18 GMT-03:00 Nicola Accettura <nick.accett...@gmail.com>:
> Hi Diego,
>
> thank you for your answer too.
>
> However there are two points I would like to point out.
>
> First, the mac-layer ack is in fact the TSCH ack, that travels on the air
> during the same timeslot of the data packet. It is sent if the data packet
> is unicast, either on shared or on dedicated cells. The 6P ACK I'm
> proposing is NOT a TSCH ack, it is a data packet sent from A to B and it
> requires its own TSCH ack from B to A.
>
First, I do not expect packets which are not Unicast during a negotiation.
What the SF needs to calculate the
timeout is any type of signalling confirming that the A->B request packet
has arrived to B. If this signal is
a different packet, it will take longer to arrive, but its meaning is not
different from what we need to start the timeout countdown.
So, if there is no time during the timeslot to bring upstream (to the SF)
the MAC ACK, then, it will do it in the next transmission opportunity,
which may happen in the next available slot. But the timeout countdown will
not start until that event happens.
In the way back, (the request response from B to A) there will be a MAC ACK
too, which will be in turn brought upstream (to the SF) in the same way as
it was brought the request from A to B, if there is no time in the current
timeslot, it will be done during the next transmission opportunity.
>
> Second, I'm totally not aligned on "...dedicated cells are for data and
> shared cells for any kind of signalling and/or negotiation." and I believe
> this is not the distinction between those types of cells.
>
> Shared or dedicated cells can be used either for signaling and/or data.
>
I understand your point on the flexibility to use any of them for different
purposes, but I would prioritize higher reliability (dedicated cells) for
data, while leaving negotiations for shared cells. As a matter of fact, 6P
now allows SFs to allocate either type of cells.
>
> 'Minimal'. as an example, has got a single shared cell. One can run
> minimal without any other more sophisticated scheduling technique just
> using that shared cell for both signaling and data. The same is possible if
> someone uses a dynamic schedule and uses also dedicated cells. I don't see
> any reason for forbidding dedicated cells to vehiculate both signaling and
> data. The difference is that in shared cells there's contention.
>
I see that a balance on the schedule is needed to address both scalability
and reliability. You can base your whole scheduling on shared or dedicated
cells, it is up to the SF now to decide where to expand and to decide which
type of traffic goes where. Before, there was the assumption of having only
a single best-effort track. Now we have two type of cells to decide on at
the SF. It is not specified yet on the SF0 draft, but a decision on this
matter must be taken.
>
> I would add that it could be possible to piggyback 6P signaling with data
> from upper layers, if there is space in the MTU. It is the encapsulation
> that makes the distinction between data and 6P signaling. Data go
> encapsulated within the IEEE802.15.4e packet payload, while 6P goes into
> the payload IEs, and these two payloads can coexist in the same
> IEEE802.15.4e frame.
>
I expect seeing opportunistic piggybacking instead of reserving a whole new
cell only for negotiation. In fact, the new cell must be negotiated itself
through the SF. Again, this may be a implementation specific, but it would
reduce power consumption.
>
> Thoughts?
>
> Nicola
>
>
--
DIEGO DUJOVNE
Profesor Asociado
Escuela de Informática y Telecomunicaciones
Facultad de IngenierÃa - Universidad Diego Portales - Chile
www.ingenieria.udp.cl
(56 2) 676 8125
_______________________________________________
6tisch mailing list
6tisch@ietf.org
https://www.ietf.org/mailman/listinfo/6tisch
