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 >
_______________________________________________ 6tisch mailing list [email protected] https://www.ietf.org/mailman/listinfo/6tisch
