--- 1/draft-ietf-manet-olsrv2-dat-metric-10.txt 2015-12-15 09:15:06.453862765 -0800 +++ 2/draft-ietf-manet-olsrv2-dat-metric-11.txt 2015-12-15 09:15:06.497863807 -0800 @@ -1,19 +1,19 @@ MANET H. Rogge Internet-Draft Fraunhofer FKIE Intended status: Experimental E. Baccelli -Expires: May 27, 2016 INRIA - November 24, 2015 +Expires: June 17, 2016 INRIA + December 15, 2015 Packet Sequence Number based directional airtime metric for OLSRv2 - draft-ietf-manet-olsrv2-dat-metric-10 + draft-ietf-manet-olsrv2-dat-metric-11 Abstract This document specifies an Directional Airtime (DAT) link metric for usage in OLSRv2. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. @@ -21,21 +21,21 @@ Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." - This Internet-Draft will expire on May 27, 2016. + This Internet-Draft will expire on June 17, 2016. Copyright Notice Copyright (c) 2015 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents @@ -48,91 +48,97 @@ Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 3. Applicability Statement . . . . . . . . . . . . . . . . . . . 4 4. Directional Airtime Metric Rationale . . . . . . . . . . . . 5 5. Metric Functioning & Overview . . . . . . . . . . . . . . . . 6 6. Protocol Constants . . . . . . . . . . . . . . . . . . . . . 7 7. Protocol Parameters . . . . . . . . . . . . . . . . . . . . . 8 7.1. Recommended Values . . . . . . . . . . . . . . . . . . . 8 - 8. Data Structures . . . . . . . . . . . . . . . . . . . . . . . 8 - 8.1. Initial Values . . . . . . . . . . . . . . . . . . . . . 9 + 8. Data Structures . . . . . . . . . . . . . . . . . . . . . . . 9 + 8.1. Initial Values . . . . . . . . . . . . . . . . . . . . . 10 9. Packets and Messages . . . . . . . . . . . . . . . . . . . . 10 9.1. Definitions . . . . . . . . . . . . . . . . . . . . . . . 10 9.2. Requirements for using DAT metric in OLSRv2 implementations . . . . . . . . . . . . . . . . . . . . . 10 9.3. Link Loss Data Gathering . . . . . . . . . . . . . . . . 11 - 9.4. HELLO Message Processing . . . . . . . . . . . . . . . . 11 + 9.4. HELLO Message Processing . . . . . . . . . . . . . . . . 12 10. Timer Event Handling . . . . . . . . . . . . . . . . . . . . 12 10.1. Packet Timeout Processing . . . . . . . . . . . . . . . 12 - 10.2. Metric Update . . . . . . . . . . . . . . . . . . . . . 12 + 10.2. Metric Update . . . . . . . . . . . . . . . . . . . . . 13 11. Security Considerations . . . . . . . . . . . . . . . . . . . 13 - 12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 14 - 13. References . . . . . . . . . . . . . . . . . . . . . . . . . 14 - 13.1. Normative References . . . . . . . . . . . . . . . . . . 14 - 13.2. Informative References . . . . . . . . . . . . . . . . . 15 + 12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 + 13. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 14 + 14. References . . . . . . . . . . . . . . . . . . . . . . . . . 15 + 14.1. Normative References . . . . . . . . . . . . . . . . . . 15 + 14.2. Informative References . . . . . . . . . . . . . . . . . 15 Appendix A. Future work . . . . . . . . . . . . . . . . . . . . 16 Appendix B. OLSR.org metric history . . . . . . . . . . . . . . 17 Appendix C. Linkspeed stabilization . . . . . . . . . . . . . . 18 Appendix D. Packet loss hysteresis . . . . . . . . . . . . . . . 18 - Appendix E. Example DAT values . . . . . . . . . . . . . . . . . 18 + Appendix E. Example DAT values . . . . . . . . . . . . . . . . . 19 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 19 1. Introduction One of the major shortcomings of Optimized Link State Routing (OLSR) [RFC3626] is the lack of a granular link cost metric between OLSR routers. Operational experience with OLSR networks gathered since its publication has revealed that wireless networks links can have highly variable and heterogeneous properties. This makes a hopcount metric insufficient for effective OLSR routing. Based on this experience, OLSRv2 [RFC7181] integrates the concept of link metrics directly into the core specification of the routing protocol. The OLSRv2 routing metric is an external process, it can be any kind of dimensionless additive cost function which reports to the OLSRv2 protocol. - Since 2004 the OLSR.org [OLSR.org] implementation of OLSR included an - Estimated Transmission Count (ETX) metric [MOBICOM04] as a - proprietary extension. While this metric is not perfect, it proved - to be sufficient for a long time for Community Mesh Networks - (Appendix B). But the increasing maximum data rate of IEEE 802.11 + Since 2004 the OLSR.org [OLSR.org] implementation of OLSR has + included an Estimated Transmission Count (ETX) metric [MOBICOM04] as + a proprietary extension. While this metric is not perfect, it proved + to be sufficient for a long time for Community Mesh Networks (see + Appendix B). But the increasing maximum data rate of IEEE 802.11 made the ETX metric less efficient than in the past, which is one reason to move to a different metric. This document describes a Directional Airtime routing metric for OLSRv2, a successor of the OLSR.org ETX-derived routing metric for OLSR. It takes both the loss rate and the link speed into account to provide a more accurate picture of the links within the network. - This experimental draft will allow OLSRv2 deployments with a metric - defined by the IETF Manet group. It enables easier interoperability - tests between implementations and will also deliver a useful baseline - to compare other metrics to. Appendix A contains a few possible - steps to improve the Directional Airtime Metric. + This specification allows OLSRv2 deployments with a metric defined by + the IETF MANET working group. It enables easier interoperability + tests between implementations and targets to deliver a useful + baseline to compare with, for experiments with this metric as well as + other metrics. Appendix A contains a few possible steps to improve + the Directional Airtime Metric. Coming experiments should also allow + to judge if the DAT metric can be useful for other IETF protocol, + both inside and out of the MANET working group. This could lead + either to moving this draft to Standard Track or to replace it with + an improved document. 2. Terminology The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119]. The terminology introduced in [RFC5444], [RFC7181] and [RFC6130], including the terms "packet", "message" and "TLV" are to be interpreted as described therein. Additionally, this document uses the following terminology and notational conventions: - DAT - Directional Airtime (Metric), the link metric described in + DAT - Directional Airtime (Metric), the link metric specified in this document, which is a directional variant of ETT. It does not take reverse path loss into account. QUEUE - a first in, first out queue of integers. QUEUE[TAIL] - the most recent element in the queue. add(QUEUE, value) - adds a new element to the TAIL of the queue. remove(QUEUE) - removes the HEAD element of the queue @@ -160,52 +165,52 @@ link. ETT - Estimated Travel Time, a link metric proportional to the amount of airtime needed to successfully transmit an IP packet over a link, not considering layer-2 overhead created by preamble, backoff time and queuing. 3. Applicability Statement 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. A dynamic rate selection algorithm selects the - unicast data rate independently for each neighbor. + [COMNET15]) in wireless IEEE 802.11 OLSRv2 [RFC7181] networks. These + networks employ link layer retransmission to increase the delivery + probability. A dynamic rate selection algorithm selects the unicast + data rate independently for each neighbor. 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). The metric works both for nodes which can send/receive [RFC5444] packet sequence numbers and those which do not have this capability. In the absence of such sequence numbers the metric calculates the packet loss based on [RFC6130] HELLO message timeouts. The metric must learn about the unicast data rate towards each one- hop neighbor from an external process, either by configuration or by - an external measurement process. This 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 (see [MOBICOM04]). + an external measurement process. This measurement could be done via + gathering cross-layer data from the operating system, via an external + daemon like DLEP [DLEP], or via indirect layer-3 measurements like + packet-pair (see [MOBICOM04]). 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 have a higher reception probability - than the slowest unicast transmission without retransmission. 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. + than the slowest unicast transmission without retransmission. For + example, with 802.11g, it might be necessary to increase the data- + rate of the multicast transmissions, e.g. set the multicast data-rate + to 6 MBit/s. The metric can only handle a certain range of packet loss and unicast data-rate. The maximum packet loss that can be encoded into the - metric a loss of 7 of 8 packets (87.5%), without link layer + metric is a loss of 7 of 8 packets (87.5%), without link layer retransmissions. The unicast data-rate that can be encoded by this metric can be between 1 kBit/s and 2 GBit/s. This metric has been designed for data-rates of 1 MBit/s and hundreds of MBit/s. 4. Directional Airtime Metric Rationale 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. @@ -217,35 +222,36 @@ o OLSRv2 [RFC7181] defines the link metric as directional costs between routers. o Not all link layer implementations use acknowledgement mechanisms. Most link layer implementations who do use them use less airtime and a more robust modulation for the acknowledgement than the data transmission, which makes it more likely for the data transmission to be disrupted compared to the acknowledgement. - o Incoming packet loss and linkspeed can be measured locally, + o Incoming packet loss and linkspeed can be measured locally, while symmetric link loss would need an additional signaling TLV in the [RFC6130] HELLO and would delay metric calculation by up to one HELLO interval. 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. The routing decision of most operation systems don't take packet size into account. Multiplying all link costs of a topology with the size of a data-plane packet would never change the Dijkstra result anyways. - The queue based packet loss estimator has been tested extensively in - the OLSR.org ETX implementation, see Appendix B. The output is the - average of the packet loss over a configured time period. + The queue based packet loss estimator specified in this document has + been tested extensively in the OLSR.org ETX implementation, see + Appendix B. The output is the average of the packet loss over a + configured time period. The metric normally measures the loss of a link by tracking the incoming [RFC5444] packet sequence numbers. Without these packet sequence numbers, the metric does calculate the loss of the link based of received and lost [RFC5444] HELLO messages. It uses the incoming HELLO interval time (or if not present, the validity time) to decide when a HELLO is lost. When a neighbor router resets, its packet sequence number might jump to a random value. The metric tries to detect jumps in the packet @@ -302,23 +308,22 @@ INTERVAL_TIME message TLV is present in the HELLO messages and when each RFC5444 packet contains an interface specific sequence number. It also adds a number of new data entries to be stored for each RFC6130 Link. 6. Protocol Constants This specification defines the following constants, which define the range of metric values that can be encoded by the DAT metric (see Table 1). They cannot be changed without making the metric outputs - incomparable and should only be changed for MANET's with a very slow - or very fast link layer. See Appendix D Appendix E for example - metric values. + incomparable and should only be changed for a MANET with very slow or + very fast link layer. See Appendix E for example metric values. DAT_MAXIMUM_LOSS - Fraction of the loss rate used in this routing metric. Loss rate will be between 0/DAT_MAXIMUM_LOSS and (DAT_MAXIMUM_LOSS-1)/DAT_MAXIMUM_LOSS. DAT_MINIMUM_BITRATE - Minimal bit-rate in Bit/s used by this routing metric. +---------------------+-------+ | Name | Value | @@ -350,23 +355,23 @@ DAT_SEQNO_RESTART_DETECTION - threshold in number of missing packets (based on received packet sequence numbers) at which point the router considers the neighbor has restarted. This parameter is only used for packet sequence number based loss estimation. This number MUST be larger than DAT_MAXIMUM_LOSS. 7.1. Recommended Values The proposed values of the protocol parameters are for Community Mesh - Networks, which mostly use immobile routers. Using this metric for - mobile networks might require shorter DAT_REFRESH_INTERVAL and/or - DAT_MEMORY_LENGTH. + Networks, which mostly use routers that are not mobile. Using this + metric for mobile networks might require shorter DAT_REFRESH_INTERVAL + and/or DAT_MEMORY_LENGTH. DAT_MEMORY_LENGTH := 64 DAT_REFRESH_INTERVAL := 1 DAT_HELLO_TIMEOUT_FACTOR := 1.2 DAT_SEQNO_RESTART_DETECTION := 256 8. Data Structures @@ -402,22 +407,22 @@ received from this link. Methods to obtain the value of L_DAT_rx_bitrate are out of the scope of this specification. Such methods may include static configuration via a configuration file or dynamic measurement through mechanisms described in a separate specification (e.g. [DLEP]). Any Link tuple with L_status = HEARD or L_status = SYMMETRIC MUST have a specified value of L_DAT_rx_bitrate if it is to be used by this routing metric. The incoming bitrate value should be stabilized by a hysteresis - filter to improve the stability of this metric. See Appendix B - Appendix C for an example. + filter to improve the stability of this metric. See Appendix C for + an example. 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]) 8.1. Initial Values 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: @@ -596,21 +601,21 @@ 6. remove(L_DAT_total) 7. add(L_DAT_total, 0) 8. remove(L_DAT_received) 9. add(L_DAT_received, 0) The calculated L_in_metric value should be stabilized by a hysteresis - function. See Appendix C Appendix D for an example. + function. See Appendix D for an example. 11. Security Considerations Artificial manipulation of metrics values can drastically alter network performance. In particular, advertising a higher L_in_metric value may decrease the amount of incoming traffic, while advertising lower L_in_metric may increase the amount of incoming traffic. By artificially increasing or decreasing the L_in_metric values it advertises, a rogue router may thus attract or repulse data traffic. A rogue router may then potentially degrade data throughput by not @@ -618,98 +623,103 @@ loops or bad links. It might also attract traffic for "Man in the Middle" attacks or traffic analysis. An attacker might also inject packets with incorrect packet level sequence numbers, pretending to be somebody else. This attack can be prevented by the true originator of the RFC5444 packets by adding a [RFC7182] ICV Packet TLV and TIMESTAMP Packet TLV to each packet. This allows the receiver to drop all incoming packets which have a forged packet source, both packets generated by the attacker or replayed packets. The security mechanism described in [RFC7183] does - not protect the additional sequence number of the DAT metric because - it does only sign the RFC5444 messages, not the RFC5444 packet - header. + not protect the sequence number used by the DAT metric because it + does only sign the RFC5444 messages, not the RFC5444 packet header + (which contains the RFC5444 packet sequence number). - Protection against "Man in the Middle" attacks are out of scope of - this document. + Protection mechanisms against "Man in the Middle" attacks are + nevertheless out of scope of this document. -12. Acknowledgements +12. IANA Considerations + + This document has no actions for IANA. + +13. Acknowledgements The authors would like to acknowledge the network administrators from Freifunk Berlin [FREIFUNK] and Funkfeuer Vienna [FUNKFEUER] for endless hours of testing and suggestions to improve the quality of the original ETX metric for the OLSR.org routing daemon. This effort/activity is supported by the European Community Framework Program 7 within the Future Internet Research and Experimentation Initiative (FIRE), Community Networks Testbed for the Future Internet ([CONFINE]), contract FP7-288535. The authors would like to gratefully acknowledge the following people for intense technical discussions, early reviews and comments on the specification and its components (listed alphabetically): Teco Boot (Infinity Networks), Juliusz Chroboczek (PPS, University of Paris 7), Thomas Clausen, Christopher Dearlove (BAE Systems Advanced Technology Centre), Ulrich Herberg (Fujitsu Laboratories of America), Markus Kittenberger (Funkfeuer Vienna), Joseph Macker (Naval Research - Laboratory), Fabian Nack and Stan Ratliff (Cisco Systems). + Laboratory), Fabian Nack (Freie Universitaet Berlin) and Stan Ratliff + (Cisco Systems). -13. References +14. References -13.1. Normative References +14.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", RFC 2119, BCP 14, March 1997. [RFC5444] Clausen, T., Dearlove, C., Dean, J., and C. Adjih, "Generalized Mobile Ad Hoc Network (MANET) Packet/Message Format", RFC 5444, February 2009. [RFC5497] Clausen, T. and C. Dearlove, "Representing Multi-Value Time in Mobile Ad Hoc Networks (MANETs)", RFC 5497, March 2009. [RFC6130] Clausen, T., Dearlove, C., and J. Dean, "Mobile Ad Hoc Network (MANET) Neighborhood Discovery Protocol (NHDP)", RFC 6130, April 2011. [RFC7181] Clausen, T., Jacquet, P., and C. Dearlove, "The Optimized Link State Routing Protocol version 2", RFC 7181, April 2014. -13.2. Informative References +14.2. Informative References [RFC3626] Clausen, T. and P. Jacquet, "Optimized Link State Routing Protocol", RFC 3626, October 2003. [RFC7182] Ulrich, U., Clausen, T., and C. Dearlove, "Integrity Check Value and Timestamp TLV Definitions for Mobile Ad Hoc Networks (MANETs)", RFC 7182, April 2014. [RFC7183] Ulrich, U., Dearlove, C., and T. Clausen, "Integrity Protection for the Neighborhood Discovery Protocol (NHDP) and Optimized Link State Routing Protocol Version 2 (OLSRv2)", RFC 7183, April 2014. - [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, + [COMNET15] + Barz, C., Fuchs, C., Kirchhoff, J., Niewiejska, J., and H. + Rogge, "OLSRv2 for Community Networks: Using Directional + Airtime Metric with external radios", Elsevier Computer + Networks 2015 , September 2015, . [CONFINE] "Community Networks Testbed for the Future Internet (CONFINE)", 2015, . [DLEP] Ratliff, S., Berry, B., Harrison, G., Jury, S., and D. Satterwhite, "Dynamic Link Exchange Protocol (DLEP)", - draft-ietf-manet-dlep-17 , March 2013. + draft-ietf-manet-dlep-17 , October 2015. [BATMAN] Neumann, A., Aichele, C., Lindner, M., and S. Wunderlich, "Better Approach To Mobile Ad-hoc Networking (B.A.T.M.A.N.)", draft-wunderlich-openmesh-manet- routing-00 , April 2008. [MOBICOM03] De Couto, D., Aguayo, D., Bicket, J., and R. Morris, "A High-Throughput Path Metric for Multi-Hop Wireless Routing", Proceedings of the MOBICOM Conference , 2003. @@ -726,52 +736,51 @@ [FREIFUNK] "Freifunk Wireless Community Networks", 2015, . [FUNKFEUER] "Austria Wireless Community Network", 2015, . Appendix A. Future work - As the DAT metric proved to work reasonable well for non- or slow- - moving ad hoc networks [olsrv2_paper], it should be considered as a - solid first step on a way to better MANET metrics. There are - multiple parts of the DAT metric that need to be reviewed again in - the context of real world deployments and can be subject to later - improvements. + As the DAT metric proved to work reasonably well for non- or slow- + moving ad hoc networks [COMNET15], it should be considered as a solid + first step on a way to better MANET metrics. There are multiple + parts of the DAT metric that need to be reviewed again in the context + of real world deployments and can be subject to later improvements. The easiest part of the DAT metric to change and test would be the timings parameters. A 1 minute interval for packet loss statistics might be a good compromise for some MANETs, but could easily be too large or to small for others. More data is needed to verify or improve the current parameter selection. The DAT metric considers only the multicast RFC5444 packet loss for estimating the link loss, but it would be good to integrate unicast data loss into the loss estimation. This information could be provided directly from the link layer. This could increase the accuracy of the loss rate estimation in scenarios, where the assumptions regarding the ratio of multicast vs. unicast loss do not hold. The packet loss averaging algorithm could also be improved. 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. This - makes it less suited for mobile networks. A more agile algorithm is - needed for detecting major changes while filtering out random - fluctuations regarding frame loss. However, the current "quere of - counters" algorithm suggested for DAT outperforms the binary queue - algorithm and the exponential aging algorithms used for the ETX - metric in the OLSR [RFC3626] codebase of Olsr.org. + influence, first experiments suggest that the algorithm tends to be + less agile in detecting major changes of link quality. This makes it + less suited for mobile networks. A more agile algorithm is needed + for detecting major changes while filtering out random fluctuations + regarding frame loss. However, the current "queue of counters" + algorithm suggested for DAT outperforms the binary queue algorithm + and the exponential aging algorithms used for the ETX metric in the + OLSR [RFC3626] codebase of Olsr.org. Appendix B. OLSR.org metric history The Funkfeuer [FUNKFEUER] and Freifunk networks [FREIFUNK] are OLSR- based [RFC3626] or B.A.T.M.A.N. [BATMAN] based wireless community networks with hundreds of routers in permanent operation. The Vienna Funkfeuer network in Austria, for instance, consists of 400 routers covering the whole city of Vienna and beyond, spanning roughly 40km in diameter. It has been in operation since 2003 and supplies its users with Internet access. A particularity of the Vienna Funkfeuer @@ -788,70 +797,72 @@ been in operational use in these networks for several years. The ETX metric of a link is the estimated number of transmissions required to successfully send a packet (each packet equal to or smaller than MTU) over that link, until a link layer acknowledgement is received. The ETX metric is additive, i.e., the ETX metric of a path is the sum of the ETX metrics for each link on this path. While the ETX metric delivers a reasonable performance, it doesn't handle well networks with heterogeneous links that have different - bitrates. Since every wireless link, when using ETX metric, is - characterized only by its packet loss ratio, the ETX metric prefers - long-ranged links with low bitrate (with low loss ratios) over short- - ranged links with high bitrate (with higher but reasonable loss - ratios). Such conditions, when they occur, can degrade the - performance of a network considerably by not taking advantage of - higher capacity links. + bitrates. When using ETX metric, since every wireless link is + characterized only by its packet loss ratio, long-ranged links with + low bitrate (with low loss ratios) are preferred over short-ranged + links with high bitrate (with higher but reasonable loss ratios). + Such conditions, when they occur, can degrade the performance of a + network considerably, by not taking advantage of higher capacity + links. Because of this the OLSR.org project has implemented the Directional Airtime Metric for OLSRv2, which has been inspired by the Estimated Travel Time (ETT) metric [MOBICOM04]. This metric uses an unidirectional packet loss, but also takes the bitrate into account to create a more accurate description of the relative costs or capabilities of OLSRv2 links. Appendix C. Linkspeed stabilization - The DAT metric describes how to generate a reasonable stable packet - loss value from incoming packet reception/loss events, the source of - the linkspeed used in this document is considered an external - process. + The DAT metric specifies how to generate a reasonably stable packet + loss rate value based on incoming packet reception/loss events, but + the source of the linkspeed used in this document is considered an + external process. In the presence of a layer-2 technology with variable linkspeed it is likely that the raw linkspeed will be fluctuating too fast to be useful for the DAT metric. The amount of stabilization necessary for the linkspeed depends on the implementation of the mac-layer, especially the rate control algorithm. Experiments with the Linux 802.11 wifi stack have shown that a simple Median filter over a series of raw linkspeed measurements can smooth the calculated value without introducing intermediate linkspeed - values you would get by using averaging or an exponential weighted + values one would obtain by using averaging or an exponential weighted moving average. Appendix D. Packet loss hysteresis - While the DAT metric use a sliding window to calculate a reasonable + While the DAT metric uses a sliding window to compute a reasonably stable frame loss, the implementation might choose to integrate an - additional hysteresis to prevent the metric flapping between two - values. + additional hysteresis to prevent undesirable oscillations between two + values (i.e. metric flapping). - In Section Section 10.2 DAT caluclates a fractional loss rate. The + In Section Section 10.2 DAT calculates a fractional loss rate. The fraction of 'loss := sum_total / sum_received' may result in minor fluctuations in the advertised L_in_metric due to minimal changes in - sum_total or sum_received which can cause undesirable protocol churn. + sum_total or sum_received, which can cause undesirable protocol + churn. A hysteresis function applied to the fraction could reduce the amount - of changes in the loss rate and help to stabilize the metric output. + of changes in the loss rate and help to further stabilize the metric + output. Appendix E. Example DAT values The DAT metric value can be expressed in terms of link speed (bit/s) or used airtime (s). When using the default protocol constants (see Section 6), DAT encodes link speeds between 119 bit/s and 2 Gbit/s. Table Table 2 contains a few examples for metric values and their meaning as a link speed: @@ -861,24 +872,24 @@ | MINIMUM_METRIC (1) | 2 Gbit/s | | | | | MAXIMUM_METRIC (16776960) | 119 bit/s | | | | | 2000 | 1 Mbit/s | +---------------------------+-----------+ Table 2: DAT link cost examples A path metric value could also be expressed as a link speed, but this - would be unintuitive and difficult to understand. An easier way to - transform a path metric value into a textual representation is to - divide it by the hopcount of the path and express the path cost as - average link speed together with the hopcount (see Table 3). + would be less intuitive. An easier way to transform a path metric + value into a textual representation is to divide it by the hopcount + of the path and express the path cost as average link speed together + with the hopcount (see Table 3). +---------+------+---------------+ | Metric | hops | average bit/s | +---------+------+---------------+ | 4 | 2 | 1 Gbit/s | | | | | | 4000000 | 6 | 3 kbit/s | +---------+------+---------------+ Table 3: DAT link cost examples