[Roll] Suggestions for draft-ji-roll-traffic-aware-objective-function-00

["Houjianqiang (Derek)" <[e-mail]>]

Hi Chenyang,

Nice to see that you are involved in improving the parent selection in RPL network, and thanks for bringing the idea "Packet Transmission Rate" into roll WG. Your solution is very useful, especially when traffic generated from different nodes is "highly" uneven. I have read through your draft and provide my comments and suggestions as below.


1.      The format  of your PTR metric should be modified in order to be consistent with current Metric framework as define in RFC6551. Based on my understanding, you are not requiring IANA to assign a new "DAGMC type" but rather a new "Routing-MC-Type" inside the DAG Metric Container. There is a  DAG Metric Container Format in RFC6551 you can follow and put your PTR inside the container as a new metric object. Your co-author Georgios has given a good example in his draft "draft-pkm-roll-nsa-extension-00". The metric container gives you many functions, such as combining PTR with other metrics like ETX (constraint), ChildCount (metric) and HopCount (metric), which has been mentioned in your draft.



2.      I noticed one weak point of your solution and I have come up with some possible ways to solve that. Nodes select their preferred parent node based on the PTRs of their potential parents (if I understand it right). For the two-hop cases in your draft, it's fine, but for multi-hop cases, the downstream nodes are unaware of the PTRs of the sink nodes (nodes connected to the root). For example, in the right pattern of Figure 2 in your draft, if new nodes come in below C1/C2/D1/D2, then the new nodes will prefer to choose C1/C2/D1 rather than D2 (PTR_D2 is larger). Let's say new node E1->C1, E2->C2, E3->D1, and assume E1/E2/E3 have PTR = 1pkt/s, then in this case, PTR_C1 = PTR_C2 = PTR_D1 = 2 pkt/s, PTR_A = 6 pkt/s. This in the end triggers D1 switches from A to B. So my point is when new nodes join in the downstream, they strongly influence the upstream connections. This effect causes an unstable RPL network and should be minimized. One way I come up with is to use the aggregation mode in the Metric Container so that new nodes are able to know the whole PTRs along a link to the root and then select based on the whole link condition. Another possible way is you can define a new "RANK" computation that includes the PTRs along a link, e.g. RANK_C1 = PTR_A+0.5*PTR_C1.



3.      The PTR computation method hasn't been illustrated in your draft. After thinking a bit more, here is my suggestion. The first method that came into my mind is to compute base on a time cycle, e.g. count the number of packet per 10 seconds, but then I denied this method for three reasons: 1. Nodes may have sleep mode and cannot do this PTR computation when sleeping; 2. a fixed time cycle may not be accurate to reflect PTR because nodes may send packets at different rate at different time, e.g. 1pkt/s, 1pkt/hour, 1pkt/day; 3. frequently computing PTR consumes more energy. I suggest doing the PTR computation based on the time points when sending packets. For example, a node send Packet_n-1 at time t_n-1 and send Packet_n at time t_n, then 1 / (t_n - t_n-1) reflects the packet rate. Then The PTR at time t_n could be

PTR_n = alpha * 1 / (t_n - t_n-1) + (1 - alpha) * PTR_n-1,

where alpha are constant between 0 to 1. In this way, nodes refresh their PTR when sending packets, and the PTR equation gives a smooth variation that guarantees the stability of a RPL network.

Hopefully my suggestions could help to improve the quality of your draft.

Best regards,
Derek Jianqiang Hou

Related drafts and RFC:
https://datatracker.ietf.org/doc/draft-ji-roll-traffic-aware-objective-function/
https://datatracker.ietf.org/doc/rfc6551/
https://datatracker.ietf.org/doc/draft-pkm-roll-nsa-extension/