draft-iab-link-indications-10.txt   rfc4907.txt 
Network Working Group B. Aboba, Ed. Network Working Group B. Aboba, Ed.
INTERNET-DRAFT Internet Architecture Board Request for Comments: 4907 Internet Architecture Board
Category: Informational IAB Category: Informational IAB
<draft-iab-link-indications-10.txt>
Architectural Implications of Link Indications Architectural Implications of Link Indications
By submitting this Internet-Draft, each author represents that any Status of This Memo
applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
This Internet-Draft will expire on September 1, 2007. 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 Notice
Copyright (C) The IETF Trust (2007). Copyright (C) The IETF Trust (2007).
Abstract Abstract
A link indication represents information provided by the link layer A link indication represents information provided by the link layer
to higher layers regarding the state of the link. This document to higher layers regarding the state of the link. This document
describes the role of link indications within the Internet describes the role of link indications within the Internet
Architecture. While the judicious use of link indications can architecture. While the judicious use of link indications can
provide performance benefits, inappropriate use can degrade both provide performance benefits, inappropriate use can degrade both
robustness and performance. This document summarizes current robustness and performance. This document summarizes current
proposals, describes the architectural issues and provides examples proposals, describes the architectural issues, and provides examples
of appropriate and inappropriate uses of link indications. of appropriate and inappropriate uses of link indications.
Table of Contents Table of Contents
1. Introduction.............................................. 3 1. Introduction ....................................................3
1.1 Requirements ....................................... 3 1.1. Requirements ...............................................3
1.2 Terminology ........................................ 3 1.2. Terminology ................................................3
1.3 Overview ........................................... 5 1.3. Overview ...................................................5
1.4 Layered Indication Model ........................... 6 1.4. Layered Indication Model ...................................7
2. Architectural Considerations ............................. 13 2. Architectural Considerations ...................................14
2.1 Model Validation ................................... 14 2.1. Model Validation ..........................................15
2.2 Clear Definitions .................................. 15 2.2. Clear Definitions .........................................16
2.3 Robustness ......................................... 16 2.3. Robustness ................................................17
2.4 Congestion Control ................................. 19 2.4. Congestion Control ........................................20
2.5 Effectiveness ...................................... 20 2.5. Effectiveness .............................................21
2.6 Interoperability ................................... 21 2.6. Interoperability ..........................................22
2.7 Race Conditions .................................... 21 2.7. Race Conditions ...........................................22
2.8 Layer Compression .................................. 24 2.8. Layer Compression .........................................25
2.9 Transport of Link Indications ...................... 25 2.9. Transport of Link Indications .............................26
3. Future Work .............................................. 26 3. Future Work ....................................................27
4. Security Considerations .................................. 27 4. Security Considerations ........................................28
4.1 Spoofing ........................................... 27 4.1. Spoofing ..................................................28
4.2 Indication Validation .............................. 28 4.2. Indication Validation .....................................29
4.3 Denial of Service .................................. 29 4.3. Denial of Service .........................................30
5. IANA Considerations ...................................... 29 5. References .....................................................31
6. References ............................................... 29 5.1. Normative References ......................................31
6.1 Informative References ............................. 29 5.2. Informative References ....................................31
Acknowledgments .............................................. 38 6. Acknowledgments ................................................40
Appendix A - Literature Review ............................... 39 Appendix A. Literature Review .....................................41
A.1 Link Layer ......................................... 39 A.1. Link Layer .................................................41
A.2 Internet Layer ..................................... 51 A.2. Internet Layer .............................................53
A.3 Transport Layer .................................... 53 A.3. Transport Layer ............................................55
A.4 Application Layer .................................. 57 A.4. Application Layer ..........................................60
Appendix B - IAB Members ..................................... 58 Appendix B. IAB Members ...........................................60
Authors' Addresses ........................................... 58
Full Copyright Statement ..................................... 59
Intellectual Property ........................................ 59
1. Introduction 1. Introduction
A link indication represents information provided by the link layer A link indication represents information provided by the link layer
to higher layers regarding the state of the link. While the to higher layers regarding the state of the link. While the
judicious use of link indications can provide performance benefits, judicious use of link indications can provide performance benefits,
inappropriate use can degrade both robustness and performance. inappropriate use can degrade both robustness and performance.
This document summarizes the current understanding of the role of This document summarizes the current understanding of the role of
link indications within the Internet architecture, and provides link indications within the Internet architecture, and provides
advice to document authors about the appropriate use of link advice to document authors about the appropriate use of link
indications within the Internet, Transport and Application layers. indications within the Internet, transport, and application layers.
Section 1 describes the history of link indication usage within the Section 1 describes the history of link indication usage within the
Internet architecture and provides a model for the utilization of Internet architecture and provides a model for the utilization of
link indications. Section 2 describes the architectural link indications. Section 2 describes the architectural
considerations and provides advice to document authors. Section 3 considerations and provides advice to document authors. Section 3
describes recommendations and future work. Appendix A summarizes the describes recommendations and future work. Appendix A summarizes the
literature on link indications, focusing largely on wireless Local literature on link indications, focusing largely on wireless Local
Area Networks (WLANs). Area Networks (WLANs).
1.1. Requirements 1.1. Requirements
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119]. document are to be interpreted as described in [RFC2119].
1.2. Terminology 1.2. Terminology
Access Point (AP) Access Point (AP)
A station that provides access to the fixed network (e.g. an 802.11 A station that provides access to the fixed network (e.g., an
Distribution System), via the wireless medium (WM) for associated 802.11 Distribution System), via the wireless medium (WM) for
stations. associated stations.
Asymmetric Asymmetric
A link with transmission characteristics that are different A link with transmission characteristics that are different
depending upon the relative position or design characteristics of depending upon the relative position or design characteristics
the transmitter and the receiver is said to be asymmetric. For of the transmitter and the receiver is said to be asymmetric.
instance, the range of one transmitter may be much higher than the For instance, the range of one transmitter may be much higher
range of another transmitter on the same medium. than the range of another transmitter on the same medium.
Beacon Beacon
A control message broadcast by a station (typically an Access A control message broadcast by a station (typically an Access
Point), informing stations in the neighborhood of its continuing Point), informing stations in the neighborhood of its continuing
presence, possibly along with additional status or configuration presence, possibly along with additional status or configuration
information. information.
Binding Update (BU) Binding Update (BU)
A message indicating a mobile node's current mobility binding, and A message indicating a mobile node's current mobility binding,
in particular its care-of address. and in particular its Care-of Address.
Correspondent Node Correspondent Node
A peer node with which a mobile node is communicating. The A peer node with which a mobile node is communicating. The
correspondent node may be either mobile or stationary. correspondent node may be either mobile or stationary.
Link A communication facility or medium over which nodes can communicate Link
at the link layer, i.e., the layer immediately below the Internet A communication facility or medium over which nodes can
Protocol (IP). communicate at the link layer, i.e., the layer immediately below
the Internet Protocol (IP).
Link Down Link Down
An event provided by the link layer that signifies a state change An event provided by the link layer that signifies a state
associated with the interface no longer being capable of change associated with the interface no longer being capable of
communicating data frames; transient periods of high frame loss are communicating data frames; transient periods of high frame loss
not sufficient. are not sufficient.
Link Layer
Conceptual layer of control or processing logic that is responsible
for maintaining control of the link. The link layer functions
provide an interface between the higher-layer logic and the link.
The link layer is the layer immediately below the Internet Protocol
(IP).
Link Indication Link Indication
Information provided by the link layer to higher layers regarding Information provided by the link layer to higher layers
the state of the link. regarding the state of the link.
Link Layer
Conceptual layer of control or processing logic that is
responsible for maintaining control of the link. The link layer
functions provide an interface between the higher-layer logic
and the link. The link layer is the layer immediately below the
Internet Protocol (IP).
Link Up Link Up
An event provided by the link layer that signifies a state change An event provided by the link layer that signifies a state
associated with the interface becoming capable of communicating change associated with the interface becoming capable of
data frames. communicating data frames.
Maximum Segment Size (MSS) Maximum Segment Size (MSS)
The maximum payload size available to the Transport layer. The maximum payload size available to the transport layer.
Maximum Transmission Unit (MTU) Maximum Transmission Unit (MTU)
The size in octets of the largest IP packet, including the IP The size in octets of the largest IP packet, including the IP
header and payload, that can be transmitted on a link or path. header and payload, that can be transmitted on a link or path.
Mobile Node Mobile Node
A node that can change its point of attachment from one link to A node that can change its point of attachment from one link to
another, while still being reachable via its home address. another, while still being reachable via its home address.
Point of Attachment
The endpoint on the link to which the host is currently connected.
Operable Address Operable Address
A static or dynamically assigned address which has not been A static or dynamically assigned address that has not been
relinquished, and has not expired. relinquished and has not expired.
Point of Attachment
The endpoint on the link to which the host is currently
connected.
Routable Address Routable Address
Any IP address for which routers will forward packets. This Any IP address for which routers will forward packets. This
includes private addresses as specified in "Address Allocation for includes private addresses as specified in "Address Allocation
Private Internets" [RFC1918]. for Private Internets" [RFC1918].
Station (STA) Station (STA)
Any device that contains an IEEE 802.11 conformant medium access Any device that contains an IEEE 802.11 conformant medium access
control (MAC) and physical layer (PHY) interface to the wireless control (MAC) and physical layer (PHY) interface to the wireless
medium (WM). medium (WM).
Strong End System Model Strong End System Model
The Strong End System model emphasizes the host/router distinction, The Strong End System model emphasizes the host/router
tending to model a multihomed host as a set of logical hosts within distinction, tending to model a multi-homed host as a set of
the same physical host. In the Strong End System model, addresses logical hosts within the same physical host. In the Strong End
refer to an interface, rather than to the host to which they System model, addresses refer to an interface, rather than to
attach. As a result, packets sent on an outgoing interface have a the host to which they attach. As a result, packets sent on an
source address configured on that interface and incoming packets outgoing interface have a source address configured on that
whose destination address does not correspond to the physical interface, and incoming packets whose destination address does
interface through which it is received are silently discarded. not correspond to the physical interface through which it is
received are silently discarded.
Weak End System Model Weak End System Model
In the Weak End System model, addresses refer to a host. As a In the Weak End System model, addresses refer to a host. As a
result, packets sent on an outgoing interface need not necessarily result, packets sent on an outgoing interface need not
have a source address configured on that interface, and incoming necessarily have a source address configured on that interface,
packets whose destination address does not correspond to the and incoming packets whose destination address does not
physical interface through which it is received are accepted. correspond to the physical interface through which it is
received are accepted.
1.3. Overview 1.3. Overview
The use of link indications within the Internet architecture has a The use of link indications within the Internet architecture has a
long history. In response to an attempt to send to a host that was long history. In response to an attempt to send to a host that was
off-line, the ARPANET link layer protocol provided a "Destination off-line, the ARPANET link layer protocol provided a "Destination
Dead" indication, described in "Fault Isolation and Recovery" Dead" indication, described in "Fault Isolation and Recovery"
[RFC816]. The ARPANET packet radio experiment [PRNET] incorporated [RFC816]. The ARPANET packet radio experiment [PRNET] incorporated
frame loss in the calculation of routing metrics, a precursor to more frame loss in the calculation of routing metrics, a precursor to more
recent link-aware routing metrics such as Expected Transmission Count recent link-aware routing metrics such as Expected Transmission Count
(ETX), described in "A High-Throughput Path Metric for Multi-Hop (ETX), described in "A High-Throughput Path Metric for Multi-Hop
Wireless Routing" [ETX]. Wireless Routing" [ETX].
"Routing Information Protocol" [RFC1058] defined RIP, which is "Routing Information Protocol" [RFC1058] defined RIP, which is
descended from the Xerox Network Systems (XNS) Routing Information descended from the Xerox Network Systems (XNS) Routing Information
Protocol. "The Open Shortest Path First Specification" [RFC1131] Protocol. "The OSPF Specification" [RFC1131] defined Open Shortest
defined OSPF, which uses Link State Advertisements (LSAs) in order to Path First, which uses Link State Advertisements (LSAs) in order to
flood information relating to link status within an OSPF area. While flood information relating to link status within an OSPF area.
these and other routing protocols can utilize "Link Up" and "Link [RFC2328] defines version 2 of OSPF. While these and other routing
Down" indications provided by those links that support them, they protocols can utilize "Link Up" and "Link Down" indications provided
also can detect link loss based on loss of routing packets. As noted by those links that support them, they also can detect link loss
in "Requirements for IP Version 4 Routers" [RFC1812]: based on loss of routing packets. As noted in "Requirements for IP
Version 4 Routers" [RFC1812]:
It is crucial that routers have workable mechanisms for It is crucial that routers have workable mechanisms for determining
determining that their network connections are functioning that their network connections are functioning properly. Failure to
properly. Failure to detect link loss, or failure to take the detect link loss, or failure to take the proper actions when a
proper actions when a problem is detected, can lead to black problem is detected, can lead to black holes.
holes.
Attempts have also been made to define link indications other than Attempts have also been made to define link indications other than
"Link Up" and "Link Down". "Dynamically Switched Link Control "Link Up" and "Link Down". "Dynamically Switched Link Control
Protocol" [RFC1307] defines an experimental protocol for control of Protocol" [RFC1307] defines an experimental protocol for control of
links, incorporating "Down", "Coming Up", "Up", "Going Down", "Bring links, incorporating "Down", "Coming Up", "Up", "Going Down", "Bring
Down" and "Bring Up" states. Down", and "Bring Up" states.
"A Generalized Model for Link Layer Triggers" [GenTrig] defines "A Generalized Model for Link Layer Triggers" [GenTrig] defines
"generic triggers", including "Link Up", "Link Down", "Link Going "generic triggers", including "Link Up", "Link Down", "Link Going
Down", "Link Going Up", "Link Quality Crosses Threshold", "Trigger Down", "Link Going Up", "Link Quality Crosses Threshold", "Trigger
Rollback", and "Better Signal Quality AP Available". IEEE 802.21 Rollback", and "Better Signal Quality AP Available". IEEE 802.21
[IEEE-802.21] defines a Media Independent Handover Event Service [IEEE-802.21] defines a Media Independent Handover Event Service
(MIH-ES) that provides event reporting relating to link (MIH-ES) that provides event reporting relating to link
characteristics, link status, and link quality. Events defined characteristics, link status, and link quality. Events defined
include "Link Down", "Link Up", "Link Going Down", "Link Signal include "Link Down", "Link Up", "Link Going Down", "Link Signal
Strength" and "Link Signal/Noise Ratio". Strength", and "Link Signal/Noise Ratio".
Under ideal conditions, links in the "up" state experience low frame Under ideal conditions, links in the "up" state experience low frame
loss in both directions and are immediately ready to send and receive loss in both directions and are immediately ready to send and receive
data frames; links in the "down" state are unsuitable for sending and data frames; links in the "down" state are unsuitable for sending and
receiving data frames in either direction. receiving data frames in either direction.
Unfortunately links frequently exhibit non-ideal behavior. Wired Unfortunately, links frequently exhibit non-ideal behavior. Wired
links may fail in half-duplex mode, or exhibit partial impairment links may fail in half-duplex mode, or exhibit partial impairment
resulting in intermediate loss rates. Wireless links may exhibit resulting in intermediate loss rates. Wireless links may exhibit
asymmetry, intermittent frame loss or rapid changes in throughput due asymmetry, intermittent frame loss, or rapid changes in throughput
to interference or signal fading. In both wired and wireless links, due to interference or signal fading. In both wired and wireless
the link state may rapidly flap between the "up" and "down" states. links, the link state may rapidly flap between the "up" and "down"
This real world behavior presents challenges to the integration of states. This real-world behavior presents challenges to the
link indications with the Internet, Transport and Application layers. integration of link indications with the Internet, transport, and
application layers.
1.4. Layered Indication Model 1.4. Layered Indication Model
A layered indication model is shown in Figure 1 which includes both A layered indication model is shown in Figure 1 that includes both
internally generated link indications (such as link state and rate) internally generated link indications (such as link state and rate)
and indications arising from external interactions such as path and indications arising from external interactions such as path
change detection. In this model, it is assumed that the link layer change detection. In this model, it is assumed that the link layer
provides indications to higher layers primarily in the form of provides indications to higher layers primarily in the form of
abstract indications that are link-technology agnostic. abstract indications that are link-technology agnostic.
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Application | | Application | |
Layer | | Layer | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
skipping to change at page 8, line 19 skipping to change at page 9, line 19
validates and filters link indications and selects outgoing and validates and filters link indications and selects outgoing and
incoming interfaces based on routing metrics. incoming interfaces based on routing metrics.
The Internet layer composes its routing table based on information The Internet layer composes its routing table based on information
available from local interfaces as well as potentially by taking into available from local interfaces as well as potentially by taking into
account information provided by routers. This enables the state of account information provided by routers. This enables the state of
the local routing table to reflect link conditions on both local and the local routing table to reflect link conditions on both local and
remote links. For example, prefixes to be added or removed from the remote links. For example, prefixes to be added or removed from the
routing table may be determined from Dynamic Host Configuration routing table may be determined from Dynamic Host Configuration
Protocol (DHCP) [RFC2131][RFC3315], Router Advertisements Protocol (DHCP) [RFC2131][RFC3315], Router Advertisements
[RFC1256][RFC2461], re-direct messages or route updates incorporating [RFC1256][RFC2461], redirect messages, or route updates incorporating
information on the state of links multiple hops away. information on the state of links multiple hops away.
As described in "Packetization Layer Path MTU Discovery" [PMTUDRFC], As described in "Packetization Layer Path MTU Discovery" [RFC4821],
the Internet layer may maintain a path information cache, enabling the Internet layer may maintain a path information cache, enabling
sharing of path MTU information between concurrent or subsequent sharing of Path MTU information between concurrent or subsequent
connections. The shared cache is accessed and updated by connections. The shared cache is accessed and updated by
packetization protocols implementing packetization layer path MTU packetization protocols implementing packetization layer Path MTU
discovery. Discovery.
The Internet layer also utilizes link indications in order to The Internet layer also utilizes link indications in order to
optimize aspects of Internet Protocol (IP) configuration and optimize aspects of Internet Protocol (IP) configuration and
mobility. After receipt of a "Link Up" indication, hosts validate mobility. After receipt of a "Link Up" indication, hosts validate
potential IP configurations by Detecting Network Attachment (DNA) potential IP configurations by Detecting Network Attachment (DNA)
[RFC4436]. Once the IP configuration is confirmed, it may be [RFC4436]. Once the IP configuration is confirmed, it may be
determined that an address change has occurred. However, "Link Up" determined that an address change has occurred. However, "Link Up"
indications may not necessarily result in a change to Internet layer indications may not necessarily result in a change to Internet layer
configuration. configuration.
In "Detecting Network Attachment in IPv4" [RFC4436], after receipt of In "Detecting Network Attachment in IPv4" [RFC4436], after receipt of
a "Link Up" indication, potential IP configurations are validated a "Link Up" indication, potential IP configurations are validated
using a bi-directional reachability test. In "Detecting Network using a bidirectional reachability test. In "Detecting Network
Attachment in IPv6 Networks (DNAv6)" [DNAv6] IP configuration is Attachment in IPv6 Networks (DNAv6)" [DNAv6], IP configuration is
validated using reachability detection and Router validated using reachability detection and Router
Solicitation/Advertisement. Solicitation/Advertisement.
The routing sub-layer may utilize link indications in order to enable The routing sub-layer may utilize link indications in order to enable
more rapid response to changes in link state and effective more rapid response to changes in link state and effective
throughput. Link rate is often used in computing routing metrics. throughput. Link rate is often used in computing routing metrics.
However, in wired networks the transmission rate may be negotiated in However, in wired networks the transmission rate may be negotiated in
order to enhance energy efficiency [EfficientEthernet]. In wireless order to enhance energy efficiency [EfficientEthernet]. In wireless
networks, the negotiated rate and Frame Error Rate (FER) may change networks, the negotiated rate and Frame Error Rate (FER) may change
with link conditions so that effective throughput may vary on a with link conditions so that effective throughput may vary on a
packet by packet basis. In such situations, routing metrics may also packet-by-packet basis. In such situations, routing metrics may also
exhibit rapid variation. exhibit rapid variation.
Routing metrics incorporating link indications such as Link Up/Down Routing metrics incorporating link indications such as Link Up/Down
and effective throughput enable routers to take link conditions into and effective throughput enable routers to take link conditions into
account for the purposes of route selection. If a link experiences account for the purposes of route selection. If a link experiences
decreased rate or high frame loss, the route metric will increase for decreased rate or high frame loss, the route metric will increase for
the prefixes that it serves, encouraging use of alternate paths if the prefixes that it serves, encouraging use of alternate paths if
available. When the link condition improves, the route metric will available. When the link condition improves, the route metric will
decrease, encouraging use of the link. decrease, encouraging use of the link.
Within Weak End System implementations, changes in routing metrics Within Weak End System implementations, changes in routing metrics
and link state may result in a change in the outgoing interface for and link state may result in a change in the outgoing interface for
one or more transport connections. Routes may also be added or one or more transport connections. Routes may also be added or
withdrawn, resulting in loss or gain of peer connectivity. However, withdrawn, resulting in loss or gain of peer connectivity. However,
link indications such as changes in transmission rate or frame loss link indications such as changes in transmission rate or frame loss
do not necessarily result in a change of outgoing interface. do not necessarily result in a change of outgoing interface.
The Internet layer may also become aware of path changes by other The Internet layer may also become aware of path changes by other
mechanisms, such as receipt of updates from a routing protocol, mechanisms, such as receipt of updates from a routing protocol,
receipt of a Router Advertisement, dead gateway detection [RFC816] or receipt of a Router Advertisement, dead gateway detection [RFC816] or
network unreachability detection [RFC2461], ICMP re-directs, or a network unreachability detection [RFC2461], ICMP redirects, or a
change in the IPv4 TTL/IPv6 Hop Limit of received packets. A change change in the IPv4 TTL (Time to Live)/IPv6 Hop Limit of received
in the outgoing interface may in turn influence the mobility sub- packets. A change in the outgoing interface may in turn influence
layer, causing a change in the incoming interface. The mobility sub- the mobility sub-layer, causing a change in the incoming interface.
layer may also become aware of a change in the incoming interface of The mobility sub-layer may also become aware of a change in the
a peer (via receipt of a Mobile IP binding update [RFC3775]). incoming interface of a peer (via receipt of a Mobile IP Binding
Update [RFC3775]).
1.4.2. Transport Layer 1.4.2. Transport Layer
The Transport layer processes received link indications differently The transport layer processes received link indications differently
for the purposes of transport parameter estimation and connection for the purposes of transport parameter estimation and connection
management. management.
For the purposes of parameter estimation, the Transport layer is For the purposes of parameter estimation, the transport layer is
primarily interested in path properties that impact performance, and primarily interested in path properties that impact performance, and
where link indications may be determined to be relevant to path where link indications may be determined to be relevant to path
properties they may be utilized directly. Link indications such as properties they may be utilized directly. Link indications such as
"Link Up"/"Link Down" or changes in rate, delay and frame loss may "Link Up"/"Link Down" or changes in rate, delay, and frame loss may
prove relevant. This will not always be the case, however; where the prove relevant. This will not always be the case, however; where the
bandwidth of the bottleneck on the end-to-end path is already much bandwidth of the bottleneck on the end-to-end path is already much
lower than the transmission rate, an increase in transmission rate lower than the transmission rate, an increase in transmission rate
may not materially affect path properties. As described in Appendix may not materially affect path properties. As described in Appendix
A.3, the algorithms for utilizing link layer indications to improve A.3, the algorithms for utilizing link layer indications to improve
transport parameter estimates are still under development. transport parameter estimates are still under development.
Strict layering considerations do not apply in transport path Strict layering considerations do not apply in transport path
parameter estimation in order to enable the transport layer to make parameter estimation in order to enable the transport layer to make
use of all available information. For example, if the Transport use of all available information. For example, the transport layer
layer may determine that a link indication came from a link forming may determine that a link indication came from a link forming part of
part of a path of one or more connections. In this case, it may a path of one or more connections. In this case, it may utilize the
utilize the receipt of a "Link Down" indication followed by a receipt of a "Link Down" indication followed by a subsequent "Link
subsequent "Link Up" indication to infer the possibility of non- Up" indication to infer the possibility of non-congestive packet loss
congestive packet loss during the period between the indications, during the period between the indications, even if the IP
even if the IP configuration does not change as a result, so that no configuration does not change as a result, so that no Internet layer
Internet layer indication would be sent. indication would be sent.
The Transport layer may also find Internet layer indications useful The transport layer may also find Internet layer indications useful
for path parameter estimation. For example, path change indications for path parameter estimation. For example, path change indications
can be used as a signal to reset path parameter estimates; Where can be used as a signal to reset path parameter estimates. Where
there is no default route, loss of segments sent to a destination there is no default route, loss of segments sent to a destination
lacking a prefix in the local routing table may be assumed to be due lacking a prefix in the local routing table may be assumed to be due
to causes other than congestion, regardless of the reason for the to causes other than congestion, regardless of the reason for the
removal (either because local link conditions caused it to be removed removal (either because local link conditions caused it to be removed
or because the route was withdrawn by a remote router). or because the route was withdrawn by a remote router).
For the purposes of connection management, layering considerations For the purposes of connection management, layering considerations
are important. The Transport layer may tear down a connection based are important. The transport layer may tear down a connection based
on Internet layer indications (such as a endpoint address changes), on Internet layer indications (such as a endpoint address changes),
but does not take link indications into account. Just as a "Link Up" but does not take link indications into account. Just as a "Link Up"
event may not result in a configuration change, and a configuration event may not result in a configuration change, and a configuration
change may not result in connection teardown, the Transport layer change may not result in connection teardown, the transport layer
does not tear down connections on receipt of a "Link Down" does not tear down connections on receipt of a "Link Down"
indication, regardless of the cause. Where the "Link Down" indication, regardless of the cause. Where the "Link Down"
indication results from frame loss rather than an explicit exchange, indication results from frame loss rather than an explicit exchange,
the indication may be transient, to be soon followed by a "Link Up" the indication may be transient, to be soon followed by a "Link Up"
indication. indication.
Even where the "Link Down" indication results from an explicit Even where the "Link Down" indication results from an explicit
exchange such as receipt of a Point-to-Point Protocol (PPP) Link exchange such as receipt of a Point-to-Point Protocol (PPP) Link
Control Protocol (LCP)-Terminate or an IEEE 802.11 Disassociate or Control Protocol (LCP)-Terminate or an IEEE 802.11 Disassociate or
Deauthenticate frame, an alternative point of attachment may be Deauthenticate frame, an alternative point of attachment may be
available, allowing connectivity to be quickly restored. As a available, allowing connectivity to be quickly restored. As a
result, robustness is best achieved by allowing connections to remain result, robustness is best achieved by allowing connections to remain
up until an endpoint address changes, or the connection is torn down up until an endpoint address changes, or the connection is torn down
due to lack of response to repeated retransmission attempts. due to lack of response to repeated retransmission attempts.
For the purposes of connection management, the Transport layer is For the purposes of connection management, the transport layer is
cautious with the use of Internet layer indications. Changes in the cautious with the use of Internet layer indications. Changes in the
routing table are not relevant for the purposes of connection routing table are not relevant for the purposes of connection
management, since it is desirable for connections to remain up during management, since it is desirable for connections to remain up during
transitory routing flaps. However, the transport layer may tear down transitory routing flaps. However, the transport layer may tear down
transport connections due to invalidation of a connection endpoint IP transport connections due to invalidation of a connection endpoint IP
address. Where the connection has been established based on a Mobile address. Where the connection has been established based on a Mobile
IP home address, a change in the care-of-address need not result in IP home address, a change in the Care-of Address need not result in
connection teardown, since the configuration change is masked by the connection teardown, since the configuration change is masked by the
mobility functionality within the Internet layer, and is therefore mobility functionality within the Internet layer, and is therefore
transparent to the Transport layer. transparent to the transport layer.
"Requirements for Internet Hosts - Communication Layers" [RFC1122] "Requirements for Internet Hosts -- Communication Layers" [RFC1122],
[RFC1122] Section 2.4 requires Destination Unreachable, Source Section 2.4, requires Destination Unreachable, Source Quench, Echo
Quench, Echo Reply, Timestamp Reply and Time Exceeded ICMP messages Reply, Timestamp Reply, and Time Exceeded ICMP messages to be passed
to be passed up to the Transport layer. [RFC1122] 4.2.3.9 requires up to the transport layer. [RFC1122], Section 4.2.3.9, requires
Transmission Control Protocol (TCP) to react to an Internet Control Transmission Control Protocol (TCP) to react to an Internet Control
Message Protocol (ICMP) Source Quench by slowing transmission. Message Protocol (ICMP) Source Quench by slowing transmission.
[RFC1122] Section 4.2.3.9 distinguishes between ICMP messages [RFC1122], Section 4.2.3.9, distinguishes between ICMP messages
indicating soft error conditions, which must not cause TCP to abort a indicating soft error conditions, which must not cause TCP to abort a
connection, and hard error conditions, which should cause an abort. connection, and hard error conditions, which should cause an abort.
ICMP messages indicating soft error conditions include Destination ICMP messages indicating soft error conditions include Destination
Unreachable codes 0 (Net), 1 (Host) and 5 (Source Route Failed), Unreachable codes 0 (Net), 1 (Host), and 5 (Source Route Failed),
which may result from routing transients; Time Exceeded; and which may result from routing transients; Time Exceeded; and
Parameter Problem. ICMP messages indicating hard error conditions Parameter Problem. ICMP messages indicating hard error conditions
include Destination Unreachable codes 2 (Protocol Unreachable), 3 include Destination Unreachable codes 2 (Protocol Unreachable), 3
(Port Unreachable), and 4 (Fragmentation Needed and Don't Fragment (Port Unreachable), and 4 (Fragmentation Needed and Don't Fragment
was Set). Since hosts implementing classical ICMP-based path MTU Was Set). Since hosts implementing classical ICMP-based Path MTU
Discovery [RFC1191] use Destination Unreachable code 4, they do not Discovery [RFC1191] use Destination Unreachable code 4, they do not
treat this as a hard error condition. Hosts implementing "Path MTU treat this as a hard error condition. Hosts implementing "Path MTU
Discovery for IP version 6" [RFC1981] utilize ICMPv6 Packet Too Big Discovery for IP version 6" [RFC1981] utilize ICMPv6 Packet Too Big
messages. As noted in "TCP Problems with Path MTU Discovery" messages. As noted in "TCP Problems with Path MTU Discovery"
[RFC2923], classical path MTU discovery is vulnerable to failure if [RFC2923], classical Path MTU Discovery is vulnerable to failure if
ICMP messages are not delivered or processed. In order to address ICMP messages are not delivered or processed. In order to address
this problem, "Packetization Layer Path MTU Discovery" [PMTUDRFC] this problem, "Packetization Layer Path MTU Discovery" [RFC4821] does
does depend on the delivery of ICMP messages. depend on the delivery of ICMP messages.
"Fault Isolation and Recovery" [RFC816], Section 6 states: "Fault Isolation and Recovery" [RFC816], Section 6, states:
It is not obvious, when error messages such as ICMP Destination It is not obvious, when error messages such as ICMP Destination
Unreachable arrive, whether TCP should abandon the connection. Unreachable arrive, whether TCP should abandon the connection. The
The reason that error messages are difficult to interpret is that, reason that error messages are difficult to interpret is that, as
as discussed above, after a failure of a gateway or network, there discussed above, after a failure of a gateway or network, there is a
is a transient period during which the gateways may have incorrect transient period during which the gateways may have incorrect
information, so that irrelevant or incorrect error messages may information, so that irrelevant or incorrect error messages may
sometimes return. An isolated ICMP Destination Unreachable may sometimes return. An isolated ICMP Destination Unreachable may
arrive at a host, for example, if a packet is sent during the arrive at a host, for example, if a packet is sent during the period
period when the gateways are trying to find a new route. To when the gateways are trying to find a new route. To abandon a TCP
abandon a TCP connection based on such a message arriving would be connection based on such a message arriving would be to ignore the
to ignore the valuable feature of the Internet that for many valuable feature of the Internet that for many internal failures it
internal failures it reconstructs its function without any reconstructs its function without any disruption of the end points.
disruption of the end points.
"Requirements for IP Version 4 Routers" [RFC1812] Section 4.3.3.3 "Requirements for IP Version 4 Routers" [RFC1812], Section 4.3.3.3,
states that "Research seems to suggest that Source Quench consumes states that "Research seems to suggest that Source Quench consumes
network bandwidth but is an ineffective (and unfair) antidote to network bandwidth but is an ineffective (and unfair) antidote to
congestion", indicating that routers should not originate them. In congestion", indicating that routers should not originate them. In
general, since the Transport layer is able to determine an general, since the transport layer is able to determine an
appropriate (and conservative) response to congestion based on packet appropriate (and conservative) response to congestion based on packet
loss or explicit congestion notification, ICMP "source quench" loss or explicit congestion notification, ICMP Source Quench
indications are not needed, and the sending of additional "source indications are not needed, and the sending of additional Source
quench" packets during periods of congestion may be detrimental. Quench packets during periods of congestion may be detrimental.
"ICMP attacks against TCP" [Gont] argues that accepting ICMP messages "ICMP attacks against TCP" [Gont] argues that accepting ICMP messages
based on a correct four-tuple without additional security checks is based on a correct four-tuple without additional security checks is
ill-advised. For example, an attacker forging an ICMP hard error ill-advised. For example, an attacker forging an ICMP hard error
message can cause one or more transport connections to abort. The message can cause one or more transport connections to abort. The
authors discuss a number of precautions, including mechanisms for authors discuss a number of precautions, including mechanisms for
validating ICMP messages and ignoring or delaying response to hard validating ICMP messages and ignoring or delaying response to hard
error messages under various conditions. They also recommend that error messages under various conditions. They also recommend that
hosts ignore ICMP Source Quench messages. hosts ignore ICMP Source Quench messages.
The Transport layer may also provide information to the link layer. The transport layer may also provide information to the link layer.
For example, the Transport layer may wish to control the maximum For example, the transport layer may wish to control the maximum
number of times that a link layer frame may be retransmitted, so that number of times that a link layer frame may be retransmitted, so that
the link layer does not continue to retransmit after a Transport the link layer does not continue to retransmit after a transport
layer timeout. In IEEE 802.11, this can be achieved by adjusting the layer timeout. In IEEE 802.11, this can be achieved by adjusting the
Management Information Base (MIB) [IEEE-802.11] variables Management Information Base (MIB) [IEEE-802.11] variables
dot11ShortRetryLimit (default: 7) and dot11LongRetryLimit (default: dot11ShortRetryLimit (default: 7) and dot11LongRetryLimit (default:
4), which control the maximum number of retries for frames shorter 4), which control the maximum number of retries for frames shorter
and longer in length than dot11RTSThreshold, respectively. However, and longer in length than dot11RTSThreshold, respectively. However,
since these variables control link behavior as a whole they cannot be since these variables control link behavior as a whole they cannot be
used to separately adjust behavior on a per-transport connection used to separately adjust behavior on a per-transport connection
basis. In situations where the link layer retransmission timeout is basis. In situations where the link layer retransmission timeout is
of the same order as the path round trip timeout, link layer control of the same order as the path round-trip timeout, link layer control
may not be possible at all. may not be possible at all.
1.4.3. Application Layer 1.4.3. Application Layer
The Transport layer provides indications to the Application layer by The transport layer provides indications to the application layer by
propagating Internet layer indications (such as IP address propagating Internet layer indications (such as IP address
configuration and changes), as well as providing its own indications, configuration and changes), as well as providing its own indications,
such as connection teardown. such as connection teardown.
Since applications can typically obtain the information they need Since applications can typically obtain the information they need
more reliably from the Internet and Transport layers, they will more reliably from the Internet and transport layers, they will
typically not need to utilize link indications. A "Link Up" typically not need to utilize link indications. A "Link Up"
indication implies that the link is capable of communicating IP indication implies that the link is capable of communicating IP
packets, but does not indicate that it has been configured; packets, but does not indicate that it has been configured;
applications should use an Internet layer "IP Address Configured" applications should use an Internet layer "IP Address Configured"
event instead. "Link Down" indications are typically not useful to event instead. "Link Down" indications are typically not useful to
applications, since they can be rapidly followed by a "Link Up" applications, since they can be rapidly followed by a "Link Up"
indication; applications should respond to Transport layer teardown indication; applications should respond to transport layer teardown
indications instead. Similarly, changes in the transmission rate may indications instead. Similarly, changes in the transmission rate may
not be relevant to applications if the bottleneck bandwidth on the not be relevant to applications if the bottleneck bandwidth on the
path does not change; the transport layer is best equipped to path does not change; the transport layer is best equipped to
determine this. As a result, Figure 1 does not indicate link determine this. As a result, Figure 1 does not show link indications
indications being provided directly to applications. being provided directly to applications.
2. Architectural Considerations 2. Architectural Considerations
The complexity of real-world link behavior poses a challenge to the The complexity of real-world link behavior poses a challenge to the
integration of link indications within the Internet architecture. integration of link indications within the Internet architecture.
While the literature provides persuasive evidence of the utility of While the literature provides persuasive evidence of the utility of
link indications, difficulties can arise in making effective use of link indications, difficulties can arise in making effective use of
them. To avoid these issues, the following architectural principles them. To avoid these issues, the following architectural principles
are suggested and discussed in more detail in the sections that are suggested and discussed in more detail in the sections that
follow: follow:
skipping to change at page 13, line 28 skipping to change at page 14, line 32
(1) Proposals should avoid use of simplified link models in (1) Proposals should avoid use of simplified link models in
circumstances where they do not apply (Section 2.1). circumstances where they do not apply (Section 2.1).
(2) Link indications should be clearly defined, so that it is (2) Link indications should be clearly defined, so that it is
understood when they are generated on different link layers understood when they are generated on different link layers
(Section 2.2). (Section 2.2).
(3) Proposals must demonstrate robustness against spurious link (3) Proposals must demonstrate robustness against spurious link
indications (Section 2.3). indications (Section 2.3).
(4) Upper layers should utilize a timely recovery step so as to limit (4) Upper layers should utilize a timely recovery step so as to
the potential damage from link indications determined to be invalid limit the potential damage from link indications determined to
after they have been acted on (Section 2.3.2). be invalid after they have been acted on (Section 2.3.2).
(5) Proposals must demonstrate that effective congestion control is (5) Proposals must demonstrate that effective congestion control is
maintained (Section 2.4). maintained (Section 2.4).
(6) Proposals must demonstrate the effectiveness of proposed (6) Proposals must demonstrate the effectiveness of proposed
optimizations (Section 2.5). optimizations (Section 2.5).
(7) Link indications should not be required by upper layers, in order (7) Link indications should not be required by upper layers, in
to maintain link independence (Section 2.6). order to maintain link independence (Section 2.6).
(8) Proposals should avoid race conditions, which can occur where link (8) Proposals should avoid race conditions, which can occur where
indications are utilized directly by multiple layers of the stack link indications are utilized directly by multiple layers of the
(Section 2.7). stack (Section 2.7).
(9) Proposals should avoid inconsistencies between link and routing (9) Proposals should avoid inconsistencies between link and routing
layer metrics (Section 2.7.3). layer metrics (Section 2.7.3).
(10) Overhead reduction schemes must avoid compromising interoperability (10) Overhead reduction schemes must avoid compromising
and introducing link layer dependencies into the Internet and interoperability and introducing link layer dependencies into
Transport layers (Section 2.8). the Internet and transport layers (Section 2.8).
(11) Proposals for transport of link indications beyond the local host (11) Proposals for transport of link indications beyond the local
need to carefully consider the layering, security and transport host need to carefully consider the layering, security, and
implications (Section 2.9). transport implications (Section 2.9).
2.1. Model Validation 2.1. Model Validation
Proposals should avoid the use of link models in circumstances where Proposals should avoid the use of link models in circumstances where
they do not apply. they do not apply.
In "The mistaken axioms of wireless-network research" [Kotz], the In "The mistaken axioms of wireless-network research" [Kotz], the
authors conclude that mistaken assumptions relating to link behavior authors conclude that mistaken assumptions relating to link behavior
may lead to the design of network protocols that may not work in may lead to the design of network protocols that may not work in
practice. For example, the authors note that the three-dimensional practice. For example, the authors note that the three-dimensional
nature of wireless propagation can result in large signal strength nature of wireless propagation can result in large signal strength
changes over short distances. This can result in rapid changes in changes over short distances. This can result in rapid changes in
link indications such as rate, frame loss, and signal strength. link indications such as rate, frame loss, and signal strength.
In "Modeling Wireless Links for Transport Protocols" [GurtovFloyd], In "Modeling Wireless Links for Transport Protocols" [GurtovFloyd],
the authors provide examples of modeling mistakes and examples of how the authors provide examples of modeling mistakes and examples of how
to improve modeling of link characteristics. To accompany the paper to improve modeling of link characteristics. To accompany the paper,
the authors provide simulation scenarios in ns-2. the authors provide simulation scenarios in ns-2.
In order to avoid the pitfalls described in [Kotz] [GurtovFloyd], In order to avoid the pitfalls described in [Kotz] [GurtovFloyd],
documents that describe capabilities that are dependent on link documents that describe capabilities that are dependent on link
indications should explicitly articulate the assumptions of the link indications should explicitly articulate the assumptions of the link
model and describe the circumstances in which they apply. model and describe the circumstances in which they apply.
Generic "trigger" models may include implicit assumptions which may Generic "trigger" models may include implicit assumptions that may
prove invalid in outdoor or mesh wireless LAN deployments. For prove invalid in outdoor or mesh wireless LAN deployments. For
example, two-state Markov models assume that the link is either in a example, two-state Markov models assume that the link is either in a
state experiencing low frame loss ("up") or in a state where few state experiencing low frame loss ("up") or in a state where few
frames are successfully delivered ("down"). In these models, frames are successfully delivered ("down"). In these models,
symmetry is also typically assumed, so that the link is either "up" symmetry is also typically assumed, so that the link is either "up"
in both directions or "down" in both directions. In situations where in both directions or "down" in both directions. In situations where
intermediate loss rates are experienced, these assumptions may be intermediate loss rates are experienced, these assumptions may be
invalid. invalid.
As noted in "Hybrid Rate Control for IEEE 802.11" [Haratcherev] As noted in "Hybrid Rate Control for IEEE 802.11" [Haratcherev],
signal strength data is noisy and sometimes inconsistent, so that it signal strength data is noisy and sometimes inconsistent, so that it
needs to be filtered in order to avoid erratic results. Given this, needs to be filtered in order to avoid erratic results. Given this,
link indications based on raw signal strength data may be unreliable. link indications based on raw signal strength data may be unreliable.
In order to avoid problems, it is best to combine signal strength In order to avoid problems, it is best to combine signal strength
data with other techniques. For example, in developing a "Going data with other techniques. For example, in developing a "Going
Down" indication for use with [IEEE-802.21] it would be advisable to Down" indication for use with [IEEE-802.21] it would be advisable to
validate filtered signal strength measurements with other indications validate filtered signal strength measurements with other indications
of link loss such as lack of beacon reception. of link loss such as lack of Beacon reception.
2.2. Clear Definitions 2.2. Clear Definitions
Link indications should be clearly defined, so that it is understood Link indications should be clearly defined, so that it is understood
when they are generated on different link layers. For example, when they are generated on different link layers. For example,
considerable work has been required in order to come up with the considerable work has been required in order to come up with the
definitions of "Link Up" and "Link Down", and to define when these definitions of "Link Up" and "Link Down", and to define when these
indications are sent on various link layers. indications are sent on various link layers.
Link indication definitions should heed the following advice: Link indication definitions should heed the following advice:
(1) Do not assume symmetric link performance or frame loss that is (1) Do not assume symmetric link performance or frame loss that is
either low ("up") or high ("down"). either low ("up") or high ("down").
In wired networks, links in the "up" state typically experience low In wired networks, links in the "up" state typically experience
frame loss in both directions and are ready to send and receive low frame loss in both directions and are ready to send and
data frames; links in the "down" state are unsuitable for sending receive data frames; links in the "down" state are unsuitable
and receiving data frames in either direction. Therefore, a link for sending and receiving data frames in either direction.
providing a "Link Up" indication will typically experience low Therefore, a link providing a "Link Up" indication will
frame loss in both directions, and high frame loss in any direction typically experience low frame loss in both directions, and high
can only be experienced after a link provides a "Link Down" frame loss in any direction can only be experienced after a link
indication. However, these assumptions may not hold true for provides a "Link Down" indication. However, these assumptions
wireless LAN networks. Asymmetry is typically less of a problem may not hold true for wireless LAN networks. Asymmetry is
for cellular networks where propagation occurs over longer typically less of a problem for cellular networks where
distances, multipath effects may be less severe and the base propagation occurs over longer distances, multi-path effects may
station can transmit at much higher power than mobile stations be less severe, and the base station can transmit at much higher
while utilizing a more sensitive antenna. power than mobile stations while utilizing a more sensitive
antenna.
Specifications utilizing a "Link Up" indication should not assume Specifications utilizing a "Link Up" indication should not
that receipt of this indication means that the link is experiencing assume that receipt of this indication means that the link is
symmetric link conditions or low frame loss in either direction. experiencing symmetric link conditions or low frame loss in
In general, a "Link Up" event should not be sent due to transient either direction. In general, a "Link Up" event should not be
changes in link conditions, but only due to a change in link layer sent due to transient changes in link conditions, but only due
state. It is best to assume that a "Link Up" event may not be sent to a change in link layer state. It is best to assume that a
in a timely way. Large handoff latencies can result in a delay in "Link Up" event may not be sent in a timely way. Large handoff
the generation of a "Link Up" event as movement to an alternative latencies can result in a delay in the generation of a "Link Up"
point of attachment is delayed. event as movement to an alternative point of attachment is
delayed.
(2) Consider the sensitivity of link indications to transient link (2) Consider the sensitivity of link indications to transient link
conditions. Due to common effects such as multi-path interference, conditions. Due to common effects such as multi-path
signal strength and signal/noise ratio (SNR) may vary rapidly over interference, signal strength and signal to noise ratio (SNR)
a short distance, causing erratic behavior of link indications may vary rapidly over a short distance, causing erratic behavior
based on unfiltered measurements. As noted in [Haratcherev], of link indications based on unfiltered measurements. As noted
signal strength may prove most useful when utilized in combination in [Haratcherev], signal strength may prove most useful when
with other measurements, such as frame loss. utilized in combination with other measurements, such as frame
loss.
(3) Where possible, design link indications with built-in damping. By (3) Where possible, design link indications with built-in damping.
design, the "Link Up" and "Link Down" events relate to changes in By design, the "Link Up" and "Link Down" events relate to
the state of the link layer that make it able and unable to changes in the state of the link layer that make it able and
communicate IP packets. These changes are either generated by the unable to communicate IP packets. These changes are generated
link layer state machine based on link layer exchanges (e.g. either by the link layer state machine based on link layer
completion of the IEEE 802.11i four-way handshake for "Link Up", or exchanges (e.g., completion of the IEEE 802.11i four-way
receipt of a PPP LCP-Terminate for "Link Down") or by protracted handshake for "Link Up", or receipt of a PPP LCP-Terminate for
frame loss, so that the link layer concludes that the link is no "Link Down") or by protracted frame loss, so that the link layer
longer usable. As a result, these link indications are typically concludes that the link is no longer usable. As a result, these
less sensitive to changes in transient link conditions. link indications are typically less sensitive to changes in
transient link conditions.
(4) Do not assume that a "Link Down" event will be sent at all, or that (4) Do not assume that a "Link Down" event will be sent at all, or
if sent, that it will be received in a timely way. A good link that, if sent, it will be received in a timely way. A good link
layer implementation will both rapidly detect connectivity failure layer implementation will both rapidly detect connectivity
(such as by tracking missing Beacons) while sending a "Link Down" failure (such as by tracking missing Beacons) while sending a
event only when it concludes the link is unusable, not due to "Link Down" event only when it concludes the link is unusable,
transient frame loss. not due to transient frame loss.
However, existing wireless LAN implementations often do not do a good However, existing wireless LAN implementations often do not do a good
job of detecting link failure. During a lengthy detection phase, a job of detecting link failure. During a lengthy detection phase, a
"Link Down" event is not sent by the link layer, yet IP packets "Link Down" event is not sent by the link layer, yet IP packets
cannot be transmitted or received on the link. Initiation of a scan cannot be transmitted or received on the link. Initiation of a scan
may be delayed so that the station cannot find another point of may be delayed so that the station cannot find another point of
attachment. This can result in inappropriate backoff of attachment. This can result in inappropriate backoff of
retransmission timers within the transport layer, among other retransmission timers within the transport layer, among other
problems. This is not as much of a problem for cellular networks problems. This is not as much of a problem for cellular networks
which utilize transmit power adjustment. that utilize transmit power adjustment.
2.3. Robustness 2.3. Robustness
Link indication proposals must demonstrate robustness against Link indication proposals must demonstrate robustness against
misleading indications. Elements to consider include: misleading indications. Elements to consider include:
Implementation Variation Implementation variation
Recovery from invalid indications Recovery from invalid indications
Damping and hysteresis Damping and hysteresis
2.3.1. Implementation Variation 2.3.1. Implementation Variation
Variations in link layer implementations may have a substantial Variations in link layer implementations may have a substantial
impact on the behavior of link indications. These variations need to impact on the behavior of link indications. These variations need to
be taken into account in evaluating the performance of proposals. be taken into account in evaluating the performance of proposals.
For example, radio propagation and implementation differences can For example, radio propagation and implementation differences can
impact the reliability of Link indications. impact the reliability of link indications.
In "Link-level Measurements from an 802.11b Mesh Network" [Aguayo], In "Link-level Measurements from an 802.11b Mesh Network" [Aguayo],
the authors analyze the cause of frame loss in a 38-node urban multi- the authors analyze the cause of frame loss in a 38-node urban
hop IEEE 802.11 ad-hoc network. In most cases, links that are very multi-hop IEEE 802.11 ad-hoc network. In most cases, links that are
bad in one direction tend to be bad in both directions, and links very bad in one direction tend to be bad in both directions, and
that are very good in one direction tend to be good in both links that are very good in one direction tend to be good in both
directions. However, 30 percent of links exhibited loss rates directions. However, 30 percent of links exhibited loss rates
differing substantially in each direction. differing substantially in each direction.
As described in [Aguayo], wireless LAN links often exhibit loss rates As described in [Aguayo], wireless LAN links often exhibit loss rates
intermediate between "up" (low loss) and "down" (high loss) states, intermediate between "up" (low loss) and "down" (high loss) states,
as well as substantial asymmetry. As a result, receipt of a "Link as well as substantial asymmetry. As a result, receipt of a "Link
Up" indication may not necessarily indicate bi-directional Up" indication may not necessarily indicate bidirectional
reachability, since it could have been generated after exchange of reachability, since it could have been generated after exchange of
small frames at low rates, which might not imply bi-directional small frames at low rates, which might not imply bidirectional
connectivity for large frames exchanged at higher rates. connectivity for large frames exchanged at higher rates.
Where multi-path interference or hidden nodes are encountered, signal Where multi-path interference or hidden nodes are encountered, signal
strength may vary widely over a short distance. Several techniques strength may vary widely over a short distance. Several techniques
may be used to reduce potential disruptions. Multiple transmitting may be used to reduce potential disruptions. Multiple transmitting
and receiving antennas may be used to reduce multi-path effects; and receiving antennas may be used to reduce multi-path effects;
transmission rate adaptation can be used to find a more satisfactory transmission rate adaptation can be used to find a more satisfactory
transmission rate; transmit power adjustment can be used to improve transmission rate; transmit power adjustment can be used to improve
signal quality and reduce interference; Request-to-Send/Clear-to-Send signal quality and reduce interference; Request-to-Send/Clear-to-Send
(RTS/CTS) signaling can be used to reduce hidden node problems. (RTS/CTS) signaling can be used to reduce hidden node problems.
These techniques may not be completely effective, so that high frame These techniques may not be completely effective, so that high frame
loss may be encountered, causing the link to cycle between "up" and loss may be encountered, causing the link to cycle between "up" and
"down" states. "down" states.
To improve robustness against spurious link indications, it is To improve robustness against spurious link indications, it is
recommended that upper layers treat the indication as a "hint" recommended that upper layers treat the indication as a "hint"
(advisory in nature), rather than a "trigger" dictating a particular (advisory in nature), rather than a "trigger" dictating a particular
action. Upper layers may then attempt to validate the hint. action. Upper layers may then attempt to validate the hint.
In [RFC4436] "Link Up" indications are rate limited and IP In [RFC4436], "Link Up" indications are rate limited, and IP
configuration is confirmed using bi-directional reachability tests configuration is confirmed using bidirectional reachability tests
carried out coincident with a request for configuration via DHCP. As carried out coincident with a request for configuration via DHCP. As
a result, bi-directional reachability is confirmed prior to a result, bidirectional reachability is confirmed prior to activation
activation of an IP configuration. However, where a link exhibits an of an IP configuration. However, where a link exhibits an
intermediate loss rate, demonstration of bi-directional reachability intermediate loss rate, demonstration of bidirectional reachability
may not necessarily indicate that the link is suitable for carrying may not necessarily indicate that the link is suitable for carrying
IP data packets. IP data packets.
Another example of validation occurs in IPv4 Link-Local address Another example of validation occurs in IPv4 Link-Local address
configuration [RFC3927]. Prior to configuration of an IPv4 Link- configuration [RFC3927]. Prior to configuration of an IPv4 Link-
Local address, it is necessary to run a claim and defend protocol. Local address, it is necessary to run a claim-and-defend protocol.
Since a host needs to be present to defend its address against Since a host needs to be present to defend its address against
another claimant, and address conflicts are relatively likely, a host another claimant, and address conflicts are relatively likely, a host
returning from sleep mode or receiving a "Link Up" indication could returning from sleep mode or receiving a "Link Up" indication could
encounter an address conflict were it to utilize a formerly encounter an address conflict were it to utilize a formerly
configured IPv4 Link-Local address without rerunning claim and configured IPv4 Link-Local address without rerunning claim and
defend. defend.
2.3.2. Recovery From Invalid Indications 2.3.2. Recovery from Invalid Indications
In some situations, improper use of link indications can result in In some situations, improper use of link indications can result in
operational malfunctions. It is recommended that upper layers operational malfunctions. It is recommended that upper layers
utilize a timely recovery step so as to limit the potential damage utilize a timely recovery step so as to limit the potential damage
from link indications determined to be invalid after they have been from link indications determined to be invalid after they have been
acted on. acted on.
In DNAv4 [RFC4436], reachability tests are carried out coincident In Detecting Network Attachment in IPv4 (DNAv4) [RFC4436],
with a request for configuration via DHCP. Therefore if the bi- reachability tests are carried out coincident with a request for
directional reachability test times out, the host can still obtain an configuration via DHCP. Therefore, if the bidirectional reachability
IP configuration via DHCP, and if that fails, the host can still test times out, the host can still obtain an IP configuration via
continue to use an existing valid address if it has one. DHCP, and if that fails, the host can still continue to use an
existing valid address if it has one.
Where a proposal involves recovery at the transport layer, the Where a proposal involves recovery at the transport layer, the
recovered transport parameters (such as the Maximum Segment Size recovered transport parameters (such as the Maximum Segment Size
(MSS), RoundTrip Time (RTT), Retransmission TimeOut (RTO), Bandwidth (MSS), RoundTrip Time (RTT), Retransmission TimeOut (RTO), Bandwidth
(bw), congestion window (cwnd), etc.) should be demonstrated to (bw), congestion window (cwnd), etc.) should be demonstrated to
remain valid. Congestion window validation is discussed in "TCP remain valid. Congestion window validation is discussed in "TCP
Congestion Window Validation" [RFC2861]. Congestion Window Validation" [RFC2861].
Where timely recovery is not supported, unexpected consequences may Where timely recovery is not supported, unexpected consequences may
result. As described in [RFC3927], early IPv4 Link-Local result. As described in [RFC3927], early IPv4 Link-Local
skipping to change at page 18, line 51 skipping to change at page 20, line 10
Damping and hysteresis can be utilized to limit damage from unstable Damping and hysteresis can be utilized to limit damage from unstable
link indications. This may include damping unstable indications or link indications. This may include damping unstable indications or
placing constraints on the frequency of link indication-induced placing constraints on the frequency of link indication-induced
actions within a time period. actions within a time period.
While [Aguayo] found that frame loss was relatively stable for While [Aguayo] found that frame loss was relatively stable for
stationary stations, obstacles to radio propagation and multi-path stationary stations, obstacles to radio propagation and multi-path
interference can result in rapid changes in signal strength for a interference can result in rapid changes in signal strength for a
mobile station. As a result, it is possible for mobile stations to mobile station. As a result, it is possible for mobile stations to
encounter rapid changes in link characteristics, including changes in encounter rapid changes in link characteristics, including changes in
transmission rate, throughput, frame loss and even "Link Up"/"Link transmission rate, throughput, frame loss, and even "Link Up"/"Link
Down" indications. Down" indications.
Where link-aware routing metrics are implemented, this can result in Where link-aware routing metrics are implemented, this can result in
rapid metric changes, potentially resulting in frequent changes in rapid metric changes, potentially resulting in frequent changes in
the outgoing interface for Weak End System implementations. As a the outgoing interface for Weak End System implementations. As a
result, it may be necessary to introduce route flap dampening. result, it may be necessary to introduce route flap dampening.
However, the benefits of damping need to be weighed against the However, the benefits of damping need to be weighed against the
additional latency that can be introduced. For example, in order to additional latency that can be introduced. For example, in order to
filter out spurious "Link Down" indications, these indications may be filter out spurious "Link Down" indications, these indications may be
delayed until it can be determined that a "Link Up" indication will delayed until it can be determined that a "Link Up" indication will
not follow shortly thereafter. However, in situations where multiple not follow shortly thereafter. However, in situations where multiple
Beacons are missed such a delay may not be needed, since there is no Beacons are missed such a delay may not be needed, since there is no
evidence of a suitable point of attachment in the vicinity. evidence of a suitable point of attachment in the vicinity.
In some cases it is desirable to ignore link indications entirely. In some cases, it is desirable to ignore link indications entirely.
Since it is possible for a host to transition from an ad-hoc network Since it is possible for a host to transition from an ad-hoc network
to a network with centralized address management, a host receiving a to a network with centralized address management, a host receiving a
"Link Up" indication cannot necessarily conclude that it is "Link Up" indication cannot necessarily conclude that it is
appropriate to configure a IPv4 Link-Local address prior to appropriate to configure an IPv4 Link-Local address prior to
determining whether a DHCP server is available [RFC3927] or an determining whether a DHCP server is available [RFC3927] or an
operable configuration is valid [RFC4436]. operable configuration is valid [RFC4436].
As noted in Section 1.4, the Transport layer does not utilize "Link As noted in Section 1.4, the transport layer does not utilize "Link
Up" and "Link Down" indications for the purposes of connection Up" and "Link Down" indications for the purposes of connection
management. management.
2.4. Congestion Control 2.4. Congestion Control
Link indication proposals must demonstrate that effective congestion Link indication proposals must demonstrate that effective congestion
control is maintained [RFC2914]. One or more of the following control is maintained [RFC2914]. One or more of the following
techniques may be utilized: techniques may be utilized:
Rate limiting. Packets generated based on receipt of link Rate limiting. Packets generated based on receipt of link
indications can be rate limited (e.g. a limit of one packet per indications can be rate limited (e.g., a limit of one packet per
end-to-end path RTO). end-to-end path RTO).
Utilization of upper layer indications. Applications should Utilization of upper-layer indications. Applications should
depend on upper layer indications such as IP address depend on upper-layer indications such as IP address
configuration/change notification, rather than utilizing link configuration/change notification, rather than utilizing link
indications such as "Link Up". indications such as "Link Up".
Keepalives. In order to improve robustness against spurious link Keepalives. In order to improve robustness against spurious link
indications, an application keepalive or Transport layer indications, an application keepalive or transport layer
indication (such as connection teardown) can be used instead of indication (such as connection teardown) can be used instead of
consuming "Link Down" indications. consuming "Link Down" indications.
Conservation of resources. Proposals must demonstrate that they Conservation of resources. Proposals must demonstrate that they
are not vulnerable to congestive collapse. are not vulnerable to congestive collapse.
As noted in "Robust Rate Adaptation for 802.11 Wireless Networks" As noted in "Robust Rate Adaptation for 802.11 Wireless Networks"
[Robust], decreasing transmission rate in response to frame loss [Robust], decreasing transmission rate in response to frame loss
increases contention, potentially leading to congestive collapse. To increases contention, potentially leading to congestive collapse. To
avoid this, the link layer needs to distinguish frame loss due to avoid this, the link layer needs to distinguish frame loss due to
skipping to change at page 20, line 21 skipping to change at page 21, line 29
decreasing transmission rate. decreasing transmission rate.
Consider a proposal where a "Link Up" indication is used by a host to Consider a proposal where a "Link Up" indication is used by a host to
trigger retransmission of the last previously sent packet, in order trigger retransmission of the last previously sent packet, in order
to enable ACK reception prior to expiration of the host's to enable ACK reception prior to expiration of the host's
retransmission timer. On a rapidly moving mobile node where "Link retransmission timer. On a rapidly moving mobile node where "Link
Up" indications follow in rapid succession, this could result in a Up" indications follow in rapid succession, this could result in a
burst of retransmitted packets, violating the principle of burst of retransmitted packets, violating the principle of
"conservation of packets". "conservation of packets".
At the Application layer, link indications have been utilized by At the application layer, link indications have been utilized by
applications such as Presence [RFC2778] in order to optimize applications such as Presence [RFC2778] in order to optimize
registration and user interface update operations. For example, registration and user interface update operations. For example,
implementations may attempt presence registration on receipt of a implementations may attempt presence registration on receipt of a
"Link Up" indication, and presence de-registration by a surrogate "Link Up" indication, and presence de-registration by a surrogate
receiving a "Link Down" indication. Presence implementations using receiving a "Link Down" indication. Presence implementations using
"Link Up"/"Link Down" indications this way violate the principle of "Link Up"/"Link Down" indications this way violate the principle of
"conservation of packets" since link indications can be generated on "conservation of packets" since link indications can be generated on
a time scale less than the end-to-end path RTO. The problem is a time scale less than the end-to-end path RTO. The problem is
magnified since for each presence update, notifications can be magnified since for each presence update, notifications can be
delivered to many watchers. In addition, use of a "Link Up" delivered to many watchers. In addition, use of a "Link Up"
skipping to change at page 21, line 34 skipping to change at page 22, line 44
2.7. Race Conditions 2.7. Race Conditions
Link indication proposals should avoid race conditions, which can Link indication proposals should avoid race conditions, which can
occur where link indications are utilized directly by multiple layers occur where link indications are utilized directly by multiple layers
of the stack. of the stack.
Link indications are useful for optimization of Internet Protocol Link indications are useful for optimization of Internet Protocol
layer addressing and configuration as well as routing. Although "The layer addressing and configuration as well as routing. Although "The
BU-trigger method for improving TCP performance over Mobile IPv6" BU-trigger method for improving TCP performance over Mobile IPv6"
[Kim] describes situations in which link indications are first [Kim] describes situations in which link indications are first
processed by the Internet Protocol layer (e.g. MIPv6) before being processed by the Internet Protocol layer (e.g., MIPv6) before being
utilized by the Transport layer, for the purposes of parameter utilized by the transport layer, for the purposes of parameter
estimation, it may be desirable for the Transport layer to utilize estimation, it may be desirable for the transport layer to utilize
link indications directly. link indications directly.
In situations where the Weak End System model is implemented, a In situations where the Weak End System model is implemented, a
change of outgoing interface may occur at the same time the Transport change of outgoing interface may occur at the same time the transport
layer is modifying transport parameters based on other link layer is modifying transport parameters based on other link
indications. As a result, transport behavior may differ depending on indications. As a result, transport behavior may differ depending on
the order in which the link indications are processed. the order in which the link indications are processed.
Where a multi-homed host experiences increasing frame loss or Where a multi-homed host experiences increasing frame loss or
decreased rate on one of its interfaces, a routing metric taking decreased rate on one of its interfaces, a routing metric taking
these effects into account will increase, potentially causing a these effects into account will increase, potentially causing a
change in the outgoing interface for one or more transport change in the outgoing interface for one or more transport
connections. This may trigger Mobile IP signaling so as to cause a connections. This may trigger Mobile IP signaling so as to cause a
change in the incoming path as well. As a result, the transport change in the incoming path as well. As a result, the transport
parameters estimated for the original outgoing and incoming paths parameters estimated for the original outgoing and incoming paths
(congestion state, Maximum Segment Size (MSS) derived from the link (congestion state, Maximum Segment Size (MSS) derived from the link
maximum transmission unit (MTU) or path MTU) may no longer be valid maximum transmission unit (MTU) or Path MTU) may no longer be valid
for the new outgoing and incoming paths. for the new outgoing and incoming paths.
To avoid race conditions, the following measures are recommended: To avoid race conditions, the following measures are recommended:
Path change re-estimation Path change re-estimation
Layering Layering
Metric consistency Metric consistency
2.7.1. Path Change Re-estimation 2.7.1. Path Change Re-estimation
skipping to change at page 22, line 36 skipping to change at page 23, line 47
Another technique to avoid race conditions is to rely on layering to Another technique to avoid race conditions is to rely on layering to
damp transient link indications and provide greater link layer damp transient link indications and provide greater link layer
independence. independence.
The Internet layer is responsible for routing as well as IP The Internet layer is responsible for routing as well as IP
configuration and mobility, providing higher layers with an configuration and mobility, providing higher layers with an
abstraction that is independent of link layer technologies. abstraction that is independent of link layer technologies.
In general, it is advisable for applications to utilize indications In general, it is advisable for applications to utilize indications
from the Internet or Transport layers rather than consuming link from the Internet or transport layers rather than consuming link
indications directly. indications directly.
2.7.3. Metric Consistency 2.7.3. Metric Consistency
Proposals should avoid inconsistencies between link and routing layer Proposals should avoid inconsistencies between link and routing layer
metrics. Without careful design, potential differences between link metrics. Without careful design, potential differences between link
indications used in routing and those used in roaming and/or link indications used in routing and those used in roaming and/or link
enablement can result in instability, particularly in multi-homed enablement can result in instability, particularly in multi-homed
hosts. hosts.
skipping to change at page 23, line 14 skipping to change at page 24, line 28
Path Metric for Multi-Hop Wireless Routing" [ETX] describes a Path Metric for Multi-Hop Wireless Routing" [ETX] describes a
proposed routing metric based on the Expected Transmission Count proposed routing metric based on the Expected Transmission Count
(ETX). The authors demonstrate that ETX, based on link layer frame (ETX). The authors demonstrate that ETX, based on link layer frame
loss rates (prior to retransmission), enables the selection of routes loss rates (prior to retransmission), enables the selection of routes
maximizing effective throughput. Where the transmission rate is maximizing effective throughput. Where the transmission rate is
constant, the expected transmission time is proportional to ETX, so constant, the expected transmission time is proportional to ETX, so
that minimizing ETX also minimizes expected transmission time. that minimizing ETX also minimizes expected transmission time.
However, where the transmission rate may vary, ETX may not represent However, where the transmission rate may vary, ETX may not represent
a good estimate of the estimated transmission time. In "Routing in a good estimate of the estimated transmission time. In "Routing in
multi-radio, multi-hop wireless mesh networks" [ETX-Rate] the authors multi-radio, multi-hop wireless mesh networks" [ETX-Rate], the
define a new metric called Expected Transmission Time (ETT). This is authors define a new metric called Expected Transmission Time (ETT).
described as a "bandwidth adjusted ETX" since ETT = ETX * S/B where S This is described as a "bandwidth adjusted ETX" since ETT = ETX * S/B
is the size of the probe packet and B is the bandwidth of the link as where S is the size of the probe packet and B is the bandwidth of the
measured by a packet pair [Morgan]. However, ETT assumes that the link as measured by a packet pair [Morgan]. However, ETT assumes
loss fraction of small probe frames sent at 1 Mbps data rate is that the loss fraction of small probe frames sent at 1 Mbps data rate
indicative of the loss fraction of larger data frames at higher is indicative of the loss fraction of larger data frames at higher
rates, which tends to under-estimate the ETT at higher rates, where rates, which tends to underestimate the ETT at higher rates, where
frame loss typically increases. In "A Radio Aware Routing Protocol frame loss typically increases. In "A Radio Aware Routing Protocol
for Wireless Mesh Networks" [ETX-Radio] the authors refine the ETT for Wireless Mesh Networks" [ETX-Radio], the authors refine the ETT
metric further by estimating the loss fraction as a function of metric further by estimating the loss fraction as a function of
transmission rate. transmission rate.
However, prior to sending data packets over the link, the appropriate However, prior to sending data packets over the link, the appropriate
routing metric may not easily be predicted. As noted in [Shortest], routing metric may not easily be predicted. As noted in [Shortest],
a link that can successfully transmit the short frames utilized for a link that can successfully transmit the short frames utilized for
control, management or routing may not necessarily be able to control, management, or routing may not necessarily be able to
reliably transport larger data packets. reliably transport larger data packets.
Therefore it may be necessary to utilize alternative metrics (such as Therefore, it may be necessary to utilize alternative metrics (such
signal strength or access point load) in order to assist in as signal strength or Access Point load) in order to assist in
attachment/handoff decisions. However, unless the new interface is attachment/handoff decisions. However, unless the new interface is
the preferred route for one or more destination prefixes, a Weak End the preferred route for one or more destination prefixes, a Weak End
System implementation will not use the new interface for outgoing System implementation will not use the new interface for outgoing
traffic. Where "idle timeout" functionality is implemented, the traffic. Where "idle timeout" functionality is implemented, the
unused interface will be brought down, only to be brought up again by unused interface will be brought down, only to be brought up again by
the link enablement algorithm. the link enablement algorithm.
Within the link layer, metrics such as signal strength and frame loss Within the link layer, metrics such as signal strength and frame loss
may be used to determine the transmission rate, as well as to may be used to determine the transmission rate, as well as to
determine when to select an alternative point of attachment. In determine when to select an alternative point of attachment. In
order to enable stations to roam prior to encountering packet loss, order to enable stations to roam prior to encountering packet loss,
studies such as studies such as "An experimental study of IEEE 802.11b handover
"An experimental study of IEEE 802.11b handover performance and its performance and its effect on voice traffic" [Vatn] have suggested
effect on voice traffic" [Vatn] have suggested using signal strength using signal strength as a mechanism to more rapidly detect loss of
as a mechanism to more rapidly detect loss of connectivity, rather connectivity, rather than frame loss, as suggested in "Techniques to
than frame loss, as suggested in "Techniques to Reduce IEEE 802.11b Reduce IEEE 802.11b MAC Layer Handover Time" [Velayos].
MAC Layer Handover Time" [Velayos].
[Aguayo] notes that signal strength and distance are not good [Aguayo] notes that signal strength and distance are not good
predictors of frame loss or throughput, due to the potential effects predictors of frame loss or throughput, due to the potential effects
of multi-path interference. As a result a link brought up due to of multi-path interference. As a result, a link brought up due to
good signal strength may subsequently exhibit significant frame loss, good signal strength may subsequently exhibit significant frame loss
and a low throughput. Similarly, an Access Point (AP) demonstrating and a low throughput. Similarly, an Access Point (AP) demonstrating
low utilization may not necessarily be the best choice, since low utilization may not necessarily be the best choice, since
utilization may be low due to hardware or software problems. "OSPF utilization may be low due to hardware or software problems. "OSPF
Optimized Multipath (OSPF-OMP)" [Villamizar] notes that link Optimized Multipath (OSPF-OMP)" [Villamizar] notes that link-
utilization-based routing metrics have a history of instability. utilization-based routing metrics have a history of instability.
2.8. Layer compression 2.8. Layer Compression
In many situations, the exchanges required for a host to complete a In many situations, the exchanges required for a host to complete a
handoff and reestablish connectivity are considerable, leading to handoff and reestablish connectivity are considerable, leading to
proposals to combine exchanges occurring within multiple layers in proposals to combine exchanges occurring within multiple layers in
order to reduce overhead. While overhead reduction is a laudable order to reduce overhead. While overhead reduction is a laudable
goal, proposals need to avoid compromising interoperability and goal, proposals need to avoid compromising interoperability and
introducing link layer dependencies into the Internet and Transport introducing link layer dependencies into the Internet and transport
layers. layers.
Exchanges required for handoff and connectivity reestablishment may Exchanges required for handoff and connectivity reestablishment may
include link layer scanning, authentication and association include link layer scanning, authentication, and association
establishment; Internet layer configuration, routing and mobility establishment; Internet layer configuration, routing, and mobility
exchanges; Transport layer retransmission and recovery; security exchanges; transport layer retransmission and recovery; security
association re-establishment; application protocol re-authentication association reestablishment; application protocol re-authentication
and re-registration exchanges, etc. and re-registration exchanges, etc.
Several proposals involve combining exchanges within the link layer. Several proposals involve combining exchanges within the link layer.
For example, in [EAPIKEv2], a link layer Extensible Authentication For example, in [EAPIKEv2], a link layer Extensible Authentication
Protocol (EAP) [RFC3748] exchange may be used for the purpose of IP Protocol (EAP) [RFC3748] exchange may be used for the purpose of IP
address assignment, potentially bypassing Internet layer address assignment, potentially bypassing Internet layer
configuration. Within [PEAP], it is proposed that a link layer EAP configuration. Within [PEAP], it is proposed that a link layer EAP
exchange be used for the purpose of carrying Mobile IPv6 Binding exchange be used for the purpose of carrying Mobile IPv6 Binding
Updates. [MIPEAP] proposes that EAP exchanges be used for Updates. [MIPEAP] proposes that EAP exchanges be used for
configuration of Mobile IPv6. Where link, Internet or Transport configuration of Mobile IPv6. Where link, Internet, or transport
layer mechanisms are combined, hosts need to maintain backward layer mechanisms are combined, hosts need to maintain backward
compatibility to permit operation on networks where compression compatibility to permit operation on networks where compression
schemes are not available. schemes are not available.
Layer compression schemes may also negatively impact robustness. For Layer compression schemes may also negatively impact robustness. For
example, in order to optimize IP address assignment, it has been example, in order to optimize IP address assignment, it has been
proposed that prefixes be advertised at the link layer, such as proposed that prefixes be advertised at the link layer, such as
within the 802.11 Beacon and Probe Response frames. However, within the 802.11 Beacon and Probe Response frames. However,
[IEEE-802.1X] enables the Virtual LAN Identifier (VLANID) to be [IEEE-802.1X] enables the Virtual LAN Identifier (VLANID) to be
assigned dynamically, so that prefix(es) advertised within the Beacon assigned dynamically, so that prefix(es) advertised within the Beacon
and/or Probe Response may not correspond to the prefix(es) configured and/or Probe Response may not correspond to the prefix(es) configured
by the Internet layer after the host completes link layer by the Internet layer after the host completes link layer
authentication. Were the host to handle IP configuration at the link authentication. Were the host to handle IP configuration at the link
layer rather than within the Internet layer, the host might be unable layer rather than within the Internet layer, the host might be unable
to communicate due to assignment of the wrong IP address. to communicate due to assignment of the wrong IP address.
2.9. Transport of Link Indications 2.9. Transport of Link Indications
Proposals for the transport of link indications need to carefully Proposals for the transport of link indications need to carefully
consider the layering, security and transport implications. consider the layering, security, and transport implications.
As noted earlier, the transport layer may take the state of the local As noted earlier, the transport layer may take the state of the local
routing table into account in improving the quality of transport routing table into account in improving the quality of transport
parameter estimates. While absence of positive feedback that the parameter estimates. While absence of positive feedback that the
path is sending data end-to-end must be heeded, where a route that path is sending data end-to-end must be heeded, where a route that
had previously been absent is recovered, this may be used to trigger had previously been absent is recovered, this may be used to trigger
congestion control probing. While this enables transported link congestion control probing. While this enables transported link
indications that affect the local routing table to improve the indications that affect the local routing table to improve the
quality of transport parameter estimates, security and quality of transport parameter estimates, security and
interoperability considerations relating to routing protocols still interoperability considerations relating to routing protocols still
apply. apply.
Proposals involving transport of link indications need to demonstrate Proposals involving transport of link indications need to demonstrate
the following: the following:
(a) Superiority to implicit signals. In general, implicit signals are (a) Superiority to implicit signals. In general, implicit signals
preferred to explicit transport of link indications since they do are preferred to explicit transport of link indications since
not require participation in the routing mesh, add no new packets they do not require participation in the routing mesh, add no
in times of network distress, operate more reliably in the presence new packets in times of network distress, operate more reliably
of middle boxes such as NA(P)Ts, are more likely to be backward in the presence of middle boxes such as NA(P)Ts, are more likely
compatible, and are less likely to result in security to be backward compatible, and are less likely to result in
vulnerabilities. As a result, explicit signaling proposals must security vulnerabilities. As a result, explicit signaling
prove that implicit signals are inadequate. proposals must prove that implicit signals are inadequate.
(b) Mitigation of security vulnerabilities. Transported link (b) Mitigation of security vulnerabilities. Transported link
indications should not introduce new security vulnerabilities. indications should not introduce new security vulnerabilities.
Link indications that result in modifications to the local routing Link indications that result in modifications to the local
table represent a routing protocol, so that the vulnerabilities routing table represent a routing protocol, so that the
associated with unsecured routing protocols apply, including vulnerabilities associated with unsecured routing protocols
spoofing by off-link attackers. While mechanisms such as "SEcure apply, including spoofing by off-link attackers. While
Neighbor Discovery (SEND)" [RFC3971] may enable authentication and mechanisms such as "SEcure Neighbor Discovery (SEND)" [RFC3971]
integrity protection of router-originated messages, protecting may enable authentication and integrity protection of router-
against forgery of transported link indications, they are not yet originated messages, protecting against forgery of transported
widely deployed. link indications, they are not yet widely deployed.
(c) Validation of transported indications. Even if a transported link (c) Validation of transported indications. Even if a transported
indication can be integrity protected and authenticated, if the link indication can be integrity protected and authenticated, if
indication is sent by a host off the local link, it may not be the indication is sent by a host off the local link, it may not
clear that the sender is on the actual path in use, or which be clear that the sender is on the actual path in use, or which
transport connection(s) the indication relates to. Proposals need transport connection(s) the indication relates to. Proposals
to describe how the receiving host can validate the transported need to describe how the receiving host can validate the
link indication. transported link indication.
(d) Mapping of Identifiers. When link indications are transported, it (d) Mapping of Identifiers. When link indications are transported,
is generally for the purposes of providing information about it is generally for the purposes of providing information about
Internet, Transport or Application layer operations at a remote Internet, transport, or application layer operations at a remote
element. However application layer sessions or transport element. However, application layer sessions or transport
connections may not be visible to the remote element due to factors connections may not be visible to the remote element due to
such as load sharing between links, or use of IPsec, tunneling factors such as load sharing between links, or use of IPsec,
protocols or nested headers. As a result, proposals need to tunneling protocols, or nested headers. As a result, proposals
demonstrate how the link indication can be mapped to the relevant need to demonstrate how the link indication can be mapped to the
higher layer state. For example, on receipt of a link indication, relevant higher-layer state. For example, on receipt of a link
the Transport layer will need to identify the set of transport indication, the transport layer will need to identify the set of
sessions (source address, destination address, source port, transport sessions (source address, destination address, source
destination port, transport) that are affected. If a presence port, destination port, transport) that are affected. If a
server is receiving remote indications of "Link Up"/"Link Down" presence server is receiving remote indications of "Link
status for a particular Media Access Control (MAC) address, the Up"/"Link Down" status for a particular Media Access Control
presence server will need to associate that MAC address with the (MAC) address, the presence server will need to associate that
identity of the user (pres:user@example.com) to whom that link MAC address with the identity of the user
status change is relevant. (pres:user@example.com) to whom that link status change is
relevant.
3. Future Work 3. Future Work
Further work is needed in order to understand how link indications Further work is needed in order to understand how link indications
can be utilized by the Internet, Transport and Application layers. can be utilized by the Internet, transport, and application layers.
More work is needed to understand the connection between link More work is needed to understand the connection between link
indications and routing metrics. For example, the introduction of indications and routing metrics. For example, the introduction of
block ACKs (supported in [IEEE-802.11e]) complicates the relationship block ACKs (supported in [IEEE-802.11e]) complicates the relationship
between effective throughput and frame loss, which may necessitate between effective throughput and frame loss, which may necessitate
the development of revised routing metrics for ad-hoc networks. More the development of revised routing metrics for ad-hoc networks. More
work is also needed to reconcile handoff metrics (e.g. signal work is also needed to reconcile handoff metrics (e.g., signal
strength and link utilization) with routing metrics based on link strength and link utilization) with routing metrics based on link
indications (e.g. frame error rate and negotiated rate). indications (e.g., frame error rate and negotiated rate).
A better understanding of the use of physical and link layer metrics A better understanding of the use of physical and link layer metrics
in rate negotiation is required. For example, recent work in rate negotiation is required. For example, recent work
[Robust][CARA] has suggested that frame loss due to contention (which [Robust][CARA] has suggested that frame loss due to contention (which
would be exacerbated by rate reduction) can be distinguished from would be exacerbated by rate reduction) can be distinguished from
loss due to channel conditions (which may be improved via rate loss due to channel conditions (which may be improved via rate
reduction). reduction).
At the Transport layer, more work is needed to determine the At the transport layer, more work is needed to determine the
appropriate reaction to Internet layer indications such as routing appropriate reaction to Internet layer indications such as routing
table and path changes. More work is also needed in utilization of table and path changes. More work is also needed in utilization of
link layer indications in transport parameter estimation, including link layer indications in transport parameter estimation, including
rate changes, "Link Up"/"Link Down" indications, link layer rate changes, "Link Up"/"Link Down" indications, link layer
retransmissions and frame loss of various types (due to contention or retransmissions, and frame loss of various types (due to contention
channel conditions). or channel conditions).
More work is also needed to determine how link layers may utilize More work is also needed to determine how link layers may utilize
information from the Transport layer. For example, it is undesirable information from the transport layer. For example, it is undesirable
for a link layer to retransmit so aggressively that the link layer for a link layer to retransmit so aggressively that the link layer
round-trip time approaches that of the end-to-end transport round-trip time approaches that of the end-to-end transport
connection. Instead, it may make sense to do downward rate connection. Instead, it may make sense to do downward rate
adjustment so as to decrease frame loss and improve latency. Also, adjustment so as to decrease frame loss and improve latency. Also,
in some cases, the transport layer may not require heroic efforts to in some cases, the transport layer may not require heroic efforts to
avoid frame loss; timely delivery may be preferred instead. avoid frame loss; timely delivery may be preferred instead.
4. Security Considerations 4. Security Considerations
Proposals for the utilization of link indications may introduce new Proposals for the utilization of link indications may introduce new
skipping to change at page 27, line 33 skipping to change at page 28, line 48
4.1. Spoofing 4.1. Spoofing
Where link layer control frames are unprotected, they may be spoofed Where link layer control frames are unprotected, they may be spoofed
by an attacker. For example, PPP does not protect LCP frames such as by an attacker. For example, PPP does not protect LCP frames such as
LCP-Terminate, and [IEEE-802.11] does not protect management frames LCP-Terminate, and [IEEE-802.11] does not protect management frames
such as Associate/ Reassociate, Disassociate, or Deauthenticate. such as Associate/ Reassociate, Disassociate, or Deauthenticate.
Spoofing of link layer control traffic may enable attackers to Spoofing of link layer control traffic may enable attackers to
exploit weaknesses in link indication proposals. For example, exploit weaknesses in link indication proposals. For example,
proposals that do not implement congestion avoidance can enable proposals that do not implement congestion avoidance can enable
attackers to mount denial of service attacks. attackers to mount denial-of-service attacks.
However, even where the link layer incorporates security, attacks may However, even where the link layer incorporates security, attacks may
still be possible if the security model is not consistent. For still be possible if the security model is not consistent. For
example, wireless LANs implementing [IEEE-802.11i] do not enable example, wireless LANs implementing [IEEE-802.11i] do not enable
stations to send or receive IP packets on the link until completion stations to send or receive IP packets on the link until completion
of an authenticated key exchange protocol known as the "4-way of an authenticated key exchange protocol known as the "4-way
handshake". As a result, a link implementing [IEEE-802.11i] cannot handshake". As a result, a link implementing [IEEE-802.11i] cannot
be considered usable at the Internet layer ("Link Up") until be considered usable at the Internet layer ("Link Up") until
completion of the authenticated key exchange. completion of the authenticated key exchange.
However, while [IEEE-802.11i] requires sending of authenticated However, while [IEEE-802.11i] requires sending of authenticated
frames in order to obtain a "Link Up" indication, it does not support frames in order to obtain a "Link Up" indication, it does not support
management frame authentication. This weakness can be exploited by management frame authentication. This weakness can be exploited by
attackers to enable denial of service attacks on stations attached to attackers to enable denial-of-service attacks on stations attached to
distant Access Points (AP). distant Access Points (APs).
In [IEEE-802.11F], "Link Up" is considered to occur when an AP sends In [IEEE-802.11F], "Link Up" is considered to occur when an AP sends
a Reassociation Response. At that point, the AP sends a spoofed a Reassociation Response. At that point, the AP sends a spoofed
frame with the station's source address to a multicast address, frame with the station's source address to a multicast address,
thereby causing switches within the Distribution System (DS) to learn thereby causing switches within the Distribution System (DS) to learn
the station's MAC address. While this enables forwarding of frames the station's MAC address. While this enables forwarding of frames
to the station at the new point of attachment, it also permits an to the station at the new point of attachment, it also permits an
attacker to disassociate a station located anywhere within the ESS, attacker to disassociate a station located anywhere within the ESS,
by sending an unauthenticated Reassociation Request frame. by sending an unauthenticated Reassociation Request frame.
4.2. Indication Validation 4.2. Indication Validation
"Fault Isolation and Recovery" [RFC816] Section 3 describes how hosts "Fault Isolation and Recovery" [RFC816], Section 3, describes how
interact with routers for the purpose of fault recovery: hosts interact with routers for the purpose of fault recovery:
Since the gateways always attempt to have a consistent and correct Since the gateways always attempt to have a consistent and correct
model of the internetwork topology, the host strategy for fault model of the internetwork topology, the host strategy for fault
recovery is very simple. Whenever the host feels that something recovery is very simple. Whenever the host feels that something is
is wrong, it asks the gateway for advice, and, assuming the advice wrong, it asks the gateway for advice, and, assuming the advice is
is forthcoming, it believes the advice completely. The advice forthcoming, it believes the advice completely. The advice will be
will be wrong only during the transient period of negotiation, wrong only during the transient period of negotiation, which
which immediately follows an outage, but will otherwise be immediately follows an outage, but will otherwise be reliably
reliably correct. correct.
In fact, it is never necessary for a host to explicitly ask a In fact, it is never necessary for a host to explicitly ask a gateway
gateway for advice, because the gateway will provide it as for advice, because the gateway will provide it as appropriate. When
appropriate. When a host sends a datagram to some distant net, a host sends a datagram to some distant net, the host should be
the host should be prepared to receive back either of two advisory prepared to receive back either of two advisory messages which the
messages which the gateway may send. The ICMP "redirect" message gateway may send. The ICMP "redirect" message indicates that the
indicates that the gateway to which the host sent the datagram is gateway to which the host sent the datagram is no longer the best
no longer the best gateway to reach the net in question. The gateway to reach the net in question. The gateway will have
gateway will have forwarded the datagram, but the host should forwarded the datagram, but the host should revise its routing table
revise its routing table to have a different immediate address for to have a different immediate address for this net. The ICMP
this net. The ICMP "destination unreachable" message indicates "destination unreachable" message indicates that as a result of an
that as a result of an outage, it is currently impossible to reach outage, it is currently impossible to reach the addressed net or host
the addressed net or host in any manner. On receipt of this in any manner. On receipt of this message, a host can either abandon
message, a host can either abandon the connection immediately the connection immediately without any further retransmission, or
without any further retransmission, or resend slowly to see if the resend slowly to see if the fault is corrected in reasonable time.
fault is corrected in reasonable time.
Given today's security environment, it is inadvisable for hosts to Given today's security environment, it is inadvisable for hosts to
act on indications provided by routers without careful consideration. act on indications provided by routers without careful consideration.
As noted in "ICMP attacks against TCP" [Gont], existing ICMP error As noted in "ICMP attacks against TCP" [Gont], existing ICMP error
messages may be exploited by attackers in order to abort connections messages may be exploited by attackers in order to abort connections
in progress, prevent setup of new connections, or reduce throughput in progress, prevent setup of new connections, or reduce throughput
of ongoing connections. Similar attacks may also be launched against of ongoing connections. Similar attacks may also be launched against
the Internet layer via forging of ICMP redirects. the Internet layer via forging of ICMP redirects.
Proposals for transported link indications need to demonstrate that Proposals for transported link indications need to demonstrate that
they will not add a new set of similar vulnerabilities. Since they will not add a new set of similar vulnerabilities. Since
transported link indications are typically unauthenticated, hosts transported link indications are typically unauthenticated, hosts
receiving them may not be able to determine whether they are receiving them may not be able to determine whether they are
authentic, or even plausible. authentic, or even plausible.
Where link indication proposals may respond to unauthenticated link Where link indication proposals may respond to unauthenticated link
layer frames, they should utilize upper layer security mechanisms, layer frames, they should utilize upper-layer security mechanisms,
where possible. For example, even though a host might utilize an where possible. For example, even though a host might utilize an
unauthenticated link layer control frame to conclude that a link has unauthenticated link layer control frame to conclude that a link has
become operational, it can use SEND [RFC3971] or authenticated DHCP become operational, it can use SEND [RFC3971] or authenticated DHCP
[RFC3118] in order to obtain secure Internet layer configuration. [RFC3118] in order to obtain secure Internet layer configuration.
4.3. Denial of Service 4.3. Denial of Service
Link indication proposals need to be particularly careful to avoid Link indication proposals need to be particularly careful to avoid
enabling denial of service attacks that can be mounted at a distance. enabling denial-of-service attacks that can be mounted at a distance.
While wireless links are naturally vulnerable to interference, such While wireless links are naturally vulnerable to interference, such
attacks can only be perpetrated by an attacker capable of attacks can only be perpetrated by an attacker capable of
establishing radio contact with the target network. However, attacks establishing radio contact with the target network. However, attacks
that can be mounted from a distance, either by an attacker on another that can be mounted from a distance, either by an attacker on another
point of attachment within the same network or by an off-link point of attachment within the same network or by an off-link
attacker, expand the level of vulnerability. attacker, expand the level of vulnerability.
The transport of link indications can increase risk by enabling The transport of link indications can increase risk by enabling
vulnerabilities exploitable only by attackers on the local link to be vulnerabilities exploitable only by attackers on the local link to be
executed across the Internet. Similarly, by integrating link executed across the Internet. Similarly, by integrating link
indications with upper layers, proposals may enable a spoofed link indications with upper layers, proposals may enable a spoofed link
layer frame to consume more resources on the host than might layer frame to consume more resources on the host than might
otherwise be the case. As a result, while it is important for upper otherwise be the case. As a result, while it is important for upper
layers to validate link indications, they should not expend excessive layers to validate link indications, they should not expend excessive
resources in doing so. resources in doing so.
Congestion control is not only a transport issue, it is also a Congestion control is not only a transport issue, it is also a
security issue. In order to not provide leverage to an attacker, a security issue. In order to not provide leverage to an attacker, a
single forged link layer frame should not elicit a magnified response single forged link layer frame should not elicit a magnified response
from one or more hosts, either by generating multiple responses or a from one or more hosts, by generating either multiple responses or a
single larger response. For example, proposals should not enable single larger response. For example, proposals should not enable
multiple hosts to respond to a frame with a multicast destination multiple hosts to respond to a frame with a multicast destination
address. address.
5. IANA Considerations 5. References
This document has no actions for IANA. 5.1. Normative References
6. References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
6.1. Informative References 5.2. Informative References
[RFC816] Clark, D., "Fault Isolation and Recovery", RFC 816, July [RFC816] Clark, D., "Fault Isolation and Recovery", RFC 816,
1982. July 1982.
[RFC1058] Hedrick, C., "Routing Information Protocol", RFC 1058, [RFC1058] Hedrick, C., "Routing Information Protocol", RFC 1058,
June 1988. June 1988.
[RFC1122] Braden, R., "Requirements for Internet Hosts -- [RFC1122] Braden, R., "Requirements for Internet Hosts --
Communication Layers", RFC 1122, October 1989. Communication Layers", STD 3, RFC 1122, October 1989.
[RFC1131] Moy, J., "The OSPF Specification", RFC 1131, October [RFC1131] Moy, J., "The OSPF Specification", RFC 1131, October
1989. 1989.
[RFC1191] Mogul, J. and S. Deering, "Path MTU discovery", RFC 1191, [RFC1191] Mogul, J. and S. Deering, "Path MTU discovery", RFC
November 1990. 1191, November 1990.
[RFC1256] Deering, S., "ICMP Router Discovery Messages", RFC 1256, [RFC1256] Deering, S., "ICMP Router Discovery Messages", RFC
Xerox PARC, September 1991. 1256, September 1991.
[RFC1305] Mills, D., "Network Time Protocol (Version 3) [RFC1305] Mills, D., "Network Time Protocol (Version 3)
Specification, Implementation and Analysis", RFC 1305, Specification, Implementation and Analysis", RFC 1305,
March 1992. March 1992.
[RFC1307] Young, J. and A. Nicholson, "Dynamically Switched Link [RFC1307] Young, J. and A. Nicholson, "Dynamically Switched Link
Control Protocol", RFC 1307, March 1992. Control Protocol", RFC 1307, March 1992.
[RFC1661] Simpson, W., "The Point-to-Point Protocol (PPP)", STD 51, [RFC1661] Simpson, W., "The Point-to-Point Protocol (PPP)", STD
RFC 1661, July 1994. 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. [RFC1812] Baker, F., "Requirements for IP Version 4 Routers",
and E. Lear, "Address Allocation for Private Internets", RFC 1812, June 1995.
RFC 1918, February 1996.
[RFC1981] McCann, J., Deering, S. and J. Mogul, "Path MTU Discovery [RFC1918] Rekhter, Y., Moskowitz, B., Karrenberg, D., de Groot,
for IP version 6", RFC 1981, June 1996. D., and E. Lear, "Address Allocation for Private
Internets", BCP 5, RFC 1918, February 1996.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC1981] McCann, J., Deering, S. and J. Mogul, "Path MTU
Requirement Levels", BCP 14, RFC 2119, March 1997. Discovery for IP version 6", RFC 1981, June 1996.
[RFC2131] Droms, R., "Dynamic Host Configuration Protocol", RFC [RFC2131] Droms, R., "Dynamic Host Configuration Protocol", RFC
2131, March 1997. 2131, March 1997.
[RFC2461] Narten, T., Nordmark, E. and W. Simpson, "Neighbor [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 Discovery for IP Version 6 (IPv6)", RFC 2461, December
1998. 1998.
[RFC2778] Day, M., Rosenberg, J. and H. Sugano, "A Model for [RFC2778] Day, M., Rosenberg, J., and H. Sugano, "A Model for
Presence and Instant Messaging", RFC 2778, February 2000. Presence and Instant Messaging", RFC 2778, February
2000.
[RFC2861] Handley, M., Padhye, J. and S. Floyd, "TCP Congestion [RFC2861] Handley, M., Padhye, J., and S. Floyd, "TCP Congestion
Window Validation", RFC 2861, June 2000. Window Validation", RFC 2861, June 2000.
[RFC2914] Floyd, S., "Congestion Control Principles", RFC 2914, BCP [RFC2914] Floyd, S., "Congestion Control Principles", RFC 2914,
41, September 2000. BCP 41, September 2000.
[RFC2923] Lahey, K., "TCP Problems with Path MTU Discovery", RFC [RFC2923] Lahey, K., "TCP Problems with Path MTU Discovery", RFC
2923, September 2000. 2923, September 2000.
[RFC2960] Stewart, R., Xie, Q., Morneault, K., Sharp, C., [RFC2960] Stewart, R., Xie, Q., Morneault, K., Sharp, C.,
Schwarzbauer, H. Taylor, T., Rytina, I., Kalla, M., Schwarzbauer, H. Taylor, T., Rytina, I., Kalla, M.,
Zhang, L. and V. Paxson, "Stream Control Transmission Zhang, L., and V. Paxson, "Stream Control Transmission
Protocol" RFC 2960, October 2000. Protocol" RFC 2960, October 2000.
[RFC3118] Droms, R. and B. Arbaugh, "Authentication for DHCP [RFC3118] Droms, R. and B. Arbaugh, "Authentication for DHCP
Messages", RFC 3118, June 2001. Messages", RFC 3118, June 2001.
[RFC3315] Droms, R., et al., "Dynamic Host Configuration Protocol [RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins,
for IPv6 (DHCPv6)", RFC 3315, July 2003. 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 [RFC3366] Fairhurst, G. and L. Wood, "Advice to link designers
link Automatic Repeat reQuest (ARQ)", RFC 3366, August on link Automatic Repeat reQuest (ARQ)", BCP 62, RFC
2002. 3366, August 2002.
[RFC3428] Campbell, B., Rosenberg, J., Schulzrinne, H., Huitema, C. [RFC3428] Campbell, B., Rosenberg, J., Schulzrinne, H., Huitema,
and D. Gurle, "Session Initiation Protocol (SIP) C., and D. Gurle, "Session Initiation Protocol (SIP)
Extension for Instant Messaging", RFC 3428, December Extension for Instant Messaging", RFC 3428, December
2002. 2002.
[RFC3748] Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J. and H. [RFC3748] Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J., and
Lefkowetz, "Extensible Authentication Protocol (EAP)", H. Levkowetz, "Extensible Authentication Protocol
RFC 3748, June 2004. (EAP)", RFC 3748, June 2004.
[RFC3775] Johnson, D., Perkins, C. and J. Arkko, "Mobility Support [RFC3775] Johnson, D., Perkins, C., and J. Arkko, "Mobility
in IPv6", RFC 3775, June 2004. Support in IPv6", RFC 3775, June 2004.
[RFC3921] Saint-Andre, P., "Extensible Messaging and Presence [RFC3921] Saint-Andre, P., "Extensible Messaging and Presence
protocol (XMPP): Instant Messaging and Presence", RFC protocol (XMPP): Instant Messaging and Presence", RFC
3921, October 2004. 3921, October 2004.
[RFC3927] Cheshire, S., Aboba, B. and E. Guttman, "Dynamic [RFC3927] Cheshire, S., Aboba, B., and E. Guttman, "Dynamic
Configuration of Link-Local IPv4 Addresses", RFC 3927, Configuration of Link-Local IPv4 Addresses", RFC 3927,
May 2005. May 2005.
[RFC3971] Arkko, J., Kempf, J., Zill, B. and P. Nikander, "SEcure [RFC3971] Arkko, J., Kempf, J., Zill, B., and P. Nikander,
Neighbor Discovery (SEND)", RFC 3971, March 2005. "SEcure Neighbor Discovery (SEND)", RFC 3971, March
2005.
[RFC4340] Kohler, E., Handley, M. and S. Floyd, "Datagram [RFC4340] Kohler, E., Handley, M., and S. Floyd, "Datagram
Congestion Control Protocol (DCCP)", RFC 4340, March Congestion Control Protocol (DCCP)", RFC 4340, March
2006. 2006.
[RFC4423] Moskowitz, R. and P. Nikander, "Host Identity Protocol [RFC4423] Moskowitz, R. and P. Nikander, "Host Identity Protocol
(HIP) Architecture", RFC 4423, May 2006. (HIP) Architecture", RFC 4423, May 2006.
[RFC4429] Moore, N., "Optimistic Duplicate Address Detection (DAD) [RFC4429] Moore, N., "Optimistic Duplicate Address Detection
for IPv6", RFC 4429, April 2006. (DAD) for IPv6", RFC 4429, April 2006.
[RFC4436] Aboba, B., Carlson, J. and S. Cheshire, "Detecting [RFC4436] Aboba, B., Carlson, J., and S. Cheshire, "Detecting
Network Attachment in IPv4 (DNAv4)", RFC 4436, March Network Attachment in IPv4 (DNAv4)", RFC 4436, March
2006. 2006.
[PMTUDRFC] Mathis, M. and J. Heffner, "Packetization Layer Path MTU [RFC4821] Mathis, M. and J. Heffner, "Packetization Layer Path
Discovery", draft-ietf-pmtud-method-11, Internet draft MTU Discovery", RFC 4821, March 2007.
(work in progress), December 2006.
[Alimian] Alimian, A., "Roaming Interval Measurements", [Alimian] Alimian, A., "Roaming Interval Measurements",
11-04-0378-00-roaming-intervals-measurements.ppt, IEEE 11-04-0378-00-roaming-intervals-measurements.ppt, IEEE
802.11 submission (work in progress), March 2004. 802.11 submission (work in progress), March 2004.
[Aguayo] Aguayo, D., Bicket, J., Biswas, S., Judd, G. and R. [Aguayo] Aguayo, D., Bicket, J., Biswas, S., Judd, G., and R.
Morris, "Link-level Measurements from an 802.11b Mesh Morris, "Link-level Measurements from an 802.11b Mesh
Network", SIGCOMM '04, September 2004, Portland, Oregon. Network", SIGCOMM '04, September 2004, Portland,
Oregon.
[Bakshi] Bakshi, B., Krishna, P., Vadiya, N. and D.Pradhan, [Bakshi] Bakshi, B., Krishna, P., Vadiya, N., and D.Pradhan,
"Improving Performance of TCP over Wireless Networks", "Improving Performance of TCP over Wireless Networks",
Proceedings of the 1997 International Conference on Proceedings of the 1997 International Conference on
Distributed Computer Systems, Baltimore, May 1997. Distributed Computer Systems, Baltimore, May 1997.
[BFD] Katz, D. and D. Ward, "Bidirectional Forwarding [BFD] Katz, D. and D. Ward, "Bidirectional Forwarding
Detection", draft-ietf-bfd-base-05.txt, Internet draft Detection", Work in Progress, March 2007.
(work in progress), June 2006.
[Biaz] Biaz, S. and N. Vaidya, "Discriminating Congestion Losses [Biaz] Biaz, S. and N. Vaidya, "Discriminating Congestion
from Wireless Losses Using Interarrival Times at the Losses from Wireless Losses Using Interarrival Times
Receiver", Proc. IEEE Symposium on Application-Specific at the Receiver", Proceedings of the IEEE Symposium on
Systems and Software Engineering and Technology, Application-Specific Systems and Software Engineering
Richardson, TX, Mar 1999. and Technology, Richardson, TX, Mar 1999.
[CARA] Kim, J., Kim, S. and S. Choi, "CARA: Collision-Aware Rate [CARA] Kim, J., Kim, S., and S. Choi, "CARA: Collision-Aware
Adaptation for IEEE 802.11 WLANs", Korean Institute of Rate Adaptation for IEEE 802.11 WLANs", Korean
Communication Sciences (KICS) Journal, Feb. 2006 Institute of Communication Sciences (KICS) Journal,
Feb. 2006
[Chandran] Chandran, K., Raghunathan, S., Venkatesan, S. and R. [Chandran] Chandran, K., Raghunathan, S., Venkatesan, S., and R.
Prakash, "A Feedback-Based Scheme for Improving TCP Prakash, "A Feedback-Based Scheme for Improving TCP
Performance in Ad-Hoc Wireless Networks", Proceedings of Performance in Ad-Hoc Wireless Networks", Proceedings
the 18th International Conference on Distributed of the 18th International Conference on Distributed
Computing Systems (ICDCS), Amsterdam, May 1998. Computing Systems (ICDCS), Amsterdam, May 1998.
[DNAv6] Narayanan, S., "Detecting Network Attachment in IPv6 [DNAv6] Narayanan, S., "Detecting Network Attachment in IPv6
(DNAv6)", draft-ietf-dna-protocol-04.txt, Internet draft (DNAv6)", Work in Progress, March 2007.
(work in progress), February 2007.
[E2ELinkup] Dawkins, S. and C. Williams, "End-to-end, Implicit 'Link- [E2ELinkup] Dawkins, S. and C. Williams, "End-to-end, Implicit
Up' Notification", draft-dawkins-trigtran-linkup-01.txt, 'Link-Up' Notification", Work in Progress, October
Internet draft (work in progress), October 2003. 2003.
[EAPIKEv2] Tschofenig, H., Kroeselberg, D., Pashalidis, A., Ohba, [EAPIKEv2] Tschofenig, H., Kroeselberg, D., Pashalidis, A., Ohba,
Y., and F. Bersani, "EAP IKEv2 Method", draft-tschofenig- Y., and F. Bersani, "EAP IKEv2 Method", Work in
eap-ikev2-12.txt, Internet draft (work in progress), Progress, March 2007.
October 2006.
[Eckhardt] Eckhardt, D. and P. Steenkiste, "Measurement and Analysis [Eckhardt] Eckhardt, D. and P. Steenkiste, "Measurement and
of the Error Characteristics of an In-Building Wireless Analysis of the Error Characteristics of an In-
Network", SIGCOMM '96, August 1996, Stanford, CA. Building Wireless Network", SIGCOMM '96, August 1996,
Stanford, CA.
[Eddy] Eddy, W. and Y. Swami, "Adapting End Host Congestion [Eddy] Eddy, W. and Y. Swami, "Adapting End Host Congestion
Control for Mobility", Technical Report CR-2005-213838, Control for Mobility", Technical Report CR-2005-
NASA Glenn Research Center, July 2005. 213838, NASA Glenn Research Center, July 2005.
[EfficientEthernet] [EfficientEthernet]
Gunaratne, C. and K. Christensen, "Ethernet Adaptive Link Gunaratne, C. and K. Christensen, "Ethernet Adaptive
Rate: System Design and Performance Evaluation", Link Rate: System Design and Performance Evaluation",
Proceedings of the IEEE Conference on Local Computer Proceedings of the IEEE Conference on Local Computer
Networks, pp. 28-35, November 2006. Networks, pp. 28-35, November 2006.
[Eggert] Eggert, L., Schuetz, S. and S. Schmid, "TCP Extensions [Eggert] Eggert, L., Schuetz, S., and S. Schmid, "TCP
for Immediate Retransmissions", draft-eggert-tcpm-tcp- Extensions for Immediate Retransmissions", Work in
retransmit-now-02.txt, Internet draft (work in progress), Progress, June 2005.
June 2005.
[Eggert2] Eggert, L. and W. Eddy, "Towards More Expressive [Eggert2] Eggert, L. and W. Eddy, "Towards More Expressive
Transport-Layer Interfaces", MobiArch '06, San Francisco, Transport-Layer Interfaces", MobiArch '06, San
CA. Francisco, CA.
[ETX] Douglas S. J. De Couto, Daniel Aguayo, John Bicket, and [ETX] Douglas S. J. De Couto, Daniel Aguayo, John Bicket,
Robert Morris, "A High-Throughput Path Metric for Multi- and Robert Morris, "A High-Throughput Path Metric for
Hop Wireless Routing", Proceedings of the 9th ACM Multi-Hop Wireless Routing", Proceedings of the 9th
International Conference on Mobile Computing and ACM International Conference on Mobile Computing and
Networking (MobiCom '03), San Diego, California, Networking (MobiCom '03), San Diego, California,
September 2003. September 2003.
[ETX-Rate] Padhye, J., Draves, R. and B. Zill, "Routing in multi- [ETX-Rate] Padhye, J., Draves, R. and B. Zill, "Routing in
radio, multi-hop wireless mesh networks", Proceedings of multi-radio, multi-hop wireless mesh networks",
ACM MobiCom Conference, September 2003. Proceedings of ACM MobiCom Conference, September 2003.
[ETX-Radio] Kulkarni, G., Nandan, A., Gerla, M. and M. Srivastava, "A [ETX-Radio] Kulkarni, G., Nandan, A., Gerla, M., and M.
Radio Aware Routing Protocol for Wireless Mesh Networks", Srivastava, "A Radio Aware Routing Protocol for
UCLA Computer Science Department, Los Angeles, CA Wireless Mesh Networks", UCLA Computer Science
Department, Los Angeles, CA.
[GenTrig] Gupta, V. and D. Johnston, "A Generalized Model for Link [GenTrig] Gupta, V. and D. Johnston, "A Generalized Model for
Layer Triggers", submission to IEEE 802.21 (work in Link Layer Triggers", submission to IEEE 802.21 (work
progress), March 2004, available at: in progress), March 2004, available at:
http://www.ieee802.org/handoff/march04_meeting_docs/ <http://www.ieee802.org/handoff/march04_meeting_docs/
Generalized_triggers-02.pdf Generalized_triggers-02.pdf>.
[Goel] Goel, S. and D. Sanghi, "Improving TCP Performance over [Goel] Goel, S. and D. Sanghi, "Improving TCP Performance
Wireless Links", Proceedings of TENCON'98, pages 332-335. over Wireless Links", Proceedings of TENCON'98, pages
IEEE, December 1998. 332-335. IEEE, December 1998.
[Gont] Gont, F., "ICMP attacks against TCP", draft-ietf-tcpm- [Gont] Gont, F., "ICMP attacks against TCP", Work in
icmp-attacks-01, Internet draft (work in progress), Progress, October 2006.
October 2006.
[Gurtov] Gurtov, A. and J. Korhonen, "Effect of Vertical Handovers [Gurtov] Gurtov, A. and J. Korhonen, "Effect of Vertical
on Performance of TCP-Friendly Rate Control", to appear Handovers on Performance of TCP-Friendly Rate
in ACM MCCR, 2004. Control", to appear in ACM MCCR, 2004.
[GurtovFloyd] Gurtov, A. and S. Floyd, "Modeling Wireless Links for [GurtovFloyd] Gurtov, A. and S. Floyd, "Modeling Wireless Links for
Transport Protocols", Computer Communications Review Transport Protocols", Computer Communications Review
(CCR) 34, 2 (2003). (CCR) 34, 2 (2003).
[Haratcherev] Haratcherev, I., Lagendijk, R., Langendoen, K. and H. [Haratcherev] Haratcherev, I., Lagendijk, R., Langendoen, K., and H.
Sips, "Hybrid Rate Control for IEEE 802.11", MobiWac '04, Sips, "Hybrid Rate Control for IEEE 802.11", MobiWac
October 1, 2004, Philadelphia, Pennsylvania, USA '04, October 1, 2004, Philadelphia, Pennsylvania, USA.
[Haratcherev2] Haratcherev, I., "Application-oriented Link Adaptation [Haratcherev2] Haratcherev, I., "Application-oriented Link Adaptation
for IEEE 802.11", Ph.D. Thesis, Technical University of for IEEE 802.11", Ph.D. Thesis, Technical University
Delft, Netherlands, ISBN-10:90-9020513-6, of Delft, Netherlands, ISBN-10:90-9020513-6, ISBN-
ISBN-13:978-90-9020513-7, March 2006. 13:978-90-9020513-7, March 2006.
[HMP] Lee, S., Cho, J. and A. Campbell, "Hotspot Mitigation [HMP] Lee, S., Cho, J., and A. Campbell, "Hotspot Mitigation
Protocol (HMP)", draft-lee-hmp-00.txt, Internet draft Protocol (HMP)", Work in Progress, October 2003.
(work in progress), October 2003.
[Holland] Holland, G. and N. Vaidya, "Analysis of TCP Performance [Holland] Holland, G. and N. Vaidya, "Analysis of TCP
over Mobile Ad Hoc Networks", Proceedings of the Fifth Performance over Mobile Ad Hoc Networks", Proceedings
International Conference on Mobile Computing and of the Fifth International Conference on Mobile
Networking, pages 219-230. ACM/IEEE, Seattle, August Computing and Networking, pages 219-230. ACM/IEEE,
1999. Seattle, August 1999.
[Iannaccone] Iannaccone, G., Chuah, C., Mortier, R., Bhattacharyya, S. [Iannaccone] Iannaccone, G., Chuah, C., Mortier, R., Bhattacharyya,
and C. Diot, "Analysis of link failures in an IP S., and C. Diot, "Analysis of link failures in an IP
backbone", Proc. of ACM Sigcomm Internet Measurement backbone", Proc. of ACM Sigcomm Internet Measurement
Workshop, November, 2002. Workshop, November, 2002.
[IEEE-802.1X] Institute of Electrical and Electronics Engineers, "Local [IEEE-802.1X] Institute of Electrical and Electronics Engineers,
and Metropolitan Area Networks: Port-Based Network Access "Local and Metropolitan Area Networks: Port-Based
Control", IEEE Standard 802.1X, December 2004. Network Access Control", IEEE Standard 802.1X,
December 2004.
[IEEE-802.11] Institute of Electrical and Electronics Engineers, [IEEE-802.11] Institute of Electrical and Electronics Engineers,
"Wireless LAN Medium Access Control (MAC) and Physical "Wireless LAN Medium Access Control (MAC) and Physical
Layer (PHY) Specifications", IEEE Standard 802.11, 2003. Layer (PHY) Specifications", IEEE Standard 802.11,
2003.
[IEEE-802.11e] Institute of Electrical and Electronics Engineers, [IEEE-802.11e] Institute of Electrical and Electronics Engineers,
"Standard for Telecommunications and Information Exchange "Standard for Telecommunications and Information
Between Systems - LAN/MAN Specific Requirements - Part Exchange Between Systems - LAN/MAN Specific
11: Wireless LAN Medium Access Control (MAC) and Physical Requirements - Part 11: Wireless LAN Medium Access
Layer (PHY) Specifications - Amendment 8: Medium Access Control (MAC) and Physical Layer (PHY) Specifications
Control (MAC) Quality of Service Enhancements", IEEE - Amendment 8: Medium Access Control (MAC) Quality of
802.11e, November 2005. Service Enhancements", IEEE 802.11e, November 2005.
[IEEE-802.11F] Institute of Electrical and Electronics Engineers, "IEEE [IEEE-802.11F] Institute of Electrical and Electronics Engineers,
Trial-Use Recommended Practice for Multi-Vendor Access "IEEE Trial-Use Recommended Practice for Multi-Vendor
Point Interoperability via an Inter-Access Point Protocol Access Point Interoperability via an Inter-Access
Across Distribution Systems Supporting IEEE 802.11 Point Protocol Across Distribution Systems Supporting
Operation", IEEE 802.11F, June 2003 (now deprecated). IEEE 802.11 Operation", IEEE 802.11F, June 2003 (now
deprecated).
[IEEE-802.11i] Institute of Electrical and Electronics Engineers, [IEEE-802.11i] Institute of Electrical and Electronics Engineers,
"Supplement to Standard for Telecommunications and "Supplement to Standard for Telecommunications and
Information Exchange Between Systems - LAN/MAN Specific Information Exchange Between Systems - LAN/MAN
Requirements - Part 11: Wireless LAN Medium Access Specific Requirements - Part 11: Wireless LAN Medium
Control (MAC) and Physical Layer (PHY) Specifications: Access Control (MAC) and Physical Layer (PHY)
Specification for Enhanced Security", IEEE 802.11i, July Specifications: Specification for Enhanced Security",
2004. IEEE 802.11i, July 2004.
[IEEE-802.11k] Institute of Electrical and Electronics Engineers, "Draft [IEEE-802.11k] Institute of Electrical and Electronics Engineers,
Amendment to Telecommunications and Information Exchange "Draft Amendment to Telecommunications and Information
Between Systems - LAN/MAN Specific Requirements - Part Exchange Between Systems - LAN/MAN Specific
11: Wireless LAN Medium Access Control (MAC) and Physical Requirements - Part 11: Wireless LAN Medium Access
Layer (PHY) Specifications - Amendment 7: Radio Resource Control (MAC) and Physical Layer (PHY) Specifications
Management", IEEE 802.11k/D7.0, January 2007. - Amendment 7: Radio Resource Management", IEEE
802.11k/D7.0, January 2007.
[IEEE-802.21] Institute of Electrical and Electronics Engineers, "Draft [IEEE-802.21] Institute of Electrical and Electronics Engineers,
Standard for Telecommunications and Information Exchange "Draft Standard for Telecommunications and Information
Between Systems - LAN/MAN Specific Requirements - Part Exchange Between Systems - LAN/MAN Specific
21: Media Independent Handover", IEEE 802.21D0, June Requirements - Part 21: Media Independent Handover",
2005. IEEE 802.21D0, June 2005.
[Kamerman] Kamerman, A. and L. Monteban, "WaveLAN II: A High- [Kamerman] Kamerman, A. and L. Monteban, "WaveLAN II: A High-
Performance Wireless LAN for the Unlicensed Band", Bell Performance Wireless LAN for the Unlicensed Band",
Labs Technical Journal, Summer 1997. Bell Labs Technical Journal, Summer 1997.
[Kim] Kim, K., Park, Y., Suh, K., and Y. Park, "The BU-trigger [Kim] Kim, K., Park, Y., Suh, K., and Y. Park, "The BU-
method for improving TCP performance over Mobile IPv6", trigger method for improving TCP performance over
draft-kim-tsvwg-butrigger-00.txt, Internet draft (work in Mobile IPv6", Work in Progress, August 2004.
progress), August 2004.
[Kotz] Kotz, D., Newport, C. and C. Elliot, "The mistaken axioms [Kotz] Kotz, D., Newport, C., and C. Elliot, "The mistaken
of wireless-network research", Dartmouth College Computer axioms of wireless-network research", Dartmouth
Science Technical Report TR2003-467, July 2003. College Computer Science Technical Report TR2003-467,
July 2003.
[Krishnan] Krishnan, R., Sterbenz, J., Eddy, W., Partridge, C. and [Krishnan] Krishnan, R., Sterbenz, J., Eddy, W., Partridge, C.,
M. Allman, "Explicit Transport Error Notification (ETEN) and M. Allman, "Explicit Transport Error Notification
for Error-Prone Wireless and Satellite Networks", (ETEN) for Error-Prone Wireless and Satellite
Computer Networks, 46 (3), October 2004. Networks", Computer Networks, 46 (3), October 2004.
[Lacage] Lacage, M., Manshaei, M. and T. Turletti, "IEEE 802.11 [Lacage] Lacage, M., Manshaei, M., and T. Turletti, "IEEE
Rate Adaptation: A Practical Approach", MSWiM '04, 802.11 Rate Adaptation: A Practical Approach", MSWiM
October 4-6, 2004, Venezia, Italy. '04, October 4-6, 2004, Venezia, Italy.
[Lee] Park, S., Lee, M. and J. Korhonen, "Link Characteristics [Lee] Park, S., Lee, M., and J. Korhonen, "Link
Information for Mobile IP", draft-daniel-mip-link- Characteristics Information for Mobile IP", Work in
characteristic-03.txt, Internet draft (work in progress), Progress, January 2007.
January 2007.
[Ludwig] Ludwig, R. and B. Rathonyi, "Link-layer Enhancements for [Ludwig] Ludwig, R. and B. Rathonyi, "Link-layer Enhancements
TCP/IP over GSM", Proceedings of IEEE Infocom '99, March for TCP/IP over GSM", Proceedings of IEEE Infocom '99,
1999. March 1999.
[MIPEAP] Giaretta, C., Guardini, I., Demaria, E., Bournelle, J. [MIPEAP] Giaretta, C., Guardini, I., Demaria, E., Bournelle,
and M. Laurent-Maknavicius, "MIPv6 Authorization and J., and M. Laurent-Maknavicius, "MIPv6 Authorization
Configuration based on EAP", draft-giaretta- and Configuration based on EAP", Work in Progress,
mip6-authorization-eap-04.txt, Internet draft (work in October 2006.
progress), October 2006.
[Mishra] Mitra, A., Shin, M., and W. Arbaugh, "An Empirical [Mishra] Mitra, A., Shin, M., and W. Arbaugh, "An Empirical
Analysis of the IEEE 802.11 MAC Layer Handoff Process", Analysis of the IEEE 802.11 MAC Layer Handoff
CS-TR-4395, University of Maryland Department of Computer Process", CS-TR-4395, University of Maryland
Science, September 2002. Department of Computer Science, September 2002.
[Morgan] Morgan, S. and S. Keshav, "Packet-Pair Rate Control - [Morgan] Morgan, S. and S. Keshav, "Packet-Pair Rate Control -
Buffer Requirements and Overload Performance", Technical Buffer Requirements and Overload Performance",
Memorandum, AT&T Bell Laboratories, October 1994. Technical Memorandum, AT&T Bell Laboratories, October
1994.
[Mun] Mun, Y. and J. Park, "Layer 2 Handoff for Mobile-IPv4 [Mun] Mun, Y. and J. Park, "Layer 2 Handoff for Mobile-IPv4
with 802.11", draft-mun-mobileip-layer2-handoff- with 802.11", Work in Progress, March 2004.
mipv4-01.txt, Internet draft (work in progress), March
2004.
[ONOE] Onoe Rate Control, [ONOE] Onoe Rate Control,
http://madwifi.org/browser/trunk/ath_rate/onoe <http://madwifi.org/browser/trunk/ath_rate/onoe>.
[Park] Park, S., Njedjou, E. and N. Montavont, "L2 Triggers [Park] Park, S., Njedjou, E., and N. Montavont, "L2 Triggers
Optimized Mobile IPv6 Vertical Handover: The 802.11/GPRS Optimized Mobile IPv6 Vertical Handover: The
Example", draft-daniel-mip6-optimized-vertical- 802.11/GPRS Example", Work in Progress, July 2004.
handover-00.txt, July 2004.
[Pavon] Pavon, J. and S. Choi, "Link adaptation strategy for [Pavon] Pavon, J. and S. Choi, "Link adaptation strategy for
IEEE802.11 WLAN via received signal strength IEEE802.11 WLAN via received signal strength
measurement", IEEE International Conference on measurement", IEEE International Conference on
Communications, 2003 (ICC '03), volume 2, pages Communications, 2003 (ICC '03), volume 2, pages 1108-
1108-1113, Anchorage, Alaska, USA, May 2003. 1113, Anchorage, Alaska, USA, May 2003.
[PEAP] Palekar, A., Simon, D., Salowey, J., Zhou, H., Zorn, G. [PEAP] Palekar, A., Simon, D., Salowey, J., Zhou, H., Zorn,
and S. Josefsson, "Protected EAP Protocol (PEAP) Version G., and S. Josefsson, "Protected EAP Protocol (PEAP)
2", draft-josefsson-pppext-eap-tls-eap-10.txt, Internet Version 2", Work in Progress, October 2004.
draft (work in progress), October 2004.
[PRNET] Jubin, J. and J. Tornow, "The DARPA packet radio network [PRNET] Jubin, J. and J. Tornow, "The DARPA packet radio
protocols", Proceedings of the IEEE, 75(1), January 1987. network protocols", Proceedings of the IEEE, 75(1),
January 1987.
[Qiao] Qiao D., Choi, S., Jain, A. and Kang G. Shin, "MiSer: An [Qiao] Qiao D., Choi, S., Jain, A., and Kang G. Shin, "MiSer:
Optimal Low-Energy Transmission Strategy for IEEE 802.11 An Optimal Low-Energy Transmission Strategy for IEEE
a/h", in Proc. ACM MobiCom'03, San Diego, CA, September 802.11 a/h", in Proc. ACM MobiCom'03, San Diego, CA,
2003. September 2003.
[RBAR] Holland, G., Vaidya, N. and P. Bahl, "A Rate-Adaptive MAC [RBAR] Holland, G., Vaidya, N., and P. Bahl, "A Rate-Adaptive
Protocol for Multi-Hop Wireless Networks", Proceedings MAC Protocol for Multi-Hop Wireless Networks",
ACM MOBICOM, July 2001. Proceedings ACM MOBICOM, July 2001.
[Ramani] Ramani, I. and S. Savage, "SyncScan: Practical Fast [Ramani] Ramani, I. and S. Savage, "SyncScan: Practical Fast
Handoff for 802.11 Infrastructure Networks", Proceedings Handoff for 802.11 Infrastructure Networks",
of the IEEE InfoCon 2005, March 2005. Proceedings of the IEEE InfoCon 2005, March 2005.
[Robust] Wong, S., Yang, H ., Lu, S. and V. Bharghavan, "Robust [Robust] Wong, S., Yang, H ., Lu, S., and V. Bharghavan,
Rate Adaptation for 802.11 Wireless Networks", ACM "Robust Rate Adaptation for 802.11 Wireless Networks",
MobiCom'06, Los Angeles, CA, September 2006. ACM MobiCom'06, Los Angeles, CA, September 2006.
[SampleRate] Bicket, J., "Bit-rate Selection in Wireless networks", [SampleRate] Bicket, J., "Bit-rate Selection in Wireless networks",
MIT Master's Thesis, 2005. MIT Master's Thesis, 2005.
[Scott] Scott, J., Mapp, G., "Link Layer Based TCP Optimisation [Scott] Scott, J., Mapp, G., "Link Layer Based TCP
for Disconnecting Networks", ACM SIGCOMM Computer Optimisation for Disconnecting Networks", ACM SIGCOMM
Communication Review, 33(5), October 2003. Computer Communication Review, 33(5), October 2003.
[Schuetz] Schutz, S., Eggert, L., Schmid, S. and M. Brunner, [Schuetz] Schutz, S., Eggert, L., Schmid, S., and M. Brunner,
"Protocol Enhancements for Intermittently Connected "Protocol Enhancements for Intermittently Connected
Hosts", ACM SIGCOMM Computer Communications Review, Hosts", ACM SIGCOMM Computer Communications Review,
Volume 35, Number 2, July 2005. Volume 35, Number 2, July 2005.
[Shortest] Douglas S. J. De Couto, Daniel Aguayo, Benjamin A. [Shortest] Douglas S. J. De Couto, Daniel Aguayo, Benjamin A.
Chambers and Robert Morris, "Performance of Multihop Chambers and Robert Morris, "Performance of Multihop
Wireless Networks: Shortest Path is Not Enough", Wireless Networks: Shortest Path is Not Enough",
Proceedings of the First Workshop on Hot Topics in Proceedings of the First Workshop on Hot Topics in
Networking (HotNets-I), Princeton, New Jersey, October Networking (HotNets-I), Princeton, New Jersey, October
2002. 2002.
[TRIGTRAN] Dawkins, S., Williams, C. and A. Yegin, "Framework and [TRIGTRAN] Dawkins, S., Williams, C., and A. Yegin, "Framework
Requirements for TRIGTRAN", draft-dawkins-trigtran- and Requirements for TRIGTRAN", Work in Progress,
framework-00.txt, Internet draft (work in progress),
August 2003. August 2003.
[Vatn] Vatn, J., "An experimental study of IEEE 802.11b handover [Vatn] Vatn, J., "An experimental study of IEEE 802.11b
performance and its effect on voice traffic", TRITA-IMIT- handover performance and its effect on voice traffic",
TSLAB R 03:01, KTH Royal Institute of Technology, TRITA-IMIT-TSLAB R 03:01, KTH Royal Institute of
Stockholm, Sweden, July 2003. Technology, Stockholm, Sweden, July 2003.
[Velayos] Velayos, H. and G. Karlsson, "Techniques to Reduce IEEE [Velayos] Velayos, H. and G. Karlsson, "Techniques to Reduce
802.11b MAC Layer Handover Time", TRITA-IMIT-LCN R 03:02, IEEE 802.11b MAC Layer Handover Time", TRITA-IMIT-LCN
KTH Royal Institute of Technology, Stockholm, Sweden, R 03:02, KTH Royal Institute of Technology, Stockholm,
April 2003. Sweden, April 2003.
[Vertical] Zhang, Q., Guo, C., Guo, Z. and W. Zhu, "Efficient [Vertical] Zhang, Q., Guo, C., Guo, Z., and W. Zhu, "Efficient
Mobility Management for Vertical Handoff between WWAN and Mobility Management for Vertical Handoff between WWAN
WLAN", IEEE Communications Magazine, November 2003. and WLAN", IEEE Communications Magazine, November
2003.
[Villamizar] Villamizar, C., "OSPF Optimized Multipath (OSPF-OMP)", [Villamizar] Villamizar, C., "OSPF Optimized Multipath (OSPF-OMP)",
draft-ietf-ospf-omp-02.txt, Internet draft (work in Work in Progress, February 1999.
progress), February 1999.
[Xylomenos] Xylomenos, G., "Multi Service Link Layers: An Approach to [Xylomenos] Xylomenos, G., "Multi Service Link Layers: An Approach
Enhancing Internet Performance over Wireless Links", to Enhancing Internet Performance over Wireless
Ph.D. thesis, University of California at San Diego, Links", Ph.D. thesis, University of California at San
1999. Diego, 1999.
[Yegin] Yegin, A., "Link-layer Triggers Protocol", draft-yegin- [Yegin] Yegin, A., "Link-layer Triggers Protocol", Work in
l2-triggers-00.txt, Internet Draft (work in progress), Progress, June 2002.
June 2002.
Acknowledgments 6. Acknowledgments
The authors would like to acknowledge James Kempf, Phil Roberts, The authors would like to acknowledge James Kempf, Phil Roberts,
Gorry Fairhurst, John Wroclawski, Aaron Falk, Sally Floyd, Pekka Gorry Fairhurst, John Wroclawski, Aaron Falk, Sally Floyd, Pekka
Savola, Pekka Nikander, Dave Thaler, Yogesh Swami, Wesley Eddy and Savola, Pekka Nikander, Dave Thaler, Yogesh Swami, Wesley Eddy, and
Janne Peisa for contributions to this document. Janne Peisa for contributions to this document.
Appendix A - Literature Review Appendix A. Literature Review
This Appendix summarizes the literature with respect to link This appendix summarizes the literature with respect to link
indications on wireless local area networks. indications on wireless local area networks.
A.1 Link Layer A.1. Link Layer
The characteristics of wireless links have been found to vary The characteristics of wireless links have been found to vary
considerably depending on the environment. considerably depending on the environment.
In "Performance of Multihop Wireless Networks: Shortest Path is Not In "Performance of Multihop Wireless Networks: Shortest Path is Not
Enough" [Shortest] the authors studied the performance of both an Enough" [Shortest], the authors studied the performance of both an
indoor and outdoor mesh network. By measuring inter-node throughput, indoor and outdoor mesh network. By measuring inter-node throughput,
the best path between nodes was computed. The throughput of the best the best path between nodes was computed. The throughput of the best
path was compared with the throughput of the shortest path computed path was compared with the throughput of the shortest path computed
based on a hop-count metric. In almost all cases, the shortest path based on a hop-count metric. In almost all cases, the shortest path
route offered considerably lower throughput than the best path. route offered considerably lower throughput than the best path.
In examining link behavior, the authors found that rather than In examining link behavior, the authors found that rather than
exhibiting a bi-modal distribution between "up" (low loss rate) and exhibiting a bi-modal distribution between "up" (low loss rate) and
"down" (high loss rates), many links exhibited intermediate loss "down" (high loss rate), many links exhibited intermediate loss
rates. Asymmetry was also common, with 30 percent of links rates. Asymmetry was also common, with 30 percent of links
demonstrating substantial differences in the loss rates in each demonstrating substantial differences in the loss rates in each
direction. As a result, on wireless networks the measured throughput direction. As a result, on wireless networks the measured throughput
can differ substantially from the negotiated rate due to can differ substantially from the negotiated rate due to
retransmissions, and successful delivery of routing packets is not retransmissions, and successful delivery of routing packets is not
necessarily an indication that the link is useful for delivery of necessarily an indication that the link is useful for delivery of
data. data.
In "Measurement and Analysis of the Error Characteristics of an In- In "Measurement and Analysis of the Error Characteristics of an
Building Wireless Network" [Eckhardt], the authors characterize the In-Building Wireless Network" [Eckhardt], the authors characterize
performance of an AT&T Wavelan 2 Mbps in-building WLAN operating in the performance of an AT&T Wavelan 2 Mbps in-building WLAN operating
Infrastructure mode on the Carnegie-Mellon Campus. In this study, in Infrastructure mode on the Carnegie Mellon campus. In this study,
very low frame loss was experienced. As a result, links could either very low frame loss was experienced. As a result, links could be
be assumed to operate very well or not at all. assumed to operate either very well or not at all.
In "Link-level Measurements from an 802.11b Mesh Network" [Aguayo], In "Link-level Measurements from an 802.11b Mesh Network" [Aguayo],
the authors analyze the causes of frame loss in a 38-node urban the authors analyze the causes of frame loss in a 38-node urban
multi-hop 802.11 ad-hoc network. In most cases, links that are very multi-hop 802.11 ad-hoc network. In most cases, links that are very
bad in one direction tend to be bad in both directions, and links bad in one direction tend to be bad in both directions, and links
that are very good in one direction tend to be good in both that are very good in one direction tend to be good in both
directions. However, 30 percent of links exhibited loss rates directions. However, 30 percent of links exhibited loss rates
differing substantially in each direction. differing substantially in each direction.
Signal to noise ratio and distance showed little value in predicting Signal to noise ratio (SNR) and distance showed little value in
loss rates, and rather than exhibiting a step-function transition predicting loss rates, and rather than exhibiting a step-function
between "up" (low loss) or "down" (high loss) states, inter-node transition between "up" (low loss) or "down" (high loss) states,
loss rates varied widely, demonstrating a nearly uniform distribution inter-node loss rates varied widely, demonstrating a nearly uniform
over the range at the lower rates. The authors attribute the distribution over the range at the lower rates. The authors
observed effects to multi-path fading, rather than attenuation or attribute the observed effects to multi-path fading, rather than
interference. attenuation or interference.
The findings of [Eckhardt] and [Aguayo] demonstrate the diversity of The findings of [Eckhardt] and [Aguayo] demonstrate the diversity of
link conditions observed in practice. While for indoor link conditions observed in practice. While for indoor
infrastructure networks site surveys and careful measurement can infrastructure networks site surveys and careful measurement can
assist in promoting ideal behavior, in ad-hoc/mesh networks node assist in promoting ideal behavior, in ad-hoc/mesh networks node
mobility and external factors such as weather may not be easily mobility and external factors such as weather may not be easily
controlled. controlled.
Considerable diversity in behavior is also observed due to Considerable diversity in behavior is also observed due to
implementation effects. "Techniques to reduce IEEE 802.11b MAC layer implementation effects. "Techniques to reduce IEEE 802.11b MAC layer
handover time" [Velayos] measured handover times for a stationary STA handover time" [Velayos] measured handover times for a stationary STA
after the AP was turned off. This study divided handover times into after the AP was turned off. This study divided handover times into
detection (determination of disconnection from the existing point of detection (determination of disconnection from the existing point of
attachment), search (discovery of alternative attachment points), and attachment), search (discovery of alternative attachment points), and
execution phases (connection to an alternative point of attachment). execution (connection to an alternative point of attachment) phases.
These measurements indicated that the duration of the detection phase These measurements indicated that the duration of the detection phase
(the largest component of handoff delay) is determined by the number (the largest component of handoff delay) is determined by the number
of non-acknowledged frames triggering the search phase and delays due of non-acknowledged frames triggering the search phase and delays due
to precursors such as RTS/CTS and rate adaptation. to precursors such as RTS/CTS and rate adaptation.
Detection behavior varied widely between implementations. For Detection behavior varied widely between implementations. For
example, NICs designed for desktops attempted more retransmissions example, network interface cards (NICs) designed for desktops
prior to triggering search as compared with laptop designs, since attempted more retransmissions prior to triggering search as compared
they assumed that the AP was always in range, regardless of whether with laptop designs, since they assumed that the AP was always in
the Beacon was received. range, regardless of whether the Beacon was received.
The study recommends that the duration of the detection phase be The study recommends that the duration of the detection phase be
reduced by initiating the search phase as soon as collisions can be reduced by initiating the search phase as soon as collisions can be
excluded as the cause of non-acknowledged transmissions; the authors excluded as the cause of non-acknowledged transmissions; the authors
recommend three consecutive transmission failures as the cutoff. recommend three consecutive transmission failures as the cutoff.
This approach is both quicker and more immune to multi-path This approach is both quicker and more immune to multi-path
interference than monitoring of the S/N ratio. Where the STA is not interference than monitoring of the SNR. Where the STA is not
sending or receiving frames, it is recommended that Beacon reception sending or receiving frames, it is recommended that Beacon reception
be tracked in order to detect disconnection, and that Beacon spacing be tracked in order to detect disconnection, and that Beacon spacing
be reduced to 60 ms in order to reduce detection times. In order to be reduced to 60 ms in order to reduce detection times. In order to
compensate for more frequent triggering of the search phase, the compensate for more frequent triggering of the search phase, the
authors recommend algorithms for wait time reduction, as well as authors recommend algorithms for wait time reduction, as well as
interleaving of search and data frame transmission. interleaving of search and data frame transmission.
"An Empirical Analysis of the IEEE 802.11 MAC Layer Handoff Process" "An Empirical Analysis of the IEEE 802.11 MAC Layer Handoff Process"
[Mishra] investigates handoff latencies obtained with three mobile [Mishra] investigates handoff latencies obtained with three mobile
STA implementations communicating with two APs. The study found that STA implementations communicating with two APs. The study found that
there is large variation in handoff latency among STA and AP there is a large variation in handoff latency among STA and AP
implementations and that implementations utilize different message implementations and that implementations utilize different message
sequences. For example, one STA sends a Reassociation Request prior sequences. For example, one STA sends a Reassociation Request prior
to authentication, which results in receipt of a Deauthenticate to authentication, which results in receipt of a Deauthenticate
message. The study divided handoff latency into discovery, message. The study divided handoff latency into discovery,
authentication and reassociation exchanges, concluding that the authentication, and reassociation exchanges, concluding that the
discovery phase was the dominant component of handoff delay. Latency discovery phase was the dominant component of handoff delay. Latency
in the detection phase was not investigated. in the detection phase was not investigated.
"SyncScan: Practical Fast Handoff for 802.11 Infrastructure Networks" "SyncScan: Practical Fast Handoff for 802.11 Infrastructure Networks"
[Ramani] weighs the pros and cons of active versus passive scanning. [Ramani] weighs the pros and cons of active versus passive scanning.
The authors point out the advantages of timed beacon reception, which The authors point out the advantages of timed Beacon reception, which
had previously been incorporated into [IEEE-802.11k]. Timed beacon had previously been incorporated into [IEEE-802.11k]. Timed Beacon
reception allows the station to continually keep up to date on the reception allows the station to continually keep up to date on the
signal/noise ratio of neighboring APs, allowing handoff to occur signal to noise ratio of neighboring APs, allowing handoff to occur
earlier. Since the station does not need to wait for initial and earlier. Since the station does not need to wait for initial and
subsequent responses to a broadcast Probe Response (MinChannelTime subsequent responses to a broadcast Probe Response (MinChannelTime
and MaxChannelTime, respectively), performance is comparable to what and MaxChannelTime, respectively), performance is comparable to what
is achievable with 802.11k Neighbor Reports and unicast Probe is achievable with 802.11k Neighbor Reports and unicast Probe
Requests. Requests.
The authors measure the channel switching delay, the time it takes to The authors measured the channel switching delay, the time it takes
switch to a new frequency, and begin receiving frames. Measurements to switch to a new frequency and begin receiving frames.
ranged from 5 ms to 19 ms per channel; where timed Beacon reception Measurements ranged from 5 ms to 19 ms per channel; where timed
or interleaved active scanning is used, switching time contributes Beacon reception or interleaved active scanning is used, switching
significantly to overall handoff latency. The authors propose time contributes significantly to overall handoff latency. The
deployment of APs with Beacons synchronized via Network Time Protocol authors propose deployment of APs with Beacons synchronized via
(NTP) [RFC1305], enabling a driver implementing SyncScan to work with Network Time Protocol (NTP) [RFC1305], enabling a driver implementing
legacy APs without requiring implementation of new protocols. The SyncScan to work with legacy APs without requiring implementation of
authors measure the distribution of inter-arrival times for stations new protocols. The authors measured the distribution of inter-
implementing SyncScan, with excellent results. arrival times for stations implementing SyncScan, with excellent
results.
"Roaming Interval Measurements" [Alimian] presents data on the "Roaming Interval Measurements" [Alimian] presents data on the
behavior of stationary STAs after the AP signal has been shut off. behavior of stationary STAs after the AP signal has been shut off.
This study highlighted implementation differences in rate adaptation This study highlighted implementation differences in rate adaptation
as well as detection, scanning and handoff. As in [Velayos], as well as detection, scanning, and handoff. As in [Velayos],
performance varied widely between implementations, from half an order performance varied widely between implementations, from half an order
of magnitude variation in rate adaptation to an order of magnitude of magnitude variation in rate adaptation to an order of magnitude
difference in detection times, two orders of magnitude in scanning, difference in detection times, two orders of magnitude in scanning,
and one and a half orders of magnitude in handoff times. and one and a half orders of magnitude in handoff times.
"An experimental study of IEEE 802.11b handoff performance and its "An experimental study of IEEE 802.11b handoff performance and its
effect on voice traffic" [Vatn] describes handover behavior observed effect on voice traffic" [Vatn] describes handover behavior observed
when the signal from the AP is gradually attenuated, which is more when the signal from the AP is gradually attenuated, which is more
representative of field experience than the shutoff techniques used representative of field experience than the shutoff techniques used
in [Velayos]. Stations were configured to initiate handover when in [Velayos]. Stations were configured to initiate handover when
signal strength dipped below a threshold, rather than purely based on signal strength dipped below a threshold, rather than purely based on
frame loss, so that they could begin handover while still connected frame loss, so that they could begin handover while still connected
to the current AP. It was noted that stations continue to receive to the current AP. It was noted that stations continued to receive
data frames during the search phase. Station-initiated data frames during the search phase. Station-initiated
Disassociation and pre-authentication were not observed in this Disassociation and pre-authentication were not observed in this
study. study.
A.1.1 Link Indications A.1.1. Link Indications
Within a link layer, the definition of "Link Up" and "Link Down" may Within a link layer, the definition of "Link Up" and "Link Down" may
vary according to the deployment scenario. For example, within PPP vary according to the deployment scenario. For example, within PPP
[RFC1661], either peer may send an LCP-Terminate frame in order to [RFC1661], either peer may send an LCP-Terminate frame in order to
terminate the PPP link layer, and a link may only be assumed to be terminate the PPP link layer, and a link may only be assumed to be
usable for sending network protocol packets once NCP negotiation has usable for sending network protocol packets once Network Control
completed for that protocol. Protocol (NCP) negotiation has completed for that protocol.
Unlike PPP, IEEE 802 does not include facilities for network layer Unlike PPP, IEEE 802 does not include facilities for network layer
configuration, and the definition of "Link Up" and "Link Down" varies configuration, and the definition of "Link Up" and "Link Down" varies
by implementation. Empirical evidence suggests that the definition by implementation. Empirical evidence suggests that the definition
of "Link Up" and "Link Down" may depend on whether the station is of "Link Up" and "Link Down" may depend on whether the station is
mobile or stationary, whether infrastructure or ad-hoc mode is in mobile or stationary, whether infrastructure or ad-hoc mode is in
use, and whether security and Inter-Access Point Protocol (IAPP) is use, and whether security and Inter-Access Point Protocol (IAPP) is
implemented. implemented.
Where a STA encounters a series of consecutive non-acknowledged Where a STA encounters a series of consecutive non-acknowledged
frames while having missed one or more beacons, the most likely cause frames while having missed one or more Beacons, the most likely cause
is that the station has moved out of range of the AP. As a result, is that the station has moved out of range of the AP. As a result,
[Velayos] recommends that the station begin the search phase after [Velayos] recommends that the station begin the search phase after
collisions can be ruled out; since this approach does not take rate collisions can be ruled out; since this approach does not take rate
adaptation into account, it may be somewhat aggressive. Only when no adaptation into account, it may be somewhat aggressive. Only when no
alternative workable rate or point of attachment is found is a "Link alternative workable rate or point of attachment is found is a "Link
Down" indication returned. Down" indication returned.
In a stationary point-to-point installation, the most likely cause of In a stationary point-to-point installation, the most likely cause of
an outage is that the link has become impaired, and alternative an outage is that the link has become impaired, and alternative
points of attachment may not be available. As a result, points of attachment may not be available. As a result,
implementations configured to operate in this mode tend to be more implementations configured to operate in this mode tend to be more
persistent. For example, within 802.11 the short interframe space persistent. For example, within 802.11 the short interframe space
(SIFS) interval may be increased and MIB variables relating to (SIFS) interval may be increased and MIB variables relating to
timeouts (such as dot11AuthenticationResponseTimeout, timeouts (such as dot11AuthenticationResponseTimeout,
dot11AssociationResponseTimeout, dot11ShortRetryLimit, and dot11AssociationResponseTimeout, dot11ShortRetryLimit, and
dot11LongRetryLimit) may be set to larger values. In addition a dot11LongRetryLimit) may be set to larger values. In addition, a
"Link Down" indication may be returned later. "Link Down" indication may be returned later.
In IEEE 802.11 ad-hoc mode with no security, reception of data frames In IEEE 802.11 ad-hoc mode with no security, reception of data frames
is enabled in State 1 ("Unauthenticated" and "Unassociated"). As a is enabled in State 1 ("Unauthenticated" and "Unassociated"). As a
result, reception of data frames is enabled at any time, and no result, reception of data frames is enabled at any time, and no
explicit "Link Up" indication exists. explicit "Link Up" indication exists.
In Infrastructure mode, IEEE 802.11-2003 enables reception of data In Infrastructure mode, IEEE 802.11-2003 enables reception of data
frames only in State 3 ("Authenticated" and "Associated"). As a frames only in State 3 ("Authenticated" and "Associated"). As a
result, a transition to State 3 (e.g. completion of a successful result, a transition to State 3 (e.g., completion of a successful
Association or Reassociation exchange) enables sending and receiving Association or Reassociation exchange) enables sending and receiving
of network protocol packets and a transition from State 3 to State 2 of network protocol packets and a transition from State 3 to State 2
(reception of a "Disassociate" frame) or State 1 (reception of a (reception of a "Disassociate" frame) or State 1 (reception of a
"Deauthenticate" frame) disables sending and receiving of network "Deauthenticate" frame) disables sending and receiving of network
protocol packets. As a result, IEEE 802.11 stations typically signal protocol packets. As a result, IEEE 802.11 stations typically signal
"Link Up" on receipt of a successful Association/Reassociation "Link Up" on receipt of a successful Association/Reassociation
Response. Response.
As described within [IEEE-802.11F], after sending a Reassociation As described within [IEEE-802.11F], after sending a Reassociation
Response, an Access Point will send a frame with the station's source Response, an Access Point will send a frame with the station's source
address to a multicast destination. This causes switches within the address to a multicast destination. This causes switches within the
Distribution System (DS) to update their learning tables, readying Distribution System (DS) to update their learning tables, readying
the DS to forward frames to the station at its new point of the DS to forward frames to the station at its new point of
attachment. Were the AP to not send this "spoofed" frame, the attachment. Were the AP to not send this "spoofed" frame, the
station's location would not be updated within the distribution station's location would not be updated within the distribution
system until it sends its first frame at the new location. Thus the system until it sends its first frame at the new location. Thus, the
purpose of spoofing is to equalize uplink and downlink handover purpose of spoofing is to equalize uplink and downlink handover
times. This enables an attacker to deny service to authenticated and times. This enables an attacker to deny service to authenticated and
associated stations by spoofing a Reassociation Request using the associated stations by spoofing a Reassociation Request using the
victim's MAC address, from anywhere within the ESS. Without victim's MAC address, from anywhere within the ESS. Without
spoofing, such an attack would only be able to disassociate stations spoofing, such an attack would only be able to disassociate stations
on the AP to which the Reassociation Request was sent. on the AP to which the Reassociation Request was sent.
The signaling of "Link Down" is considerably more complex. Even The signaling of "Link Down" is considerably more complex. Even
though a transition to State 2 or State 1 results in the station though a transition to State 2 or State 1 results in the station
being unable to send or receive IP packets, this does not necessarily being unable to send or receive IP packets, this does not necessarily
imply that such a transition should be considered a "Link Down" imply that such a transition should be considered a "Link Down"
indication. In an infrastructure network, a station may have a indication. In an infrastructure network, a station may have a
choice of multiple access points offering connection to the same choice of multiple Access Points offering connection to the same
network. In such an environment, a station that is unable to reach network. In such an environment, a station that is unable to reach
State 3 with one access point may instead choose to attach to another State 3 with one Access Point may instead choose to attach to another
access point. Rather than registering a "Link Down" indication with Access Point. Rather than registering a "Link Down" indication with
each move, the station may instead register a series of "Link Up" each move, the station may instead register a series of "Link Up"
indications. indications.
In [IEEE-802.11i] forwarding of frames from the station to the In [IEEE-802.11i], forwarding of frames from the station to the
distribution system is only feasible after the completion of the distribution system is only feasible after the completion of the
4-way handshake and group-key handshake, so that entering State 3 is 4-way handshake and group-key handshake, so that entering State 3 is
no longer sufficient. This has resulted in several observed no longer sufficient. This has resulted in several observed
problems. For example, where a "Link Up" indication is triggered on problems. For example, where a "Link Up" indication is triggered on
the station by receipt of an Association/Reassociation Response, DHCP the station by receipt of an Association/Reassociation Response, DHCP
[RFC2131] or Router Solicitation/Router Advertisement (RS/RA) may be [RFC2131] or Router Solicitation/Router Advertisement (RS/RA) may be
triggered prior to when the link is usable by the Internet layer, triggered prior to when the link is usable by the Internet layer,
resulting in configuration delays or failures. Similarly, Transport resulting in configuration delays or failures. Similarly, transport
layer connections will encounter packet loss, resulting in back-off layer connections will encounter packet loss, resulting in back-off
of retransmission timers. of retransmission timers.
A.1.2 Smart Link Layer Proposals A.1.2. Smart Link Layer Proposals
In order to improve link layer performance, several studies have In order to improve link layer performance, several studies have
investigated "smart link layer" proposals. investigated "smart link layer" proposals.
"Advice to link designers on link Automatic Repeat reQuest (ARQ)" "Advice to link designers on link Automatic Repeat reQuest (ARQ)"
[RFC3366] provides advice to the designers of digital communication [RFC3366] provides advice to the designers of digital communication
equipment and link-layer protocols employing link-layer Automatic equipment and link-layer protocols employing link-layer Automatic
Repeat reQuest (ARQ) techniques for IP. It discusses the use of ARQ, Repeat reQuest (ARQ) techniques for IP. It discusses the use of ARQ,
timers, persistency in retransmission and the challenges that arise timers, persistency in retransmission, and the challenges that arise
from sharing links between multiple flows and in differentiation from sharing links between multiple flows and from different
transport flow requirements. transport requirements.
In "Link-layer Enhancements for TCP/IP over GSM" [Ludwig], the In "Link-layer Enhancements for TCP/IP over GSM" [Ludwig], the
authors describe how the GSM reliable and unreliable link layer modes authors describe how the Global System for Mobile Communications
can be simultaneously utilized without higher layer control. Where a (GSM)-reliable and unreliable link layer modes can be simultaneously
reliable link layer protocol is required (where reliable transports utilized without higher layer control. Where a reliable link layer
such TCP and Stream Control Transmission Protocol (SCTP) [RFC2960] protocol is required (where reliable transports such TCP and Stream
are used), the Radio Link Protocol (RLP) can be engaged; with delay Control Transmission Protocol (SCTP) [RFC2960] are used), the Radio
sensitive applications such as those based on UDP, the transparent Link Protocol (RLP) can be engaged; with delay-sensitive applications
mode (no RLP) can be used. The authors also describe how PPP such as those based on UDP, the transparent mode (no RLP) can be
negotiation can be optimized over high latency GSM links using used. The authors also describe how PPP negotiation can be optimized
"Quickstart-PPP". over high-latency GSM links using "Quickstart-PPP".
In "Link Layer Based TCP Optimisation for Disconnecting Networks" In "Link Layer Based TCP Optimisation for Disconnecting Networks"
[Scott], the authors describe performance problems that occur with [Scott], the authors describe performance problems that occur with
reliable transport protocols facing periodic network disconnections, reliable transport protocols facing periodic network disconnections,
such as those due to signal fading or handoff. The authors define a such as those due to signal fading or handoff. The authors define a
disconnection as a period of connectivity loss that exceeds a disconnection as a period of connectivity loss that exceeds a
retransmission timeout, but is shorter than the connection lifetime. retransmission timeout, but is shorter than the connection lifetime.
One issue is that link-unaware senders continue to back off during One issue is that link-unaware senders continue to back off during
periods of disconnection. The authors suggest that a link-aware periods of disconnection. The authors suggest that a link-aware
reliable transport implementation halt retransmission after receiving reliable transport implementation halt retransmission after receiving
skipping to change at page 45, line 11 skipping to change at page 47, line 12
retransmitted. In addition to looking at retransmission of a single retransmitted. In addition to looking at retransmission of a single
packet per connection, the authors also examined other schemes such packet per connection, the authors also examined other schemes such
as retransmission of multiple packets and simulated duplicate as retransmission of multiple packets and simulated duplicate
reception of single or multiple packets (known as rereception). reception of single or multiple packets (known as rereception).
In general, retransmission schemes were superior to rereception In general, retransmission schemes were superior to rereception
schemes, since rereception cannot stimulate fast retransmit after a schemes, since rereception cannot stimulate fast retransmit after a
timeout. Retransmission of multiple packets did not appreciably timeout. Retransmission of multiple packets did not appreciably
improve performance over retransmission of a single packet. Since improve performance over retransmission of a single packet. Since
the focus of the research was on disconnection rather than just lossy the focus of the research was on disconnection rather than just lossy
channels, a two state Markov model was used, with the "up" state channels, a two-state Markov model was used, with the "up" state
representing no loss, and the "down" state representing one hundred representing no loss, and the "down" state representing 100 percent
percent loss. loss.
In "Multi Service Link Layers: An Approach to Enhancing Internet In "Multi Service Link Layers: An Approach to Enhancing Internet
Performance over Wireless Links" [Xylomenos], the authors use ns-2 to Performance over Wireless Links" [Xylomenos], the authors use ns-2 to
simulate the performance of various link layer recovery schemes (raw simulate the performance of various link layer recovery schemes (raw
link without retransmission, go back N, XOR based FEC, selective link without retransmission, go back N, XOR-based FEC, selective
repeat, Karn's RLP, out of sequence RLP and Berkeley Snoop) in stand- repeat, Karn's RLP, out-of-sequence RLP, and Berkeley Snoop) in
alone file transfer, web browsing and continuous media distribution. stand-alone file transfer, Web browsing, and continuous media
While selective repeat and Karn's RLP provide the highest throughput distribution. While selective repeat and Karn's RLP provide the
for file transfer and web browsing scenarios, continuous media highest throughput for file transfer and Web browsing scenarios,
distribution requires a combination of low delay and low loss and the continuous media distribution requires a combination of low delay and
out of sequence RLP performed best in this scenario. Since the low loss and the out-of-sequence RLP performed best in this scenario.
results indicate that no single link layer recovery scheme is optimal Since the results indicate that no single link layer recovery scheme
for all applications, the authors propose that the link layer is optimal for all applications, the authors propose that the link
implement multiple recovery schemes. Simulations of the multi- layer implement multiple recovery schemes. Simulations of the
service architecture showed that the combination of a low-error rate multi-service architecture showed that the combination of a low-error
recovery scheme for TCP (such as Karn's RLP) and a low-delay scheme rate recovery scheme for TCP (such as Karn's RLP) and a low-delay
for UDP traffic (such as out of sequence RLP) provides for good scheme for UDP traffic (such as out-of-sequence RLP) provides for
performance in all scenarios. The authors then describe how a multi- good performance in all scenarios. The authors then describe how a
service link layer can be integrated with Differentiated Services. multi-service link layer can be integrated with Differentiated
Services.
In "WaveLAN-II: A High-Performance Wireless LAN for the Unlicensed In "WaveLAN-II: A High-Performance Wireless LAN for the Unlicensed
Band" [Kamerman], the authors propose an open-loop rate adaptation Band" [Kamerman], the authors propose an open-loop rate adaptation
algorithm known as Automatic Rate Fallback (ARF). In ARF, the sender algorithm known as Automatic Rate Fallback (ARF). In ARF, the sender
adjusts the rate upwards after a fixed number of successful adjusts the rate upwards after a fixed number of successful
transmissions, and adjusts the rate downwards after one or two transmissions, and adjusts the rate downwards after one or two
consecutive failures. If after an upwards rate adjustment the consecutive failures. If after an upwards rate adjustment the
transmission fails, the rate is immediately readjusted downwards. transmission fails, the rate is immediately readjusted downwards.
In "A Rate-Adaptive MAC Protocol for Multi-Hop Wireless Networks" In "A Rate-Adaptive MAC Protocol for Multi-Hop Wireless Networks"
[RBAR], the authors propose a closed loop rate adaptation approach [RBAR], the authors propose a closed-loop rate adaptation approach
that requires incompatible changes to the IEEE 802.11 MAC. In order that requires incompatible changes to the IEEE 802.11 MAC. In order
to enable the sender to better determine the transmission rate, the to enable the sender to better determine the transmission rate, the
receiver determines the packet length and Signal/Noise Ratio (SNR) of receiver determines the packet length and signal to noise ratio (SNR)
a received RTS frame and calculates the corresponding rate based on a of a received RTS frame and calculates the corresponding rate based
theoretical channel model, rather than channel usage statistics. The on a theoretical channel model, rather than channel usage statistics.
recommended rate is sent back in the CTS frame. This allows the rate The recommended rate is sent back in the CTS frame. This allows the
(and potentially the transmit power) to be optimized on each rate (and potentially the transmit power) to be optimized on each
transmission, albeit at the cost of requiring RTS/CTS for every frame transmission, albeit at the cost of requiring RTS/CTS for every frame
transmission. transmission.
In "MiSer: An Optimal Low-Energy Transmission Strategy for IEEE In "MiSer: An Optimal Low-Energy Transmission Strategy for IEEE
802.11 a/h" [Qiao] the authors propose a scheme for optimizing 802.11 a/h" [Qiao], the authors propose a scheme for optimizing
transmit power. The proposal mandates the use of RTS/CTS in order to transmit power. The proposal mandates the use of RTS/CTS in order to
deal with hidden nodes, requiring that CTS and ACK frames be sent at deal with hidden nodes, requiring that CTS and ACK frames be sent at
full power. The authors utilize a theoretical channel model rather full power. The authors utilize a theoretical channel model rather
than one based on channel usage statistics. than one based on channel usage statistics.
In "IEEE 802.11 Rate Adaptation: A Practical Approach" [Lacage] the In "IEEE 802.11 Rate Adaptation: A Practical Approach" [Lacage], the
authors distinguish between low latency implementations which enable authors distinguish between low-latency implementations, which enable
per-packet rate decisions, and high latency implementations which do per-packet rate decisions, and high-latency implementations, which do
not. The former implementations typically include dedicated CPUs in not. The former implementations typically include dedicated CPUs in
their design, enabling them to meet real-time requirements. The their design, enabling them to meet real-time requirements. The
latter implementations are typically based on highly integrated latter implementations are typically based on highly integrated
designs in which the upper MAC is implemented on the host. As a designs in which the upper MAC is implemented on the host. As a
result, due to operating system latencies the information required to result, due to operating system latencies the information required to
make per-packet rate decisions may not be available in time. make per-packet rate decisions may not be available in time.
The authors propose an Adaptive ARF (AARF) algorithm for use with The authors propose an Adaptive ARF (AARF) algorithm for use with
low-latency implementations. This enables rapid downward rate low-latency implementations. This enables rapid downward rate
negotiation on failure to receive an ACK, while increasing the amount negotiation on failure to receive an ACK, while increasing the number
number of successful transmission required for upward rate of successful transmissions required for upward rate negotiation.
negotiation. The AARF algorithm is therefore highly stable in The AARF algorithm is therefore highly stable in situations where
situations where channel properties are changing slowly, but slow to channel properties are changing slowly, but slow to adapt upwards
adapt upwards when channel conditions improve. In order to test the when channel conditions improve. In order to test the algorithm, the
algorithm, the authors utilized ns-2 simulations as well as authors utilized ns-2 simulations as well as implementing a version
implementing a version of AARF adapted to a high latency of AARF adapted to a high-latency implementation, the AR 5212
implementation, the AR 5212 chipset. The Multiband Atheros Driver chipset. The Multiband Atheros Driver for WiFi (MadWiFi) driver
for WiFi (MADWIFI) driver enables a fixed schedule of rates and enables a fixed schedule of rates and retries to be provided when a
retries to be provided when a frame is queued for transmission. The frame is queued for transmission. The adapted algorithm, known as
adapted algorithm, known as the Adaptive Multi Rate Retry (AMRR), the Adaptive Multi Rate Retry (AMRR), requests only one transmission
requests only one transmission at each of three rates, the last of at each of three rates, the last of which is the minimum available
which is the minimum available rate. This enables adaptation to rate. This enables adaptation to short-term fluctuations in the
short-term fluctuations in the channel with minimal latency. The channel with minimal latency. The AMRR algorithm provides
AMRR algorithm provides performance considerably better than the performance considerably better than the existing MadWifi driver.
existing Madwifi driver.
In "Link Adaptation Strategy for IEEE 802.11 WLAN via Received Signal In "Link Adaptation Strategy for IEEE 802.11 WLAN via Received Signal
Strength Measurement" [Pavon], the authors propose an algorithm by Strength Measurement" [Pavon], the authors propose an algorithm by
which a STA adjusts the transmission rate based on a comparison of which a STA adjusts the transmission rate based on a comparison of
the received signal strength (RSS) from the AP with dynamically the received signal strength (RSS) from the AP with dynamically
estimated threshold values for each transmission rate. Upon estimated threshold values for each transmission rate. Upon
reception of a frame, the STA updates the average RSS, and on reception of a frame, the STA updates the average RSS, and on
transmission the STA selects a rate and adjusts the RSS threshold transmission the STA selects a rate and adjusts the RSS threshold
values based on whether the transmission is successful or not. In values based on whether or not the transmission is successful. In
order to validate the algorithm, the authors utilized an OPNET order to validate the algorithm, the authors utilized an OPNET
simulation without interference, and an ideal curve of bit error rate simulation without interference, and an ideal curve of bit error rate
(BER) vs. signal/noise ratio (SNR) was assumed. Not surprisingly, (BER) vs. signal to noise ratio (SNR) was assumed. Not surprisingly,
the simulation results closely matched the maximum throughput the simulation results closely matched the maximum throughput
achievable for a given signal/noise ratio, based on the ideal BER vs. achievable for a given signal to noise ratio, based on the ideal BER
SNR curve. vs. SNR curve.
In "Hybrid Rate Control for IEEE 802.11" [Haratcherev], the authors In "Hybrid Rate Control for IEEE 802.11" [Haratcherev], the authors
describe a hybrid technique utilizing Signal Strength Indication describe a hybrid technique utilizing Signal Strength Indication
(SSI) data to constrain the potential rates selected by statistics- (SSI) data to constrain the potential rates selected by statistics-
based automatic rate control. Statistics-based rate control based automatic rate control. Statistics-based rate control
techniques include: techniques include:
Maximum Throughput Maximum Throughput
This technique, which was chosen as the statistics-based technique This technique, which was chosen as the statistics-based technique in
in the hybrid scheme, sends a fraction of data at adjacent rates the hybrid scheme, sends a fraction of data at adjacent rates in
in order to estimate which rate provides the maximum throughput. order to estimate which rate provides the maximum throughput. Since
Since accurate estimation of throughput requires a minimum number accurate estimation of throughput requires a minimum number of frames
of frames to be sent at each rate, and only a fraction of frames to be sent at each rate, and only a fraction of frames are utilized
are utilized for this purpose, this technique adapts more slowly for this purpose, this technique adapts more slowly at lower rates;
at lower rates; with 802.11b rates, the adaptation time scale is with 802.11b rates, the adaptation time scale is typically on the
typically on the order of a second. Depending on how many rates order of a second. Depending on how many rates are tested, this
are tested, this technique can enable adaptation beyond adjacent technique can enable adaptation beyond adjacent rates. However,
rates. However, where maximum rate and low frame loss are already where maximum rate and low frame loss are already being encountered,
being encountered, this technique results in lower throughput. this technique results in lower throughput.
Frame Error Rate (FER) Control Frame Error Rate (FER) Control
This technique estimates the FER, attempting to keep it between a This technique estimates the FER, attempting to keep it between a
lower limit (if FER moves below, increase rate) and upper limit lower limit (if FER moves below, increase rate) and upper limit (if
(if FER moves above, decrease rate). Since this technique can FER moves above, decrease rate). Since this technique can utilize
utilize all the transmitted data, it can respond faster than all the transmitted data, it can respond faster than maximum
maximum throughput techniques. However, there is a tradeoff of throughput techniques. However, there is a tradeoff of reaction time
reaction time versus FER estimation accuracy; at lower rates versus FER estimation accuracy; at lower rates either reaction times
either reaction times slow or FER estimation accuracy will suffer. slow or FER estimation accuracy will suffer. Since this technique
Since this technique only measures the FER at the current rate, it only measures the FER at the current rate, it can only enable
can only enable adaptation to adjacent rates. adaptation to adjacent rates.
Retry-based Retry-based
This technique modifies FER control techniques by enabling rapid This technique modifies FER control techniques by enabling rapid
downward rate adaptation after a number (5-10) of unsuccessful re- downward rate adaptation after a number (5-10) of unsuccessful
transmissions. Since fewer packets are required, the sensitivity retransmissions. Since fewer packets are required, the sensitivity
of reaction time to rate is reduced. However, upward rate of reaction time to rate is reduced. However, upward rate adaptation
adaptation proceeds more slowly since it is based on collection of proceeds more slowly since it is based on a collection of FER data.
FER data. This technique is limited to adaptation to adjacent This technique is limited to adaptation to adjacent rates, and it has
rates, and has the disadvantage of potentially worsening frame the disadvantage of potentially worsening frame loss due to
loss due to contention. contention.
While statistics-based techniques are robust against short-lived link While statistics-based techniques are robust against short-lived link
quality changes, they do not respond quickly to long-lived changes. quality changes, they do not respond quickly to long-lived changes.
By constraining the rate selected by statistics-based techniques By constraining the rate selected by statistics-based techniques
based on ACK SSI versus rate data (not theoretical curves), more based on ACK SSI versus rate data (not theoretical curves), more
rapid link adaptation was enabled. In order to ensure rapid rapid link adaptation was enabled. In order to ensure rapid
adaptation during rapidly varying conditions, the rate constraints adaptation during rapidly varying conditions, the rate constraints
are tightened when the SSI values are changing rapidly, encouraging are tightened when the SSI values are changing rapidly, encouraging
rate transitions. The authors validated their algorithms by rate transitions. The authors validated their algorithms by
implementing a driver for the Atheros AR5000 chipset, and then implementing a driver for the Atheros AR5000 chipset, and then
skipping to change at page 48, line 40 skipping to change at page 50, line 40
(and improvement) in channel properties, since it is not restricted (and improvement) in channel properties, since it is not restricted
to moving to adjacent rates. to moving to adjacent rates.
In "CARA: Collision-Aware Rate Adaptation for IEEE 802.11 WLANs" In "CARA: Collision-Aware Rate Adaptation for IEEE 802.11 WLANs"
[CARA], the authors propose Collision-Aware Rate Adaptation (CARA). [CARA], the authors propose Collision-Aware Rate Adaptation (CARA).
This involves utilization of Clear Channel Assessment (CCA) along This involves utilization of Clear Channel Assessment (CCA) along
with adaptation of the Request-to-Send/Clear-to-Send (RTS/CTS) with adaptation of the Request-to-Send/Clear-to-Send (RTS/CTS)
mechanism to differentiate losses caused by frame collisions from mechanism to differentiate losses caused by frame collisions from
losses caused by channel conditions. Rather than decreasing rate as losses caused by channel conditions. Rather than decreasing rate as
the result of frame loss due to collisions, which leads to increased the result of frame loss due to collisions, which leads to increased
contention, CARA selectively enables RTS/CTS (e.g. after a frame contention, CARA selectively enables RTS/CTS (e.g., after a frame
loss), reducing the likelihood of frame loss due to hidden stations. loss), reducing the likelihood of frame loss due to hidden stations.
CARA can also utilize CCA to determine whether a collision has CARA can also utilize CCA to determine whether a collision has
occurred after a transmission; however since CCA may not detect a occurred after a transmission; however, since CCA may not detect a
significant fraction of all collisions (particularly when significant fraction of all collisions (particularly when
transmitting at low rate), its use is optional. As compared with transmitting at low rate), its use is optional. As compared with
ARF, in simulations the authors show large improvements in aggregate ARF, in simulations the authors show large improvements in aggregate
throughput due to addition of adaptive RTS/CTS, and additional modest throughput due to addition of adaptive RTS/CTS, and additional modest
improvements with the additional help of CCA. improvements with the additional help of CCA.
In "Robust Rate Adaptation for 802.11 Wireless Networks" [Robust] the In "Robust Rate Adaptation for 802.11 Wireless Networks" [Robust],
authors implemented the ARF, AARF and SampleRate [SampleRate] the authors implemented the ARF, AARF, and SampleRate [SampleRate]
algorithms on a programmable Access Point platform, and algorithms on a programmable Access Point platform, and
experimentally examined the performance of these algorithms as well experimentally examined the performance of these algorithms as well
as the ONOE [ONOE] algorithm implemented in MADWiFi. Based on their as the ONOE [ONOE] algorithm implemented in MadWiFi. Based on their
experiments, the authors critically examine the assumptions experiments, the authors critically examine the assumptions
underlying existing rate negotiation algorithms: underlying existing rate negotiation algorithms:
Decrease transmission rate upon severe frame loss Decrease transmission rate upon severe frame loss
Where severe frame loss is due to channel conditions, rate Where severe frame loss is due to channel conditions, rate
reduction can improve throughput. However, where frame loss is due reduction can improve throughput. However, where frame loss is
to contention (such as from hidden stations), reducing transmission due to contention (such as from hidden stations), reducing
rate increases congestion, lowering throughput and potentially transmission rate increases congestion, lowering throughput and
leading to congestive collapse. Instead, the authors propose potentially leading to congestive collapse. Instead, the
adaptive enabling of RTS/CTS so as to reduce contention due to authors propose adaptive enabling of RTS/CTS so as to reduce
hidden stations. Once RTS/CTS is enabled, remaining losses are contention due to hidden stations. Once RTS/CTS is enabled,
more likely to be due to channel conditions, providing more remaining losses are more likely to be due to channel
reliable guidance on increasing or decreasing transmission rate. conditions, providing more reliable guidance on increasing or
decreasing transmission rate.
Use probe frames to assess possible new rates Use probe frames to assess possible new rates
Probe frames reliably estimate frame loss at a given rate unless Probe frames reliably estimate frame loss at a given rate unless
the sample size is sufficient and the probe frames are of the sample size is sufficient and the probe frames are of
comparable length to data frames. The authors argue that rate comparable length to data frames. The authors argue that rate
adaptation schemes such as SampleRate are too sensitive to loss of adaptation schemes such as SampleRate are too sensitive to loss
probe packets. In order to satisfy sample size constraints, a of probe packets. In order to satisfy sample size constraints,
significant number of probe frames are required. This can increase a significant number of probe frames are required. This can
frame loss if the probed rate is too high, and can lower throughput increase frame loss if the probed rate is too high, and can
if the probed rate is too low. Instead, the authors propose lower throughput if the probed rate is too low. Instead, the
assessment of the channel condition by tracking the frame loss authors propose assessment of the channel condition by tracking
ratio within a window of 5 to 40 frames. the frame loss ratio within a window of 5 to 40 frames.
Use consecutive transmission successes/losses to increase/decrease rate Use consecutive transmission successes/losses to increase/decrease
rate
The authors argue that consecutive successes or losses are not a The authors argue that consecutive successes or losses are not a
reliable basis for rate increases or decreases; greater sample size reliable basis for rate increases or decreases; greater sample
is needed. size is needed.
Use PHY metrics like SNR to infer new transmission rate Use PHY metrics like SNR to infer new transmission rate
The authors argue that received signal/noise ratio routinely varies The authors argue that received signal to noise ratio (SNR)
5 dB per packet and that variations of 10-14 dB are common. As a routinely varies 5 dB per packet and that variations of 10-14 dB
result, rate decisions based on signal/noise ratio or signal are common. As a result, rate decisions based on SNR or signal
strength can cause transmission rate to vary rapidly. The authors strength can cause transmission rate to vary rapidly. The
question the value of such rapid variation, since studies such as authors question the value of such rapid variation, since
[Aguayo] show little correlation between signal to noise ratio and studies such as [Aguayo] show little correlation between SNR and
frame loss probability. As a result, the authors argue that frame loss probability. As a result, the authors argue that
neither received signal strength indication (RSSI) nor background neither received signal strength indication (RSSI) nor
energy level can be used to distinguish losses due to contention background energy level can be used to distinguish losses due to
from those due to channel conditions. While multi-path contention from those due to channel conditions. While multi-
interference can simultaneously result in high signal strength and path interference can simultaneously result in high signal
frame loss, the relationship between low signal strength and high strength and frame loss, the relationship between low signal
frame loss is stronger. Therefore transmission rate decreases due strength and high frame loss is stronger. Therefore,
to low received signal strength probably do reflect sudden transmission rate decreases due to low received signal strength
worsening in channel conditions, although sudden increases may not probably do reflect sudden worsening in channel conditions,
necessarily indicate that channel conditions have improved. although sudden increases may not necessarily indicate that
channel conditions have improved.
Long-term smoothened operation produces best average performance Long-term smoothened operation produces best average performance
The authors present evidence that frame losses more than 150 ms The authors present evidence that frame losses more than 150 ms
apart are uncorrelated. Therefore collection of statistical data apart are uncorrelated. Therefore, collection of statistical
over intervals of 1 second or greater reduce responsiveness, but do data over intervals of 1 second or greater reduces
not improve the quality of transmission rate decisions. Rather, responsiveness, but does not improve the quality of transmission
the authors argue that a sampling period of 100 ms provides the rate decisions. Rather, the authors argue that a sampling
best average performance. Such small sampling periods also argue period of 100 ms provides the best average performance. Such
against use of probes, since probe packets can only represent a small sampling periods also argue against use of probes, since
fraction of all data frames and probes collected more than 150ms probe packets can only represent a fraction of all data frames
apart may not provide reliable information on channel conditions. and probes collected more than 150 ms apart may not provide
reliable information on channel conditions.
Based on these flaws, the authors propose the Robust Rate Adaptation Based on these flaws, the authors propose the Robust Rate Adaptation
Algorithm (RRAA). RRAA utilizes only the frame loss ratio at the Algorithm (RRAA). RRAA utilizes only the frame loss ratio at the
current transmission rate to determine whether to increase or current transmission rate to determine whether to increase or
decrease the transmission rate; PHY layer information or probe decrease the transmission rate; PHY layer information or probe
packets are not used. Each transmission rate is associated with an packets are not used. Each transmission rate is associated with an
estimation window, a maximum tolerable loss threshold (MTL) and an estimation window, a maximum tolerable loss threshold (MTL) and an
opportunistic rate increase threshold (ORI). If the loss ratio is opportunistic rate increase threshold (ORI). If the loss ratio is
larger than the MTL, the transmission rate is decreased and if it is larger than the MTL, the transmission rate is decreased, and if it is
smaller than ORI, transmission rate is increased; otherwise smaller than the ORI, transmission rate is increased; otherwise
transmission rate remains the same. The thresholds are selected in transmission rate remains the same. The thresholds are selected in
order to maximize throughput. Although RRAA only allows movement order to maximize throughput. Although RRAA only allows movement
between adjacent transmission rates, the algorithm does not require between adjacent transmission rates, the algorithm does not require
collection of an entire estimation window prior to increasing or collection of an entire estimation window prior to increasing or
decreasing transmission rates; if additional data collection would decreasing transmission rates; if additional data collection would
not change the decision, the change is made immediately. not change the decision, the change is made immediately.
The authors validate the RRAA algorithm using experiments and field The authors validate the RRAA algorithm using experiments and field
trials; the results indicate that RRAA without adaptive RTS/CTS trials; the results indicate that RRAA without adaptive RTS/CTS
outperforms the ARF, AARF and Sample Rate algorithms. This occurs outperforms the ARF, AARF, and Sample Rate algorithms. This occurs
because RRAA is not as sensitive to transient frame loss and does not because RRAA is not as sensitive to transient frame loss and does not
use probing, enabling it to more frequently utilize higher use probing, enabling it to more frequently utilize higher
transmission rates. Where there are no hidden stations, turning on transmission rates. Where there are no hidden stations, turning on
adaptive RTS/CTS reduces performance by at most a few percent. adaptive RTS/CTS reduces performance by at most a few percent.
However, where there is substantial contention from hidden stations, However, where there is substantial contention from hidden stations,
adaptive RTS/CTS provides large performance gains, due to reduction adaptive RTS/CTS provides large performance gains, due to reduction
in frame loss which enables selection of a higher transmission rate. in frame loss that enables selection of a higher transmission rate.
In "Efficient Mobility Management for Vertical Handoff between WWAN In "Efficient Mobility Management for Vertical Handoff between WWAN
and WLAN" [Vertical], the authors propose use of signal strength and and WLAN" [Vertical], the authors propose use of signal strength and
link utilization in order to optimize vertical handoff. WLAN to WWAN link utilization in order to optimize vertical handoff. WLAN to WWAN
handoff is driven by SSI decay. When IEEE 802.11 SSI falls below a handoff is driven by SSI decay. When IEEE 802.11 SSI falls below a
threshold (S1), FFT-based decay detection is undertaken to determine threshold (S1), Fast Fourier Transform (FFT)-based decay detection is
if the signal is likely to continue to decay. If so, then handoff to undertaken to determine if the signal is likely to continue to decay.
the WWAN is initiated when the signal falls below the minimum If so, then handoff to the WWAN is initiated when the signal falls
acceptable level (S2). WWAN to WLAN handoff is driven by both PHY below the minimum acceptable level (S2). WWAN to WLAN handoff is
and MAC characteristics of the IEEE 802.11 target network. At the driven by both PHY and MAC characteristics of the IEEE 802.11 target
PHY layer, characteristics such as SSI are examined to determine if network. At the PHY layer, characteristics such as SSI are examined
the signal strength is greater than a minimum value (S3); at the MAC to determine if the signal strength is greater than a minimum value
layer the IEEE 802.11 Network Allocation Vector (NAV) occupation is (S3). At the MAC layer, the IEEE 802.11 Network Allocation Vector
examined in order to estimate the maximum available bandwidth and (NAV) occupation is examined in order to estimate the maximum
mean access delay. Note that depending on the value of S3, it is available bandwidth and mean access delay. Note that depending on
possible for the negotiated rate to be less than the available the value of S3, it is possible for the negotiated rate to be less
bandwidth. In order to prevent premature handoff between WLAN and than the available bandwidth. In order to prevent premature handoff
WWAN, S1 and S2 are separated by 6 dB; in order to prevent between WLAN and WWAN, S1 and S2 are separated by 6 dB; in order to
oscillation between WLAN and WWAN media, S3 needs to be greater than prevent oscillation between WLAN and WWAN media, S3 needs to be
S1 by an appropriate margin. greater than S1 by an appropriate margin.
A.2 Internet Layer A.2. Internet Layer
Within the Internet layer, proposals have been made for utilizing Within the Internet layer, proposals have been made for utilizing
link indications to optimize IP configuration, to improve the link indications to optimize IP configuration, to improve the
usefulness of routing metrics, and to optimize aspects of Mobile IP usefulness of routing metrics, and to optimize aspects of Mobile IP
handoff. handoff.
In "Analysis of link failures in an IP backbone" [Iannaccone] the In "Analysis of link failures in an IP backbone" [Iannaccone], the
authors investigate link failures in Sprint's IP backbone. They authors investigate link failures in Sprint's IP backbone. They
identify the causes of convergence delay, including delays in identify the causes of convergence delay, including delays in
detection of whether an interface is down or up. While it is fastest detection of whether an interface is down or up. While it is fastest
for a router to utilize link indications if available, there are for a router to utilize link indications if available, there are
situations in which it is necessary to depend on loss of routing situations in which it is necessary to depend on loss of routing
packets to determine the state of the link. Once the link state has packets to determine the state of the link. Once the link state has
been determined, a delay may occur within the routing protocol in been determined, a delay may occur within the routing protocol in
order to dampen link flaps. Finally, another delay may be introduced order to dampen link flaps. Finally, another delay may be introduced
in propagating the link state change, in order to rate limit link in propagating the link state change, in order to rate limit link
state advertisements, and guard against instability. state advertisements, and guard against instability.
"Bidirectional Forwarding Detection" [BFD] notes that link layers may "Bidirectional Forwarding Detection" [BFD] notes that link layers may
provide only limited failure indications, and that relatively slow provide only limited failure indications, and that relatively slow
"Hello" mechanisms are used in routing protocols to detect failures "Hello" mechanisms are used in routing protocols to detect failures
when no link layer indications are available. This results in when no link layer indications are available. This results in
failure detection times of the order of a second, which is too long failure detection times of the order of a second, which is too long
for some applications. The authors describe a mechanism that can be for some applications. The authors describe a mechanism that can be
used for liveness detection over any media, enabling rapid detection used for liveness detection over any media, enabling rapid detection
of failures in the path between adjacent forwarding engines. A path of failures in the path between adjacent forwarding engines. A path
is declared operational when bi-directional reachability has been is declared operational when bidirectional reachability has been
confirmed. confirmed.
In "Detecting Network Attachment (DNA) in IPv4" [RFC4436], a host In "Detecting Network Attachment (DNA) in IPv4" [RFC4436], a host
that has moved to a new point of attachment utilizes a bi-directional that has moved to a new point of attachment utilizes a bidirectional
reachability test in parallel with DHCP [RFC2131] to rapidly reachability test in parallel with DHCP [RFC2131] to rapidly
reconfirm an operable configuration. reconfirm an operable configuration.
In "L2 Triggers Optimized Mobile IPv6 Vertical Handover: The In "L2 Triggers Optimized Mobile IPv6 Vertical Handover: The
802.11/GPRS Example" [Park], the authors propose that the mobile node 802.11/GPRS Example" [Park], the authors propose that the mobile node
send a router solicitation on receipt of a "Link Up" indication in send a router solicitation on receipt of a "Link Up" indication in
order to provide lower handoff latency than would be possible using order to provide lower handoff latency than would be possible using
generic movement detection [RFC3775]. The authors also suggest generic movement detection [RFC3775]. The authors also suggest
immediate invalidation of the Care-Of-Address (CoA) on receipt of a immediate invalidation of the Care-of Address (CoA) on receipt of a
"Link Down" indication. However, this is problematic where a "Link "Link Down" indication. However, this is problematic where a "Link
Down" indication can be followed by a "Link Up" indication without a Down" indication can be followed by a "Link Up" indication without a
resulting change in IP configuration, as described in [RFC4436]. resulting change in IP configuration, as described in [RFC4436].
In "Layer 2 Handoff for Mobile-IPv4 with 802.11" [Mun], the authors In "Layer 2 Handoff for Mobile-IPv4 with 802.11" [Mun], the authors
suggest that MIPv4 Registration messages be carried within suggest that MIPv4 Registration messages be carried within
Information Elements of IEEE 802.11 Association/Reassociation frames, Information Elements of IEEE 802.11 Association/Reassociation frames,
in order to minimize handoff delays. This requires modification to in order to minimize handoff delays. This requires modification to
the mobile node as well as 802.11 APs. However, prior to detecting the mobile node as well as 802.11 APs. However, prior to detecting
network attachment, it is difficult for the mobile node to determine network attachment, it is difficult for the mobile node to determine
whether the new point of attachment represents a change of network or whether or not the new point of attachment represents a change of
not. For example, even where a station remains within the same ESS, network. For example, even where a station remains within the same
it is possible that the network will change. Where no change of ESS, it is possible that the network will change. Where no change of
network results, sending a MIPv4 Registration message with each network results, sending a MIPv4 Registration message with each
Association/Reassociation is unnecessary. Where a change of network Association/Reassociation is unnecessary. Where a change of network
results, it is typically not possible for the mobile node to results, it is typically not possible for the mobile node to
anticipate its new CoA at Association/Reassociation; for example, a anticipate its new CoA at Association/Reassociation; for example, a
DHCP server may assign a CoA not previously given to the mobile node. DHCP server may assign a CoA not previously given to the mobile node.
When dynamic VLAN assignment is used, the VLAN assignment is not even When dynamic VLAN assignment is used, the VLAN assignment is not even
determined until IEEE 802.1X authentication has completed, which is determined until IEEE 802.1X authentication has completed, which is
after Association/Reassociation in [IEEE-802.11i]. after Association/Reassociation in [IEEE-802.11i].
In "Link Characteristics Information for Mobile IP" [Lee], link In "Link Characteristics Information for Mobile IP" [Lee], link
characteristics are included in registration/binding update messages characteristics are included in registration/Binding Update messages
sent by the mobile node to the home agent and correspondent node. sent by the mobile node to the home agent and correspondent node.
Where the mobile node is acting as a receiver, this allows the Where the mobile node is acting as a receiver, this allows the
correspondent node to adjust its transport parameters window more correspondent node to adjust its transport parameters window more
rapidly than might otherwise be possible. Link characteristics that rapidly than might otherwise be possible. Link characteristics that
may be communicated include the link type (e.g. 802.11b, CDMA, GPRS, may be communicated include the link type (e.g., 802.11b, CDMA (Code
etc.) and link bandwidth. While the document suggests that the Division Multiple Access), GPRS (General Packet Radio Service), etc.)
and link bandwidth. While the document suggests that the
correspondent node should adjust its sending rate based on the correspondent node should adjust its sending rate based on the
advertised link bandwidth, this may not be wise in some advertised link bandwidth, this may not be wise in some
circumstances. For example, where the mobile node link is not the circumstances. For example, where the mobile node link is not the
bottleneck, adjusting the sending rate based on the link bandwidth bottleneck, adjusting the sending rate based on the link bandwidth
could cause in congestion. Also, where the transmission rate changes could cause congestion. Also, where the transmission rate changes
frequently, sending registration messages on each transmission rate frequently, sending registration messages on each transmission rate
change could by itself consume significant bandwidth. Even where the change could by itself consume significant bandwidth. Even where the
advertised link characteristics indicate the need for a smaller advertised link characteristics indicate the need for a smaller
congestion window, it may be non-trivial to adjust the sending rates congestion window, it may be non-trivial to adjust the sending rates
of individual connections where there are multiple connections open of individual connections where there are multiple connections open
between a mobile node and correspondent node. A more conservative between a mobile node and correspondent node. A more conservative
approach would be to trigger parameter re-estimation and slow start approach would be to trigger parameter re-estimation and slow start
based on the receipt of a registration message or binding update. based on the receipt of a registration message or Binding Update.
In "Hotspot Mitigation Protocol (HMP)" [HMP], it is noted that Mobile In "Hotspot Mitigation Protocol (HMP)" [HMP], it is noted that Mobile
Ad-hoc NETwork (MANET) routing protocols have a tendency to Ad-hoc NETwork (MANET) routing protocols have a tendency to
concentrate traffic since they utilize shortest path metrics and concentrate traffic since they utilize shortest-path metrics and
allow nodes to respond to route queries with cached routes. The allow nodes to respond to route queries with cached routes. The
authors propose that nodes participating in an ad-hoc wireless mesh authors propose that nodes participating in an ad-hoc wireless mesh
monitor local conditions such as MAC delay, buffer consumption and monitor local conditions such as MAC delay, buffer consumption, and
packets loss. Where congestion is detected, this is communicated to packet loss. Where congestion is detected, this is communicated to
neighboring nodes via an IP option. In response to moderate neighboring nodes via an IP option. In response to moderate
congestion, nodes suppress route requests; where major congestion is congestion, nodes suppress route requests; where major congestion is
detected, nodes rate control transport connections flowing through detected, nodes rate control transport connections flowing through
them. The authors argue that for ad-hoc networks, throttling by them. The authors argue that for ad-hoc networks, throttling by
intermediate nodes is more effective than end-to-end congestion intermediate nodes is more effective than end-to-end congestion
control mechanisms. control mechanisms.
A.3 Transport Layer A.3. Transport Layer
Within the Transport layer, proposals have focused on countering the Within the transport layer, proposals have focused on countering the
effects of handoff-induced packet loss and non-congestive loss caused effects of handoff-induced packet loss and non-congestive loss caused
by lossy wireless links. by lossy wireless links.
Where a mobile host moves to a new network, the transport parameters Where a mobile host moves to a new network, the transport parameters
(including the RTT, RTO and congestion window) may no longer be (including the RTT, RTO, and congestion window) may no longer be
valid. Where the path change occurs on the sender (e.g. change in valid. Where the path change occurs on the sender (e.g., change in
outgoing or incoming interface), the sender can reset its congestion outgoing or incoming interface), the sender can reset its congestion
window and parameter estimates. However, where it occurs on the window and parameter estimates. However, where it occurs on the
receiver, the sender may not be aware of the path change. receiver, the sender may not be aware of the path change.
In "The BU-trigger method for improving TCP performance over Mobile In "The BU-trigger method for improving TCP performance over Mobile
IPv6" [Kim], the authors note that handoff-related packet loss is IPv6" [Kim], the authors note that handoff-related packet loss is
interpreted as congestion by the Transport layer. In the case where interpreted as congestion by the transport layer. In the case where
the correspondent node is sending to the mobile node, it is proposed the correspondent node is sending to the mobile node, it is proposed
that receipt of a Binding Update by the correspondent node be used as that receipt of a Binding Update by the correspondent node be used as
a signal to the Transport layer to adjust cwnd and ssthresh values, a signal to the transport layer to adjust cwnd and ssthresh values,
which may have been reduced due to handoff-induced packet loss. The which may have been reduced due to handoff-induced packet loss. The
authors recommend that cwnd and ssthresh be recovered to pre-timeout authors recommend that cwnd and ssthresh be recovered to pre-timeout
values, regardless of whether the link parameters have changed. The values, regardless of whether the link parameters have changed. The
paper does not discuss the behavior of a mobile node sending a paper does not discuss the behavior of a mobile node sending a
Binding Update, in the case where the mobile node is sending to the Binding Update, in the case where the mobile node is sending to the
correspondent node. correspondent node.
In "Effect of Vertical Handovers on Performance of TCP-Friendly Rate In "Effect of Vertical Handovers on Performance of TCP-Friendly Rate
Control" [Gurtov], the authors examine the effect of explicit Control" [Gurtov], the authors examine the effect of explicit
handover notifications on TCP-friendly rate control (TFRC). Where handover notifications on TCP-friendly rate control (TFRC). Where
skipping to change at page 54, line 24 skipping to change at page 56, line 31
of "Link Up" or "Link Down" events since these events are not of "Link Up" or "Link Down" events since these events are not
necessarily indicative of subnet change. On detection of subnet necessarily indicative of subnet change. On detection of subnet
change, it is advocated that the congestion window be reset to change, it is advocated that the congestion window be reset to
INIT_WINDOW and that transport parameters be re-estimated. The INIT_WINDOW and that transport parameters be re-estimated. The
authors argue that recovery from slow start results in higher authors argue that recovery from slow start results in higher
throughput both when the subnet change results in lower bottleneck throughput both when the subnet change results in lower bottleneck
bandwidth as well as when bottleneck bandwidth increases. bandwidth as well as when bottleneck bandwidth increases.
In "Efficient Mobility Management for Vertical Handoff between WWAN In "Efficient Mobility Management for Vertical Handoff between WWAN
and WLAN" [Vertical], the authors propose a "Virtual Connectivity and WLAN" [Vertical], the authors propose a "Virtual Connectivity
Manager" which utilizes local connection translation (LCT) and a Manager", which utilizes local connection translation (LCT) and a
subscription/notification service supporting simultaneous movement in subscription/notification service supporting simultaneous movement in
order to enable end-to-end mobility and maintain TCP throughput order to enable end-to-end mobility and maintain TCP throughput
during vertical handovers. during vertical handovers.
In an early draft of "Datagram Congestion Control Protocol (DCCP)" In an early version of "Datagram Congestion Control Protocol (DCCP)"
[RFC4340], a "Reset Congestion State" option was proposed in Section [RFC4340], a "Reset Congestion State" option was proposed in Section
4. This option was removed in part because the use conditions were 11. This option was removed in part because the use conditions were
not fully understood: not fully understood:
An Half-Connection Receiver sends the Reset Congestion State An HC-Receiver sends the Reset Congestion State option to its
option to its sender to force the sender to reset its congestion sender to force the sender to reset its congestion state -- that
state -- that is, to "slow start", as if the connection were is, to "slow start", as if the connection were beginning again.
beginning again.
... ...
The Reset Congestion State option is reserved for the very few The Reset Congestion State option is reserved for the very few
cases when an endpoint knows that the congestion properties of a cases when an endpoint knows that the congestion properties of a
path have changed. Currently, this reduces to mobility: a DCCP path have changed. Currently, this reduces to mobility: a DCCP
endpoint on a mobile host MUST send Reset Congestion State to its endpoint on a mobile host MUST send Reset Congestion State to its
peer after the mobile host changes address or path. peer after the mobile host changes address or path.
"Framework and Requirements for TRIGTRAN" [TRIGTRAN] discusses "Framework and Requirements for TRIGTRAN" [TRIGTRAN] discusses
optimizations to recover earlier from a retransmission timeout optimizations to recover earlier from a retransmission timeout
incurred during a period in which an interface or intervening link incurred during a period in which an interface or intervening link
was down. "End-to-end, Implicit 'Link-Up' Notification" [E2ELinkup] was down. "End-to-end, Implicit 'Link-Up' Notification" [E2ELinkup]
describes methods by which a TCP implementation that has backed off describes methods by which a TCP implementation that has backed off
its retransmission timer due to frame loss on a remote link can learn its retransmission timer due to frame loss on a remote link can learn
that the link has once again become operational. This enables that the link has once again become operational. This enables
retransmission to be attempted prior to expiration of the backed off retransmission to be attempted prior to expiration of the backed-off
retransmission timer. retransmission timer.
"Link-layer Triggers Protocol" [Yegin] describes transport issues "Link-layer Triggers Protocol" [Yegin] describes transport issues
arising from lack of host awareness of link conditions on downstream arising from lack of host awareness of link conditions on downstream
Access Points and routers. Transport of link layer triggers is Access Points and routers. Transport of link layer triggers is
proposed to address the issue. proposed to address the issue.
"TCP Extensions for Immediate Retransmissions" [Eggert] describes how "TCP Extensions for Immediate Retransmissions" [Eggert] describes how
a Transport layer implementation may utilize existing "end-to-end a transport layer implementation may utilize existing "end-to-end
connectivity restored" indications. It is proposed that in addition connectivity restored" indications. It is proposed that in addition
to regularly scheduled retransmissions that retransmission be to regularly scheduled retransmissions that retransmission be
attempted by the Transport layer on receipt of an indication that attempted by the transport layer on receipt of an indication that
connectivity to a peer node may have been restored. End-to-end connectivity to a peer node may have been restored. End-to-end
connectivity restoration indications include "Link Up", confirmation connectivity restoration indications include "Link Up", confirmation
of first-hop router reachability, confirmation of Internet layer of first-hop router reachability, confirmation of Internet layer
configuration, and receipt of other traffic from the peer. configuration, and receipt of other traffic from the peer.
In "Discriminating Congestion Losses from Wireless Losses Using In "Discriminating Congestion Losses from Wireless Losses Using
Interarrival Times at the Receiver" [Biaz], the authors propose a Interarrival Times at the Receiver" [Biaz], the authors propose a
scheme for differentiating congestive losses from wireless scheme for differentiating congestive losses from wireless
transmission losses based on inter-arrival times. Where the loss is transmission losses based on inter-arrival times. Where the loss is
due to wireless transmission rather than congestion, congestive due to wireless transmission rather than congestion, congestive
skipping to change at page 55, line 40 skipping to change at page 57, line 48
function well only when the wireless link is the bottleneck, which is function well only when the wireless link is the bottleneck, which is
often the case with cellular networks, but not with IEEE 802.11 often the case with cellular networks, but not with IEEE 802.11
deployment scenarios such as home or hotspot use. deployment scenarios such as home or hotspot use.
In "Improving Performance of TCP over Wireless Networks" [Bakshi], In "Improving Performance of TCP over Wireless Networks" [Bakshi],
the authors focus on the performance of TCP over wireless networks the authors focus on the performance of TCP over wireless networks
with burst losses. The authors simulate performance of TCP Tahoe with burst losses. The authors simulate performance of TCP Tahoe
within ns-2, utilizing a two-state Markov model, representing "good" within ns-2, utilizing a two-state Markov model, representing "good"
and "bad" states. Where the receiver is connected over a wireless and "bad" states. Where the receiver is connected over a wireless
link, the authors simulate the effect of an Explicit Bad State link, the authors simulate the effect of an Explicit Bad State
Notification (EBSN) sent by an access point unable to reach the Notification (EBSN) sent by an Access Point unable to reach the
receiver. In response to an EBSN, it is advocated that the existing receiver. In response to an EBSN, it is advocated that the existing
retransmission timer be canceled and replaced by a new dynamically retransmission timer be canceled and replaced by a new dynamically
estimated timeout, rather than being backed off. In the simulations, estimated timeout, rather than being backed off. In the simulations,
EBSN prevents unnecessary timeouts, decreasing RTT variance and EBSN prevents unnecessary timeouts, decreasing RTT variance and
improving throughput. improving throughput.
In "A Feedback-Based Scheme for Improving TCP Performance in Ad-Hoc In "A Feedback-Based Scheme for Improving TCP Performance in Ad-Hoc
Wireless Networks" [Chandran], the authors proposed an explicit Route Wireless Networks" [Chandran], the authors proposed an explicit Route
Failure Notification (RFN), allowing the sender to stop its Failure Notification (RFN), allowing the sender to stop its
retransmission timers when the receiver becomes unreachable. On retransmission timers when the receiver becomes unreachable. On
route reestablishment, a Route Reestablishment Notification (RRN) is route reestablishment, a Route Reestablishment Notification (RRN) is
sent, unfreezing the timer. Simulations indicate that the scheme sent, unfreezing the timer. Simulations indicate that the scheme
significantly improves throughput and reduces unnecessary significantly improves throughput and reduces unnecessary
retransmissions. retransmissions.
In "Analysis of TCP Performance over Mobile Ad Hoc Networks" In "Analysis of TCP Performance over Mobile Ad Hoc Networks"
[Holland], the authors explore how explicit link failure notification [Holland], the authors explore how explicit link failure notification
(ELFN) can improve the performance of TCP in mobile ad hoc networks. (ELFN) can improve the performance of TCP in mobile ad hoc networks.
ELFN informs the TCP sender about link and route failures so that it ELFN informs the TCP sender about link and route failures so that it
need not treat the ensuing packet loss as due to congestion. Using need not treat the ensuing packet loss as due to congestion. Using
an ns-2 simulation of TCP-Reno over 802.11 with routing provided by an ns-2 simulation of TCP Reno over 802.11 with routing provided by
the Dynamic Source Routing (DSR) protocol, it is demonstrated that the Dynamic Source Routing (DSR) protocol, it is demonstrated that
TCP performance falls considerably short of expected throughput based TCP performance falls considerably short of expected throughput based
on the percentage of the time that the network is partitioned. A on the percentage of the time that the network is partitioned. A
portion of the problem was attributed to the inability of the routing portion of the problem was attributed to the inability of the routing
protocol to quickly recognize and purge stale routes, leading to protocol to quickly recognize and purge stale routes, leading to
excessive link failures; performance improved dramatically when route excessive link failures; performance improved dramatically when route
caching was turned off. Interactions between the route request and caching was turned off. Interactions between the route request and
transport retransmission timers were also noted. Where the route transport retransmission timers were also noted. Where the route
request timer is too large, new routes cannot be supplied in time to request timer is too large, new routes cannot be supplied in time to
prevent the transport timer from expiring, and where the route prevent the transport timer from expiring, and where the route
request timer is too small, network congestion may result. request timer is too small, network congestion may result.
For their implementation of ELFN, the authors piggybacked additional For their implementation of ELFN, the authors piggybacked additional
information (sender and receiver addresses and ports, the TCP information (sender and receiver addresses and ports, the TCP
sequence number) on an existing "route failure" notice to enable the sequence number) on an existing "route failure" notice to enable the
sender to identify the affected connection. Where a TCP receives an sender to identify the affected connection. Where a TCP receives an
ELFN, it disables the retransmission timer and enters "stand-by" ELFN, it disables the retransmission timer and enters "stand-by"
mode, where packets are sent at periodic intervals to determine if mode, where packets are sent at periodic intervals to determine if
the route has been reestablished. If an acknowledgment is received the route has been reestablished. If an acknowledgment is received,
then the retransmission timers are restored. Simulations show that then the retransmission timers are restored. Simulations show that
performance is sensitive to the probe interval, with intervals of 30 performance is sensitive to the probe interval, with intervals of 30
seconds or greater giving worse performance than TCP-Reno. The seconds or greater giving worse performance than TCP Reno. The
affect of resetting the congestion window and RTO values was also effect of resetting the congestion window and RTO values was also
investigated. In the study, resetting the congestion window to one investigated. In the study, resetting the congestion window to one
did not have much of an effect on throughput, since the did not have much of an effect on throughput, since the
bandwidth/delay of the network was only a few packets. However, bandwidth/delay of the network was only a few packets. However,
resetting the RTO to a high initial value (6 seconds) did have a resetting the RTO to a high initial value (6 seconds) did have a
substantial detrimental effect, particularly at high speed. In terms substantial detrimental effect, particularly at high speed. In terms
of the probe packet sent, the simulations showed little difference of the probe packet sent, the simulations showed little difference
between sending the first packet in the congestion window, or between sending the first packet in the congestion window, or
retransmitting the packet with the lowest sequence number among those retransmitting the packet with the lowest sequence number among those
signaled as lost via the ELFNs. signaled as lost via the ELFNs.
In "Improving TCP Performance over Wireless Links" [Goel], the In "Improving TCP Performance over Wireless Links" [Goel], the
authors propose use of an ICMP-DEFER message, sent by a wireless authors propose use of an ICMP-DEFER message, sent by a wireless
access point on failure of a transmission attempt. After exhaustion Access Point on failure of a transmission attempt. After exhaustion
of retransmission attempts, an ICMP-RETRANSMIT message is sent. On of retransmission attempts, an ICMP-RETRANSMIT message is sent. On
receipt of an ICMP-DEFER message, the expiry of the retransmission receipt of an ICMP-DEFER message, the expiry of the retransmission
timer is postponed by the current RTO estimate. On receipt of an timer is postponed by the current RTO estimate. On receipt of an
ICMP-RETRANSMIT message, the segment is retransmitted. On ICMP-RETRANSMIT message, the segment is retransmitted. On
retransmission, the congestion window is not reduced; when coming out retransmission, the congestion window is not reduced; when coming out
of fast recovery, the congestion window is reset to its value prior of fast recovery, the congestion window is reset to its value prior
to fast retransmission and fast recovery. Using a two-state Markov to fast retransmission and fast recovery. Using a two-state Markov
model, simulated using ns-2, the authors show that the scheme model, simulated using ns-2, the authors show that the scheme
improves throughput. improves throughput.
skipping to change at page 57, line 39 skipping to change at page 60, line 5
transport layer in the face of changes in path characteristics transport layer in the face of changes in path characteristics
varying more quickly than the round-trip time. varying more quickly than the round-trip time.
In "Protocol Enhancements for Intermittently Connected Hosts" In "Protocol Enhancements for Intermittently Connected Hosts"
[Schuetz], the authors note that intermittent connectivity can lead [Schuetz], the authors note that intermittent connectivity can lead
to poor performance and connectivity failures. To address these to poor performance and connectivity failures. To address these
problems, the authors combine the use of the Host Identity Protocol problems, the authors combine the use of the Host Identity Protocol
(HIP) [RFC4423] with a TCP User Timeout Option and TCP Retransmission (HIP) [RFC4423] with a TCP User Timeout Option and TCP Retransmission
trigger, demonstrating significant improvement. trigger, demonstrating significant improvement.
A.4 Application Layer A.4. Application Layer
In "Application-oriented Link Adaptation for IEEE 802.11" In "Application-oriented Link Adaptation for IEEE 802.11"
[Haratcherev2], rate information generated by a link layer utilizing [Haratcherev2], rate information generated by a link layer utilizing
improved rate adaptation algorithms is provided to a video improved rate adaptation algorithms is provided to a video
application, and used for codec adaptation. Coupling the link and application, and used for codec adaptation. Coupling the link and
application layers results in major improvements in the Peak application layers results in major improvements in the Peak Signal
Signal/Noise Ratio (PSNR). Since this approach assumes that the link to Noise Ratio (PSNR). Since this approach assumes that the link
represents the path bottleneck bandwidth, it is not universally represents the path bottleneck bandwidth, it is not universally
applicable to use over the Internet. applicable to use over the Internet.
At the Application layer, the usage of "Link Down" indications has At the application layer, the usage of "Link Down" indications has
been proposed to augment presence systems. In such systems, client been proposed to augment presence systems. In such systems, client
devices periodically refresh their presence state using application devices periodically refresh their presence state using application
layer protocols such as SIMPLE [RFC3428] or XMPP [RFC3921]. If the layer protocols such as SIP for Instant Messaging and Presence
client should become disconnected, their unavailability will not be Leveraging Extensions (SIMPLE) [RFC3428] or Extensible Messaging and
detected until the presence status times out, which can take many Presence Protocol (XMPP) [RFC3921]. If the client should become
minutes. However, if a link goes down, and a disconnect indication disconnected, their unavailability will not be detected until the
can be sent to the presence server (presumably by the access point, presence status times out, which can take many minutes. However, if
which remains connected), the status of the user's communication a link goes down, and a disconnect indication can be sent to the
application can be updated nearly instantaneously. presence server (presumably by the Access Point, which remains
connected), the status of the user's communication application can be
updated nearly instantaneously.
Appendix B - IAB Members at the time of this writing Appendix B. IAB Members at the Time of This Writing
Bernard Aboba Bernard Aboba
Loa Andersson Loa Andersson
Brian Carpenter Brian Carpenter
Leslie Daigle Leslie Daigle
Elwyn Davies Elwyn Davies
Kevin Fall Kevin Fall
Olaf Kolkman Olaf Kolkman
Kurtis Lindqvist Kurtis Lindqvist
David Meyer David Meyer
David Oran David Oran
Eric Rescorla Eric Rescorla
Dave Thaler Dave Thaler
Lixia Zhang Lixia Zhang
Authors' Addresses Author's Address
Bernard Aboba Bernard Aboba, Ed.
Microsoft Corporation Microsoft Corporation
One Microsoft Way One Microsoft Way
Redmond, WA 98052 Redmond, WA 98052
EMail: bernarda@microsoft.com EMail: bernarda@microsoft.com
Phone: +1 425 706 6605 Phone: +1 425 706 6605
Fax: +1 425 936 7329 Fax: +1 425 936 7329
IAB
EMail: iab@iab.org
URI: http://www.iab.org/
Full Copyright Statement Full Copyright Statement
Copyright (C) The IETF Trust (2007). Copyright (C) The IETF Trust (2007).
This document is subject to the rights, licenses and restrictions This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors contained in BCP 78, and except as set forth therein, the authors
retain all their rights. retain all their rights.
This document and the information contained herein are provided on an This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
skipping to change at page 59, line 45 skipping to change at page 62, line 45
such proprietary rights by implementers or users of this such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr. http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at this standard. Please address the information to the IETF at
ietf-ipr@ietf.org. ietf-ipr@ietf.org.
Acknowledgment Acknowledgement
Funding for the RFC Editor function is provided by the IETF Funding for the RFC Editor function is currently provided by the
Administrative Support Activity (IASA). Internet Society.
 End of changes. 323 change blocks. 
906 lines changed or deleted 905 lines changed or added

This html diff was produced by rfcdiff 1.33. The latest version is available from http://tools.ietf.org/tools/rfcdiff/