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

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

Hi Chenyang,

Regarding your questions, please see my response in line.

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.

[RE] You are right about the weak point,thank you.
About the aggregation mode,if I understand correct that requires node to inform its direct child about its transmission rate change(new node joins its subtree,child changes parent etc),that may increase the frequency of DIO messages?

>> [Derek] The frequency of sending DIO is determined by Trickle algorithm, not the aggregation mode. RPL adapts the sending rate of DIO messages by extending the Trickle algorithm. In a network with stable links the control messages will be rare whereas an environment in which the topology changes frequently will cause RPL to send control information more often.

About rank computation,nodes with larger transmission rate will have larger rank than its neighbor nodes so there is a possibility it selects its neighbor as parent and increase the traffic of other subtree.
I don't know if I described it in the right way,I'll send a example if needed.

>>[Derek] I guess I have got what you mean. Let's still take the right pattern in Figure 2 in your draft as an example, are you saying that when PTR_D2 becomes larger, e.g. 5pkt/s, then PTR_B = 5. If using the "RANK" equation I suggested above, then RANK_A = 3, RANK_B = 5, RANK_D1 = 3.5, RANK_D2 = 7.5. In this case node D2 may change its parent from B to D1. If this is what you mean, definitely we don't want to see this happen. To avoid this, you should specify when and under what condition the parent switch will happen. The PARENT_SWITCH_THRESHOLD of D2 should be related to RANK_B together with PTR_D2. I mean since the downstream nodes influence the RANK of their upstream parent, then node D2 should compute what RANK_B will be if without the contribution of D2 itself.    

Regards, 
Derek Jianqiang Hou

-----Original Message-----
From: Chenyang JI [mailto:[e-mail]] 
Sent: Thursday, December 21, 2017 8:35 PM
To: Houjianqiang (Derek) <[e-mail]>
Cc: roll <[e-mail]>
Subject: Re: Suggestions for draft-ji-roll-traffic-aware-objective-function-00

Good morning,

Thank you a lot for the suggestions,they are very helpful.
I added some response below the suggestions after [RE]


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.

[RE] I'll make a new figure to clarify that Transmission rate is included in Metric container.


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.

[RE] You are right about the weak point,thank you.
About the aggregation mode,if I understand correct that requires node to inform its direct child about its transmission rate change(new node joins its subtree,child changes parent etc),that may increase the frequency of DIO messages?
About rank computation,nodes with larger transmission rate will have larger rank than its neighbor nodes so there is a possibility it selects its neighbor as parent and increase the traffic of other subtree.
I don't know if I described it in the right way,I'll send a example if needed.


Regards
Chenyang

----- Original Message -----
From: "Houjianqiang" <[e-mail]>
To: "Chenyang JI" <[e-mail]>
Cc: "roll" <[e-mail]>
Sent: Thursday, December 21, 2017 7:49:08 AM
Subject: Suggestions for draft-ji-roll-traffic-aware-objective-function-00

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/