Subject: Re: [Roll] Traffic aware OF -03 review

From: Remous-Aris Koutsiamanis <[email-masked]>
Date: Mon, 11 Mar 2019 23:43:12 +0100 (CET)

Hello,

thank you very much for the constructive comments Rahul. I think they will
significantly improve the quality of the draft. I have responded inline to
each point.
I have also just submitted an updated version of the draft named:
draft-koutsiamanis-roll-traffic-aware-of-00
https://datatracker.ietf.org/doc/draft-koutsiamanis-roll-traffic-aware-of/

Kind regards,
Aris

On Tue, Nov 6, 2018 at 1:21 PM Rahul Arvind Jadhav <[email-masked]>
wrote:

> Hello Authors-of-TAOF,
>
>
>
> Network lifetime is a known problem in the space and I am glad to see
> something been done in the context. Following are some thoughts I have:
>
>
>
>
> 1.       Handling Config: DIO may need to carry OF configuration
> parameters .. i.e. all the nodes need to agree on the unit for e.g. for
> THROUGHPUT_PERIOD defined in the draft. It is necessary that all the nodes
> agree on the time unit.
>
You are absolutely right and this is something that concerned me as well
when we first introduced it.
For starters, to be more accurate I have renamed THROUGHPUT_PERIOD to
THROUGHPUT_WINDOW since a sliding window is specified explicitly. See
Section 5.
So at this point I have tried to offer flexibility. One can either
configure THROUGHPUT_WINDOW in the whole network in any external way
desired (e.g. compile-time constant, via COAP or other higher-level
configuration mechanism) or provide this information along with the RT
value with some overhead in the DIO.
As is customary for optional information, I have defined a TLV for this
value.
I followed the same approach for the unit (i.e. either configure externally
or provide optional TLV) new introduced as THROUGHPUT_WINDOW_UNIT.
See Section 6.

I hope that although these options do incur overhead in the packet size,
they allow for maximum flexibility.
If someone wants to avoid some or all of the overhead they can still
hard-code some or all of the TLVs and sacrifice some flexibility.

> During ROLL session, Pascal mentioned that parent oscillations should be
> avoided and suggested use of multiple parents while the transition is in
> progress. Another way to handle this is to involve hysteresis in this draft
> and give guidelines/recommendations for configuring thresholds.
>
This was a very good point raised and my view is that we need to perform
some experimental evaluations to get an idea of what will work well.
Unfortunately, at this point we have not yet completed this evaluation,
although we plan to.
We might have some results in time for the IETF but I am not sure about it
yet.
Therefore, at this point, I think that the idea for carrying the RT metric
is relatively solid but some more work is needed to specify how the TAOF
might use it. I have added a reference to this idea in the draft but no
concrete solution is provided at this time.

2.       Certain deployments have roughly similar data stream generated
> from all nodes .. for e.g. metering.. Current draft requires throughtput
> measurement on 6LRs .. In all cases this throughput calc may not be
> required .. But there is still a case to balance the network nonetheless ..
> Is it possible to consider balancing based on the sub-dodag size rooted at
> 6lr (naturally works only for storing MOP) ? In this sense, the work
> qasem-load-balancing was trying to do was similar considering nodes have
> similar traffic patterns.
>
Yes, I am aware of the qasem-load-balancing work, basically counting the
number of children.
In my opinion this is, as you say, an approximation or simplification for
the case where the nodes all generate more or less the same traffic.
Actually measuring the traffic is more accurate, in my opinion, so it
should be preferred if possible.
So the question is: are there any downsides to having to measure traffic?
In terms of computational resources, the overhead should be minimal for
adding an entry in a list every time a packet is sent and counting the
packets in a window every time a DIO is sent.
There might be some measurable memory overhead if the window is very large
*and* the traffic load is high. I wouldn't expect this to be the case in
our use cases, however.
Finally, there is a potential additional implementation complexity from
adding this tracking. Given that we have already done this -if maybe not
very efficiently- in Contiki, the modifications were a few hundred lines of
code.
I'm sorry I don't have specific numbers right now. If you think this an
important issue, I'll be more than happy to count bytes, cycles, and lines
of code :) to get some actual data.
So in my view it all depends on what weighs more important, flexibility and
accuracy with a little bit of overhead vs a simpler solution for one case.
Any thoughts?

> 3.       Section 6: There are several bits that needs to be defined in
> context for every routing metric (as per 6551) .. These are P, C, O, R, A
> bits. It is better you clarify the bits in RT context. I am specifically
> interested in understanding in how to handle this metric at multiple hops.
> How to do additive RT metric?
>
You are absolutely right. I have added a new Section "6.1. DAG Metric
Container fields" in the draft which explains these fields.
Also, the semantics of the RT metric (*remaining* throughput) are not
really useful in an additive metric context. At least I couldn't think of a
way to use it meaningfully this way. In our implementation, we use the
minimum metric function, i.e. a node A with parent P reports in its DIO:
DIO_RT(A) = MIN(DIO_RT(P), RT(A))
where RT(A) is the locally calculated remaining throughput at node A and
DIO_RT(P) is the RT value of its parent P received via a DIO from P.

> 4.       I don’t understand why enrollment aspect was brought (this was
> not present in earlier draft) .. The relay chosen during enrollment and
> parent chosen during routing could be different. Enrollment can choose a
> different set of metrics from routing.. Enrollment of nodes happens few
> times during the lifetime of the device. The metrics enrollment could
> consider could be completely different from routing metrics.
>
You are correct that the two processes are independent, and the relay and
preferred parent do not necessarily coincide.
However, we discussed whether it would be useful for accelerating the
enrollment.
If one has a large number of devices which need to connect, it can be
useful for each device to be able to pick as quickly as possible a good
DODAG and preferred parent.
Since each relay will probably only be part of one DODAG, using RT to
affect the pan priority helps the node pick a relay in a less congested
DODAG, instead of picking a relay, joining to its DODAG (congested) and
waiting for DIOs from other DODAGs or parents to optimise connectivity.
I agree this is an optimisation for a specific use case, but my impression
is that this is a desired feature to have. At the end of the day, it just
specifies how to convert an RT value into a pan priority value.

>
>
> Regards,
>
> Rahul
> _______________________________________________
> Roll mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/roll
>