Hi Jiazi, I agree with your observation. I will add the sentence.
Best Ulrich On Mon, Feb 11, 2013 at 12:37 PM, Jiazi Yi <[email protected]> wrote: > 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 <[email protected]> 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 <[email protected]> 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 <[email protected]> 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 protected] 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 protected] mailing lists by 2013-02-24. Exceptionally, comments may be >>>> sent to [email protected] 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 protected] >>>> https://www.ietf.org/mailman/listinfo/manet >>> >
