Nicola,
I created a new thread to discuss this item.
Can you continue there so as separate the topics?
Thank you.
Regards,
Diego
2016-10-31 19:29 GMT-03:00 Nicola Accettura <[email protected]>:
> Diego,
>
> defining priorities about the management of packets is implementation
> specific, I guess. But I can be wrong.
>
> To be honest, from what I saw in practical implementations, the best is to
> give the highest priority to 6P packets both on shared and dedicated cells,
> because they are in charge to enlarge/reduce bandwidth starting from
> 'minimal'.
>
> Data will be always be created and, if you don't give priority to 6P
> negotiations, they will quickly fill up queues while congesting the small
> bandwidth available. Data must be able to travel only if the network is
> sufficiently capable - if there are dedicated cells. To get dedicated cells
> you need first 6P negotiations.
>
> If the network has sufficient bandwith (dedicated cells have been
> allocated very quickly), data will use the average bandwidth and there will
> not be many negotiations.
>
> I know it's counter-intuitive: if you give more priority to 6P packets you
> will in fact allow data to stay very comfortable in the dedicated cells
> allocated.
>
> Nicola
>
>
> 2016-10-31 20:48 GMT+01:00 Prof. Diego Dujovne <[email protected]>
> :
>
>> 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 <[email protected]>:
>>
>>> 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
>>
>
>
--
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
[email protected]
https://www.ietf.org/mailman/listinfo/6tisch
