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 <ulrich@xxxxxxxxxxxx> wrote: > 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 > > On Mon, Feb 11, 2013 at 4:28 PM, Abdussalam Baryun > <abdussalambaryun@xxxxxxxxx> wrote: >> 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 >>> >