Subject: Re: [manet] IETF last call and review of draft-cardenas-dff-09.txt

From: Jiazi Yi <[email-masked]>
Date: Mon, 11 Feb 2013 19:47:38 +0100

Dear all, 

I had a through review of dff-07 with detailed comments. In the new revision, my questions and concerns have been properly addressed -- thanks to all the authors. 

The mechanism is well documented, and I have tested the protocol in the scenarios described in the applicability statement, which brings interesting performance improvement. 

Therefore, I would like to encourage the publication of it. 

Just one more comment:

	o In section 8 Protocol Parameters, it would be better to have some limitations or recommendations for those parameters. For P_HOLD_TIME, I think it's OK by saying "at least be MAX_HOP_LIMIT times  the expected time to send a Packet to a router on the same link.". It would be event better to give such limitations to MAX_HOP_LIMIT. A regular value related to NET_DIAMETER won't work, because DFF can have significant higher hop count and result in packet drop. Maybe we can have something like "it MUST NOT be higher than the number of routers in the DFF routing domain. If the number of routers is greater than 255, it is set to 255 by default." 

best

Jiazi

On Feb 8, 2013, at 7:22 PM, Ralph Droms <[email-masked]> wrote:

> draft-cardenas-dff is under consideration for publication as an AD-sponsored individual submission Experimental RFC.  I agreed to sponsor it for publication because it doesn't really fit in any existing working groups and the requested publication status is Experimental.  As part of the review process, the document is in a 2-week IETF last call.  The last call announcement is included below.  To ensure the quality of the document, it would be helpful to get reviews from manet WG participants (posted to the [email-masked] discussion list).
> 
> Thanks.
> 
> - Ralph
> 
> 
> =====
> 
> 
> The IESG has received a request from an individual submitter to consider
> the following document:
> - 'Depth-First Forwarding in Unreliable Networks (DFF)'
> <draft-cardenas-dff-09.txt> as Experimental RFC
> 
> The IESG plans to make a decision in the next few weeks, and solicits
> final comments on this action. Please send substantive comments to the
> [email-masked] mailing lists by 2013-02-24. Exceptionally, comments may be
> sent to [email-masked] instead. In either case, please retain the
> beginning of the Subject line to allow automated sorting.
> 
> Abstract
> 
> 
>  This document specifies the "Depth-First Forwarding" (DFF) protocol
>  for IPv6 networks, a data forwarding mechanism that can increase
>  reliability of data delivery in networks with dynamic topology and/or
>  lossy links.  The protocol operates entirely on the forwarding plane,
>  but may interact with the routing plane.  DFF forwards data packets
>  using a mechanism similar to a "depth-first search" for the
>  destination of a packet.  The routing plane may be informed of
>  failures to deliver a packet or loops.  This document specifies the
>  DFF mechanism both for IPv6 networks (as specified in RFC2460) and in
>  addition also for LoWPAN "mesh-under" networks (as specified in
>  RFC4944).
> 
> 
> 
> 
> The file can be obtained via
> http://datatracker.ietf.org/doc/draft-cardenas-dff/
> 
> IESG discussion can be tracked via
> http://datatracker.ietf.org/doc/draft-cardenas-dff/ballot/
> 
> 
> The following IPR Declarations may be related to this I-D:
> 
>  http://datatracker.ietf.org/ipr/1645/
>  http://datatracker.ietf.org/ipr/1646/
> 
> 
> _______________________________________________
> manet mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/manet

---

From: Ulrich Herberg <[email-masked]>
Date: Mon, 11 Feb 2013 11:49:32 -0800

Jiazi,

thank you very much for your review. I am glad that the latest
revision addresses your previous concerns.

As to your suggestion, I agree that having some constraints is useful.
To your suggestion considering the number of routers in the DFF
domain, I think this would be difficult to use normative language, as
the number of routers may not be known (e.g. when not using a
proactive routing protocol). DFF does not mandate to have this
information at hand.
Another example of setting the value would be to depend on the
expected path length (e.g. based on information from the routing
protocol). It may, e.g., be reasonable to set a MAX_HOP_LIMIT that is,
say, 50% longer than the distance in hops indicated by a routing
protocol. I think that it would be very interesting to find out
appropriate values as experiments for the protocol (given that the
document is Experimental).

How about adding the following text to MAX_HOP_LIMIT:

----- added text ------
Finding optimal values for MAX_HOP_LIMIT is part of experiments that
can be performed with the protocol proposed in this document.
For example, one possible experiment would be to set MAX_HOP_LIMIT to
different factors of the expected path length to the destination in
number of hops if provided by a routing protocol.
---------------------

Best regards
Ulrich

---

From: Jiazi Yi <[email-masked]>
Date: Mon, 11 Feb 2013 21:37:13 +0100

Hi, 

I can imagine that it would be hard to set this parameter. According to my simulation results, even with the same network scenario, the hop count would be very different depending on if a routing protocol is used, or which protocol is used. 

I think it's a good idea to indicate the experimental point, to encourage people to try it out, and give feedback. 

best

Jiazi

---

From: Ulrich Herberg <[email-masked]>
Date: Mon, 11 Feb 2013 13:26:08 -0800

Hi Jiazi,

I agree with your observation. I will add the sentence.

Best
Ulrich

---

From: Abdussalam Baryun <[email-masked]>
Date: Tue, 12 Feb 2013 01:28:11 +0100

Hi Ulrich,

I agree with Jiazi, that you need to provide values of parameters for
the experiment I-D, or some default recommendations. I think it is
important but your text proposed does not follow the request of
parameters values,

AB

On 2/11/13, Ulrich Herberg <[email-masked]> wrote:
>> I had a through review of dff-07 with detailed comments. In the new
>> revision, my questions and concerns have been properly addressed -- thanks
>> to all the authors.
>>
>> The mechanism is well documented, and I have tested the protocol in the
>> scenarios described in the applicability statement, which brings
>> interesting performance improvement.
>>
>>         o In section 8 Protocol Parameters, it would be better to have
>> some limitations or recommendations for those parameters. For P_HOLD_TIME,
>> I think it's OK by saying "at least be MAX_HOP_LIMIT times  the expected
>> time to send a Packet to a router on the same link.". It would be event
>> better to give such limitations to MAX_HOP_LIMIT. A regular value related
>> to NET_DIAMETER won't work, because DFF can have significant higher hop
>> count and result in packet drop. Maybe we can have something like "it MUST
>> NOT be higher than the number of routers in the DFF routing domain. If the
>> number of routers is greater than 255, it is set to 255 by default."
>>
>> best
>>
>> Jiazi
>>
>>
>> > draft-cardenas-dff is under consideration for publication as an
>> > AD-sponsored individual submission Experimental RFC.  I agreed to
>> > sponsor it for publication because it doesn't really fit in any existing
>> > working groups and the requested publication status is Experimental.  As
>> > part of the review process, the document is in a 2-week IETF last call.
>> > The last call announcement is included below.  To ensure the quality of
>> > the document, it would be helpful to get reviews from manet WG
>> > participants (posted to the [email-masked] discussion list).
>> >
>> > Thanks.
>> >
>> > - Ralph
>> >
>> >
>> > =====
>> >
>> >

---

From: Ulrich Herberg <[email-masked]>
Date: Mon, 11 Feb 2013 16:33:23 -0800

AB,

as said to Jiazi, the text already has some recommendations of
constraints for the parameters (and I will add the sentence I
suggested to Jiazi). I am unsure what additional text you would like
to see.

Best regards
Ulrich

---

From: Abdussalam Baryun <[email-masked]>
Date: Tue, 12 Feb 2013 02:18:47 +0100

Similar way of parameters in RFC6606 which I think can be related,
however, I will answer your question better in my review messages
(still not finished). Just wanted to support the idea of a
participant,

AB

On 2/12/13, Ulrich Herberg <[email-masked]> wrote:
>>>> > [email-masked] mailing lists by 2013-02-24. Exceptionally, comments
>>>> > may
>>>> > be