Hi,   I have reviewed draft-ietf-manet-olsrv2-dat-metric-09 as part of the Operational directorate's ongoing effort to review all IETF documents being processed by the IESG.  These comments were written with the intent of improving the operational aspects of the IETF drafts. Comments that are not addressed in last call may be included in AD reviews during the IESG review.  Document editors and WG chairs should treat these comments just like any other last call comments.   “This document specifies an directional airtime link metric for usage in OLSRv2.”   My overall view of the document is 'Almost ready' for publication, however, there are technical comments still need to be addressed or responded before it moves forward.   * Section 2, page 3: > diff_seqno(new, old)  - an operation which returns the positive >       distance between two elements of the circular sequence number >       space defined in section 5.1 of [RFC5444].  Its value is either >       (new - old) if this result is positive, or else its value is (new >       - old + 65536).   May specify the length and sign of the the sequence numbers, otherwise the _expression_ "new - old + 65536" wouldn't make sense.     * Section 2, page 4: >    ETT  - Estimated Travel Time, a link metric proportional to the >       amount of airtime needed to transmit an IP packet over a link, not >       considering layer-2 overhead created by preamble, backoff time and >       queuing.   "...needed to transmit an IP packet" might be "needed to successfully transmit an IP packet"? May comment a bit how this metric relates with the other definitions in this section? And how does the packet size affect this metric?     * Section 3, page 4: >    The Directional Airtime Metric was designed and tested (see >    [olsrv2_paper]) in wireless IEEE 802.11 OLSRv2 [RFC7181] networks. >    These networks employ link layer retransmission to increase the >    delivery probability and multiple unicast data rates.   What does "multiple unicast data rates" mean? Hard to parse.     * Section 3, page 4: > his measurement could be done by >    gathering cross-layer data from the operating system or an external >    daemon like DLEP [DLEP], but also by indirect layer-3 measurements >    like packet-pair.   Please provide a reference for "indirect layer-3 measurements like packet-pair".     * Section 3, pages 4/5: >    The metric uses RFC5444 multicast control traffic to determine the >    link packet loss.  The administrator should take care that link layer >    multicast transmission do not not have a higher reception probability >    than the slowest unicast transmission.  It might, for example in >    802.11g, be necessary to increase the data-rate of the multicast >    transmissions, e.g. set the multicast data-rate to 6 MBit/s.   What if multicast traffic has a lower reception probability, as it usually does?     * Section 3, page 5: > The maximum packet loss that can be encoded into the >    metric a loss of 7 of 8 packets, without link layer retransmissions.   packets per second, or?     * Section 4, page 5: >    The Directional Airtime Metric does not integrate the packet size >    into the link cost.  Doing so is not feasible in most link-state >    routing protocol implementations.    Multiplying >    all link costs of a topology with the size of a data-plane packet >    would never change the Dijkstra result anyways.   Measuring the airtime may depend on the packet size.     * Section 11, page 13: May note that attracting traffic can also be of use for traffic sniffing, and Man-in-the-Middle attacks.     **** Editorial ****   * Section 1, page 2:   Please expand "OLSR"     * Section 1, page 3: >    This document describes a Directional Airtime routing metric for >    OLSRv2, a successor of the ETX-derived OLSR.org routing metric for >    OLSR.     "of the OLSR.org ETX-derived routing metric"?     * Section 1, page 3: > It enables easier interoperability >    tests between implementations and will also deliver an useful >    baseline to compare other metrics to.   s/an useful/a useful/     * Section 1, page 3: > DAT metric   Please expand the acronym upon first occurrence.     * Section 2, page 3: > TLV   Please expand the acronym.     * Section 3, page 4: >    As specified in OLSRv2 the metric calculates only the incoming link >    cost.  It does neither calculate the outgoing metric, nor does it >    decide the link status (heard, symmetric, lost).   Missing comma right after "OLSRv2".     * Section 3, page 4: >    The metric works both for nodes which can send/receive [RFC5444] >    packet sequence numbers and such which do not have this capability.   s/such/those/?     * Section 3, page 4: >    The metric uses RFC5444 multicast control traffic to determine the >    link packet loss.   May probably replace "RFC5444" with "[RFC5444]" (i.e., make it a reference).     * Section 3, page 5: > This metric has been designed for >    data-rates of 1 MBit/s and hundreds of MBit/s.     May probably be rephrased as "data-rates between 1 MBit/s and hundreds of MBit/s."     * Section 4, page 5: >    The Directional Airtime Metric has been inspired by the publications >    on the ETX [MOBICOM03] and ETT [MOBICOM04] metric, but differs from >    both of these in several ways.   s/metric/metrics/     * Section 4, page 5: >    o  Incoming packet loss and linkspeed can be measured locally, >       symmetric link loss would need an additional signaling TLV in the >       [RFC6130] HELLO and would delay metric calculation by up to one >       HELLO interval.   May s/[RFC6130] HELLO/HELLO [RFC6130]/     * Section 4, page 5: > The routing decision of most >    operation systems don't take packet size into account.   Please rephrase as "The routing decision of most operating systems does not take packet size into account."   * Section 4, page 5: >    The queue based packet loss estimator has been tested extensively in >    the OLSR.org ETX implementation, see Appendix B.   May rephrase as "...implementation (see Appendix B)".     * Section 4, page 6: > The metric tries to detect jumps in the packet >    sequence number and removes them from the data set, because the >    already gathered link loss data should still be valid (see >    Section 9.3.   The closing parenthesis (")") is missing.     * Section 5, title: > 5.  Metric Functioning & Overview   s/&/and/     * Section 5 page 6: >    The Directional Airtime Metric is calculated for each link set entry, >    as defined in [RFC6130] section 7.1.   Please rephrase to "...in section 7.1 of [RFC6130]".     * Section 5, page 6: > Incoming packet loss and packet reception event are >    accumulated   s/event/events/     * Section 5, page 6: > and remove the oldest counter from both.   s/remove/removes/   * Section 6, page 7: >     (see [RFC6130] Section 5.3.1)   Please rephrase to "(see Section 5.3.1 of [RFC6130])".     * Section 6.1, page 7: > immobile routers.   Maybe use "non-mobile routers", instead?     * Section 7, page 8: > See Appendix D Appendix E for example metric >    values.   Missing "and".   * Section 8, page 8: >    This specification extends the Link Set of the Interface Information >    Base, as defined in [RFC6130] section 7.1   Please rephrase as "..section 7.1 of [RFC6130]"     * Section 8 page 9: >    L_DAT_hello_interval  - the interval between two hello messages of >       the links neighbor as signaled by the INTERVAL_TIME TLV [RFC5497] >       of NHDP messages [RFC6130].   Please expand "NHDP".     * Section 8, page 9: > See Appendix B >    Appendix C for an example.   Missing "and".     * Section 8, page 9: >    This specification updates the L_in_metric field of the Link Set of >    the Interface Information Base, as defined in section 8.1. of >    [RFC7181])   Please replace ")" with ".".     * Section 8.1, page 9: >    When generating a new tuple in the Link Set, as defined in [RFC6130] >    section 12.5 bullet 3, the values of the elements specified in >    Section 8 are set as follows:   Please rephrase as " defined in bullet 3 of Section 12.5 in [RFC6130]...."     * Section 9, page 10: >    This section describes the necessary changes of [RFC7181] >    implementation   s/of/to/     * Section 9.1, page 10: >    o  "interval_time" is the time encoded in the INTERVAL_TIME message >       TLV of a received [RFC6130] HELLO message. > >    o  "validity_time" is the time encoded in the VALIDITY_TIME message >       TLV of a received [RFC6130] HELLO message.   In both instances, change to "HELLO message [RFC6130]".     * Section 9.2, page 10: >    o  an INTERVAL_TIME message TLV in each HELLO message, as defined in >       [RFC6130] section 4.3.2. > >    o  an interface specific packet sequence number as defined in >       [RFC5444] section 5.1 which is incremented by 1 for each outgoing >       [RFC5444] packet on the interface.   In both cases, change to "Section XXX of [RFCYYYY]"  (obviously please replace XXX and YYYY as appropriate). Note: There are many of this throughout the document.     * Section 9.2, page 10: > Hello messages   s/Hello/HELLO/.     * Section 92, page 10: > timeout based loss >    detection slower   s/timeout based/timeout-based/     * Section 9.4, page 13: > See Appendix C Appendix D for an example.   Missing "and".     * Section 13.2, page 15: >    [olsrv2_paper] >               C., C., C., C., J., J., J., J., and H. H., "OLSRv2 for >               Community Networks: Using Directional Airtime Metric with >               external radios", Elsevier Computer Networks 2015 , >               September 2015, >               < http://dx.doi.org/10.1016/j.comnet.2015.09.022 >.   Please expand the last names of the authors as appropriate.     * Section 13.2, page 16: >   As the DAT metric proved to work reasonable well for non- or slow- >    moving ad hoc networks [olsrv2_paper]   s/reasonable/reasonably/     * Section 13.2, page 16: >  can be subject to later >    improvements.   s/later/further/?   * Section 13.2, page 16: > to small for others   s/to/too/     * Section 13.2, page 16: > in scenarios, where the   Please remove the comma.     * Section 13.2, page 16 >  While >    the DAT metric provides a stable sliding time interval to average the >    incoming packet loss and not giving the recent input too much >    influence, However, first experiments suggest that the algorithm >    tends to be less agile detecting major changes of link quality.   Please re-write as:     The DAT metric provides a stable sliding time interval to average the   incoming packet loss, not giving the recent input too much   influence. However, first experiments suggest that the algorithm   tends to be less agile detecting major changes of link quality.     * Appendix B, page 17: >    Operational experience of the OLSR project [OLSR.org] with these >    networks have revealed   s/have/has/     * Appendix D, page 18: >    In Section Section 10.2 DAT caluclates a fractional loss rate.   Rephrase to: "In Section 10.2 DAT calculates a fractional loss rate." (two changes)     * Appendix D, page 18: >    A hysteresis function   s/A/An/     * Appendix E, page 18: >    Table Table 2 contains a few examples for metric values and their >    meaning as a link speed:     Please remove one instance of "Table".     * Appendix E, page 19: > unintuitive   s/unintuitive/counter-intuitive/?       (To Gunter, I hope the deadline was written in American time J )   Regards, Will ----------------------------------------------------------------------------------- Shucheng LIU (Will), Ph.D. Senior Researcher & Standard Representative Huawei Technologies Co.,Ltd Email: liushucheng at huawei.com http://www.linkedin.com/in/shucheng -----------------------------------------------------------------------------------