Packet Sequence Number based directional ETT Metric for OLSRv2

The Funkfeuer and Freifunk networks are OLSR-based wireless community networks with hundreds of routers in permanent operation. The Vienna Funkfeuer network in Austria, for instance, consists of 400 routers (around 600 routes) 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. The particularity of the Vienna Funkfeuer network is that it manages to provide Internet access through a city wide, large scale Wi-Fi mesh cloud, with just a single uplink. Operational experience with such a network has revealed that the use of hop-count as routing metric leads to unsatisfactory network performance. Experiments with the ETX metric were therefore undertaken in parallel in the Berlin Freifunk network as well as in the Vienna Funkfeuer network, and found satisfactory, i.e. sufficiently easy to implement and providing sufficiently good performance. This metric has now been in operational use in these networks for more than 2 years. This ETX metric of a link is the estimated number of transmissions required to successfully send a packet (each packet smaller than MTU) over that link, until an 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 networks with heterogeneous links that have different linkspeed well. Every link is only measured by its packet loss, the metric prefers long and slow links over short and fast links, which can degrade the performance of a network considerably. Based on the ETX metric this document describes an Estimated Travel Time (ETT) metric for the usage with the Optimized Link State Routing Protocol Version 2, which also takes the link-speed into account. More precisely, this document specifies the processing for NHDP in order to establish the ETT metric value for a link.

The key words 'MUST', 'MUST NOT', 'REQUIRED', 'SHALL', 'SHALL NOT','SHOULD', 'SHOULD NOT', 'RECOMMENDED', 'NOT RECOMMENDED', 'MAY', and 'OPTIONAL' in this document are to be interpreted as described in. The terminology introduced in , and , including the terms "packet", "message", "Address Block", "TLV Block","TLV", "address", "address prefix", and "address object" are to be interpreted as described therein. Additionally, this document uses the following terminology and notational conventions: - a last in, first out queue of numbers. - the most recent entry added to the queue. - an operation which removes the oldest entry in the queue and places a new entry at the head of the queue. - an operation which returns the sum of all elements in a LIFO. - an operation which returns the positive distance between two elements of the circular sequence number space defined in Section 5.1 of . Its value is either (new - old) if this result is positive, or else its value is (new - old + 65536). - a constant for -1.

The mechanism specified in this document is based on the ETX metric used daily by hundreds of routers in the Funkfeuer network , as well as in similar OLSR-based wireless community networks which use the OLSR.org code base, such as , , , and . Operational experience suggests that this mechanism is viable in (at least) these kinds of networks. The ETT metric of the new OLSRv2 implementation of Olsr.org is a refinement of the ETX metric, providing a directional metric that takes into account the speed of the link to compute the link cost. The ETX metric value of a link is established by measuring the rate of successful exchange of OLSRv2 control packets over that link, which use the format defined in . ETX metric computation is thus based only on layer 3 signaling, and is therefore independent from underlying link layer technologies. Moreover, ETX metric computation does not require inspection of data traffic. The ETT metric value can only be computed if the outgoing linkspeed to each one-hop neighbor is known to the routing daemon, either by measurement or from a configuration file.

The metric specified in this document is based on the Estimated Travel Time (ETT) metric published in . The paper describes the metric as 'ETX divided by link-speed', but introduce a 'packet size' variable in the formula representation, describing the metric as 'ETX times packet-size divided by link-speed'. This document specifies the use of a variant of the ETT metric without any packet-size variable integrated into the link costs. There are two reasons for this decision: The original ETT metric was designed for a DSR derived source-routed protocol. Typical linkstate protocols like OSLRv2 do not process each data-plane packet on its own, which makes it difficult to integrate the size of the data-plane packets into the routing metric. The original ETT metric assumes that the airtime spend on a link is proportional to the size of the packet transmitted over the link. Multiplying all topology edge costs 'ETX divided by link-speed' with the size of a packet would not change the result of the shortest path calculation, independently of the packet size. This means both description of ETT should result in the same next-hop decision. In addition to this, the metric described in this document is directional, it does calculate the ETX value only based on the loss in one direction.

Router A computes the ETX value of its link to router B by continuously estimating the loss rates for incoming traffic over this link. The ETT metric is calculated as the ETX metric, divided by a normalized link speed of the incoming unicast traffic and use this value as L_in_metric for NHDP (as defined in section 8.1. of NHDP).

This specification extends the Link Set per Interface Information Base, as defined in , with the following additional elements for each link tuple: L_METRIC_received_lifo is a LIFO queue with ETT_MEMORY_LENGTH integer elements. Each entry contains the number of successfully received packets within an interval of ETT_METRIC_INTERVAL. L_METRIC_total_lifo is a LIFO queue with ETT_MEMORY_LENGTH integer elements. Each entry contains the estimated number of packets transmitted by the neighbor, based on the received packet sequence numbers within an interval of ETT_METRIC_INTERVAL. L_METRIC_last_pkt_seqno is the last received packet sequence number received from this link. L_METRIC_hello_time is the time when the next hello will be expected. This is used to detect missing hellos by timeout . L_METRIC_hello_interval is the interval between two hello messages of the links neighbor as signaled by the INTERVAL_TIME TLV. L_METRIC_lost_hello_messages is the estimated number of lost hello messages from this neighbor, based on the value of the hello interval. L_METRIC_rx_bitrate is the current linkspeed of incoming unicast traffic for this neighbor. Methods to obtain the value of L_METRIC_rx_bitrate are out of scope for this specification. Such methods may be static autoconfiguration via a configuration file, or dynamic measurement through mechanisms described in a separate specification. Any Link tuple with L_status = HEARD or L_status = SYMMETRIC MUST have a specified value of L_METRIC_rx_bitrate if it is to be used by this routing metric.

When generating a new tuple in the Link Set, the values of the elements specified above are set as follows: L_METRIC_received_lifo := 0, ..., 0. L_METRIC_total_lifo := 0, ..., 0. L_METRIC_last_pkt_seqno := UNDEFINED. L_METRIC_hello_time := EXPIRED. L_METRIC_hello_interval := UNDEFINED. L_METRIC_lost_hello_messages := 0

This specification uses the parameters defined in . This specification defines the following additional parameters: - ETT algorithm memory length in seconds. All received and lost packets within this time period are used to calculate the ETT cost of the link. - interval in seconds between two metric recalculations as described in . - threshold in number of missing packets (based on received packet sequence numbers) at which point the router considers the neighbor has restarted. - timeout factor for HELLO interval at which point a HELLO is definitely considered lost. The value must be a floating point number larger than 1.0. - Maximum ETX value used in this routing metric. - Maximum link speed in bits/s of used in routing metric. - Minimum link speed in bits/s used in this metric. - metric value for ETX 1.0 and ETT_WORST_LINKSPEED linkspeed.

Generated packets and messages use the format defined in . The present specification adds the following constraints: A packet MUST contain a packet sequence number as defined in . This sequence number MUST be interface specific and must be incremented by 1 for each packet.

Each incoming packet is processed as defined in OLSRv2 . Furthermore, the following additional processing MUST be carried out after the packet has been processed on the link set tuple corresponding to the source of the packet: If L_METRIC_last_pkt_seqno = UNDEFINED, then: L_METRIC_received_lifo[current] := 1. L_METRIC_total_lifo[current] := 1. Otherwise: L_METRIC_received_lifo[current] := L_METRIC_received_lifo[current] + 1. diff := seq_diff(seqno, L_METRIC_last_pkt_seqno). If diff > ETT_SEQNO_RESTART_DETECTION, then: diff := 1. L_METRIC_total_lifo[current] := L_METRIC_total_lifo[current] + diff. L_METRIC_last_pkt_seqno := seqno.

When L_METRIC_hello_time has timed out, the following step MUST be done: L_METRIC_lost_hellos := L_METRIC_lost_hellos + 1. L_METRIC_hello_time := L_METRIC_hello_time + L_METRIC_hello_interval.

This metric stores the number of received packets per link from a neighbor and use the packet sequence number to calculate the total number of sent packets from the neighbor. The total number of packets divided by the number of received packets is used as an ETX value for the link. If connectivity of link with a node is lost, no packets are received anymore and neither the received nor total value of packets will change. To prevent a constant result in this case, the metric stores the number of HELLO message interval timeouts since the last received packet from a neighbor and uses this value to reduce the received packet count proportionally to the length of the metric memory ETT_MEMORY_LENGTH. Once every ETT_METRIC_INTERVAL, this protocol MUST recalculate all L_in_metric values in all Link Set entries: sum_received := sum(L_METRIC_total_lifo). sum_total := sum(L_METRIC_received_lifo). If L_METRIC_hello_interval != UNDEFINED and L_METRIC_lost_hellos > 0, then: penalty := L_METRIC_hello_interval * L_METRIC_lost_hellos / ETT_MEMORY_LENGTH. sum_received := sum_received * ( 1 - penalty ); If sum_received < 1, then: L_METRIC_r_etx := UNDEFINED. L_in_metric := MAXIMUM_METRIC. Otherwise: etx := sum_total / sum_received. If etx > ETT_WORST_ETX, then: etx := ETT_WORST_ETX. speed := L_METRIC_rx_bitrate. If speed > ETT_BEST_LINKSPEED, then: speed := ETT_BEST_LINKSPEED. If speed < ETT_WORST_LINKSPEED, then: speed := ETT_WORST_LINKSPEED. L_in_metric := ETT_NO_LOSS_METRIC_VALUE * etx / (speed / ETT_WORST_LINKSPEED). push(L_METRIC_total_lifo, 0) push(L_METRIC_received_lifo, 0)

This section proposes values for various parameters used in this specification. ETT_MEMORY_LENGTH := 64 seconds ETT_METRIC_INTERVAL := 1 second ETT_SEQNO_RESTART_DETECTION := 256 ETT_HELLO_TIMEOUT_FACTOR := 1.5 ETT_WORST_ETX := 16 ETT_BEST_LINKSPEED := 256 MBit/s ETT_WORST_LINKSPEED := 1 MBit/s ETT_NO_LOSS_METRIC_VALUE := 4096 With this values this ETT metric will go from 16 (256+ MBit/s, ETX 1.0) over 4096 (1 MBit/s, ETX 1.0) to a maximum of 65536 (1 MBit/s, ETX 16.0).

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 forwarding data as it should or redirecting traffic into routing loops or bad links.

The authors would like to acknowledge the network administrators from Freifunk Berlin and Funkfeuer Vienna 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 Programme 7 within the Future Internet Research and Experimentation Initiative (FIRE), Community Networks Testbed for the Future Internet (), 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), Thomas Clausen (LIX, Ecole Polytechnique), Christopher Dearlove (BAE Systems Advanced Technology Centre), Ulrich Herberg (Fujitsu Laboratories of America), Markus Kittenberger (Funkfeuer Vienna).