Re: [Roll] ROLL WG Last Call on draft-ietf-roll-p2p-measurement-04 and draft-ietf-roll-p2p-rpl-09

[Mukul Goyal <[e-mail]>]

Hi Cedric

Thanks for your detailed comments!

**********************************************************************************
[Cedric]
On big question that rise my mind is, what happened if the route discovery fail ? 
Some protocols sends out an error message when the route discovery fails or get stuck.  
Do authors think that it could be relevant to add a "discovery-error" message as defined in other route discovery protocols ? 

[Mukul]
I dont think it is possible to detect the failure of a P2P-RPL route discovery. No node knows if a P2P-RPL route discovery has failed.

P2P-RPL forms a temporary DAG and the route discovery (well, at least the first half) succeeds when a target joins the DAG. Only the target knows whether it joined the DAG or not. So, no node knows if the (first half of the) route discovery failed.

Second half involves the target sending DRO to the origin. If the DRO does not reach the origin, (the second half of) the route discovery fails. The target can ensure (or at least increase the probability of) success by asking for DRO-ACK and retransmitting the DRO if the DRO-ACK is not received within certain time duration. DRO message travels by multicast, so an intermediate router, that forwards a DRO further, has no idea whether the next hop on the route received the DRO or not. Again, no node knows if the (second half of the) there is no one to generate the discovery-error message.

I think an origin might infer the route discovery to have failed, if the DAG's life time has expired but no DRO is received. But I am not sure we should mandate this to be the way failure is inferred. We have just 4 values for the DAG life time. So, I think we should leave it to origin how much to wait for a DRO before admitting failure.

***************************************************************************************************   
[Cedric]
Another point that has been discussed today during the ROLL meeting, is that some people may find other mechanisms than trickle more efficient to flood the RDO. 
Could we let the door opened to other flooding optimization mechanism, or explicitly say that the trickle mechanism MUST be used ? 

[Mukul]
I think inherent dependence on the trickle mechanism is apparent because of the fact that the route discovery takes place by forming a temporary DAG. DAG creation (or DIO generation) depends on trickle algorithm. So, P2P-RPL also depends on trickle algorithm. P2P-RPL being an extension of core RPL, I dont think there is a way to separate P2P-RPL from trickle algorithm.

*********************************************************************************************************** 

[Cedric]
In details :  


p3 : P2P-RPL does not guarantee discovery of a route. 
But how do we know if the RDO has been lost, of if the request has failed ? 
in other words, how do we know if the route doesn't exist, or if the request has been lost ? 
In addition, it may be relevant to cite an example where the discovery of a route cannot be achieved. 

[Mukul]
You mention two possibilities: 1) route does not exist 2) DIO has been lost
The second possibility is avoided (to a large extent) by periodic DIO transmission as per the trickle algorithm. This ofcourse depends on the life time of the DAG, trickle parameters and how consistent/inconsistent events are defined.

As I discussed above, it is not possible to determine whether the route exists or not. Even if the route exists, P2P-RPL may not be able to discover it. This could happen because constraints are too strict or DIOs moving in the direction of the target get lost. I will add some text that makes this clear.

*******************************************************************************************

[Cedric]
p5 : If there is no existing route between the origin and the target(s) or the cost
   measurement for the existing routes fails, the origin will have to
   guess the constraints to be used in the initial route discovery. 
Any recommendation to guess the metric in use ? Is it relevant to use hop count by default (to limit the scope) ? 

[Mukul]
I dont think the draft could make any recommendation in this regard or suggest any particular metric to be used by default. The draft does allow the route discovery to work without using any routing metric when OF0 is the OF in use (in this case, the MaxRank field in P2P-RDO still provides a way to specify the scope of route discovery).

**************************************************************************************************
[Cedric] 
p6 :  P2P-RPL allows for the discovery of one hop-by-hop route or upto four source
   routes per target. 
upto --> up to. 
Why 4 ? Any reason to limit the choice to 4 ? 

[Mukul]
Because we had just two bits for the purpose and 4 routes to a particular destination sounds sufficient.

******************************************************************************************************

[Cedric]
p6 :  A P2P mode DIO always carries one P2P Route Discovery Option (defined in Section 7.1 ) in which the origin specifies the
   following information: 
So you should put a MUST for this. 

[Mukul]
OK.
***********************************************************************************************************

[Cedric]
p9 :  o DIOIntervalMin: 6, which translates to 64ms as the value for Imin parameter in Trickle operation. 
Should we really fix numbers in this spec ? Could we turn the MUST of these parameters into recommended values ? 
Not sure this timing is applicable to all RPL networks. 

[Mukul]
This is the DIOIntervalMin value in the default DODAG Configuration Option, which comes in effect only when DIO does not contain an explicit DODAG Configuration Option. An explicit DODAG Configuration Option can specify any value for its parameters. The recommendations for trickle parameters are made in Section 9.2

**************************************************************************************************************

p12 :  This specification does not allow for the establishment of hop-by-hop routes in the backward direction.

[Cedric] 
Why ? This would enable to establish 2 routes within a single route request. 
Furthermore, you stipulates in the draft that links have to be bidirectional to propagates RDO, in order to be able to send back the DRO. 
So if I understand it correctly you ensure that you have a reliable path in both ways. Why using it in a single way only ? 

[Mukul]
Suppose a DRO establishing a forward hop-by-hop route fails to make it to the origin. In this case, all we have is some nodes storing the hop-by-hop state for a broken route but that route is never used since the origin never gets the DRO. On the other hand, if the DRO establishing a backward hop-by-hop route fails to make it to the origin, we have a broken route that the target is likely to use (to reach the origin). So, if we want P2P-RPL to establish a backward hop-by-hop route, the target MUST ask for a DRO-ACK from the origin (to make sure that the DRO does reach the origin and hence the backward route is not broken). This can be done if you think it will be useful. We did not include this in P2P-RPL because we did not have a usecase for backward hop-by-hop routes and we wanted to avoid the additional complexity. 

This is how we can implement this functionality: we will let the target decide whether it wants the DRO to establish a backward hop-by-hop route. In that case:
1) the target will set a new flag, the B flag (B for backward hop-by-hop route), inside the DRO to let intermediate routers know that backward route state needs to be established as well;
2) the target will set the A flag to require a DRO-ACK from the origin;
3) the target will specify (inside a new field in the DRO), an RPLInstanceID under which the hop-by-hop state for the backward route will be stored. Note that the RPLInstanceID of the forward route (selected by the origin) may not be OK for use in backward route (because the target may have already used this RPLInstanceID for another hop-by-hop route, using different routing-metrics/constraints/OF, to the origin).
When the intermediate routers receive this DRO, they will store the hop-by-hop state for the backward route. This hop-by-hop state will consist of: 
1) Target address (taken from P2P-RDO inside the DRO).
2) RPLInstanceID specified by the target
3) The destination, i.e., the origin address (same as DODAGID inside the DRO).

Do you want this functionality?

*****************************************************************************************

p13 :  The IPv6 addresses in the Address vector MUST be reachable in both forward and backward directions. 
[Cedric]
Does it means that links have to be bidirectional on the path ? How do you verify that ? 

[Mukul]
The DRO message travels from the target to the origin along a discovered route. So, yes, the links should have bidirectional reachability. It does not mean that the link should have same value for the routing metrics in both direction. Just simple reachability should allow the DRO to travel back to the origin.

*****************************************************************************************

p14 :  A DRO message travels from the target to the origin via link-local multicast along the
   route specified inside the Address vector in the P2P-RDO. 

[Cedric]
Why using multicast if you know every destinators ? 
Could we unicast packets to each destinators in the address vector ? 

[Mukul]
DRO travels by link local multicast so that the nodes, that are on the temporary DAG but not necessarily on a discovered route, may know that the route discovery is over (via the stop flag) and there is no need to generate any more DIOs. This may lead to a significant reduction in the (unnecessary) DIOs generated. Only the routers on the discovered route do the multicast-based forwarding though. 

****************************************************************************************

p15 :  Stop (S): This flag, when set to one by a target, indicates that the P2P-RPL route discovery is over.

[Cedric] 
Is this bit really usefull ? My guess is that it will be always set to 1. 
If you hear a DRO, this indeed means that the RDO has reached the target, so you could just stop processing RDO when you hear a DRO. 
Do we really need a flag to stop RDO processing or the hearing of a DRO type message could do the job ? 

[Mukul]
A P2P-RPL invocation might involve discovery of multiple source routes. In that case, receipt of a DRO does not mean route discovery is over. Only when the target sets the stop flag in the DRO, a node could be sure that the route discovery is over.

**************************************************************************************

p21 :  Example methods include selecting each route that meets the specified routing constraints
   until the desired number have been selected or selecting the best
   routes discovered over a certain time period. 

[Cedric]
How could we know the time to wait until we get all the RDO ? 
Is there a way to evaluate it according to some parameters related to the network (diameter of the network for instance) ? 

[Mukul] This has to be a local decision. Perhaps, the target can look at the aggregated values of the routing metrics from the origin and determine its distance from the origin. This distance estimate, along with trickle parameters, could perhaps give it a better idea of how much to wait. I dont think that the draft should talk about this.

***********************************************************************************
p25 :  o DRO_ACK_WAIT_TIME: The time duration a target waits for the DRO- ACK before retransmitting a DRO message.  DRO_ACK_WAIT_TIME has a
      value of 1 second. 

[Cedric]
I'm not sure it is compliant with all RPL deployments. 
Could we adapt it to the characteristics of the network used ?

[Mukul] 
I am OK with making DRO_ACK_WAIT_TIME as well as MAX_DRO_RETRANSMISSIONS configurable parameters.
**********************************************************************************

[Cedric]
p28 : References need to be updated according to recent RFCs. 

[Mukul]
Yes.
**********************************************************************************
Thanks
Mukul