2016-11-11 17:14 GMT-03:00 Prof. Diego Dujovne <[email protected]>:

> Yasuyuki,
>               -02 version does not take into account symmetry.
> In fact, we do not specify which type of cells (RX,TX) we
> are allocating, we only say that we need to allocate them as
> an introduction to the section.
>               We implicitly assume that we are allocating TX
> traffic (which is RX from the point of view of the neighbour).
> The opposite sense is correct: If the neighbour needs TX traffic,
> it is RX for the node.
>               We do not specify on the draft where (i.e. from which
> neighbour)
> the incoming traffic comes from. In fact, the incoming traffic can arrive
> from any neighbour. However, if we assume that we are using RPL, all the
> traffic from the child nodes is forwarded to the parent in the TX sense,
> while downstream traffic would be parent->node->slave.
>              IMHO, I believe you are right when you say that taking into
> account only the outgoing traffic is a good estimator on the number of
> required cells, since it includes not only the locally generated traffic
> but also the
> traffic from the neighbours traversing the node to that neighbour.
> Furthermore, it would be more accurate (and overprovisioning could be
> smaller)
> because we assume also that we are not using track nor flow identifiers to
> map incoming traffic from the other nodes to the neighbours.
>              I think the symmetry interpretation comes from
> the idea that we are measuring the incoming cell requests from
> a specific neighbour and then adding the outgoing number of cells
> to the same neighbour and calculate the total amount of required cells.
> But we still have to differentiate between TX and RX cells.
>             Hope this helps.
>             Let me know your thoughts about it.
>             Regards,
>
>                                         Diego Dujovne
>
>
>
>
>
>
> 2016-11-11 14:20 GMT-03:00 Yasuyuki Tanaka <[email protected]
> >:
>
>> Hi all,
>>
>> I'd appreciate it if someone could help me understand SF0 Cell
>> Estimation Algorithm mentioned in draft-ietf-6tisch-6top-sf0-02...
>>
>> https://tools.ietf.org/html/draft-ietf-6tisch-6top-sf0-02#section-5
>>
>> What I've read from the draft is that the Cell Estimation Algorithm
>> tries to have at least as many TX cells to a neighbor as RX cells
>> which has been allocated for the neighbor as requested. It seems the
>> algorithm assumes the communication triggering SF0 is symmetric.
>>
>> This idea explains why REQUIREDCELLS is given "by adding the current
>> number of effectively used cells and the new incoming cells
>> requirement." In the draft, cells requested to the allocation policy
>> by the cell estimation algorithm are always TX. The numbers of
>> SCHEDULEDCELLS and REQUIREDCELLS are only about TX cells.
>>
>> Is it correct? If this is the case, I wonder where the assumption,
>> communication with a neighbor is symmetric, comes from.
>>
>> Supposing communication is asymmetric, where a node which has
>> allocated RX cells for a neighbor rarely sends data to it, TX cell
>> allocation triggered by an incoming cell requirement could not only be
>> in vain but also cause unnecessary 6P transactions. With this
>> scenario, it seems better that the estimation algorithm does not to
>> take into account "incoming cell requirements."  I may overlook
>> something...
>>
>> I have another thing to ask, but I'd like to clarify the above first.
>>
>> Best,
>> Yatch
>>
>> _______________________________________________
>> 6tisch mailing list
>> [email protected]
>> https://www.ietf.org/mailman/listinfo/6tisch
>>
>
>
>
> --
> 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

Reply via email to