RFC 4907
Architectural Implications of Link Indications
Architectural Implications of Link Indications 🦋
okay bestie, this is RFC 4907 🎀 and it's giving informational energy. It was put out by the Network Working Group in June 2007 and it's Category: Informational, which means it shares info and doesn't specify any Internet standard ✨. The authors are B. Aboba, Ed. (the "Ed." means he was the editor who wrangled everyone's input 💅) from the Internet Architecture Board (IAB). Its header has no Obsoletes or Updates line, so it doesn't list any RFCs it replaces or changes 🌸.
Status of This Memo 💌
This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited.
Copyright Notice ©️
Copyright (C) The IETF Trust (2007).
Abstract 🧚
A link indication is basically the link layer spilling the tea to higher layers about what's going on with the link 🫖. This doc explains the role of link indications in the Internet architecture. Using them judiciously can give you performance perks, but using them inappropriately can wreck both robustness and performance 😭. The doc sums up current proposals, digs into the architectural issues, and gives examples of appropriate and inappropriate uses of link indications.
Table of Contents 📚
1. Introduction ....................................................3
1.1. Requirements ...............................................3
1.2. Terminology ................................................3
1.3. Overview ...................................................5
1.4. Layered Indication Model ...................................7
2. Architectural Considerations ...................................14
2.1. Model Validation ..........................................15
2.2. Clear Definitions .........................................16
2.3. Robustness ................................................17
2.4. Congestion Control ........................................20
2.5. Effectiveness .............................................21
2.6. Interoperability ..........................................22
2.7. Race Conditions ...........................................22
2.8. Layer Compression .........................................25
2.9. Transport of Link Indications .............................26
3. Future Work ....................................................27
4. Security Considerations ........................................28
4.1. Spoofing ..................................................28
4.2. Indication Validation .....................................29
4.3. Denial of Service .........................................30
5. References .....................................................31
5.1. Normative References ......................................31
5.2. Informative References ....................................31
6. Acknowledgments ................................................40
Appendix A. Literature Review .....................................41
A.1. Link Layer .................................................41
A.2. Internet Layer .............................................53
A.3. Transport Layer ............................................55
A.4. Application Layer ..........................................60
Appendix B. IAB Members ...........................................601. Introduction ✨
bestie, here's the big picture 🌈. A link indication is info the link layer hands up to higher layers about the state of the link. Judicious use can give performance benefits, but inappropriate use can degrade both robustness and performance 🙈.
This doc sums up how people currently understand the role of link indications in the Internet architecture, and it gives advice to document authors on using them well across the Internet, transport, and application layers 💖.
Section 1 describes the history of link indication usage within the Internet architecture and provides a model for using link indications. Section 2 describes the architectural considerations and provides advice to document authors. Section 3 describes recommendations and future work. Appendix A summarizes the literature on link indications, focusing largely on wireless Local Area Networks (WLANs) 📡.
1.1. Requirements 🫶
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].
1.2. Terminology 📖
okay, the glossary moment 🧠. These are the terms the rest of the doc leans on, so let's get them down pat 💅.
Access Point (AP): a station that gives access to the fixed network (for example, an 802.11 Distribution System) through the wireless medium (WM) for its associated stations 📶.
Asymmetric: a link is asymmetric when its transmission characteristics differ depending on the relative position or design of the transmitter and receiver. For instance, one transmitter might have way more range than another on the same medium 🔊. Lowkey unfair, but it happens.
Beacon: a control message a station (usually an Access Point) broadcasts to tell nearby stations it's still around, possibly with extra status or configuration info 🔆.
Binding Update (BU): a message saying what a mobile node's current mobility binding is, especially its Care-of Address 🏠.
Correspondent Node: a peer node that a mobile node is communicating with. The correspondent node can be mobile or stationary 🤝.
Link: a communication facility or medium that nodes can communicate over at the link layer, meaning the layer immediately below the Internet Protocol (IP) 🔗.
Link Down: an event from the link layer that signals a state change where the interface is no longer able to communicate data frames. Brief periods of high frame loss don't count, so don't freak out over a little turbulence 😤.
Link Indication: information the link layer gives higher layers about the state of the link ✨.
Link Layer: the conceptual layer of control or processing logic that keeps control of the link. It's the interface between higher-layer logic and the link, and it sits immediately below IP 🧱.
Link Up: an event from the link layer that signals a state change where the interface becomes able to communicate data frames 🟢.
Maximum Segment Size (MSS): the maximum payload size available to the transport layer 📦.
Maximum Transmission Unit (MTU): the size in octets of the largest IP packet, including the IP header and payload, that can be sent on a link or path 📏.
Mobile Node: a node that can switch its point of attachment from one link to another and still be reachable through its home address 🧳.
Operable Address: a static or dynamically assigned address that hasn't been relinquished and hasn't expired ⏳.
Point of Attachment: the endpoint on the link that the host is currently connected to 📍.
Routable Address: any IP address that routers will forward packets for. This includes private addresses from "Address Allocation for Private Internets" [RFC1918] 🗺️.
Station (STA): any device that has an IEEE 802.11 conformant medium access control (MAC) and physical layer (PHY) interface to the wireless medium (WM) 📱.
Strong End System Model: this one puts the host/router distinction front and center and tends to model a multi-homed host as a set of logical hosts inside the same physical host 🏰. Addresses refer to an interface, not to the host they attach to. So packets sent out an outgoing interface have a source address configured on that interface, and incoming packets whose destination address doesn't match the physical interface they came in on are silently discarded 🤫.
Weak End System Model: in this model, addresses refer to a host 🫂. Packets sent out an outgoing interface don't necessarily need a source address configured on that interface, and incoming packets whose destination address doesn't match the physical interface they came in on are accepted 🌊.
to be continued... 1.3 Overview is up next, bestie 🦋💜
1.3. Overview ✨
okay so link indications have a long history in the Internet architecture 🦋 Back in the ARPANET days, if you tried sending to a host that was offline, the link layer protocol gave you a "Destination Dead" indication, described in "Fault Isolation and Recovery" [RFC816]. 🌸 The ARPANET packet radio experiment [PRNET] counted frame loss in its routing metrics, which was basically the ancestor of newer link-aware metrics like Expected Transmission Count (ETX), described in "A High-Throughput Path Metric for Multi-Hop Wireless Routing" [ETX]. Iconic behavior, honestly 💅
"Routing Information Protocol" [RFC1058] defined RIP, which is descended from the Xerox Network Systems (XNS) Routing Information Protocol 🧚 "The OSPF Specification" [RFC1131] defined Open Shortest Path First, which uses Link State Advertisements (LSAs) to flood link status information within an OSPF area. [RFC2328] defines version 2 of OSPF. These routing protocols can use "Link Up" and "Link Down" indications from links that provide them, but they can also detect link loss by noticing when routing packets stop arriving. As noted in "Requirements for IP Version 4 Routers" [RFC1812]:
It is crucial that routers have workable mechanisms for determining that their network connections are functioning properly. Failure to detect link loss, or failure to take the proper actions when a problem is detected, can lead to black holes.
People have also tried defining link indications beyond "Link Up" and "Link Down" 🌈 "Dynamically Switched Link Control Protocol" [RFC1307] is an experimental protocol for controlling links, with "Down", "Coming Up", "Up", "Going Down", "Bring Down", and "Bring Up" states. Very dramatic, very kind of a lot 💀
"A Generalized Model for Link Layer Triggers" [GenTrig] defines "generic triggers", including "Link Up", "Link Down", "Link Going Down", "Link Going Up", "Link Quality Crosses Threshold", "Trigger Rollback", and "Better Signal Quality AP Available" 🍓 IEEE 802.21 [IEEE-802.21] defines a Media Independent Handover Event Service (MIH-ES) that reports events about link characteristics, link status, and link quality. Its events include "Link Down", "Link Up", "Link Going Down", "Link Signal Strength", and "Link Signal/Noise Ratio" ✨
Under ideal conditions, links in the "up" state have low frame loss in both directions and are immediately ready to send and receive data frames. Links in the "down" state are unsuitable for sending and receiving data frames in either direction. Simple enough, right? 🫶
Unfortunately, links are not always ideal 😭 Wired links may fail in half-duplex mode, or get partially impaired and show intermediate loss rates. Wireless links may be asymmetric, drop frames intermittently, or have throughput that changes rapidly due to interference or signal fading. In both wired and wireless links, the link state can rapidly flap between "up" and "down" 🙈 This real-world chaos makes it hard to integrate link indications with the Internet, transport, and application layers. Not me being stressed about it 💜
1.4. Layered Indication Model 🎀
A layered indication model is shown in Figure 1. It includes both internally generated link indications (such as link state and rate) and indications from external interactions, such as path change detection. In this model, the link layer is assumed to provide indications to higher layers primarily as abstract indications that are link-technology agnostic. Abstraction queen behavior 👑
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Application | |
Layer | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
^ ^ ^
! ! !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-!-+-+-!-+-!-+-+-+-+
| ! ! ! |
| ! ^ ^ |
| Connection Management ! ! Teardown |
Transport | ! ! |
Layer +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-!-+-+-!-+-+-+-+-+-+
| ! ! |
| ! ! |
| ^ ! |
| Transport Parameter Estimation ! |
|(MSS, RTT, RTO, cwnd, bw, ssthresh)! |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-!-+-+-+-+-+-+
^ ^ ^ ^ ^ !
! ! ! ! ! !
+-!-+-!-+-+-+-+-+-!-+-+-+-!-+-!-+-+-!-+-+-+-+-+-+
| ! ! Incoming !MIP ! ! ! |
| ! ! Interface !BU ! ! ! |
| ! ! Change !Receipt! ! ! |
| ! ^ ^ ^ ! ^ |
Internet | ! ! Mobility ! ! ! ! |
Layer +-!-+-!-+-+-+-+-+-!-+-+-+-!-+-!-+-+-!-+-+-+-+-+-+
| ! ! Outgoing ! Path ! ! ! |
| ! ! Interface ! Change! ! ! |
| ^ ^ Change ^ ^ ! ^ |
| ! ! ! ! |
| ! Routing ! ! ! |
+-!-+-+-+-+-+-+-+-+-+-+-+-!-+-!-+-+-!-+-+-+-+-+-+
| ! ! v ! IP |
| ! ! Path ! Address |
| ! IP Configuration ^ Info ^ Config/ |
| ! ! Cache Changes |
+-!-+-+-+-+-+-+-+-+-+-+-+-!-+-+-+-+-+-+-+-+-+-+-+
! !
! !
+-!-+-+-+-+-+-+-+-+-+-+-+-!-+-+-+-+-+-+-+-+-+-+-+
| ! ! |
Link | ^ ^ |
Layer | Rate, FER, Link |
| Delay Up/Down |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 1. Layered Indication Model1.4.1. Internet Layer 🌷
One of the jobs of the Internet layer is to shield higher layers from the specifics of link behavior. So the Internet layer validates and filters link indications, and selects outgoing and incoming interfaces based on routing metrics. It's the bouncer, but make it aesthetic 🧚
The Internet layer builds its routing table from information available on local interfaces, and potentially also from information provided by routers. This means the local routing table can reflect link conditions on both local and remote links. For example, prefixes to be added or removed from the routing table may be determined from Dynamic Host Configuration Protocol (DHCP) [RFC2131][RFC3315], Router Advertisements [RFC1256][RFC2461], redirect messages, or route updates that include information on the state of links multiple hops away. Main character energy across the whole network 💖
As described in "Packetization Layer Path MTU Discovery" [RFC4821], the Internet layer may maintain a path information cache, which lets Path MTU information be shared between concurrent or later connections. The shared cache is accessed and updated by packetization protocols that implement packetization layer Path MTU Discovery 🍓
The Internet layer also uses link indications to optimize parts of Internet Protocol (IP) configuration and mobility 🦋 After receiving a "Link Up" indication, hosts validate potential IP configurations by Detecting Network Attachment (DNA) [RFC4436]. Once the IP configuration is confirmed, it may turn out that an address change has occurred. However, "Link Up" indications do not necessarily result in a change to Internet layer configuration. Plot twist 🙃
In "Detecting Network Attachment in IPv4" [RFC4436], after receiving a "Link Up" indication, potential IP configurations are validated using a bidirectional reachability test. In "Detecting Network Attachment in IPv6 Networks (DNAv6)" [DNAv6], IP configuration is validated using reachability detection and Router Solicitation/Advertisement 🔥
The routing sub-layer may use link indications to respond more quickly to changes in link state and effective throughput. Link rate is often used when computing routing metrics. However, in wired networks the transmission rate may be negotiated in order to enhance energy efficiency [EfficientEthernet]. In wireless networks, the negotiated rate and Frame Error Rate (FER) may change with link conditions, so effective throughput may vary on a packet-by-packet basis. In situations like these, routing metrics may also vary rapidly ⚡
Routing metrics that incorporate link indications, such as Link Up/Down and effective throughput, let routers take link conditions into account when selecting routes. If a link experiences decreased rate or high frame loss, the route metric increases for the prefixes it serves, which encourages use of alternate paths if they're available. When the link condition improves, the route metric decreases, which encourages use of the link again 🌈
Within Weak End System implementations, changes in routing metrics and link state may result in a change of outgoing interface for one or more transport connections. Routes may also be added or withdrawn, which results in loss or gain of peer connectivity. However, link indications such as changes in transmission rate or frame loss do not necessarily result in a change of outgoing interface 👑
The Internet layer may also become aware of path changes through other mechanisms, such as receiving updates from a routing protocol, receiving a Router Advertisement, dead gateway detection [RFC816] or network unreachability detection [RFC2461], ICMP redirects, or a change in the IPv4 TTL (Time to Live)/IPv6 Hop Limit of received packets. A change in the outgoing interface may in turn influence the mobility sub-layer, causing a change in the incoming interface. The mobility sub-layer may also become aware of a change in the incoming interface of a peer (via receipt of a Mobile IP Binding Update [RFC3775]) 🫶
1.4.2. Transport Layer ✨
okay so the transport layer looks at link indications in two totally different ways 💅 one for figuring out how the path is performing, and one for managing the connection itself. layering is the vibe here 🎀
For parameter estimation, the transport layer mostly cares about path properties that affect performance. If a link indication seems relevant to those properties, it can be used directly 🦋 Things like "Link Up"/"Link Down" or changes in rate, delay, and frame loss may be relevant. but it's not always the case! if the bottleneck bandwidth on the end-to-end path is already way lower than the transmission rate, a rate increase might not change the path properties at all 🙈 As described in Appendix A.3, the algorithms for using link layer indications to improve transport parameter estimates are still under development 🛠️
strict layering doesn't apply to transport path parameter estimation. this lets the transport layer use all the info it can get 🌈 For example, the transport layer may figure out that a link indication came from a link that's part of the path for one or more connections. in that case, it may use a "Link Down" indication followed by a later "Link Up" indication to infer that non-congestive packet loss might have happened in between. this can happen even if the IP configuration doesn't change, so no Internet layer indication gets sent 🧚
the transport layer may also find Internet layer indications helpful for parameter estimation. for example, path change indications can be used as a signal to reset path parameter estimates 🔄 If there's no default route, loss of segments sent to a destination that doesn't have a prefix in the local routing table may be assumed to be caused by something other than congestion. this holds regardless of why the route was removed, whether local link conditions removed it or a remote router withdrew it 💀
now for connection management, where layering really matters 🫶 The transport layer may tear down a connection based on Internet layer indications (such as endpoint address changes), but it does not take link indications into account. just like a "Link Up" event may not cause a configuration change, and a configuration change may not cause connection teardown, the transport layer does not tear down connections when it receives a "Link Down" indication, no matter the cause 😭 When the "Link Down" indication comes from frame loss rather than an explicit exchange, it may be transient and soon followed by a "Link Up" indication ✨
even when the "Link Down" indication comes from an explicit exchange, like receipt of a Point-to-Point Protocol (PPP) Link Control Protocol (LCP)-Terminate or an IEEE 802.11 Disassociate or Deauthenticate frame, an alternative point of attachment may be available. that means connectivity can be restored quickly 🌸 So robustness is best achieved by letting connections stay up until an endpoint address changes, or until the connection is torn down because of a lack of response to repeated retransmission attempts 👑
for connection management, the transport layer is also careful about how it uses Internet layer indications 🧐 Changes in the routing table are not relevant for connection management, because connections should stay up during temporary routing flaps 🦋 Still, the transport layer may tear down transport connections when a connection endpoint IP address gets invalidated. If the connection was set up using a Mobile IP home address, a change in the Care-of Address doesn't need to cause teardown. the configuration change is hidden by the mobility functionality in the Internet layer, so the transport layer never sees it 🎀
"Requirements for Internet Hosts -- Communication Layers" [RFC1122], Section 2.4, requires Destination Unreachable, Source Quench, Echo Reply, Timestamp Reply, and Time Exceeded ICMP messages to be passed up to the transport layer 📬 [RFC1122], Section 4.2.3.9, requires Transmission Control Protocol (TCP) to react to an Internet Control Message Protocol (ICMP) Source Quench by slowing transmission 🐢
[RFC1122], Section 4.2.3.9, separates ICMP messages that indicate soft error conditions, which must not cause TCP to abort a connection, from hard error conditions, which should cause an abort 🧠 ICMP messages indicating soft error conditions include Destination Unreachable codes 0 (Net), 1 (Host), and 5 (Source Route Failed), which may come from routing transients. They also include Time Exceeded and Parameter Problem 🌀 ICMP messages indicating hard error conditions include Destination Unreachable codes 2 (Protocol Unreachable), 3 (Port Unreachable), and 4 (Fragmentation Needed and Don't Fragment Was Set) 💥 Hosts implementing classical ICMP-based Path MTU Discovery [RFC1191] use Destination Unreachable code 4, so they don't treat it as a hard error condition 🙃 Hosts implementing "Path MTU Discovery for IP version 6" [RFC1981] use ICMPv6 Packet Too Big messages 📦
as "TCP Problems with Path MTU Discovery" [RFC2923] points out, classical Path MTU Discovery can fail if ICMP messages aren't delivered or processed 😬 To fix this, "Packetization Layer Path MTU Discovery" [RFC4821] does depend on ICMP messages being delivered 🛟
"Fault Isolation and Recovery" [RFC816], Section 6, says:
It is not obvious, when error messages such as ICMP Destination Unreachable arrive, whether TCP should abandon the connection. The reason that error messages are difficult to interpret is that, as discussed above, after a failure of a gateway or network, there is a transient period during which the gateways may have incorrect information, so that irrelevant or incorrect error messages may sometimes return. An isolated ICMP Destination Unreachable may arrive at a host, for example, if a packet is sent during the period when the gateways are trying to find a new route. To abandon a TCP connection based on such a message arriving would be to ignore the valuable feature of the Internet that for many internal failures it reconstructs its function without any disruption of the end points.
"Requirements for IP Version 4 Routers" [RFC1812], Section 4.3.3.3, states that "Research seems to suggest that Source Quench consumes network bandwidth but is an ineffective (and unfair) antidote to congestion", which means routers should not originate them 🙅♀️ In general, the transport layer can work out a suitable (and conservative) response to congestion based on packet loss or explicit congestion notification. so ICMP Source Quench indications aren't needed, and sending extra Source Quench packets during congestion may actually make things worse 😤
"ICMP attacks against TCP" [Gont] argues that accepting ICMP messages based only on a correct four-tuple, without extra security checks, is ill-advised 🚨 For example, an attacker who forges an ICMP hard error message can make one or more transport connections abort 😱 The authors discuss several precautions, including mechanisms for validating ICMP messages and ignoring or delaying responses to hard error messages under various conditions 🔐 They also recommend that hosts ignore ICMP Source Quench messages 🙈
the transport layer may also give information to the link layer 🧵 For example, the transport layer may want to control the maximum number of times a link layer frame can be retransmitted, so the link layer doesn't keep retransmitting after a transport layer timeout 🔁 In IEEE 802.11, this can be done by adjusting the Management Information Base (MIB) [IEEE-802.11] variables dot11ShortRetryLimit (default: 7) and dot11LongRetryLimit (default: 4). These control the maximum number of retries for frames shorter and longer than dot11RTSThreshold, respectively 📊 However, since these variables control link behavior as a whole, they can't be used to adjust behavior separately for each transport connection 🙅♀️ When the link layer retransmission timeout is about the same order of magnitude as the path round-trip timeout, link layer control may not be possible at all 🫠
1.4.3. Application Layer 🌷
the transport layer gives indications to the application layer by passing along Internet layer indications (such as IP address configuration and changes), and by providing its own indications, like connection teardown 📣
applications can usually get the info they need more reliably from the Internet and transport layers, so they typically don't need to use link indications 🧚♀️ A "Link Up" indication means the link can carry IP packets, but it does not mean the link has been configured. applications should use an Internet layer "IP Address Configured" event instead 🎯 "Link Down" indications are typically not useful to applications, since they can be quickly followed by a "Link Up" indication. applications should respond to transport layer teardown indications instead 🔗 Similarly, changes in the transmission rate may not matter to applications if the bottleneck bandwidth on the path doesn't change, and the transport layer is best placed to figure that out 📈 So Figure 1 does not show link indications being given directly to applications 🖼️
2. Architectural Considerations ✨
okay so this part is where the architecture stuff gets real 💅 link indications are super useful, but they're also kinda tricky to use well, so the doc gives us some principles to keep us out of trouble 🫶 here they are, and each one gets its own section below:
- Proposals should avoid use of simplified link models in circumstances where they do not apply (Section 2.1).
- Link indications should be clearly defined, so that it is understood when they are generated on different link layers (Section 2.2).
- Proposals must demonstrate robustness against spurious link indications (Section 2.3).
- Upper layers should utilize a timely recovery step so as to limit the potential damage from link indications determined to be invalid after they have been acted on (Section 2.3.2).
- Proposals must demonstrate that effective congestion control is maintained (Section 2.4).
- Proposals must demonstrate the effectiveness of proposed optimizations (Section 2.5).
- Link indications should not be required by upper layers, in order to maintain link independence (Section 2.6).
- Proposals should avoid race conditions, which can occur where link indications are utilized directly by multiple layers of the stack (Section 2.7).
- Proposals should avoid inconsistencies between link and routing layer metrics (Section 2.7.3).
- Overhead reduction schemes must avoid compromising interoperability and introducing link layer dependencies into the Internet and transport layers (Section 2.8).
- Proposals for transport of link indications beyond the local host need to carefully consider the layering, security, and transport implications (Section 2.9).
2.1. Model Validation
okay this one is my fave 🔥 the big idea is don't pretend your link model fits every situation when it doesn't. proposals should avoid using link models in circumstances where they don't apply 💀
"The mistaken axioms of wireless-network research" [Kotz] is the paper that says wrong assumptions about link behavior can lead to protocols that just don't work in practice 😭 one example: wireless propagation is three-dimensional, so the signal strength can change a LOT over a short distance. that means link indications like rate, frame loss, and signal strength can swing really fast. so chaotic 🙈
"Modeling Wireless Links for Transport Protocols" [GurtovFloyd] goes through modeling mistakes and shows how to model link characteristics better. the authors also made simulation scenarios in ns-2 to go with it 🧚
so to dodge the traps in [Kotz] [GurtovFloyd], any doc describing capabilities that depend on link indications should explicitly spell out the assumptions of its link model and say when those assumptions apply. no vibes-based modeling allowed 💅
generic "trigger" models can hide implicit assumptions that may turn out to be invalid in outdoor or mesh wireless LAN deployments ✨ for example, two-state Markov models assume the link is either in a state with low frame loss ("up") or a state where few frames get through ("down"). those models also usually assume symmetry, so the link is "up" in both directions or "down" in both directions. but when you're dealing with intermediate loss rates, those assumptions may not hold 😩
as noted in "Hybrid Rate Control for IEEE 802.11" [Haratcherev], signal strength data is noisy and sometimes inconsistent, so it needs filtering to avoid erratic results 🌸 that means link indications based on raw signal strength may be unreliable. the fix is to combine signal strength data with other techniques. for example, if you're developing a "Going Down" indication for use with [IEEE-802.21], it would be advisable to validate filtered signal strength measurements with other indications of link loss, such as lack of Beacon reception 🫶
2.2. Clear Definitions
link indications should be clearly defined, so it's understood when they get generated on different link layers 💖 like, a lot of work went into coming up with the definitions of "Link Up" and "Link Down" and figuring out when those indications get sent on the various link layers. it's a whole thing 😭
so here's the advice for link indication definitions:
- Do not assume symmetric link performance or frame loss that is either low ("up") or high ("down").
in wired networks, links in the "up" state typically have low frame loss in both directions and are ready to send and receive data frames 🦋 links in the "down" state are unsuitable for sending and receiving data frames in either direction. so a link giving a "Link Up" indication will typically have low frame loss both ways, and high frame loss in any direction can only show up after the link gives a "Link Down" indication. BUT these assumptions may not hold for wireless LAN networks 💀 asymmetry is typically less of a problem for cellular networks, where propagation happens over longer distances, multi-path effects may be less severe, and the base station can transmit at much higher power than mobile stations while using a more sensitive antenna 📡
specs using a "Link Up" indication should not assume that getting it means the link has symmetric conditions or low frame loss in either direction 🙅♀️ in general, a "Link Up" event should not be sent because of transient changes in link conditions, only because of a change in link layer state. it's best to assume a "Link Up" event may not be sent in a timely way. large handoff latencies can delay the "Link Up" event, since movement to an alternative point of attachment gets delayed too 🐢
- Consider how sensitive link indications are to transient link conditions 👀 because of stuff like multi-path interference, signal strength and signal to noise ratio (SNR) can change rapidly over a short distance. that can make link indications based on unfiltered measurements act erratically 🌀 as noted in [Haratcherev], signal strength may be most useful when combined with other measurements, like frame loss.
- Where possible, design link indications with built-in damping 🧸 by design, the "Link Up" and "Link Down" events are about changes in the link layer state that make it able or unable to communicate IP packets. those changes come from the link layer state machine based on link layer exchanges (for example, completing the IEEE 802.11i four-way handshake for "Link Up", or receiving a PPP LCP-Terminate for "Link Down"), or from protracted frame loss, so the link layer concludes the link is no longer usable. so these indications are typically less sensitive to transient link conditions ✨
- Do not assume that a "Link Down" event will be sent at all, or that, if it is sent, it will be received in a timely way 😬 a good link layer implementation will rapidly detect connectivity failure (such as by tracking missing Beacons) while only sending a "Link Down" event when it concludes the link is unusable, not because of transient frame loss 🎀
however, existing wireless LAN implementations often don't do a great job detecting link failure 😤 during a lengthy detection phase, no "Link Down" event is sent by the link layer, even though IP packets can't be sent or received on the link. starting a scan may get delayed, so the station can't find another point of attachment. this can lead to inappropriate backoff of retransmission timers in the transport layer, among other problems 💔 this isn't as big a deal for cellular networks that use transmit power adjustment 📶
2.3. Robustness
link indication proposals must demonstrate robustness against misleading indications 🛡️ things to think about include:
- Implementation variation
- Recovery from invalid indications
- Damping and hysteresis
2.3.1. Implementation Variation
okay bestie, link layer implementations are NOT all the same 😭 and that can seriously change how link indications behave 💅 so when you're judging a proposal, you have to account for it. radio propagation and implementation differences can totally mess with how reliable link indications are 📡
in "Link-level Measurements from an 802.11b Mesh Network" [Aguayo], the authors investigated why frames were getting lost in a 38-node urban multi-hop IEEE 802.11 ad-hoc network 🌆 mostly, links that are super bad in one direction are also bad in the other direction, and links that are super good one way are good the other way too 🫶 but ngl, 30 percent of links had loss rates that were wildly different in each direction 🙈 asymmetry is real, bestie.
as [Aguayo] describes, wireless LAN links often have loss rates somewhere in between "up" (low loss) and "down" (high loss) 🌈 and they can be very asymmetric too. so receiving a "Link Up" indication may not actually mean bidirectional reachability 😬 it could have been generated after only small frames got exchanged at low rates, and that doesn't guarantee the link can handle large frames exchanged at higher rates 💀
where there's multi-path interference or hidden nodes, signal strength can swing a lot over a short distance 📶 there are a few techniques to reduce the mess 🧹 multiple transmitting and receiving antennas can reduce multi-path effects, transmission rate adaptation can help find a more satisfactory transmission rate, transmit power adjustment can improve signal quality and reduce interference, and Request-to-Send/Clear-to-Send (RTS/CTS) signaling can reduce hidden node problems 🦋 but these techniques may not be completely effective, so high frame loss can still happen, and the link can keep cycling between "up" and "down" states 🎢
to make things more robust against spurious link indications, it is recommended that upper layers treat the indication as a "hint" (advisory in nature) rather than a "trigger" that dictates a particular action ✨ that way, upper layers can go validate the hint first 🔍 the vibe is literally "verify before you act" 💖
in [RFC4436], "Link Up" indications are rate limited, and the IP configuration gets confirmed with bidirectional reachability tests that run at the same time as a DHCP configuration request 🎀 so bidirectional reachability is confirmed before an IP configuration gets activated 👑 however, if a link has an intermediate loss rate, showing bidirectional reachability may still not mean the link is suitable for carrying IP data packets 😅
another validation example is IPv4 Link-Local address configuration [RFC3927] 🏠 before configuring an IPv4 Link-Local address, a claim-and-defend protocol has to be run 🥊 a host needs to be present to defend its address against another claimant, and address conflicts are relatively likely. so a host returning from sleep mode, or one that receives a "Link Up" indication, could run into an address conflict if it used a formerly configured IPv4 Link-Local address without rerunning claim and defend 💀 no thank you 🙅♀️
2.3.2. Recovery from Invalid Indications
okay so, improper use of link indications can cause operational malfunctions 😩 so it is recommended that upper layers use a timely recovery step to limit the potential damage from link indications that turn out to be invalid after they've already been acted on 🛟
in Detecting Network Attachment in IPv4 (DNAv4) [RFC4436], reachability tests run at the same time as a DHCP configuration request 🤝 so if the bidirectional reachability test times out, the host can still obtain an IP configuration via DHCP. and if that fails, the host can still keep using an existing valid address if it has one 🌸 that's a solid safety net, honestly 🧚
where a proposal involves recovery at the transport layer, the recovered transport parameters should be demonstrated to remain valid 📊 the examples here are the Maximum Segment Size (MSS), RoundTrip Time (RTT), Retransmission TimeOut (RTO), Bandwidth (bw), congestion window (cwnd), and so on 🧮 congestion window validation is discussed in "TCP Congestion Window Validation" [RFC2861] 🌊
if timely recovery isn't supported, unexpected consequences can happen 🚨 as [RFC3927] describes, early IPv4 Link-Local implementations would wait five minutes before trying to obtain a routable address after assigning an IPv4 Link-Local address ⏳ one implementation was observed where mobile hosts changed their point of attachment more often than every five minutes, and they never got a routable address 😭 the problem was an invalid link indication (signaling "Link Up" before link layer authentication was complete), which caused an initial failure to obtain a routable address using DHCP 💔 because of this, [RFC3927] recommends against modifying the maximum retransmission timeout (64 seconds) provided in [RFC2131] 🙅♀️
2.3.3. Damping and Hysteresis
damping and hysteresis can be used to limit the damage from unstable link indications 🌀 this can include damping unstable indications, or putting constraints on how often link indication-induced actions can happen within a time period ⏱️ basically, chill out, bestie 🧘♀️
while [Aguayo] found that frame loss was relatively stable for stationary stations, obstacles to radio propagation and multi-path interference can cause rapid changes in signal strength for a mobile station 🏃♀️💨 so mobile stations can run into rapid changes in link characteristics, like changes in transmission rate, throughput, frame loss, and even "Link Up"/"Link Down" indications 🎢
where link-aware routing metrics are implemented, this can cause rapid metric changes 📉 which could lead to frequent changes in the outgoing interface for Weak End System implementations 🔁 so it may be necessary to introduce route flap dampening 🛑
BUT the benefits of damping have to be weighed against the additional latency it can introduce ⚖️ for example, to filter out spurious "Link Down" indications, those indications may be delayed until it can be determined that a "Link Up" indication won't follow shortly after 🙃 however, when multiple Beacons are missed, that delay may not be needed, since there's no evidence of a suitable point of attachment nearby 📡
in some cases, it's desirable to ignore link indications entirely 🙈 since a host can move from an ad-hoc network to a network with centralized address management, a host that gets a "Link Up" indication can't automatically conclude it should configure an IPv4 Link-Local address 🏠 before figuring out whether a DHCP server is available [RFC3927] or whether an operable configuration is valid [RFC4436] 🫶
as noted in Section 1.4, the transport layer does not use "Link Up" and "Link Down" indications for connection management 🌷
2.4. Congestion Control
okay this part is SO important 🔥 link indication proposals must demonstrate that effective congestion control is maintained [RFC2914] 💪 one or more of the following techniques may be used:
- Rate limiting. packets generated from link indications can be rate limited (for example, a limit of one packet per end-to-end path RTO) ⏲️
- Utilization of upper-layer indications. applications should depend on upper-layer indications, like IP address configuration/change notification, instead of using link indications such as "Link Up" 🧠
- Keepalives. to improve robustness against spurious link indications, an application keepalive or transport layer indication (like connection teardown) can be used instead of consuming "Link Down" indications 💌
- Conservation of resources. proposals must demonstrate that they are not vulnerable to congestive collapse 🛡️
as noted in "Robust Rate Adaptation for 802.11 Wireless Networks" [Robust], decreasing transmission rate in response to frame loss increases contention, which can lead to congestive collapse 😱 to avoid this, the link layer needs to tell apart frame loss caused by congestion from loss caused by channel conditions 🧩 only frame loss from a deterioration in channel conditions can be used as a basis for decreasing transmission rate 📉
consider a proposal where a host uses a "Link Up" indication to trigger retransmission of the last packet it sent, so it can receive an ACK before its retransmission timer expires 🤔 on a rapidly moving mobile node where "Link Up" indications come in quick succession, this could cause a burst of retransmitted packets, which violates the principle of "conservation of packets" 💥 not it 🙅♀️
at the application layer, link indications have been used by applications like Presence [RFC2778] to optimize registration and user interface update operations 💜 for example, implementations may attempt presence registration on receipt of a "Link Up" indication, and presence de-registration by a surrogate on receipt of a "Link Down" indication 📲 but presence implementations doing this violate the principle of "conservation of packets", since link indications can be generated on a time scale shorter than the end-to-end path RTO 🫠 it gets even worse, because each presence update can be delivered to many watchers 🫣 also, using "Link Up" this way is just unwise, since the interface may not yet have an operable Internet layer configuration 🙃 instead, an "IP address configured" indication may be used 🎀
2.5. Effectiveness
proposals must demonstrate the effectiveness of their proposed optimizations 📈 optimizations typically add complexity, so a substantial performance improvement is required to make a compelling case 💅
when link indications are unreliable, effectiveness may depend on the penalty for false positives and false negatives 🎯 in the case of DNAv4 [RFC4436], the benefits of a successful optimization are modest, but being unable to confirm an operable configuration costs a lengthy timeout ⌛ so the recommended strategy is to test multiple potential configurations in parallel, in addition to attempting configuration via DHCP 🧪 this virtually guarantees that DNAv4 will always perform equal to or better than DHCP alone 🏆 slay 👑
2.6. Interoperability
while link indications can be used where they're available, they should not be required by upper layers, so that link layer independence is maintained 🦋 for example, if information on supported prefixes is provided at the link layer, hosts that don't understand those hints must still be able to obtain an IP address 🌈
where link indications are proposed to optimize Internet layer configuration, proposals must demonstrate that they don't compromise robustness by interfering with address assignment or routing protocol behavior, making address collisions more likely, or compromising Duplicate Address Detection (DAD) [RFC4429] 🛡️ no messing with the safety stuff, periodt 💅
finally, to avoid compromising interoperability while chasing performance, proposals must demonstrate that interoperability remains possible (potentially with degraded performance) even if one or more participants don't implement the proposal 🫶 everyone deserves to be in the group chat 💖
2.7. Race Conditions ✨
okay bestie, link indication proposals should avoid race conditions 🙈 These happen when link indications get used directly by multiple layers of the stack at once, and it gets messy fast 💀
Link indications are super useful for optimizing Internet Protocol layer addressing and configuration, and for routing too 🦋 "The BU-trigger method for improving TCP performance over Mobile IPv6" [Kim] describes situations where link indications get processed by the Internet Protocol layer (e.g., MIPv6) before the transport layer uses them for parameter estimation. But for those parameter estimation purposes, it may also be desirable for the transport layer to use link indications directly 🎀
In situations where the Weak End System model is implemented, a change of outgoing interface may happen at the same time the transport layer is modifying transport parameters based on other link indications 😭 So transport behavior may differ depending on the order the link indications are processed in. not ideal!!
Where a multi-homed host sees increasing frame loss or decreased rate on one of its interfaces, a routing metric that takes these effects into account will go up, potentially causing a change in the outgoing interface for one or more transport connections. This may trigger Mobile IP signaling so the incoming path changes too 🌈 As a result, the transport parameters estimated for the original outgoing and incoming paths (congestion state, Maximum Segment Size (MSS) derived from the link maximum transmission unit (MTU) or Path MTU) may no longer be valid for the new outgoing and incoming paths 💔
To avoid race conditions, the following measures are recommended:
- Path change re-estimation
- Layering
- Metric consistency
2.7.1. Path Change Re-estimation
When the Internet layer detects a path change, things like a major change in transmission rate, a change in the outgoing or incoming interface of the host or the incoming interface of a peer, or even a substantial change in the IPv4 TTL/IPv6 Hop Limit of received packets, it may be worth considering whether to reset transport parameters (RTT, RTO, cwnd, bw, MSS) to their initial values so they can be re-estimated ✨ That way, estimates based on the former path don't stick around after they've gone stale 🧚 Appendix A.3 summarizes the research on this topic 📚
2.7.2. Layering
Another technique for avoiding race conditions is to rely on layering to damp transient link indications and give you greater link layer independence 🌸
The Internet layer handles routing, IP configuration, and mobility, and it gives higher layers an abstraction that doesn't depend on the link layer technology underneath 👑
In general, it is advisable for applications to use indications from the Internet or transport layers rather than consuming link indications directly 💅
2.7.3. Metric Consistency
Proposals should avoid inconsistencies between link and routing layer metrics 🫶 Without careful design, differences between the link indications used in routing and the ones used in roaming and/or link enablement can cause instability, especially in multi-homed hosts 😵💫
Once a link is in the "up" state, how effective it is at transmitting data packets can be used to pick an appropriate routing metric. When transmission time makes up a big chunk of the total transit time, minimizing total transmission time is equivalent to maximizing effective throughput 🔥 "A High-Throughput Path Metric for Multi-Hop Wireless Routing" [ETX] describes a proposed routing metric based on the Expected Transmission Count (ETX). The authors show that ETX, based on link layer frame loss rates (prior to retransmission), lets you select routes that maximize effective throughput 🙌 When the transmission rate is constant, the expected transmission time is proportional to ETX, so minimizing ETX also minimizes expected transmission time 💖
But where the transmission rate can vary, ETX may not be a good estimate of the transmission time 🤔 In "Routing in multi-radio, multi-hop wireless mesh networks" [ETX-Rate], the authors define a new metric called Expected Transmission Time (ETT). It's described as a "bandwidth adjusted ETX", since ETT = ETX * S/B, where S is the size of the probe packet and B is the bandwidth of the link as measured by a packet pair [Morgan]. Here's the catch though: ETT assumes that the loss fraction of small probe frames sent at a 1 Mbps data rate reflects the loss fraction of larger data frames at higher rates. That tends to underestimate ETT at higher rates, where frame loss typically goes up 😬 In "A Radio Aware Routing Protocol for Wireless Mesh Networks" [ETX-Radio], the authors refine ETT further by estimating the loss fraction as a function of transmission rate 🦋
Prior to sending data packets over the link, though, the right routing metric may not be easy to predict 🔮 As noted in [Shortest], a link that can successfully transmit the short frames used for control, management, or routing may not necessarily be able to reliably transport larger data packets 📦
So it may be necessary to use alternative metrics (such as signal strength or Access Point load) to help with attachment/handoff decisions 🎀 Still, unless the new interface is the preferred route for one or more destination prefixes, a Weak End System implementation will not use the new interface for outgoing traffic. And where "idle timeout" functionality is implemented, the unused interface will be brought down, and only brought back up by the link enablement algorithm 💤
Within the link layer, metrics like signal strength and frame loss may be used to determine the transmission rate, and to decide when to pick a different point of attachment 📡 To let stations roam before they hit packet loss, studies such as "An experimental study of IEEE 802.11b handover performance and its effect on voice traffic" [Vatn] have suggested using signal strength to detect loss of connectivity more quickly, rather than frame loss as suggested in "Techniques to Reduce IEEE 802.11b MAC Layer Handover Time" [Velayos] 🏃♀️
[Aguayo] notes that signal strength and distance aren't good predictors of frame loss or throughput, because of the potential effects of multi-path interference 🌀 So a link brought up because of good signal strength may then show significant frame loss and low throughput 😩 Similarly, an Access Point (AP) with low utilization may not be the best choice, since low utilization can be caused by hardware or software problems 🙃 "OSPF Optimized Multipath (OSPF-OMP)" [Villamizar] notes that link-utilization-based routing metrics have a history of instability 📉
2.8. Layer Compression
In many situations, the exchanges a host needs to complete a handoff and reestablish connectivity are pretty considerable 😮💨 That's why there are proposals to combine exchanges across multiple layers to cut down on overhead. Reducing overhead is a laudable goal, but proposals need to avoid compromising interoperability and introducing link layer dependencies into the Internet and transport layers 🫶
Exchanges required for handoff and connectivity reestablishment may include link layer scanning, authentication, and association establishment; Internet layer configuration, routing, and mobility exchanges; transport layer retransmission and recovery; security association reestablishment; application protocol re-authentication and re-registration exchanges, etc. 🗂️ It's a whole lot, bestie!
Several proposals involve combining exchanges within the link layer 🧩 For example, in [EAPIKEv2], a link layer Extensible Authentication Protocol (EAP) [RFC3748] exchange may be used for IP address assignment, potentially bypassing Internet layer configuration. Within [PEAP], it is proposed that a link layer EAP exchange be used to carry Mobile IPv6 Binding Updates. And [MIPEAP] proposes that EAP exchanges be used for configuration of Mobile IPv6 🌈 When link, Internet, or transport layer mechanisms get combined like this, hosts need to maintain backward compatibility so they can still operate on networks where those compression schemes aren't available 🔄
Layer compression schemes can also negatively impact robustness 💀 For example, to optimize IP address assignment, it has been proposed that prefixes be advertised at the link layer, such as within the 802.11 Beacon and Probe Response frames. However, [IEEE-802.1X] lets the Virtual LAN Identifier (VLANID) be assigned dynamically. So the prefix(es) advertised within the Beacon and/or Probe Response may not match the prefix(es) configured by the Internet layer after the host completes link layer authentication 🙈 If the host handled IP configuration at the link layer instead of within the Internet layer, it might be unable to communicate because it got assigned the wrong IP address 😭
2.9. Transport of Link Indications 🦋
okay so proposals for sending link indications between hosts need to think super carefully about layering, security, and transport implications 🫶
the transport layer can look at the local routing table to make its transport parameter estimates better ✨ absence of positive feedback that the path is sending data end-to-end must be heeded, but when a route that used to be absent comes back, that can be used to trigger congestion control probing 🌸 it's giving very "we can do this, but still be careful." transported link indications that change the local routing table can improve those estimates, but security and interoperability issues for routing protocols still apply 🔥
any proposal that involves transporting link indications needs to show all of the following 💅
- (a) Superiority to implicit signals. generally, implicit signals are preferred over explicit transport of link indications, bc they don't need anyone to take part in the routing mesh, they add no new packets when the network is already in distress, they work more reliably with middle boxes like NA(P)Ts, they're more likely to be backward compatible, and they're less likely to cause security vulnerabilities 😭 so explicit signaling proposals have to prove that implicit signals are inadequate 🙈
- (b) Mitigation of security vulnerabilities. transported link indications should not introduce new security vulnerabilities 💀 when link indications change the local routing table, they count as a routing protocol, so the vulnerabilities of unsecured routing protocols apply, including spoofing by off-link attackers. "SEcure Neighbor Discovery (SEND)" [RFC3971] may help with authentication and integrity protection of router-originated messages, and protect against forgery of transported link indications, but those mechanisms aren't widely deployed yet 🥺
- (c) Validation of transported indications. even if a transported link indication is integrity protected and authenticated, if the sender is a host off the local link, it might not be clear that the sender is on the actual path in use, or which transport connection(s) the indication is about 🧚 proposals need to describe how the receiving host can validate the transported link indication ✨
- (d) Mapping of Identifiers. when link indications get transported, it's usually to share information about Internet, transport, or application layer operations at a remote element 🌈 but application layer sessions or transport connections might not be visible to that remote element because of things like load sharing between links, or use of IPsec, tunneling protocols, or nested headers 👀 so proposals need to show how the link indication can be mapped to the relevant higher-layer state. for example, the transport layer, on receiving a link indication, will need to figure out the set of transport sessions (source address, destination address, source port, destination port, transport) that are affected. and if a presence server gets remote "Link Up"/"Link Down" status for a particular Media Access Control (MAC) address, it'll need to connect that MAC address to the user (
pres:user@example.com) that the link status change is relevant to 💖
3. Future Work ✨
okay so we still need more research on how link indications can be used by the Internet, transport, and application layers 🔍
we also need to understand the connection between link indications and routing metrics 🧠 for example, block ACKs (supported in [IEEE-802.11e]) make the relationship between effective throughput and frame loss way messier, which might mean we need revised routing metrics for ad-hoc networks 😩 it's also needed to reconcile handoff metrics (e.g., signal strength and link utilization) with routing metrics based on link indications (e.g., frame error rate and negotiated rate) 🎀
we need a much better understanding of how physical and link layer metrics get used in rate negotiation 💅 for example, recent work [Robust][CARA] has suggested that frame loss due to contention (which would be made worse by rate reduction) can be told apart from loss due to channel conditions (which may be improved by rate reduction) 🤯
at the transport layer, we need more work to figure out the right reaction to Internet layer indications, like routing table and path changes 🛣️ we also need more work on using link layer indications in transport parameter estimation, including rate changes, "Link Up"/"Link Down" indications, link layer retransmissions, and frame loss of various types (due to contention or channel conditions) 🌸
and we need to know how link layers might use information from the transport layer 🦋 for example, it's not great for a link layer to retransmit so aggressively that its round-trip time gets close to that of the end-to-end transport connection 😬 instead, it might make sense to do downward rate adjustment to decrease frame loss and improve latency ✨ also, sometimes the transport layer doesn't need heroic efforts to avoid frame loss, and timely delivery might be preferred instead ⭐
4. Security Considerations 🔐
proposals for using link indications might introduce new security vulnerabilities 😱 these include:
- Spoofing
- Indication validation
- Denial of service
4.1. Spoofing 🥷
when link layer control frames aren't protected, an attacker can spoof them 🙈 for example, PPP doesn't protect LCP frames like LCP-Terminate, and [IEEE-802.11] doesn't protect management frames like Associate/Reassociate, Disassociate, or Deauthenticate 💀
spoofing link layer control traffic can let attackers exploit weaknesses in link indication proposals 😈 for example, proposals that don't implement congestion avoidance can let attackers mount denial-of-service attacks 🚨
even where the link layer has security built in, attacks can still happen if the security model isn't consistent 👀
for example, wireless LANs implementing [IEEE-802.11i] don't let stations send or receive IP packets on the link until an authenticated key exchange protocol called the "4-way handshake" is done 🤝 so a link implementing [IEEE-802.11i] can't be treated as usable at the Internet layer ("Link Up") until that authenticated key exchange finishes ✨
but while [IEEE-802.11i] requires authenticated frames to get a "Link Up" indication, it doesn't support management frame authentication 😭 attackers can use that weakness to launch denial-of-service attacks on stations attached to distant Access Points (APs) 💔
in [IEEE-802.11F], "Link Up" is considered to happen when an AP sends a Reassociation Response 🛜 at that point, the AP sends a spoofed frame with the station's source address to a multicast address, which makes switches inside the Distribution System (DS) learn the station's MAC address 🧩 this lets frames get forwarded to the station at its new point of attachment, but it also lets an attacker disassociate a station anywhere within the ESS by sending an unauthenticated Reassociation Request frame 🫣
4.2. Indication Validation 🛡️
"Fault Isolation and Recovery" [RFC816], Section 3, explains how hosts work with routers for fault recovery 🧚 the basic idea is that gateways always try to keep a consistent, correct model of the internetwork topology, so the host's fault recovery strategy is very simple 💖 whenever a host thinks something's wrong, it asks the gateway for advice, and if the advice comes back, the host believes it completely 🫶 the advice is only wrong during the short negotiation period right after an outage, and otherwise it's reliably correct ✨
the host doesn't even have to ask, because the gateway gives advice when it's appropriate 👑 when a host sends a datagram to a distant net, it should be ready to receive either of two advisory messages the gateway might send 📨 the ICMP "redirect" message says the gateway the host sent the datagram to is no longer the best gateway for that net 🗺️ the gateway will already have forwarded the datagram, but the host should update its routing table to use a different immediate address for that net 🔄 the ICMP "destination unreachable" message says that, because of an outage, the addressed net or host can't currently be reached in any way 🚧 when a host gets that message, it can either drop the connection right away without retransmitting, or resend slowly to see whether the fault gets fixed in a reasonable time ⏳
given today's security environment, it's inadvisable for hosts to act on indications from routers without careful thought ⚠️
as "ICMP attacks against TCP" [Gont] points out, existing ICMP error messages can be exploited by attackers to abort connections in progress, stop new connections from being set up, or reduce the throughput of ongoing connections 😭 similar attacks can also target the Internet layer by forging ICMP redirects 🥀
proposals for transported link indications need to show they won't add a new set of similar vulnerabilities 🔍 since transported link indications are typically unauthenticated, hosts receiving them may not be able to tell whether they're authentic, or even plausible 🤷♀️
when link indication proposals respond to unauthenticated link layer frames, they should use upper-layer security mechanisms where possible 🧁 for example, even though a host might use an unauthenticated link layer control frame to conclude that a link has become operational, it can use SEND [RFC3971] or authenticated DHCP [RFC3118] to get secure Internet layer configuration 🎀
4.3. Denial of Service 💥
okay so this one is the big scary one, bestie 😭 link indication proposals need to be super careful not to hand attackers a way to cause denial of service from far away 🚨 wireless links are already kinda vulnerable to interference, but to mess with one you have to be able to get radio contact with the target network 📡 the real problem is attacks from a distance, either from an attacker on another point of attachment inside the same network, or from an off-link attacker. that's a much bigger vulnerability, not me being dramatic 💀
the transport of link indications can make things worse 🙈 it could let vulnerabilities that only a local-link attacker can exploit get pulled across the Internet 🌐 also, when link indications get integrated with upper layers, a spoofed link layer frame might be able to use up more of the host's resources than it normally would 😬 so upper layers absolutely need to validate link indications 🫶 but they REALLY shouldn't spend a ton of resources doing it 🧚
and here's the plot twist 🌈 congestion control isn't only a transport issue, it's a security issue too 🔥 so to avoid giving an attacker any leverage, one forged link layer frame should not get a magnified response from one or more hosts. that means no multiple responses, and no single response that's bigger than it should be 🚫 for example, proposals should not let multiple hosts respond to a frame sent to a multicast destination address 💅
5. References 📚
okay bestie, here's the reference list, copied exactly so nothing gets mangled 🎀 the normative one comes first, then the informative ones 💖
5.1. Normative References ⭐
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.5.2. Informative References 🦋
[RFC816] Clark, D., "Fault Isolation and Recovery", RFC 816,
July 1982.
[RFC1058] Hedrick, C., "Routing Information Protocol", RFC 1058,
June 1988.
[RFC1122] Braden, R., "Requirements for Internet Hosts --
Communication Layers", STD 3, RFC 1122, October 1989.
[RFC1131] Moy, J., "The OSPF Specification", RFC 1131, October
1989.
[RFC1191] Mogul, J. and S. Deering, "Path MTU discovery", RFC
1191, November 1990.
[RFC1256] Deering, S., "ICMP Router Discovery Messages", RFC
1256, September 1991.
[RFC1305] Mills, D., "Network Time Protocol (Version 3)
Specification, Implementation and Analysis", RFC 1305,
March 1992.
[RFC1307] Young, J. and A. Nicholson, "Dynamically Switched Link
Control Protocol", RFC 1307, March 1992.
[RFC1661] Simpson, W., "The Point-to-Point Protocol (PPP)", STD
51, RFC 1661, July 1994.
[RFC1812] Baker, F., "Requirements for IP Version 4 Routers",
RFC 1812, June 1995.
[RFC1918] Rekhter, Y., Moskowitz, B., Karrenberg, D., de Groot,
D., and E. Lear, "Address Allocation for Private
Internets", BCP 5, RFC 1918, February 1996.
[RFC1981] McCann, J., Deering, S. and J. Mogul, "Path MTU
Discovery for IP version 6", RFC 1981, June 1996.
[RFC2131] Droms, R., "Dynamic Host Configuration Protocol", RFC
2131, March 1997.
[RFC2328] Moy, J., "OSPF Version 2", STD 54, RFC 2328, April
1998.
[RFC2461] Narten, T., Nordmark, E., and W. Simpson, "Neighbor
Discovery for IP Version 6 (IPv6)", RFC 2461, December
1998.
[RFC2778] Day, M., Rosenberg, J., and H. Sugano, "A Model for
Presence and Instant Messaging", RFC 2778, February
2000.
[RFC2861] Handley, M., Padhye, J., and S. Floyd, "TCP Congestion
Window Validation", RFC 2861, June 2000.
[RFC2914] Floyd, S., "Congestion Control Principles", RFC 2914,
BCP 41, September 2000.
[RFC2923] Lahey, K., "TCP Problems with Path MTU Discovery", RFC
2923, September 2000.
[RFC2960] Stewart, R., Xie, Q., Morneault, K., Sharp, C.,
Schwarzbauer, H. Taylor, T., Rytina, I., Kalla, M.,
Zhang, L., and V. Paxson, "Stream Control Transmission
Protocol" RFC 2960, October 2000.
[RFC3118] Droms, R. and B. Arbaugh, "Authentication for DHCP
Messages", RFC 3118, June 2001.
[RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins,
C., and M. Carney, "Dynamic Host Configuration
Protocol for IPv6 (DHCPv6)", RFC 3315, July 2003.
[RFC3366] Fairhurst, G. and L. Wood, "Advice to link designers
on link Automatic Repeat reQuest (ARQ)", BCP 62, RFC
3366, August 2002.
[RFC3428] Campbell, B., Rosenberg, J., Schulzrinne, H., Huitema,
C., and D. Gurle, "Session Initiation Protocol (SIP)
Extension for Instant Messaging", RFC 3428, December
2002.
[RFC3748] Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J., and
H. Levkowetz, "Extensible Authentication Protocol
(EAP)", RFC 3748, June 2004.
[RFC3775] Johnson, D., Perkins, C., and J. Arkko, "Mobility
Support in IPv6", RFC 3775, June 2004.
[RFC3921] Saint-Andre, P., "Extensible Messaging and Presence
protocol (XMPP): Instant Messaging and Presence", RFC
3921, October 2004.
[RFC3927] Cheshire, S., Aboba, B., and E. Guttman, "Dynamic
Configuration of Link-Local IPv4 Addresses", RFC 3927,
May 2005.
[RFC3971] Arkko, J., Kempf, J., Zill, B., and P. Nikander,
"SEcure Neighbor Discovery (SEND)", RFC 3971, March
2005.
[RFC4340] Kohler, E., Handley, M., and S. Floyd, "Datagram
Congestion Control Protocol (DCCP)", RFC 4340, March
2006.
[RFC4423] Moskowitz, R. and P. Nikander, "Host Identity Protocol
(HIP) Architecture", RFC 4423, May 2006.
[RFC4429] Moore, N., "Optimistic Duplicate Address Detection
(DAD) for IPv6", RFC 4429, April 2006.
[RFC4436] Aboba, B., Carlson, J., and S. Cheshire, "Detecting
Network Attachment in IPv4 (DNAv4)", RFC 4436, March
2006.
[RFC4821] Mathis, M. and J. Heffner, "Packetization Layer Path
MTU Discovery", RFC 4821, March 2007.
[Alimian] Alimian, A., "Roaming Interval Measurements",
11-04-0378-00-roaming-intervals-measurements.ppt, IEEE
802.11 submission (work in progress), March 2004.
[Aguayo] Aguayo, D., Bicket, J., Biswas, S., Judd, G., and R.
Morris, "Link-level Measurements from an 802.11b Mesh
Network", SIGCOMM '04, September 2004, Portland,
Oregon.
[Bakshi] Bakshi, B., Krishna, P., Vadiya, N., and D.Pradhan,
"Improving Performance of TCP over Wireless Networks",
Proceedings of the 1997 International Conference on
Distributed Computer Systems, Baltimore, May 1997.
[BFD] Katz, D. and D. Ward, "Bidirectional Forwarding
Detection", Work in Progress, March 2007.
[Biaz] Biaz, S. and N. Vaidya, "Discriminating Congestion
Losses from Wireless Losses Using Interarrival Times
at the Receiver", Proceedings of the IEEE Symposium on
Application-Specific Systems and Software Engineering
and Technology, Richardson, TX, Mar 1999.
[CARA] Kim, J., Kim, S., and S. Choi, "CARA: Collision-Aware
Rate Adaptation for IEEE 802.11 WLANs", Korean
Institute of Communication Sciences (KICS) Journal,
Feb. 2006
[Chandran] Chandran, K., Raghunathan, S., Venkatesan, S., and R.
Prakash, "A Feedback-Based Scheme for Improving TCP
Performance in Ad-Hoc Wireless Networks", Proceedings
of the 18th International Conference on Distributed
Computing Systems (ICDCS), Amsterdam, May 1998.
[DNAv6] Narayanan, S., "Detecting Network Attachment in IPv6
(DNAv6)", Work in Progress, March 2007.
[E2ELinkup] Dawkins, S. and C. Williams, "End-to-end, Implicit
'Link-Up' Notification", Work in Progress, October
2003.
[EAPIKEv2] Tschofenig, H., Kroeselberg, D., Pashalidis, A., Ohba,
Y., and F. Bersani, "EAP IKEv2 Method", Work in
Progress, March 2007.
[Eckhardt] Eckhardt, D. and P. Steenkiste, "Measurement and
Analysis of the Error Characteristics of an In-
Building Wireless Network", SIGCOMM '96, August 1996,
Stanford, CA.
[Eddy] Eddy, W. and Y. Swami, "Adapting End Host Congestion
Control for Mobility", Technical Report CR-2005-
213838, NASA Glenn Research Center, July 2005.
[EfficientEthernet]
Gunaratne, C. and K. Christensen, "Ethernet Adaptive
Link Rate: System Design and Performance Evaluation",
Proceedings of the IEEE Conference on Local Computer
Networks, pp. 28-35, November 2006.
[Eggert] Eggert, L., Schuetz, S., and S. Schmid, "TCP
Extensions for Immediate Retransmissions", Work in
Progress, June 2005.
[Eggert2] Eggert, L. and W. Eddy, "Towards More Expressive
Transport-Layer Interfaces", MobiArch '06, San
Francisco, CA.
[ETX] Douglas S. J. De Couto, Daniel Aguayo, John Bicket,
and Robert Morris, "A High-Throughput Path Metric for
Multi-Hop Wireless Routing", Proceedings of the 9th
ACM International Conference on Mobile Computing and
Networking (MobiCom '03), San Diego, California,
September 2003.
[ETX-Rate] Padhye, J., Draves, R. and B. Zill, "Routing in
multi-radio, multi-hop wireless mesh networks",
Proceedings of ACM MobiCom Conference, September 2003.
[ETX-Radio] Kulkarni, G., Nandan, A., Gerla, M., and M.
Srivastava, "A Radio Aware Routing Protocol for
Wireless Mesh Networks", UCLA Computer Science
Department, Los Angeles, CA.
[GenTrig] Gupta, V. and D. Johnston, "A Generalized Model for
Link Layer Triggers", submission to IEEE 802.21 (work
in progress), March 2004, available at:
<http://www.ieee802.org/handoff/march04_meeting_docs/
Generalized_triggers-02.pdf>.
[Goel] Goel, S. and D. Sanghi, "Improving TCP Performance
over Wireless Links", Proceedings of TENCON'98, pages
332-335. IEEE, December 1998.
[Gont] Gont, F., "ICMP attacks against TCP", Work in
Progress, October 2006.
[Gurtov] Gurtov, A. and J. Korhonen, "Effect of Vertical
Handovers on Performance of TCP-Friendly Rate
Control", to appear in ACM MCCR, 2004.
[GurtovFloyd] Gurtov, A. and S. Floyd, "Modeling Wireless Links for
Transport Protocols", Computer Communications Review
(CCR) 34, 2 (2003).- [Haratcherev] Haratcherev, I., Lagendijk, R., Langendoen, K., and H. Sips, "Hybrid Rate Control for IEEE 802.11", MobiWac '04, October 1, 2004, Philadelphia, Pennsylvania, USA. 🎀
- [Haratcherev2] Haratcherev, I., "Application-oriented Link Adaptation for IEEE 802.11", Ph.D. Thesis, Technical University of Delft, Netherlands, ISBN-10:90-9020513-6, ISBN-13:978-90-9020513-7, March 2006. 📚
- [HMP] Lee, S., Cho, J., and A. Campbell, "Hotspot Mitigation Protocol (HMP)", Work in Progress, October 2003.
- [Holland] Holland, G. and N. Vaidya, "Analysis of TCP Performance over Mobile Ad Hoc Networks", Proceedings of the Fifth International Conference on Mobile Computing and Networking, pages 219-230. ACM/IEEE, Seattle, August 1999. 🌸
- [Iannaccone] Iannaccone, G., Chuah, C., Mortier, R., Bhattacharyya, S., and C. Diot, "Analysis of link failures in an IP backbone", Proc. of ACM Sigcomm Internet Measurement Workshop, November, 2002.
- [IEEE-802.1X] Institute of Electrical and Electronics Engineers, "Local and Metropolitan Area Networks: Port-Based Network Access Control", IEEE Standard 802.1X, December 2004.
- [IEEE-802.11] Institute of Electrical and Electronics Engineers, "Wireless LAN Medium Access Control (MAC) and Physical Layer (PHY) Specifications", IEEE Standard 802.11, 2003.
- [IEEE-802.11e] Institute of Electrical and Electronics Engineers, "Standard for Telecommunications and Information Exchange Between Systems - LAN/MAN Specific Requirements - Part 11: Wireless LAN Medium Access Control (MAC) and Physical Layer (PHY) Specifications - Amendment 8: Medium Access Control (MAC) Quality of Service Enhancements", IEEE 802.11e, November 2005. ✨
- [IEEE-802.11F] Institute of Electrical and Electronics Engineers, "IEEE Trial-Use Recommended Practice for Multi-Vendor Access Point Interoperability via an Inter-Access Point Protocol Across Distribution Systems Supporting IEEE 802.11 Operation", IEEE 802.11F, June 2003 (now deprecated). 🥀
- [IEEE-802.11i] Institute of Electrical and Electronics Engineers, "Supplement to Standard for Telecommunications and Information Exchange Between Systems - LAN/MAN Specific Requirements - Part 11: Wireless LAN Medium Access Control (MAC) and Physical Layer (PHY) Specifications: Specification for Enhanced Security", IEEE 802.11i, July 2004. 🔐
- [IEEE-802.11k] Institute of Electrical and Electronics Engineers, "Draft Amendment to Telecommunications and Information Exchange Between Systems - LAN/MAN Specific Requirements - Part 11: Wireless LAN Medium Access Control (MAC) and Physical Layer (PHY) Specifications - Amendment 7: Radio Resource Management", IEEE 802.11k/D7.0, January 2007.
- [IEEE-802.21] Institute of Electrical and Electronics Engineers, "Draft Standard for Telecommunications and Information Exchange Between Systems - LAN/MAN Specific Requirements - Part 21: Media Independent Handover", IEEE 802.21D0, June 2005.
- [Kamerman] Kamerman, A. and L. Monteban, "WaveLAN II: A High-Performance Wireless LAN for the Unlicensed Band", Bell Labs Technical Journal, Summer 1997.
- [Kim] Kim, K., Park, Y., Suh, K., and Y. Park, "The BU-trigger method for improving TCP performance over Mobile IPv6", Work in Progress, August 2004.
- [Kotz] Kotz, D., Newport, C., and C. Elliot, "The mistaken axioms of wireless-network research", Dartmouth College Computer Science Technical Report TR2003-467, July 2003. 🙈
- [Krishnan] Krishnan, R., Sterbenz, J., Eddy, W., Partridge, C., and M. Allman, "Explicit Transport Error Notification (ETEN) for Error-Prone Wireless and Satellite Networks", Computer Networks, 46 (3), October 2004.
- [Lacage] Lacage, M., Manshaei, M., and T. Turletti, "IEEE 802.11 Rate Adaptation: A Practical Approach", MSWiM '04, October 4-6, 2004, Venezia, Italy.
- [Lee] Park, S., Lee, M., and J. Korhonen, "Link Characteristics Information for Mobile IP", Work in Progress, January 2007.
- [Ludwig] Ludwig, R. and B. Rathonyi, "Link-layer Enhancements for TCP/IP over GSM", Proceedings of IEEE Infocom '99, March 1999.
- [MIPEAP] Giaretta, C., Guardini, I., Demaria, E., Bournelle, J., and M. Laurent-Maknavicius, "MIPv6 Authorization and Configuration based on EAP", Work in Progress, October 2006.
- [Mishra] Mitra, A., Shin, M., and W. Arbaugh, "An Empirical Analysis of the IEEE 802.11 MAC Layer Handoff Process", CS-TR-4395, University of Maryland Department of Computer Science, September 2002.
- [Morgan] Morgan, S. and S. Keshav, "Packet-Pair Rate Control - Buffer Requirements and Overload Performance", Technical Memorandum, AT&T Bell Laboratories, October 1994.
- [Mun] Mun, Y. and J. Park, "Layer 2 Handoff for Mobile-IPv4 with 802.11", Work in Progress, March 2004.
- [ONOE] Onoe Rate Control, <http://madwifi.org/browser/trunk/ath_rate/onoe>.
- [Park] Park, S., Njedjou, E., and N. Montavont, "L2 Triggers Optimized Mobile IPv6 Vertical Handover: The 802.11/GPRS Example", Work in Progress, July 2004.
- [Pavon] Pavon, J. and S. Choi, "Link adaptation strategy for IEEE802.11 WLAN via received signal strength measurement", IEEE International Conference on Communications, 2003 (ICC '03), volume 2, pages 1108-1113, Anchorage, Alaska, USA, May 2003.
- [PEAP] Palekar, A., Simon, D., Salowey, J., Zhou, H., Zorn, G., and S. Josefsson, "Protected EAP Protocol (PEAP) Version 2", Work in Progress, October 2004.
- [PRNET] Jubin, J. and J. Tornow, "The DARPA packet radio network protocols", Proceedings of the IEEE, 75(1), January 1987.
- [Qiao] Qiao D., Choi, S., Jain, A., and Kang G. Shin, "MiSer: An Optimal Low-Energy Transmission Strategy for IEEE 802.11 a/h", in Proc. ACM MobiCom'03, San Diego, CA, September 2003.
- [RBAR] Holland, G., Vaidya, N., and P. Bahl, "A Rate-Adaptive MAC Protocol for Multi-Hop Wireless Networks", Proceedings ACM MOBICOM, July 2001.
- [Ramani] Ramani, I. and S. Savage, "SyncScan: Practical Fast Handoff for 802.11 Infrastructure Networks", Proceedings of the IEEE InfoCon 2005, March 2005.
- [Robust] Wong, S., Yang, H., Lu, S., and V. Bharghavan, "Robust Rate Adaptation for 802.11 Wireless Networks", ACM MobiCom'06, Los Angeles, CA, September 2006.
- [SampleRate] Bicket, J., "Bit-rate Selection in Wireless networks", MIT Master's Thesis, 2005.
- [Scott] Scott, J., Mapp, G., "Link Layer Based TCP Optimisation for Disconnecting Networks", ACM SIGCOMM Computer Communication Review, 33(5), October 2003.
- [Schuetz] Schutz, S., Eggert, L., Schmid, S., and M. Brunner, "Protocol Enhancements for Intermittently Connected Hosts", ACM SIGCOMM Computer Communications Review, Volume 35, Number 2, July 2005.
- [Shortest] Douglas S. J. De Couto, Daniel Aguayo, Benjamin A. Chambers and Robert Morris, "Performance of Multihop Wireless Networks: Shortest Path is Not Enough", Proceedings of the First Workshop on Hot Topics in Networking (HotNets-I), Princeton, New Jersey, October 2002.
- [TRIGTRAN] Dawkins, S., Williams, C., and A. Yegin, "Framework and Requirements for TRIGTRAN", Work in Progress, August 2003.
- [Vatn] Vatn, J., "An experimental study of IEEE 802.11b handover performance and its effect on voice traffic", TRITA-IMIT-TSLAB R 03:01, KTH Royal Institute of Technology, Stockholm, Sweden, July 2003.
- [Velayos] Velayos, H. and G. Karlsson, "Techniques to Reduce IEEE 802.11b MAC Layer Handover Time", TRITA-IMIT-LCN R 03:02, KTH Royal Institute of Technology, Stockholm, Sweden, April 2003.
- [Vertical] Zhang, Q., Guo, C., Guo, Z., and W. Zhu, "Efficient Mobility Management for Vertical Handoff between WWAN and WLAN", IEEE Communications Magazine, November 2003.
- [Villamizar] Villamizar, C., "OSPF Optimized Multipath (OSPF-OMP)", Work in Progress, February 1999.
- [Xylomenos] Xylomenos, G., "Multi Service Link Layers: An Approach to Enhancing Internet Performance over Wireless Links", Ph.D. thesis, University of California at San Diego, 1999.
- [Yegin] Yegin, A., "Link-layer Triggers Protocol", Work in Progress, June 2002.
6. Acknowledgments 🫶
The authors want to give a massive shoutout to James Kempf, Phil Roberts, Gorry Fairhurst, John Wroclawski, Aaron Falk, Sally Floyd, Pekka Savola, Pekka Nikander, Dave Thaler, Yogesh Swami, Wesley Eddy, and Janne Peisa for their contributions to this document. The real MVPs 👑💖
Appendix A. Literature Review 📚
This appendix is a roundup of the literature on link indications over wireless local area networks. Lots of research to dig through, bestie 🧚✨
A.1. Link Layer 📡✨
okay so wireless links are literally so inconsistent, and it depends SO much on where you are 🌈 the characteristics vary a lot from environment to environment, and that's the big vibe here 💅
In "Performance of Multihop Wireless Networks: Shortest Path is Not Enough" [Shortest], the authors looked at how an indoor mesh network and an outdoor mesh network performed 🌸 they measured throughput between nodes to figure out the best path, then compared that with the path you'd get from the shortest hop count. the shortest-hop path was way slower than the best path in almost every case 😭
the authors also noticed that links weren't just "up" (low loss rate) or "down" (high loss rate) like a light switch 💡 a lot of links sat in the middle, and asymmetry was super common too. about 30 percent of links had really different loss rates in each direction 🙈 which means measured throughput can be way off from the negotiated rate because of retransmissions. and just because routing packets get delivered doesn't mean the link is good enough for data, bestie 🫶
In "Measurement and Analysis of the Error Characteristics of an In-Building Wireless Network" [Eckhardt], the authors checked out an AT&T Wavelan 2 Mbps in-building WLAN running in Infrastructure mode on the Carnegie Mellon campus 🎓 frame loss was super low in that study, so links could basically be assumed to work either very well or not at all ✨
In "Link-level Measurements from an 802.11b Mesh Network" [Aguayo], the authors dug into why frames get lost in a 38-node urban multi-hop 802.11 ad-hoc network 🏙️ most of the time, a link that's really bad one way is bad both ways, and a link that's really good one way is good both ways. but again, 30 percent of links had loss rates that were noticeably different in each direction 👀
signal to noise ratio (SNR) and distance were not great at predicting loss rates, honestly 🙃 instead of a clean step between "up" (low loss) and "down" (high loss), inter-node loss rates were all over the place, pretty much evenly spread across the lower rates. the authors blamed multi-path fading, not attenuation or interference 🌊
so [Eckhardt] and [Aguayo] together show just how different link conditions can be in the real world 🦋 indoor infrastructure networks can get closer to ideal with site surveys and careful measurement, but in ad-hoc and mesh networks, node mobility and stuff like weather are hard to control. it's giving unpredictable, and that's the point 🌦️
⚠️ implementation effects are a whole other chaos wave too. the difference between devices can be wild, bestie 😭
"Techniques to reduce IEEE 802.11b MAC layer handover time" [Velayos] measured handover times for a stationary STA after the AP got turned off 🔌 they split handover into three phases: detection (figuring out you've been disconnected from your current point of attachment), search (finding alternative attachment points), and execution (connecting to an alternative point of attachment) 🧩 the detection phase was the biggest chunk of handoff delay, and it was set by how many non-acknowledged frames it took to trigger the search phase, plus delays from things like RTS/CTS and rate adaptation 🕰️
detection behavior was all over the place between implementations 💀 for example, network interface cards (NICs) built for desktops kept retransmitting more before triggering search than laptop designs did. the desktop ones assumed the AP was always in range, no matter whether the Beacon was received 🖥️
the study recommends shortening the detection phase by starting the search phase as soon as collisions can be ruled out as the cause of the non-acknowledged transmissions 🎯 the authors recommend three consecutive transmission failures as the cutoff. honestly this approach is both quicker and more immune to multi-path interference than watching the SNR 👑 when a STA isn't sending or receiving frames, it's recommended to track Beacon reception so it can detect disconnection, and to reduce Beacon spacing to 60 ms so detection is faster ⏱️ to make up for triggering the search phase more often, the authors recommend wait time reduction algorithms, plus interleaving search and data frame transmission 🧁
"An Empirical Analysis of the IEEE 802.11 MAC Layer Handoff Process" [Mishra] looked at handoff latencies across three mobile STA implementations talking to two APs 📶 the big takeaway was that handoff latency varies a LOT between STA and AP implementations, and they use different message sequences too. one STA sent a Reassociation Request before authentication, which got it a Deauthenticate message back 😂 the study split handoff latency into discovery, authentication, and reassociation exchanges, and discovery was the dominant part of handoff delay. the detection phase wasn't investigated at all 🙈
"SyncScan: Practical Fast Handoff for 802.11 Infrastructure Networks" [Ramani] weighs the pros and cons of active versus passive scanning ⚖️ the authors love the advantages of timed Beacon reception, which had already been added to [IEEE-802.11k] 💜 timed Beacon reception lets the station stay up to date on the signal to noise ratio of neighboring APs, so handoff can happen earlier 🚀 the station doesn't have to wait around for initial and subsequent responses to a broadcast Probe Response (MinChannelTime and MaxChannelTime, respectively), so performance is comparable to what you'd get with 802.11k Neighbor Reports and unicast Probe Requests 🍓
the authors measured channel switching delay, which is how long it takes to switch to a new frequency and start receiving frames 🔄 it ranged from 5 ms to 19 ms per channel. where timed Beacon reception or interleaved active scanning is used, switching time adds a big chunk to overall handoff latency 🧠 the authors propose deploying APs with Beacons synchronized via Network Time Protocol (NTP) [RFC1305], so a driver implementing SyncScan can work with legacy APs without needing any new protocols 🎀 they also measured the distribution of inter-arrival times for stations implementing SyncScan, and the results were excellent 🌟
"Roaming Interval Measurements" [Alimian] shares data on how stationary STAs behave after the AP signal has been shut off 📴 this study highlighted implementation differences in rate adaptation, as well as in detection, scanning, and handoff. just like [Velayos], performance varied widely between implementations: about half an order of magnitude of variation in rate adaptation, an order of magnitude difference in detection times, two orders of magnitude in scanning, and one and a half orders of magnitude in handoff times 📊 that's a LOT of range, periodt 💅
"An experimental study of IEEE 802.11b handoff performance and its effect on voice traffic" [Vatn] describes the handover behavior observed when the signal from the AP is gradually attenuated 🌅 the authors say this is more representative of field experience than the shutoff techniques used in [Velayos] 🙌 stations were set up to start handover when signal strength dropped below a threshold, instead of relying purely on frame loss, so they could begin handover while still connected to the current AP 🪄 it was also noted that stations kept receiving data frames during the search phase ✨ and station-initiated Disassociation and pre-authentication were not observed in this study 🦋
A.1.1. Link Indications
Okay so, within a link layer, what "Link Up" and "Link Down" actually mean can change depending on the deployment scenario 💅 For example, in PPP [RFC1661], either peer can send an LCP-Terminate frame to shut down the PPP link layer 🔌, and a link only counts as usable for sending network protocol packets once Network Control Protocol (NCP) negotiation has finished for that protocol ✨
Unlike PPP, IEEE 802 doesn't come with any facilities for network layer configuration 🙈 So the definition of "Link Up" and "Link Down" varies from implementation to implementation. Empirical evidence suggests it can depend on whether the station is mobile or stationary, whether infrastructure or ad-hoc mode is being used, and whether security and Inter-Access Point Protocol (IAPP) is implemented. It's giving "it depends" energy, fr fr 🌈
Here's a tea moment ☕ If a STA runs into a series of consecutive non-acknowledged frames while it has missed one or more Beacons, the most likely cause is that the station has wandered out of range of the AP 🚶♀️ So [Velayos] recommends that the station start the search phase once collisions can be ruled out. Since this approach doesn't take rate adaptation into account, it might be a bit aggressive 😬 Only when no alternative workable rate or point of attachment is found does a "Link Down" indication get returned.
In a stationary point-to-point installation, the most likely cause of an outage is that the link has become impaired, and alternative points of attachment may not be available 🧱 So implementations set up to operate in this mode tend to be more persistent 💪 For example, within 802.11 the short interframe space (SIFS) interval may be increased, and the MIB variables for timeouts (like dot11AuthenticationResponseTimeout, dot11AssociationResponseTimeout, dot11ShortRetryLimit, and dot11LongRetryLimit) may be set to larger values ⏳ Also, a "Link Down" indication may be returned later on, which is very patient of it 🦋
In IEEE 802.11 ad-hoc mode with no security, reception of data frames is enabled in State 1 ("Unauthenticated" and "Unassociated"). So reception of data frames is enabled at any time, and there's no explicit "Link Up" indication at all 👀
In Infrastructure mode, IEEE 802.11-2003 only enables reception of data frames in State 3 ("Authenticated" and "Associated") 🎀 That means a transition to State 3 (like completing a successful Association or Reassociation exchange) enables sending and receiving of network protocol packets. A transition from State 3 to State 2 (on receipt of a "Disassociate" frame) or to State 1 (on receipt of a "Deauthenticate" frame) disables sending and receiving of network protocol packets. So IEEE 802.11 stations typically signal "Link Up" when they get a successful Association/Reassociation Response 🫶
Now the spoofing drama 😭 As described within [IEEE-802.11F], after sending a Reassociation Response, an Access Point will send a frame with the station's source address to a multicast destination. This makes the switches inside the Distribution System (DS) update their learning tables, so the DS is ready to forward frames to the station at its new point of attachment 🔁 If the AP didn't send this "spoofed" frame, the station's location wouldn't get updated within the distribution system until it sends its first frame from the new location. So the whole point of spoofing is to even out uplink and downlink handover times ⚖️ BUT here's the catch: this lets an attacker deny service to authenticated and associated stations by spoofing a Reassociation Request using the victim's MAC address, from anywhere within the ESS 💀 Without spoofing, that attack could only disassociate stations on the AP the Reassociation Request was sent to. Not it, hacker 🙅♀️
Signaling "Link Down" is honestly way more complicated 🌀 Even though a transition to State 2 or State 1 means the station can't send or receive IP packets, that doesn't automatically mean the transition should count as a "Link Down" indication. In an infrastructure network, a station might have a choice of multiple Access Points offering a connection to the same network 🗺️ In that situation, a station that can't reach State 3 with one Access Point might just choose to attach to another one instead. So rather than registering a "Link Down" indication with each move, the station may register a series of "Link Up" indications instead ✨
In [IEEE-802.11i], forwarding frames from the station to the distribution system is only feasible after the 4-way handshake and group-key handshake have completed, so entering State 3 is no longer sufficient 🔐 This has caused several observed problems. For example, when a "Link Up" indication gets triggered on the station by receipt of an Association/Reassociation Response, DHCP [RFC2131] or Router Solicitation/Router Advertisement (RS/RA) may kick off before the link is actually usable by the Internet layer 😩 That leads to configuration delays or failures. Similarly, transport layer connections will run into packet loss, which results in back-off of retransmission timers. Ugh, so relatable 💜
A.1.2. Smart Link Layer Proposals
Okay, so in order to improve link layer performance, several studies have looked into "smart link layer" proposals 🧠✨
"Advice to link designers on link Automatic Repeat reQuest (ARQ)" [RFC3366] gives advice to designers of digital communication equipment and link-layer protocols that use link-layer Automatic Repeat reQuest (ARQ) techniques for IP 🛠️ It talks about the use of ARQ, timers, persistency in retransmission, and the challenges that come up from sharing links between multiple flows and from different transport requirements. Very thorough, very iconic 📚
In "Link-layer Enhancements for TCP/IP over GSM" [Ludwig], the authors describe how the Global System for Mobile Communications (GSM) reliable and unreliable link layer modes can be used at the same time without any higher layer control 📱 When a reliable link layer protocol is needed (where reliable transports such as TCP and Stream Control Transmission Protocol (SCTP) [RFC2960] are used), the Radio Link Protocol (RLP) can be engaged. For delay-sensitive applications, like those based on UDP, the transparent mode (no RLP) can be used 🦋 The authors also describe how PPP negotiation can be optimized over high-latency GSM links using "Quickstart-PPP" 🚀
In "Link Layer Based TCP Optimisation for Disconnecting Networks" [Scott], the authors describe performance problems that happen with reliable transport protocols when they face periodic network disconnections, like the ones caused by signal fading or handoff 📉 They define a disconnection as a period of connectivity loss that exceeds a retransmission timeout but is shorter than the connection lifetime. One issue is that link-unaware senders keep backing off during periods of disconnection 😤 The authors suggest that a link-aware reliable transport implementation halt retransmission after receiving a "Link Down" indication. Another issue is that, on reconnection, the lengthened retransmission times cause delays in using the link 🐢
To make things faster, a "smart link layer" is proposed. It stores the first packet that wasn't successfully transmitted on a connection, then retransmits it when it gets a "Link Up" indication 🔄 Since a disconnection can leave hosts facing different network conditions on reconnection, the authors don't advocate bypassing slow start or trying to raise the congestion window 🙅♀️ Where IPsec is used and connections can't be told apart because transport headers aren't visible, the first untransmitted packet for a given sender and destination IP address can be retransmitted instead. Beyond retransmitting a single packet per connection, the authors also looked at other schemes, like retransmitting multiple packets and simulated duplicate reception of single or multiple packets (known as rereception) 🧩
In general, retransmission schemes beat rereception schemes, since rereception can't stimulate fast retransmit after a timeout 🏆 Retransmitting multiple packets didn't really improve performance over retransmitting a single packet. And because the research focused on disconnection rather than just lossy channels, a two-state Markov model was used, with the "up" state representing no loss and the "down" state representing 100 percent loss 📊
In "Multi Service Link Layers: An Approach to Enhancing Internet Performance over Wireless Links" [Xylomenos], the authors use ns-2 to simulate the performance of various link layer recovery schemes. These are: raw link without retransmission, go back N, XOR-based FEC, selective repeat, Karn's RLP, out-of-sequence RLP, and Berkeley Snoop. They tested them in stand-alone file transfer, Web browsing, and continuous media distribution 🎬 Selective repeat and Karn's RLP gave the highest throughput for file transfer and Web browsing, but continuous media distribution needs a combo of low delay and low loss, and out-of-sequence RLP performed best there 🎵 Since no single link layer recovery scheme is optimal for every application, the authors propose that the link layer implement multiple recovery schemes 🌈 Their simulations showed that pairing a low-error rate recovery scheme for TCP (like Karn's RLP) with a low-delay scheme for UDP traffic (like out-of-sequence RLP) performs well in all scenarios 👑 The authors then describe how a multi-service link layer can be integrated with Differentiated Services 💖
In "WaveLAN-II: A High-Performance Wireless LAN for the Unlicensed Band" [Kamerman], the authors propose an open-loop rate adaptation algorithm known as Automatic Rate Fallback (ARF) 📶 In ARF, the sender adjusts the rate upwards after a fixed number of successful transmissions, and adjusts it downwards after one or two consecutive failures. If the transmission fails right after an upwards rate adjustment, the rate is immediately readjusted downwards 📉
In "A Rate-Adaptive MAC Protocol for Multi-Hop Wireless Networks" [RBAR], the authors propose a closed-loop rate adaptation approach that requires incompatible changes to the IEEE 802.11 MAC 🔧 To help the sender pick the transmission rate better, the receiver determines the packet length and signal to noise ratio (SNR) of a received RTS frame, then calculates the corresponding rate based on a theoretical channel model, rather than on channel usage statistics 🧮 The recommended rate is sent back in the CTS frame. This lets the rate (and potentially the transmit power) get optimized on each transmission, albeit at the cost of needing RTS/CTS for every frame transmission. Big commitment, bestie 💅
In "MiSer: An Optimal Low-Energy Transmission Strategy for IEEE 802.11 a/h" [Qiao], the authors propose a scheme for optimizing transmit power ⚡ The proposal mandates the use of RTS/CTS to deal with hidden nodes, and requires that CTS and ACK frames be sent at full power. The authors use a theoretical channel model rather than one based on channel usage statistics 🌸
okay so in "IEEE 802.11 Rate Adaptation: A Practical Approach" [Lacage] 🎀 the authors split things into two camps: low-latency implementations, which can make rate decisions per packet, and high-latency ones, which can't. the low-latency crew usually has dedicated CPUs in the design so it can hit real-time requirements 💅. the high-latency crew is usually highly integrated, with the upper MAC running on the host, so because of OS latencies the info needed for a per-packet rate decision might not show up in time 😭
for the low-latency side they propose an Adaptive ARF (AARF) algorithm ✨. when an ACK doesn't come back, it drops the rate fast, but it wants more successful transmissions before it'll go back up. so it's super stable when channel properties change slowly, but slow to adapt upwards when conditions get better 🙈. to test it they used ns-2 simulations and also built a version for a high-latency chipset, the AR 5212 🧚. the Multiband Atheros Driver for WiFi (MadWiFi) driver lets you queue a fixed schedule of rates and retries when a frame is ready to go. the adapted version, the Adaptive Multi Rate Retry (AMRR), asks for just one transmission at each of three rates, and the last one is the minimum available rate 🔥. that means it can adjust to short-term channel fluctuations with minimal latency, and the AMRR algorithm performs considerably better than the existing MadWifi driver 👑.
in "Link Adaptation Strategy for IEEE 802.11 WLAN via Received Signal Strength Measurement" [Pavon] 🌸, the authors propose an algorithm where a STA adjusts its transmission rate by comparing the received signal strength (RSS) from the AP against dynamically estimated threshold values for each rate. when a frame comes in, the STA updates its average RSS, and when it transmits, it picks a rate and adjusts the RSS threshold values depending on whether the transmission worked 💜. to validate it they ran an OPNET simulation with no interference, and they assumed an ideal bit error rate (BER) vs. signal to noise ratio (SNR) curve. not surprisingly 💅, the simulation results closely matched the maximum throughput achievable for a given SNR, based on that ideal BER vs. SNR curve.
in "Hybrid Rate Control for IEEE 802.11" [Haratcherev] 🦋, the authors describe a hybrid technique that uses Signal Strength Indication (SSI) data to constrain the rates that statistics-based automatic rate control can pick. okay so statistics-based rate control techniques come in a few flavors:
Maximum Throughput: this one was picked as the statistics-based part of the hybrid scheme. it sends a fraction of data at adjacent rates to figure out which rate gives the maximum throughput. accurate throughput estimates need a minimum number of frames at each rate, and only a fraction of frames get used for this, so it adapts more slowly at lower rates. with 802.11b rates, the adaptation time scale is typically on the order of a second 😭. depending on how many rates get tested, it can adapt beyond adjacent rates. but where the maximum rate and low frame loss are already being hit, this technique ends up with lower throughput.
Frame Error Rate (FER) Control: this one estimates the FER and tries to keep it between a lower limit (if FER drops below it, increase the rate) and an upper limit (if FER goes above it, decrease the rate) 🌈. since it can use all the transmitted data, it can react faster than the maximum throughput techniques. the catch is a tradeoff between reaction time and FER estimation accuracy: at lower rates, either reactions slow down or the FER estimate gets worse. and since it only measures FER at the current rate, it can only adapt to adjacent rates.
Retry-based: this one tweaks FER control by allowing rapid downward rate adaptation after a number (5-10) of unsuccessful retransmissions ⭐. fewer packets are needed, so the sensitivity of reaction time to rate goes down. but upward adaptation is slower, since it's based on a collection of FER data. it's also limited to adjacent rates, and it has the downside of potentially making frame loss worse due to contention 💀.
while statistics-based techniques are robust against short-lived link quality changes, they don't respond quickly to long-lived changes 🫶. by constraining the rate that statistics-based techniques can select, based on ACK SSI versus rate data (not theoretical curves), the authors got faster link adaptation. to keep adaptation quick during rapidly varying conditions, the rate constraints get tightened when the SSI values are changing rapidly, which encourages rate transitions ✨. the authors validated their algorithms by implementing a driver for the Atheros AR5000 chipset and then testing how it responded to being inserted into and removed from a microwave oven acting as a Faraday cage 🙈. the hybrid algorithm dropped many fewer packets than the maximum throughput technique by itself.
to estimate the SSI of data at the receiver, they used the ACK SSI. this means the receiver doesn't have to tell the sender the received power, so it can be implemented without changing the IEEE 802.11 MAC 🔥. calibrating the rate versus ACK SSI curves doesn't require a symmetric channel, but it does require that channel properties in both directions vary in a proportional way and that the ACK transmit power stays constant. the authors checked the proportionality assumption and found that the SSI of received data correlated highly (74%) with the SSI of received ACKs. low pass filtering and monotonicity constraints were applied to remove noise from the rate versus SSI curves. the resulting hybrid rate adaptation algorithm could respond to rapid deterioration (and improvement) in channel properties, since it isn't restricted to moving to adjacent rates 👑.
in "CARA: Collision-Aware Rate Adaptation for IEEE 802.11 WLANs" [CARA] 💖, the authors propose Collision-Aware Rate Adaptation (CARA). it uses Clear Channel Assessment (CCA), along with adapting the Request-to-Send/Clear-to-Send (RTS/CTS) mechanism, to tell apart losses caused by frame collisions from losses caused by channel conditions. rather than decreasing the rate because of frame loss from collisions (which just leads to even more contention), CARA selectively enables RTS/CTS (for example, after a frame loss), which reduces the likelihood of frame loss due to hidden stations 🦋. CARA can also use CCA to figure out whether a collision happened after a transmission. however, since CCA may not detect a significant fraction of all collisions (particularly when transmitting at a low rate), its use is optional 🤷♀️. compared with ARF, the authors' simulations show large improvements in aggregate throughput from adaptive RTS/CTS, with additional modest improvements when CCA helps too 🌈.
in "Robust Rate Adaptation for 802.11 Wireless Networks" [Robust] 🧚, the authors implemented the ARF, AARF, and SampleRate [SampleRate] algorithms on a programmable Access Point platform. they experimentally examined how these algorithms performed, along with the ONOE [ONOE] algorithm implemented in MadWiFi. based on those experiments, the authors critically examine the assumptions underlying existing rate negotiation algorithms, and honestly the takes are so good 😭:
Decrease transmission rate upon severe frame loss: where severe frame loss comes from channel conditions, rate reduction can improve throughput. but where frame loss is due to contention (such as from hidden stations), reducing the rate increases congestion, lowers throughput, and could lead to congestive collapse 💀. instead, the authors propose adaptively enabling RTS/CTS to reduce contention from hidden stations. once RTS/CTS is on, the remaining losses are more likely to be due to channel conditions, which gives more reliable guidance on whether to raise or lower the rate.
Use probe frames to assess possible new rates: probe frames reliably estimate frame loss at a given rate only if the sample size is sufficient and the probe frames are about the same length as data frames. the authors argue that rate adaptation schemes like SampleRate are too sensitive to losing probe packets. to meet sample size constraints, you'd need a significant number of probe frames, which can increase frame loss if the probed rate is too high, and can lower throughput if the probed rate is too low 😬. instead, the authors propose assessing channel condition by tracking the frame loss ratio within a window of 5 to 40 frames ✨.
Use consecutive transmission successes/losses to increase/decrease rate: the authors argue that consecutive successes or losses aren't a reliable basis for rate increases or decreases. a greater sample size is needed 🙈.
Use PHY metrics like SNR to infer new transmission rate: the authors argue that received signal to noise ratio (SNR) routinely varies 5 dB per packet, and variations of 10-14 dB are common 🌊. as a result, rate decisions based on SNR or signal strength can make the transmission rate vary rapidly. the authors question the value of that rapid variation, since studies such as [Aguayo] show little correlation between SNR and frame loss probability. so the authors argue that neither received signal strength indication (RSSI) nor background energy level can be used to tell losses due to contention apart from those due to channel conditions. multi-path interference can cause high signal strength and frame loss at the same time, but the relationship between low signal strength and high frame loss is stronger 💅. therefore, transmission rate decreases due to low received signal strength probably do reflect sudden worsening of channel conditions, although sudden increases may not necessarily mean channel conditions have improved 🫶.
Long-term smoothened operation produces best average performance: the authors present evidence that frame losses more than 150 ms apart are uncorrelated. so collecting statistical data over intervals of 1 second or greater reduces responsiveness without improving the quality of transmission rate decisions 😭. instead, the authors argue that a sampling period of 100 ms gives the best average performance. such small sampling periods also argue against using probes, since probe packets can only represent a fraction of all data frames, and probes collected more than 150 ms apart may not provide reliable information on channel conditions 🎀.
okay so the authors looked at all those flaws and said "bestie, we can do better" 💅 and built the Robust Rate Adaptation Algorithm (RRAA) ✨. The big glow-up is that RRAA only looks at the frame loss ratio at the current transmission rate to decide whether to go up or down. No PHY layer info, no probe packets, just vibes and loss numbers 🦋. Each transmission rate gets its own estimation window, a maximum tolerable loss threshold (MTL), and an opportunistic rate increase threshold (ORI) 🎀. If the loss ratio is bigger than the MTL, the rate drops. If it's smaller than the ORI, the rate goes up. If it's in between, the rate just stays put 🌸. The thresholds are picked to maximize throughput 👑. RRAA only moves between adjacent transmission rates, but it doesn't wait for a full estimation window before changing anything. If more data wouldn't change the decision, it switches right away ⚡. No waiting around, iconic 💖.
The authors tested RRAA with experiments and field trials, and it came out on top 🔥. Without adaptive RTS/CTS, it beat ARF, AARF, and Sample Rate. Why? It's not as shook by transient frame loss and it doesn't do probing, so it can hang out at higher transmission rates more often 🧚. Where there are no hidden stations, turning adaptive RTS/CTS on only costs a few percent at most 🙈. But where hidden stations are causing a lot of contention, adaptive RTS/CTS gives huge gains, because fewer frames get lost and that lets you pick a higher transmission rate 💜.
In "Efficient Mobility Management for Vertical Handoff between WWAN and WLAN" [Vertical], the authors use signal strength and link utilization to make vertical handoff smoother 🌈. WLAN to WWAN handoff is driven by SSI decay. When IEEE 802.11 SSI drops below a threshold (S1), they run Fast Fourier Transform (FFT)-based decay detection to see if the signal is likely to keep sliding 📉. If it is, the handoff to the WWAN starts once the signal falls below the minimum acceptable level (S2) ✨. WWAN to WLAN handoff is driven by both PHY and MAC characteristics of the IEEE 802.11 target network 🦋. At the PHY layer, things like SSI get checked to see if the signal strength is greater than a minimum value (S3) 📶. At the MAC layer, they look at the IEEE 802.11 Network Allocation Vector (NAV) occupation to estimate the maximum available bandwidth and mean access delay 🍓. Note that depending on the value of S3, the negotiated rate can end up lower than the available bandwidth 👀. To stop premature handoff between WLAN and WWAN, S1 and S2 are separated by 6 dB 🎀. To stop the device from oscillating between WLAN and WWAN media, S3 needs to be greater than S1 by an appropriate margin 💅.
A.2. Internet Layer ✨
Up in the Internet layer, people have proposed using link indications to optimize IP configuration, to make routing metrics more useful, and to tune parts of Mobile IP handoff 🌸.
In "Analysis of link failures in an IP backbone" [Iannaccone], the authors dig into link failures in Sprint's IP backbone 🔍. They figure out what causes convergence delay, including delays in detecting whether an interface is down or up 😭. It's fastest for a router to use link indications when they're available, but sometimes it has to rely on losing routing packets to figure out what the link is doing 🫶. Once the link state is known, the routing protocol might add a delay to dampen link flaps 🌊. And then there can be another delay when propagating the link state change, which rate limits link state advertisements and guards against instability 🛡️.
"Bidirectional Forwarding Detection" [BFD] points out that link layers may only give limited failure indications, and that routing protocols use relatively slow "Hello" mechanisms to detect failures when no link layer indications are available 🐢. That means failure detection times on the order of a second, which is way too long for some applications 💀. The authors describe a mechanism for liveness detection over any media, so failures in the path between adjacent forwarding engines can be detected rapidly ⚡. A path is declared operational once bidirectional reachability has been confirmed 💜.
In "Detecting Network Attachment (DNA) in IPv4" [RFC4436], a host that has moved to a new point of attachment runs a bidirectional reachability test in parallel with DHCP [RFC2131]. This lets it quickly reconfirm a working configuration 🧚.
In "L2 Triggers Optimized Mobile IPv6 Vertical Handover: The 802.11/GPRS Example" [Park], the authors suggest that the mobile node sends a router solicitation when it gets a "Link Up" indication 🎀. That gives lower handoff latency than generic movement detection [RFC3775] can manage 🚀. The authors also suggest immediately invalidating the Care-of Address (CoA) when a "Link Down" indication arrives 🙈. But that's problematic when a "Link Down" indication can be followed by a "Link Up" indication without any resulting change in IP configuration, as described in [RFC4436] 😬.
In "Layer 2 Handoff for Mobile-IPv4 with 802.11" [Mun], the authors suggest carrying MIPv4 Registration messages inside Information Elements of IEEE 802.11 Association/Reassociation frames, to cut down on handoff delays 💫. This needs changes to the mobile node as well as the 802.11 APs 🛠️. But before a node has detected network attachment, it's hard for it to tell whether the new point of attachment is actually a change of network 🤔. For example, even when a station stays within the same ESS, the network can still change 😳. If no change of network happens, sending a MIPv4 Registration message with each Association/Reassociation is unnecessary 🙅♀️. If a change of network does happen, the mobile node usually can't predict its new CoA at Association/Reassociation. A DHCP server might assign a CoA that was never given to the mobile node before 🎲. And when dynamic VLAN assignment is used, the VLAN isn't even determined until IEEE 802.1X authentication finishes, which happens after Association/Reassociation in [IEEE-802.11i] 📋.
In "Link Characteristics Information for Mobile IP" [Lee], link characteristics go along in the registration/Binding Update messages the mobile node sends to the home agent and correspondent node 📨. When the mobile node is acting as a receiver, this lets the correspondent node adjust its transport parameters window faster than it otherwise could 🏃♀️. Link characteristics that can be communicated include the link type (e.g., 802.11b, CDMA (Code Division Multiple Access), GPRS (General Packet Radio Service), etc.) and link bandwidth 📡. The document suggests the correspondent node should adjust its sending rate based on the advertised link bandwidth, but that might not be wise in some situations 🤨. For example, if the mobile node's link isn't the bottleneck, adjusting the sending rate based on the link bandwidth could cause congestion 🚧. Also, if the transmission rate changes often, sending registration messages on every change could eat up a lot of bandwidth by itself 💸. Even when the advertised link characteristics suggest a smaller congestion window is needed, it can be non-trivial to adjust the sending rates of individual connections when there are several open between a mobile node and correspondent node 🧩. A more conservative approach would be to trigger parameter re-estimation and slow start based on receiving a registration message or Binding Update 🐌.
In "Hotspot Mitigation Protocol (HMP)" [HMP], it's noted that Mobile Ad-hoc NETwork (MANET) routing protocols have a tendency to concentrate traffic, since they use shortest-path metrics and let nodes answer route queries with cached routes 🌋. The authors propose that nodes in an ad-hoc wireless mesh monitor local conditions like MAC delay, buffer consumption, and packet loss 👀. When congestion is detected, it gets communicated to neighboring nodes through an IP option 📣. In response to moderate congestion, nodes suppress route requests. When major congestion is detected, nodes rate control the transport connections flowing through them 🚦. The authors argue that for ad-hoc networks, throttling by intermediate nodes works better than end-to-end congestion control mechanisms 🫶.
A.3. Transport Layer 🦋
In the transport layer, proposals have focused on countering handoff-induced packet loss and non-congestive loss caused by lossy wireless links 🌧️.
When a mobile host moves to a new network, the transport parameters (including the RTT, RTO, and congestion window) may no longer be valid 😵. If the path change happens on the sender (e.g., a change in outgoing or incoming interface), the sender can reset its congestion window and parameter estimates ✅. But if it happens on the receiver, the sender may not even know the path changed 👻.
In "The BU-trigger method for improving TCP performance over Mobile IPv6" [Kim], the authors note that the transport layer reads handoff-related packet loss as congestion 🚨. When the correspondent node is sending to the mobile node, they propose that receiving a Binding Update at the correspondent node be used as a signal to the transport layer to adjust cwnd and ssthresh values, which may have been reduced because of handoff-induced packet loss 💫. The authors recommend recovering cwnd and ssthresh to pre-timeout values, whether or not the link parameters have changed 🔄. The paper doesn't discuss what a mobile node does when it's sending a Binding Update while it's sending to the correspondent node 🤷♀️.
In "Effect of Vertical Handovers on Performance of TCP-Friendly Rate Control" [Gurtov], the authors look at how explicit handover notifications affect TCP-friendly rate control (TFRC) 📊. When an explicit handover notification includes information on the loss rate and throughput of the new link, it can be used to change the sender's transmission rate instantly ⚡. The authors also found that resetting the TFRC receiver state after handover lets parameter estimates adjust more quickly 🏁.
A.4. Application Layer ✨
okay so the application layer has its own little drama too 🎀 A team looked at [Haratcherev2] and it's giving smart coupling. Rate info from a link layer that uses improved rate adaptation algorithms gets passed up to a video app, and the app uses it to adapt its codec 🎬 Linking the link and application layers led to major wins in Peak Signal to Noise Ratio (PSNR) 📈 ngl that's iconic, BUT there's a catch 🙈 this approach assumes the link is the path's bottleneck bandwidth, so it isn't universally applicable over the Internet 🌐
Next up, presence systems! 💜 Someone proposed using "Link Down" indications to make them better. Here's the tea: client devices keep refreshing their presence state using application layer protocols like SIP for Instant Messaging and Presence Leveraging Extensions (SIMPLE) [RFC3428] or Extensible Messaging and Presence Protocol (XMPP) [RFC3921] 💬 If a client gets disconnected, nobody notices its unavailability until the presence status times out, and that can take many minutes 😭 That's literally so long, bestie.
BUT if the link goes down and a disconnect indication can be sent to the presence server (presumably by the Access Point, which stays connected 🧚), the user's status can update nearly instantaneously ⚡ Main character energy for the status bar, fr fr 💅✨
Appendix B. IAB Members at the Time of This Writing ✨
Okay so bestie, this is the little roll call at the end of the doc 🎀 It's the IAB members who were around when this got written. Iconic lineup, no cap 👑
- Bernard Aboba
- Loa Andersson
- Brian Carpenter
- Leslie Daigle
- Elwyn Davies
- Kevin Fall
- Olaf Kolkman
- Kurtis Lindqvist
- David Meyer
- David Oran
- Eric Rescorla
- Dave Thaler
- Lixia Zhang
Author's Address 💌
Bernard Aboba, Ed. is the one listed as the author, and he's at Microsoft Corporation, One Microsoft Way, Redmond, WA 98052 🌸
EMail: bernarda@microsoft.com Phone: +1 425 706 6605 Fax: +1 425 936 7329
There's also an IAB contact entry, reachable at:
EMail: iab@iab.org URI: http://www.iab.org/
Full Copyright Statement ⭐
Copyright (C) The IETF Trust (2007). 🦋
This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 💅
Intellectual Property 🧚
The IETF takes no position on whether any Intellectual Property Rights might be claimed over the technology in this document, or how much license might be available under those rights. It also doesn't claim it has done any independent search for such rights. Info on how rights work for RFC documents is in BCP 78 and BCP 79 📚
Copies of IPR disclosures sent to the IETF Secretariat, plus any assurances of licenses, or the results of an attempt to get a general license or permission for implementers or users, can be found in the IETF's online IPR repository at http://www.ietf.org/ipr. 🔥
The IETF invites anyone to flag any copyrights, patents, patent applications, or other proprietary rights that might cover technology needed to implement this standard. Send that to ietf-ipr@ietf.org 💜
Acknowledgement 🍓
Funding for the RFC Editor function is currently provided by the Internet Society. Thank you, Internet Society 🫶
📦 where this page comes from
- ietf: rfc4907 2007-06
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms