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@xxxxxxxxxxxx> 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@xxxxxxxxxxx> 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.ietf@xxxxxxxxx> 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@xxxxxxxx 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@xxxxxxxx mailing lists by 2013-02-24. Exceptionally, comments may >> > be >> > sent to iesg@xxxxxxxx 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@xxxxxxxx >> > https://www.ietf.org/mailman/listinfo/manet >> > _______________________________________________ > manet mailing list > manet@xxxxxxxx > https://www.ietf.org/mailman/listinfo/manet >