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 <ulrich(_at_)herberg(_dot_)name> wrote:
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
On Mon, Feb 11, 2013 at 10:47 AM, Jiazi Yi <ietf(_at_)jiaziyi(_dot_)com>
wrote:
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
<rdroms(_dot_)ietf(_at_)gmail(_dot_)com> 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 ietf(_at_)ietf(_dot_)org 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
ietf(_at_)ietf(_dot_)org mailing lists by 2013-02-24. Exceptionally,
comments may
be
sent to iesg(_at_)ietf(_dot_)org 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
manet(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/manet
_______________________________________________
manet mailing list
manet(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/manet