Date: Sun, 1 Apr 2012 22:46:52 -0500 (CDT)
From: Mukul Goyal <mukul@uwm.edu>
To: C Chauvenet <c.chauvenet@watteco.com>
Message-ID: <466430945.1770002.1333338412632.JavaMail.root@mail17.pantherlink.uwm.edu>
In-Reply-To: <A484DA39-6BCB-439D-8FDE-A249BD492014@watteco.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
Cc: ROLL WG <roll@ietf.org>
Subject: Re: [Roll] ROLL WG Last Call
 on	draft-ietf-roll-p2p-measurement-04	and draft-ietf-roll-p2p-rpl-09
Precedence: list

Hi Cedric

Thanks for your detailed comments!

***************************************************************************=
*******
[Cedric]
On big question that rise my mind is, what happened if the route discovery =
fail ?=20
Some protocols sends out an error message when the route discovery fails or=
 get stuck.=C2=A0=20
Do authors think that it could be relevant to add a "discovery-error" messa=
ge as defined in other route discovery protocols ?=20

[Mukul]
I dont think it is possible to detect the failure of a P2P-RPL route discov=
ery. 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 f=
irst half) succeeds when a target joins the DAG. Only the target knows whet=
her 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 t=
arget can ensure (or at least increase the probability of) success by askin=
g for DRO-ACK and retransmitting the DRO if the DRO-ACK is not received wit=
hin certain time duration. DRO message travels by multicast, so an intermed=
iate 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 h=
alf 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 DA=
G's life time has expired but no DRO is received. But I am not sure we shou=
ld mandate this to be the way failure is inferred. We have just 4 values fo=
r the DAG life time. So, I think we should leave it to origin how much to w=
ait for a DRO before admitting failure.

***************************************************************************=
************************  =20
[Cedric]
Another point that has been discussed today during the ROLL meeting, is tha=
t some people may find other mechanisms than trickle more efficient to floo=
d the RDO.=20
Could we let the door opened to other flooding optimization mechanism, or e=
xplicitly say that the trickle mechanism MUST be used ?=20

[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.

***************************************************************************=
********************************=20

[Cedric]
In details :=C2=A0=20


p3 : P2P-RPL does not guarantee discovery of a route.=20
But how do we know if the RDO has been lost, of if the request has failed ?=
=20
in other words, how do we know if the route doesn't exist, or if the reques=
t has been lost ?=20
In addition, it may be relevant to cite an example where the discovery of a=
 route cannot be achieved.=20

[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 trans=
mission as per the trickle algorithm. This ofcourse depends on the life tim=
e 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 exi=
sts or not. Even if the route exists, P2P-RPL may not be able to discover i=
t. This could happen because constraints are too strict or DIOs moving in t=
he direction of the target get lost. I will add some text that makes this c=
lear.

***************************************************************************=
****************

[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.=20
Any recommendation to guess the metric in use ? Is it relevant to use hop c=
ount by default (to limit the scope) ?=20

[Mukul]
I dont think the draft could make any recommendation in this regard or sugg=
est any particular metric to be used by default. The draft does allow the r=
oute 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]=20
p6 :=C2=A0 P2P-RPL allows for the discovery of one hop-by-hop route or upto=
 four source
   routes per target.=20
upto --> up to.=20
Why 4 ? Any reason to limit the choice to 4 ?=20

[Mukul]
Because we had just two bits for the purpose and 4 routes to a particular d=
estination sounds sufficient.

***************************************************************************=
***************************

[Cedric]
p6 :=C2=A0 A P2P mode DIO always carries one P2P Route Discovery Option (de=
fined in Section 7.1 ) in which the origin specifies the
   following information:=20
So you should put a MUST for this.=20

[Mukul]
OK.
***************************************************************************=
********************************

[Cedric]
p9 :=C2=A0 o DIOIntervalMin: 6, which translates to 64ms as the value for I=
min parameter in Trickle operation.=20
Should we really fix numbers in this spec ? Could we turn the MUST of these=
 parameters into recommended values ?=20
Not sure this timing is applicable to all RPL networks.=20

[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 Con=
figuration Option. An explicit DODAG Configuration Option can specify any v=
alue for its parameters. The recommendations for trickle parameters are mad=
e in Section 9.2

***************************************************************************=
***********************************

p12 :=C2=A0 This specification does not allow for the establishment of hop-=
by-hop routes in the backward direction.

[Cedric]=20
Why ? This would enable to establish 2 routes within a single route request=
.=20
Furthermore, you stipulates in the draft that links have to be bidirectiona=
l to propagates RDO, in order to be able to send back the DRO.=20
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 ?=20

[Mukul]
Suppose a DRO establishing a forward hop-by-hop route fails to make it to t=
he origin. In this case, all we have is some nodes storing the hop-by-hop s=
tate 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 es=
tablish 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 use=
ful. We did not include this in P2P-RPL because we did not have a usecase f=
or backward hop-by-hop routes and we wanted to avoid the additional complex=
ity.=20

This is how we can implement this functionality: we will let the target dec=
ide whether it wants the DRO to establish a backward hop-by-hop route. In t=
hat case:
1) the target will set a new flag, the B flag (B for backward hop-by-hop ro=
ute), inside the DRO to let intermediate routers know that backward route s=
tate 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 RPLInstanceI=
D under which the hop-by-hop state for the backward route will be stored. N=
ote that the RPLInstanceID of the forward route (selected by the origin) ma=
y 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 routi=
ng-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:=20
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 DR=
O).

Do you want this functionality?

***************************************************************************=
**************

p13 :=C2=A0 The IPv6 addresses in the Address vector MUST be reachable in b=
oth forward and backward directions.=20
[Cedric]
Does it means that links have to be bidirectional on the path ? How do you =
verify that ?=20

[Mukul]
The DRO message travels from the target to the origin along a discovered ro=
ute. 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 :=C2=A0 A DRO message travels from the target to the origin via link-lo=
cal multicast along the
   route specified inside the Address vector in the P2P-RDO.=20

[Cedric]
Why using multicast if you know every destinators ?=20
Could we unicast packets to each destinators in the address vector ?=20

[Mukul]
DRO travels by link local multicast so that the nodes, that are on the temp=
orary DAG but not necessarily on a discovered route, may know that the rout=
e discovery is over (via the stop flag) and there is no need to generate an=
y more DIOs. This may lead to a significant reduction in the (unnecessary) =
DIOs generated. Only the routers on the discovered route do the multicast-b=
ased forwarding though.=20

***************************************************************************=
*************

p15 :=C2=A0 Stop (S): This flag, when set to one by a target, indicates tha=
t the P2P-RPL route discovery is over.

[Cedric]=20
Is this bit really usefull ? My guess is that it will be always set to 1.=
=20
If you hear a DRO, this indeed means that the RDO has reached the target, s=
o you could just stop processing RDO when you hear a DRO.=20
Do we really need a flag to stop RDO processing or the hearing of a DRO typ=
e message could do the job ?=20

[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 whe=
n the target sets the stop flag in the DRO, a node could be sure that the r=
oute discovery is over.

***************************************************************************=
***********

p21 :=C2=A0 Example methods include selecting each route that meets the spe=
cified routing constraints
   until the desired number have been selected or selecting the best
   routes discovered over a certain time period.=20

[Cedric]
How could we know the time to wait until we get all the RDO ?=20
Is there a way to evaluate it according to some parameters related to the n=
etwork (diameter of the network for instance) ?=20

[Mukul] This has to be a local decision. Perhaps, the target can look at th=
e aggregated values of the routing metrics from the origin and determine it=
s distance from the origin. This distance estimate, along with trickle para=
meters, could perhaps give it a better idea of how much to wait. I dont thi=
nk that the draft should talk about this.

***************************************************************************=
********
p25 :=C2=A0 o DRO_ACK_WAIT_TIME: The time duration a target waits for the D=
RO- ACK before retransmitting a DRO message.  DRO_ACK_WAIT_TIME has a
      value of 1 second.=20

[Cedric]
I'm not sure it is compliant with all RPL deployments.=20
Could we adapt it to the characteristics of the network used ?

[Mukul]=20
I am OK with making DRO_ACK_WAIT_TIME as well as MAX_DRO_RETRANSMISSIONS co=
nfigurable parameters.
***************************************************************************=
*******

[Cedric]
p28 : References need to be updated according to recent RFCs.=20

[Mukul]
Yes.
***************************************************************************=
*******
Thanks
Mukul