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
On Feb 11, 2013, at 8:49 PM, 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