Subject: [Roll] P2P drafts

From: <[email-masked]>
Date: Thu, 11 Nov 2010 11:58:05 +0100

Hello Emmanuel, all

Following your plea for feedback at the meeting today, here are some
observations that occured to me while reading the two drafts: "p2p-rpl"
and "p2p-measurement"
Best,

Dominique

------------------------

1) "p2p-rpl" draft
Section 5.2 page 10: you specify that one or more DMCs must be placed
before the Route Discovery option and one or more after the RD. This
implies that ordering of the options in the DIO must be maintained as
DIOs are propagated in the network. We add a similar ordering
requirement in the metrics draft earlier on, and it was considered an
issue.
If you maintain the idea of having differentiated propagation
constraints and route constraints, I would suggest differentiating them
explicitely. For example, there are still some bits available in the DMC
format.

Section 5.6 on page 13: <<selecting the "n" best good enough routes
(using the OCP specified in the Route Discovery option to do the
comparison)>>
In what I assume to be the frequent case, aggregated metric), the
comparison between routes does not need to resort to the OF. The DMC
contains all what is needed to compare route costs. If there is a single
(aggregated) metric in use, lower is better or higher is better,
depending on which metric we talk about. If there are multiple metrics
in use, the precedence is provided in the DMC as well. Only in the case
of recorded metrics does the OF intervene. That's the very reason for
recorded metrics: plan ahead for cases where none of
addition/multiplication/max/min would fit the application needs.
However, the OF may decide when a node thinks it has gathered suffisant
information to make a final decision.
Therefore, I would recommend to write
<<selecting the "n" best good enough routes discovered over a certain
time period, potentially using the OF specified in the Route Discovery
option.>>
 
Page 9: just curious about the values represented by the L field. They
increase in uneven factors (2 to 10). Why not just buinary increase in
seconds?

Nit on page 19: s/complimentary/complementary/

2) "p2p-measurement" draft
Section 3 on page 5: Metric Container Options. I'm not sure whether you
are referring to a Dag Metric Container, including its (Type=2,Length)
header, or to a Routing Metric/Constraint object, starting with the
Routing-MC-Type field. I assume the latter.

Section 7 on page 11
<<If a routing metric object contains local metric values recorded by
enroute nodes, the origin node MAY aggregate these local values into an
end-to-end value as per the aggregation rules for the metric.>>
If a metric was recorded instead of being aggregated enroute, then the A
field in the DMC is meaning less. The computation that takes place at
the end node to gauge of the quality of the path is defined in the
Objective Function defined by the OCP.
Therefore, I would recommend writing
<<If a routing metric object contains local metric values recorded by
enroute nodes, the origin node MAY compute an end-to-end value out of
these local values as per the objective function in use.>>

---

From: Mukul Goyal <[email-masked]>
Date: Thu, 11 Nov 2010 11:10:51 -0600 (CST)

Hi Dominique

Thanks for your comments. Please see inline.

[Dominique]
1) "p2p-rpl" draft 
Section 5.2 page 10: you specify that one or more DMCs must be placed before the Route Discovery option and one or more after the RD. This implies that ordering of the options in the DIO must be maintained as DIOs are propagated in the network. We add a similar ordering requirement in the metrics draft earlier on, and it was considered an issue. 

If you maintain the idea of having differentiated propagation constraints and route constraints, I would suggest differentiating them explicitely. For example, there are still some bits available in the DMC format. 

[Mukul]
Would it make sense to directly include a DAG Metric Container for "route constraints" inside Route Discovery option? I guess we dont want P2P concepts to affect core definitions.

[Dominique]
Section 5.6 on page 13: <<selecting the "n" best good enough routes (using the OCP specified in the Route Discovery option to do the comparison)>> 

In what I assume to be the frequent case, aggregated metric), the comparison between routes does not need to resort to the OF. The DMC contains all what is needed to compare route costs. If there is a single (aggregated) metric in use, lower is better or higher is better, depending on which metric we talk about. If there are multiple metrics in use, the precedence is provided in the DMC as well. Only in the case of recorded metrics does the OF intervene. That's the very reason for recorded metrics: plan ahead for cases where none of addition/multiplication/max/min would fit the application needs. 

However, the OF may decide when a node thinks it has gathered suffisant information to make a final decision. 
Therefore, I would recommend to write 
<<selecting the "n" best good enough routes discovered over a certain time period, potentially using the OF specified in the Route Discovery option.>> 

[Mukul]

I am fine with this change.

[Dominique]

Page 9: just curious about the values represented by the L field. They increase in uneven factors (2 to 10). Why not just buinary increase in seconds? 

[Mukul]

These values were considered most useful by us. I would be OK with taking some of the reserved bits and allowing specification of the minimum life time as the exponent of 2 in units of seconds.

[Dominique]

[Mukul]
Thanks.

[Dominique]

2) "p2p-measurement" draft 
Section 3 on page 5: Metric Container Options. I'm not sure whether you are referring to a Dag Metric Container, including its (Type=2,Length) header, or to a Routing Metric/Constraint object, starting with the Routing-MC-Type field. I assume the latter. 

[Mukul]
This is referring to Dag Metric Container. Can a Routing Metric/Constraint object exist outside a DMC??

[Dominique]

Section 7 on page 11 
<<If a routing metric object contains local metric values recorded by enroute nodes, the origin node MAY aggregate these local values into an end-to-end value as per the aggregation rules for the metric.>> 

If a metric was recorded instead of being aggregated enroute, then the A field in the DMC is meaning less. The computation that takes place at the end node to gauge of the quality of the path is defined in the Objective Function defined by the OCP. 

Therefore, I would recommend writing 
<<If a routing metric object contains local metric values recorded by enroute nodes, the origin node MAY compute an end-to-end value out of these local values as per the objective function in use.>> 

[Mukul]

Thanks for this correction.

Thanks
Mukul
_______________________________________________
Roll mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/roll