draft-iab-link-indications-07.txt   draft-iab-link-indications-08.txt 
Network Working Group B. Aboba, Ed. Network Working Group B. Aboba, Ed.
INTERNET-DRAFT Internet Architecture Board INTERNET-DRAFT Internet Architecture Board
Category: Informational IAB Category: Informational IAB
<draft-iab-link-indications-07.txt> <draft-iab-link-indications-08.txt>
6 February 2007 19 February 2007
Architectural Implications of Link Indications Architectural Implications of Link Indications
By submitting this Internet-Draft, each author represents that any By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware 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 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. aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
skipping to change at page 1, line 32 skipping to change at page 1, line 32
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt. http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
This Internet-Draft will expire on August 8, 2007. This Internet-Draft will expire on August 26, 2007.
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
skipping to change at page 2, line 10 skipping to change at page 2, line 10
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 ........................................... 4 1.3 Overview ........................................... 5
1.4 Layered Indication Model ........................... 6 1.4 Layered Indication Model ........................... 6
2. Architectural Considerations ............................. 13 2. Architectural Considerations ............................. 13
2.1 Model Validation ................................... 14 2.1 Model Validation ................................... 14
2.2 Clear Definitions .................................. 14 2.2 Clear Definitions .................................. 15
2.3 Robustness ......................................... 16 2.3 Robustness ......................................... 16
2.4 Congestion Control ................................. 19 2.4 Congestion Control ................................. 19
2.5 Effectiveness ...................................... 20 2.5 Effectiveness ...................................... 21
2.6 Interoperability ................................... 20 2.6 Interoperability ................................... 21
2.7 Race Conditions .................................... 21 2.7 Race Conditions .................................... 21
2.8 Layer Compression .................................. 24 2.8 Layer Compression .................................. 24
2.9 Transport of Link Indications ...................... 25 2.9 Transport of Link Indications ...................... 25
3. Future Work .............................................. 26 3. Future Work .............................................. 26
4. Security Considerations .................................. 27 4. Security Considerations .................................. 27
4.1 Spoofing ........................................... 27 4.1 Spoofing ........................................... 27
4.2 Indication Validation .............................. 28 4.2 Indication Validation .............................. 28
4.3 Denial of Service .................................. 29 4.3 Denial of Service .................................. 29
5. IANA Considerations ...................................... 29 5. IANA Considerations ...................................... 30
6. References ............................................... 29 6. References ............................................... 30
6.1 Informative References ............................. 29 6.1 Informative References ............................. 30
Appendix A - Literature Review ............................... 38 Acknowledgments .............................................. 39
A.0 Terminology ........................................ 38 Appendix A - Literature Review ............................... 40
A.1 Link Layer ......................................... 38 A.0 Terminology ........................................ 40
A.2 Internet Layer ..................................... 48 A.1 Link Layer ......................................... 40
A.3 Transport Layer .................................... 49 A.2 Internet Layer ..................................... 52
A.4 Application Layer .................................. 53 A.3 Transport Layer .................................... 54
Appendix B - IAB Members ..................................... 55 A.4 Application Layer .................................. 58
Authors' Addresses ........................................... 55 Appendix B - IAB Members ..................................... 59
Full Copyright Statement ..................................... 55 Authors' Addresses ........................................... 59
Intellectual Property ........................................ 56 Full Copyright Statement ..................................... 60
Intellectual Property ........................................ 60
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, and provides advice to document authors about the link indications within the Internet architecture, and provides
appropriate use of link indications within the Internet, Transport advice to document authors about the appropriate use of link
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 in wireless Local Area Networks literature on link indications, focusing largely on wireless Local
(LANs). 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
Asymmetric Asymmetric
A link with transmission characteristics which 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 of
the transmitter and the receiver is said to be asymmetric. For the transmitter and the receiver is said to be asymmetric. For
instance, the range of one transmitter may be much higher than the instance, the range of one transmitter may be much higher than the
range of another transmitter on the same medium. range of another transmitter on the same medium.
Link A communication facility or medium over which nodes can communicate Link A communication facility or medium over which nodes can communicate
at the link layer, i.e., the layer immediately below the Internet at the link layer, i.e., the layer immediately below the Internet
Protocol (IP). Protocol (IP).
Link Down Link Down
skipping to change at page 4, line 8 skipping to change at page 4, line 8
communicating data frames; transient periods of high frame loss are communicating data frames; transient periods of high frame loss are
not sufficient. not sufficient.
Link Layer Link Layer
Conceptual layer of control or processing logic that is responsible Conceptual layer of control or processing logic that is responsible
for maintaining control of the link. The link layer functions for maintaining control of the link. The link layer functions
provide an interface between the higher-layer logic and the link. provide an interface between the higher-layer logic and the link.
The link layer is the layer immediately below the Internet Protocol The link layer is the layer immediately below the Internet Protocol
(IP). (IP).
Link indication Link Indication
Information provided by the link layer to higher layers regarding Information provided by the link layer to higher layers regarding
the state of the link. the state of the link.
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 change
associated with the interface becoming capable of communicating associated with the interface becoming capable of communicating
data frames. data frames.
Maximum Segment Size (MSS)
The maximum payload size available to the Transport layer.
Maximum Transmission Unit (MTU)
The size in octets of the largest IP packet, including the IP
header and payload, that can be transmitted on a link or path.
Point of Attachment Point of Attachment
The endpoint on the link to which the host is currently connected. The endpoint on the link to which the host is currently connected.
Operable address Operable Address
The term "operable address" refers to either a static address or a A static or dynamically assigned address which has not been
dynamically assigned address which has not been relinquished, and relinquished, and has not expired.
has not expired.
Routable address Routable Address
In this specification, the term "routable address" refers to any Any IP address other than a Link-Local address. This includes
IPv4 address other than an IPv4 Link-Local address. This includes
private addresses as specified in "Address Allocation for Private private addresses as specified in "Address Allocation for Private
Internets" [RFC1918]. Internets" [RFC1918].
Strong End System Model Strong End System Model
In the Strong End System model, packets sent out an interface have The Strong End System model emphasizes the host/router distinction,
a source address configured on that interface and incoming packets
whose destination does not correspond to the physical interface
through which it is received are silently discarded. In general,
the Strong End System model emphasizes the host/router distinction,
tending to model a multihomed host as a set of logical hosts within tending to model a multihomed host as a set of logical hosts within
the same physical host. the same physical host. In the Strong End System model, addresses
refer to an interface, rather than to the host to which they
attach. As a result, packets sent on an outgoing interface have a
source address configured on that interface and incoming packets
whose destination address does not correspond to the physical
interface through which it is received are silently discarded. The
Strong End System model is very commonly implemented at the link
layer, but rarely at the Internet layer.
Weak End System Model Weak End System Model
In the Weak End System Model, packets sent out an interface need In the Weak End System model, addresses refer to a host. As a
not necessarily have a source address configured on that interface, result, packets sent on an outgoing interface need not necessarily
and incoming packets whose destination does not correspond to the have a source address configured on that interface, and incoming
physical interface through which it is received are accepted. packets whose destination address does not correspond to the
physical interface through which it is received are accepted. The
Weak End System model is very commonly implemented at the Internet
layer, but rarely at the link layer.
1.3. Overview 1.3. Overview
The integration of link indications with the Internet architecture The use of link indications within the Internet architecture has a
has a long history. Link status was first taken into account in long history. In response to an attempt to send to a host that was
routing as 1969. In response to an attempt to send to a host that off-line, the ARPANET link layer protocol provided a "Destination
was 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]. Link-aware routing metrics also have a long history; the [RFC816]. The ARPANET packet radio experiment [PRNET] incorporated
ARPANET packet radio experiment [PRNET] incorporated frame loss in frame loss in the calculation of routing metrics, a precursor to more
the calculation of routing metrics, a precursor to more recent link- recent link-aware routing metrics such as Expected Transmission Count
aware routing metrics such as Expected Transmission Count (ETX), (ETX), described in "A High-Throughput Path Metric for Multi-Hop
described in "A High-Throughput Path Metric for Multi-Hop Wireless Wireless Routing" [ETX].
Routing" [ETX].
"Routing Information Protocol" [RFC1058] defines 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 Open Shortest Path First Specification" [RFC1131]
defined OSPF, which uses Link State Advertisements (LSAs) in order to defined OSPF, 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. While
these and other routing protocols can utilize "Link Up" and "Link these and other routing protocols can utilize "Link Up" and "Link
Down" indications provided by those links that support them, they Down" indications provided by those links that support them, they
also can detect link loss based on loss of routing packets. As noted also can detect link loss based on loss of routing packets. As noted
in "Requirements for IP Version 4 Routers" [RFC1812]: 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
skipping to change at page 6, line 4 skipping to change at page 6, line 13
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 attainable asymmetry, intermittent frame loss or rapid changes in throughput due
data rate due to interference or signal fading. In both wired and to interference or signal fading. In both wired and wireless links,
wireless links, the link state may rapidly flap between the "up" and the link state may rapidly flap between the "up" and "down" states.
"down" states. This real world behavior presents challenges to the This real world behavior presents challenges to the integration of
integration of link indications with the Internet, Transport and link indications with the Internet, Transport and Application layers.
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 which 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. change detection.
In this model, it is assumed that the link layer provides indications In this model, it is assumed that the link layer provides indications
to higher layers primarily in the form of abstract indications that to higher layers primarily in the form of abstract indications that
skipping to change at page 6, line 39 skipping to change at page 6, line 47
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 DHCP [RFC2131][RFC3315], Router routing table may be determined from DHCP [RFC2131][RFC3315], Router
Advertisements [RFC1256][RFC2461], re-direct messages or route Advertisements [RFC1256][RFC2461], re-direct messages or route
updates incorporating information on the state of links multiple hops updates incorporating information on the state of links multiple hops
away. away.
The Internet layer also utilizes link indications in order to
optimize aspects of Internet Protocol (IP) configuration and
mobility. After receipt of a "Link Up" indication, hosts validate
potential IP configurations by Detecting Network Attachment (DNA)
[RFC4436]. Once the IP configuration is confirmed, it may be
determined that an address change has occurred. However, "Link Up"
indications may not result in a change to Internet layer
configuration.
In "Detecting Network Attachment in IPv4" [RFC4436], after receipt of
a "Link Up" indication, potential IP configurations are validated
using a bi-directional reachability test. In "Detecting Network
Attachment in IPv6 Networks (DNAv6)" [DNAv6] IP configuration is
validated using reachability detection and Router
Solicitation/Advertisement.
The routing sub-layer may utilize link indications in order to enable
more rapid response to changes in link state and effective
throughput.
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
skipping to change at page 7, line 34 skipping to change at page 7, line 21
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 bi-directional reachability has been
confirmed. confirmed.
Link rate is often used in computing routing metrics. For wired As described in "Packetization Layer Path MTU Discovery" [PMTUDRFC],
networks, the rate is typically constant. However for wireless the Internet layer may maintain a path information cache, enabling
networks, the negotiated rate and frame loss may change with link sharing of path MTU information between concurrent or subsequent
conditions so that effective throughput may vary on a packet by connections. The shared cache is accessed and updated by
packet basis. In such situations, routing metrics may also exhibit packetization protocols implementing packetization layer path MTU
rapid variation. discovery.
The Internet layer also utilizes link indications in order to
optimize aspects of Internet Protocol (IP) configuration and
mobility. After receipt of a "Link Up" indication, hosts validate
potential IP configurations by Detecting Network Attachment (DNA)
[RFC4436]. Once the IP configuration is confirmed, it may be
determined that an address change has occurred. However, "Link Up"
indications may not necessarily result in a change to Internet layer
configuration.
In "Detecting Network Attachment in IPv4" [RFC4436], after receipt of
a "Link Up" indication, potential IP configurations are validated
using a bi-directional reachability test. In "Detecting Network
Attachment in IPv6 Networks (DNAv6)" [DNAv6] IP configuration is
validated using reachability detection and Router
Solicitation/Advertisement.
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Application | |
Layer | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
^ ^ ^
! ! !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-!-+-+-!-+-!-+-+-+-+
| ! ! ! |
| ! ^ ^ |
| Connection Management ! ! Teardown |
Transport | ! ! |
Layer +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-!-+-+-!-+-+-+-+-+-+
| ! ! |
| ! ! |
| ^ ! |
| Transport Parameter Estimation ! |
|(MSS, RTT, RTO, cwnd, bw, ssthresh)! |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-!-+-+-+-+-+-+
^ ^ ^ ^ ^ !
! ! ! ! ! !
+-!-+-!-+-+-+-+-+-!-+-+-+-!-+-!-+-+-!-+-+-+-+-+-+
| ! ! Incoming !MIP ! ! ! |
| ! ! Interface !BU ! ! ! |
| ! ! Change !Receipt! ! ! |
| ! ^ ^ ^ ! ^ |
Internet | ! ! Mobility ! ! ! ! |
Layer +-!-+-!-+-+-+-+-+-!-+-+-+-!-+-!-+-+-!-+-+-+-+-+-+
| ! ! Outgoing ! Path ! ! ! |
| ! ! Interface ! Change! ! ! |
| ! ^ Change ^ ^ ! ^ |
| ! ! ! ! |
| ^ Routing ! ! ! |
+-!-+-+-+-+-+-+-+-+-+-+-+-!-+-!-+-+-!-+-+-+-+-+-+
| ! ! v ! IP |
| ! ! Path ! Address |
| ! IP Configuration ^ Info ^ Config/ |
| ! ! Cache Changes |
+-!-+-+-+-+-+-+-+-+-+-+-+-!-+-+-+-+-+-+-+-+-+-+-+
! !
! !
+-!-+-+-+-+-+-+-+-+-+-+-+-!-+-+-+-+-+-+-+-+-+-+-+
| ! ! |
Link | v ^ |
Layer | Rate, FER, Link |
| Delay Up/Down |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 1. Layered Indication Model
The routing sub-layer may utilize link indications in order to enable
more rapid response to changes in link state and effective
throughput. Link rate is often used in computing routing metrics.
However, in wired networks the transmission rate may be negotiated in
order to enhance energy efficiency [EfficientEthernet]. In wireless
networks, the negotiated rate and Frame Error Rate (FER) may change
with link conditions so that effective throughput may vary on a
packet by packet basis. In such situations, routing metrics may also
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 link rate or frame loss do not link indications such as changes in transmission rate or frame loss
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 by running a routing protocol, receipt of a mechanisms, such as receipt of updates from a routing protocol,
Router Advertisement, dead gateway detection [RFC816] or network receipt of a Router Advertisement, dead gateway detection [RFC816] or
unreachability detection [RFC2461], ICMP re-directs, or a change in network unreachability detection [RFC2461], ICMP re-directs, or a
the IP TTL of received packets. A change in the outgoing interface change in the IP TTL of received packets. A change in the outgoing
may in turn influence the mobility sub-layer, causing a change in the interface may in turn influence the mobility sub-layer, causing a
incoming interface. The mobility sub-layer may also become aware of change in the incoming interface. The mobility sub-layer may also
a change in the incoming interface of a peer (via receipt of a Mobile become aware of a change in the incoming interface of a peer (via
IP binding update). receipt of a Mobile IP binding update).
1.4.2. Transport Layer 1.4.2. Transport Layer
The Transport layer processes link indications differently for the The Transport layer processes received link indications differently
purposes of transport parameter estimation and connection management. for the purposes of transport parameter estimation and connection
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 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
bottleneck bandwidth is already much lower than the link rate, an bandwidth of the bottleneck on the end-to-end path is already much
increase in link rate may not materially affect path properties. As lower than the transmission rate, an increase in transmission rate
described in Appendix A.3, the algorithms for utilizing link layer may not materially affect path properties. As described in Appendix
indications to improve transport parameter estimates are still under A.3, the algorithms for utilizing link layer indications to improve
development. transport parameter estimates are still under development.
For the purposes of transport parameter estimation, strict layering For the purposes of transport parameter estimation, strict layering
considerations do not apply since they may hide useful information. considerations do not apply since they may hide useful information.
For example, the Transport layer may utilize the receipt of a "Link For example, if the Transport layer can determine that link
Down" indication followed by a subsequent "Link Up" indication to indication came from a link forming part of the path, it may utilize
infer the possibility of non-congestive packet loss during the period the receipt of a "Link Down" indication followed by a subsequent
between the indications, even if the IP configuration does not change "Link Up" indication to infer the possibility of non-congestive
as a result, so that no Internet layer indication would be sent. packet loss during the period between the indications, even if the IP
configuration does not change as a result, so that no Internet layer
indication would be sent.
For the purposes of parameter estimation, the Transport layer may For the purposes of parameter estimation, the Transport layer may
also wish to use Internet layer indications. For example, path also wish to use Internet layer indications. For example, path
change indications can be used as a signal to reset parameter change indications can be used as a signal to reset parameter
estimates. Changes in the routing table may also be useful; loss of estimates. Changes in the routing table may also be useful; loss of
segments sent to a destination with no prefix in the routing table segments sent to a destination with no prefix in the routing table
may be assumed to be due to causes other than congestion, regardless may be assumed to be due to causes other than congestion, regardless
of the reason for the removal (either because local link conditions of the reason for the removal (either because local link conditions
caused it to be removed or because the route was withdrawn by a caused it to be removed or because the route was withdrawn by a
remote router). remote router).
skipping to change at page 10, line 6 skipping to change at page 11, line 31
[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 "Path MTU Discovery" [RFC1191] was Set). Since hosts implementing classical ICMP-based path MTU
use Destination Unreachable code 4, they do not treat this as a hard Discovery [RFC1191] use Destination Unreachable code 4, they do not
error condition. treat this as a hard error condition. Hosts implementing "Path MTU
Discovery for IP version 6" [RFC1981] utilize ICMPv6 Packet Too Big
messages. As noted in "TCP Problems with Path MTU Discovery"
[RFC2923], classical path MTU discovery is vulnerable to failure if
ICMP messages are not delivered or processed. In order to address
this problem, "Packetization Layer Path MTU Discovery" [PMTUDRFC]
does depend on the delivery of ICMP messages.
However, "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 reason that error messages are difficult to interpret is that, The reason that error messages are difficult to interpret is that,
as discussed above, after a failure of a gateway or network, there as discussed above, after a failure of a gateway or network, there
is a transient period during which the gateways may have incorrect is a 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 when the gateways are trying to find a new route. To period when the gateways are trying to find a new route. To
skipping to change at page 10, line 50 skipping to change at page 12, line 33
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.
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. The Transport layer may also provide such as connection teardown.
indications to the link layer. For example, where the link layer
retransmission timeout is significantly less than the path round-trip
timeout, the Transport layer may wish to control the maximum number
of times that a link layer frame may be retransmitted, so that the
link layer does not continue to retransmit after a Transport layer
timeout.
In IEEE 802.11, this can be achieved by adjusting the Management The Transport layer may also provide indications to the link layer.
Information Base (MIB) variables dot11ShortRetryLimit (default: 7) For example, where the link layer retransmission timeout is
and dot11LongRetryLimit (default: 4), which control the maximum significantly less than the path round-trip timeout, the Transport
number of retries for frames shorter and longer in length than layer may wish to control the maximum number of times that a link
layer frame may be retransmitted, so that the link layer does not
continue to retransmit after a Transport layer timeout. In IEEE
802.11, this can be achieved by adjusting the Management Information
Base (MIB) variables dot11ShortRetryLimit (default: 7) and
dot11LongRetryLimit (default: 4), which control the maximum number of
retries for frames shorter and longer in length than
dot11RTSThreshold, respectively. However, since these variables dot11RTSThreshold, respectively. However, since these variables
control link behavior as a whole they cannot be used to separately control link behavior as a whole they cannot be used to separately
adjust behavior on a per-transport connection basis. In situations adjust behavior on a per-transport connection basis. In situations
where the link layer retransmission timeout is of the same order as where the link layer retransmission timeout is of the same order as
the path round trip timeout, link layer control may not be possible the path round trip timeout, link layer control may not be possible
at all. at all.
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 link rate may not be indications instead. Similarly, changes in the transmission rate may
relevant to applications if the bottleneck bandwidth does not change; not be relevant to applications if the bottleneck bandwidth on the
the transport layer is best equipped to determine this. As a result, path does not change; the transport layer is best equipped to
Figure 1 does not indicate link indications being provided directly determine this. As a result, Figure 1 does not indicate link
to applications. indications being provided directly to applications.
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Application | |
Layer | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
^ ^ ^
! ! !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-!-+-+-!-+-!-+-+-+-+
| ! ! ! |
| ! ^ ^ |
| Connection Management ! ! Teardown |
Transport | ! ! |
Layer +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-!-+-+-!-+-+-+-+-+-+
| ^ ! |
| Rate ! |
| ! |
| Transport Parameter Estimation ! |
|(MTU, RTT, RTO, cwnd, bw, ssthresh)! |
+-!-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-!-+-+-+-+-+-+
^ ^ ^ ^ !
! ! ! ! !
+-!-+-!-+-+-+-+-+-!-+-+-+-!-+-+-+-+-!-+-+-+-+-+-+
| ! ! Incoming !MIP ! ! |
| ! ! Interface !BU ! ! |
| ! ! Change !Receipt! ! |
| ! ^ ^ ^ ^ |
Internet | ! ! Mobility ! ! ! |
Layer +-!-+-!-+-+-+-+-+-!-+-+-+-!-+-+-+-+-!-+-+-+-+-+-+
| ! ! Outgoing ! Path ! ! |
| ! ! Interface ! Change! ! |
| ! ^ Change ^ ^ ^ |
| ! ! ! |
| ^ Routing ! ! |
+-!-+-+-+-+-+-+-+-+-+-+-+-!-+-+-+-+-!-+-+-+-+-+-+
| ! ! ! IP |
| ! ! ! Address |
| ! IP Configuration ^ ^ Config/ |
| ! ! Changes |
+-!-+-+-+-+-+-+-+-+-+-+-+-!-+-+-+-+-+-+-+-+-+-+-+
! !
! !
+-!-+-+-+-+-+-+-+-+-+-+-+-!-+-+-+-+-+-+-+-+-+-+-+
| ! ! |
Link | ^ ^ |
Layer | Rate, FER, Link |
| Delay Up/Down |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 1. Layered Indication Model
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:
[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 limit
the potential damage from link indications determined to be invalid the potential damage from link indications determined to be invalid
after they have been acted on (Section 2.3.2). 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 order
to maintain link independence (Section 2.6). 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 link
indications are utilized directly by multiple layers of the stack indications are utilized directly by multiple layers of the stack
(Section 2.7). (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 interoperability
and introducing link layer dependencies into the Internet and and introducing link layer dependencies into the Internet and
Transport layers (Section 2.8). 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 host
need to carefully consider the layering, security and transport need to carefully consider the layering, security and transport
implications (Section 2.9). implications (Section 2.9).
2.1. Model Validation 2.1. Model Validation
Proposals should avoid use of link models in circumstances where they Proposals should avoid the use of link models in circumstances where
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],
skipping to change at page 15, line 9 skipping to change at page 15, line 25
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 low
frame loss in both directions and are ready to send and receive frame loss in both directions and are ready to send and receive
data frames; links in the "down" state are unsuitable for sending data frames; links in the "down" state are unsuitable for sending
and receiving data frames in either direction. Therefore, a link and receiving data frames in either direction. Therefore, a link
providing a "Link Up" indication will typically experience low providing a "Link Up" indication will typically experience low
frame loss in both directions, and high frame loss in any direction frame loss in both directions, and high frame loss in any direction
can only be experienced after a link provides a "Link Down" can only be experienced after a link provides a "Link Down"
indication. However, these assumptions may not hold true for indication. However, these assumptions may not hold true for
skipping to change at page 15, line 36 skipping to change at page 16, line 5
Specifications utilizing a "Link Up" indication should not assume Specifications utilizing a "Link Up" indication should not assume
that receipt of this indication means that the link is experiencing that receipt of this indication means that the link is experiencing
symmetric link conditions or low frame loss in either direction. symmetric link conditions or low frame loss in either direction.
In general, a "Link Up" event should not be sent due to transient In general, a "Link Up" event should not be sent due to transient
changes in link conditions, but only due to a change in link layer changes in link conditions, but only due to a change in link layer
state. It is best to assume that a "Link Up" event may not be sent state. It is best to assume that a "Link Up" event may not be sent
in a timely way. Large handoff latencies can result in a delay in in a timely way. Large handoff latencies can result in a delay in
the generation of a "Link Up" event as movement to an alternative the generation of a "Link Up" event as movement to an alternative
point of attachment is delayed. 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 interference,
signal strength and signal/noise ratio (SNR) may vary rapidly over signal strength and signal/noise ratio (SNR) may vary rapidly over
a short distance, causing erratic behavior of link indications a short distance, causing erratic behavior of link indications
based on unfiltered measurements. As noted in [Haratcherev], based on unfiltered measurements. As noted in [Haratcherev],
signal strength may prove most useful when utilized in combination signal strength may prove most useful when utilized in combination
with other measurements, such as frame loss. 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. By
design, the "Link Up" and "Link Down" events relate to changes in design, the "Link Up" and "Link Down" events relate to changes in
the state of the link layer that make it able and unable to the state of the link layer that make it able and unable to
communicate IP packets. These changes are either generated by the communicate IP packets. These changes are either generated by the
link layer state machine based on link layer exchanges (e.g. link layer state machine based on link layer exchanges (e.g.
completion of the IEEE 802.11i four-way handshake for "Link Up", or completion of the IEEE 802.11i four-way handshake for "Link Up", or
receipt of a PPP LCP-Terminate for "Link Down") or by protracted receipt of a PPP LCP-Terminate for "Link Down") or by protracted
frame loss, so that the link layer concludes that the link is no frame loss, so that the link layer concludes that the link is no
longer usable. As a result, these link indications are typically longer usable. As a result, these link indications are typically
less sensitive to changes in transient link conditions. 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 that
if sent, that it will be received in a timely way. A good link if sent, that 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 failure
(such as by tracking missing Beacons) while sending a "Link Down" (such as by tracking missing Beacons) while sending a "Link Down"
event only when it concludes the link is unusable, not due to event only when it concludes the link is unusable, not due to
transient frame loss. transient frame loss.
However, existing wireless LAN implementations often do not do a However, existing wireless LAN implementations often do not do a good
good job of detecting link failure. During a lengthy detection job of detecting link failure. During a lengthy detection phase, a
phase, a "Link Down" event is not sent by the link layer, yet IP "Link Down" event is not sent by the link layer, yet IP packets
packets cannot be transmitted or received on the link. Initiation cannot be transmitted or received on the link. Initiation of a scan
of a scan may be delayed so that the station cannot find another may be delayed so that the station cannot find another point of
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. which 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:
a. Implementation Variation Implementation Variation
b. Recovery from invalid indications Recovery from invalid indications
c. 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 multi-
hop IEEE 802.11 ad-hoc network. In most cases, links that are very hop IEEE 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.
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 bi-directional
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 bi-directional
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 antennas may may be used to reduce potential disruptions. Multiple transmitting
be used to reduce multi-path effects; rate adaptation can be used to and receiving antennas may be used to reduce multi-path effects;
determine if a lower rate will be more satisfactory; transmit power transmission rate adaptation can be used to find a more satisfactory
adjustment can be used to improve signal quality and reduce transmission rate; transmit power adjustment can be used to improve
interference; RTS/CTS signaling can be used to address hidden node signal quality and reduce interference; Ready-to-Send/Clear-to-Send
problems. However, these techniques may not be completely effective. (RTS/CTS) signaling can be used to reduce hidden node problems.
As a result, periods of high frame loss may be encountered, causing These techniques may not be completely effective, so that high frame
the link to cycle between "up" and "down" states. loss may be encountered, causing the link to cycle between "up" and
"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" forcing a given action. (advisory in nature), rather than a "trigger" dictating a particular
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 bi-directional 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, bi-directional reachability is confirmed prior to
activation of an IP configuration. However, where a link exhibits an activation of an IP configuration. However, where a link exhibits an
intermediate loss rate, demonstration of bi-directional reachability intermediate loss rate, demonstration of bi-directional 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.
skipping to change at page 18, line 5 skipping to change at page 18, line 24
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 [RFC4436] reachability tests are carried out coincident with a In DNAv4 [RFC4436], reachability tests are carried out coincident
request for configuration via DHCP. Therefore if the bi-directional with a request for configuration via DHCP. Therefore if the bi-
reachability test times out, the host can still obtain an IP directional reachability test times out, the host can still obtain an
configuration via DHCP, and if that fails, the host can still IP configuration via DHCP, and if that fails, the host can still
continue to use an existing valid address if it has one. 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 MTU, RTT, RTO, congestion recovered transport parameters (such as the MSS, RTT, RTO, congestion
window, etc.) should be demonstrated to remain valid. Congestion window, etc.) should be demonstrated to remain valid. Congestion
window validation is discussed in [RFC2861]. window validation is discussed in "TCP 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
implementations would wait five minutes before attempting to obtain a implementations would wait five minutes before attempting to obtain a
routable address after assigning an IPv4 Link-Local address. In one routable address after assigning an IPv4 Link-Local address. In one
implementation, it was observed that where mobile hosts changed their implementation, it was observed that where mobile hosts changed their
point of attachment more frequently than every five minutes, they point of attachment more frequently than every five minutes, they
would never obtain a routable address. would never obtain a routable address. The problem was caused by an
invalid link indication (signaling of "Link Up" prior to completion
The problem was caused by an invalid link indication (signaling of of link layer authentication), resulting in an initial failure to
"Link Up" prior to completion of link layer authentication), obtain a routable address using DHCP. As a result, [RFC3927]
resulting in an initial failure to obtain a routable address using recommends against modification of the maximum retransmission timeout
DHCP. As a result, [RFC3927] recommends against modification of the (64 seconds) provided in [RFC2131].
maximum retransmission timeout (64 seconds) provided in [RFC2131].
2.3.3. Damping and Hysteresis 2.3.3. Damping and Hysteresis
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 performance, including changes in the encounter rapid changes in link characteristics, including changes in
negotiated rate, frame loss and even "Link Up"/"Link Down" transmission rate, throughput, frame loss and even "Link Up"/"Link
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
skipping to change at page 19, line 27 skipping to change at page 19, line 51
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:
[a] 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).
[b] 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".
[c] 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.
[d] 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.
Note that "conservation of packets" may not be sufficient to avoid As noted in "Robust Rate Adaptation for 802.11 Wireless Networks"
congestive collapse in the link layer. Where rate adjustment is [Robust], decreasing transmission rate in response to frame loss
based on frame loss, it is necessary to demonstrative stability in increases contention, potentially leading to congestive collapse. To
the face of congestion. Implementations that rapidly decrease the avoid this, the link layer needs to distinguish frame loss due to
negotiated rate in response to frame loss can cause congestive congestion from loss due to channel conditions. Only frame loss due
collapse in the link layer, even where exponential backoff is to deterioration in channel conditions can be used as a basis for
implemented. For example, an implementation that decreases rate by a decreasing transmission rate.
factor of two while backing off the retransmission timer by a factor
of two has not reduced the link utilization. While such an
implementation might demonstrate "conservation of packets" it does
not conserve transmission resources.
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
skipping to change at page 20, line 34 skipping to change at page 21, line 8
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"
indication in this manner is unwise since the interface may not yet indication in this manner is unwise since the interface may not yet
even have an operable Internet layer configuration. Instead, an "IP even have an operable Internet layer configuration. Instead, an "IP
address configured" indication may be utilized. address configured" indication may be utilized.
2.5. Effectiveness 2.5. Effectiveness
Proposals must demonstrate the effectiveness of proposed Proposals must demonstrate the effectiveness of proposed
optimizations. Since optimizations typically carry a burden of optimizations. Since optimizations typically increase complexity,
increased complexity, substantial performance improvement is required substantial performance improvement is required in order to make a
in order to make a compelling case. compelling case.
In the face of unreliable link indications, effectiveness may In the face of unreliable link indications, effectiveness may depend
strongly depend on the penalty for false positives and false on the penalty for false positives and false negatives. In the case
negatives. In the case of DNAv4 [RFC4436], the benefits of of DNAv4 [RFC4436], the benefits of successful optimization are
successful optimization are modest, but the penalty for being unable modest, but the penalty for being unable to confirm an operable
to confirm an operable configuration is a lengthy timeout. As a configuration is a lengthy timeout. As a result, the recommended
result, the recommended strategy is to test multiple potential strategy is to test multiple potential configurations in parallel in
configurations in parallel in addition to attempting configuration addition to attempting configuration via DHCP. This virtually
via DHCP. This virtually guarantees that DNAv4 will always result in guarantees that DNAv4 will always result in performance equal to or
performance equal to or better than use of DHCP alone. better than use of DHCP alone.
2.6. Interoperability 2.6. Interoperability
While link indications can be utilized where available, they should While link indications can be utilized where available, they should
not be required by upper layers, in order to maintain link layer not be required by upper layers, in order to maintain link layer
independence. For example, if link layer prefix hints are provided, independence. For example, if link layer prefix hints are provided,
hosts not understanding those hints must still be able to obtain an hosts not understanding those hints must still be able to obtain an
IP address. IP address.
Where link indications are proposed to optimize Internet layer Where link indications are proposed to optimize Internet layer
configuration, proposals must demonstrate that they do not compromise configuration, proposals must demonstrate that they do not compromise
robustness by interfering with address assignment or routing protocol robustness by interfering with address assignment or routing protocol
behavior, making address collisions more likely, or compromising behavior, making address collisions more likely, or compromising
Duplicate Address Detection (DAD). Duplicate Address Detection (DAD) [RFC4429].
To avoid compromising interoperability in the pursuit of performance To avoid compromising interoperability in the pursuit of performance
optimization, proposals must demonstrate that interoperability optimization, proposals must demonstrate that interoperability
remains possible (potentially with degraded performance) even if one remains possible (potentially with degraded performance) even if one
or more participants do not implement the proposal. or more participants do not implement the proposal.
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. Similarly, as noted in "Application- link indications directly.
oriented Link Adaptation of IEEE 802.11" [Haratcherev2] there are
situations in which applications may also wish to consume link
indications.
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 for the original interface (MTU, congestion state) may no parameters estimated for the original outgoing and incoming paths
longer be valid for the new outgoing and incoming paths. (congestion state, Maximum Segment Size (MSS) derived from the link
maximum transmission unit (MTU) or path MTU) may no longer be valid
for the new outgoing and incoming paths.
To avoid race conditions, the following measures are recommended: To avoid race conditions, the following measures are recommended:
a. Path change re-estimation Path change re-estimation
b. Layering Layering
c. Metric consistency Metric consistency
2.7.1. Path Change Re-estimation 2.7.1. Path Change Re-estimation
When the Internet layer detects a path change, such as a change in When the Internet layer detects a path change, such as a major change
the outgoing or incoming interface of the host or the incoming in transmission rate, a change in the outgoing or incoming interface
interface of a peer, or perhaps even a substantial change in the TTL of the host or the incoming interface of a peer, or perhaps even a
of received IP packets, it may be worth considering whether to reset substantial change in the TTL of received IP packets, it may be worth
transport parameters (RTT, RTO, cwnd, MTU) to their initial values so considering whether to reset transport parameters (RTT, RTO, cwnd,
as to allow them to be re-estimated. This ensures that estimates bw, MSS) to their initial values so as to allow them to be re-
based on the former path do not persist after they have become estimated. This ensures that estimates based on the former path do
invalid. Appendix A.3 summarizes the research on this topic. not persist after they have become invalid. Appendix A.3 summarizes
the research on this topic.
2.7.2. Layering 2.7.2. Layering
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. Since abstraction that is independent of link layer technologies.
one of the major objectives of the Internet layer is maintaining link
layer independence, upper layers relying on Internet layer
indications rather than consuming link indications directly can avoid
link layer dependencies.
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
skipping to change at page 23, line 8 skipping to change at page 23, line 26
Once a link is in the "up" state, its effectiveness in transmission Once a link is in the "up" state, its effectiveness in transmission
of data packets can be used to determine an appropriate routing of data packets can be used to determine an appropriate routing
metric. In situations where the transmission time represents a large metric. In situations where the transmission time represents a large
portion of the total transit time, minimizing total transmission time portion of the total transit time, minimizing total transmission time
is equivalent to maximizing effective throughput. "A High-Throughput is equivalent to maximizing effective throughput. "A High-Throughput
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 negotiated 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 negotiated rate may vary, ETX may not represent a However, where the transmission rate may vary, ETX may not represent
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 authors
define a new metric called Expected Transmission Time (ETT). This is define a new metric called Expected Transmission Time (ETT). This is
described as a "bandwidth adjusted ETX" since ETT = ETX * S/B where S described as a "bandwidth adjusted ETX" since ETT = ETX * S/B where S
is the size of the probe packet and B is the bandwidth of the link as is the size of the probe packet and B is the bandwidth of the link as
measured by a packet pair [Morgan]. However, ETT assumed that the measured by a packet pair [Morgan]. However, ETT assumes that the
loss fraction of small probe frames sent at 1 Mbps data rate is loss fraction of small probe frames sent at 1 Mbps data rate is
indicative of the loss fraction of larger data frames at higher 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 under-estimate 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 data metric further by estimating the loss fraction as a function of
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 be easily be predicted. As noted in routing metric may not be easily be predicted. As noted in
[Shortest], a link that can successfully transmit the short frames [Shortest], a link that can successfully transmit the short frames
utilized for control, management or routing may not necessarily be utilized for control, management or routing may not necessarily be
able to reliably transport larger data packets. The rate adaptation able to reliably transport larger data packets.
techniques utilized in [Haratcherev] require data to be accumulated
on signal strength and rates based on successful and unsuccessful
transmissions. However, this data will not be available before a
link is used for the first time.
Therefore it may be necessary to utilize alternative metrics (such as Therefore it may be necessary to utilize alternative metrics (such as
signal strength or access point load) in order to assist in 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, signal strength and frame loss may be used by Within the link layer, metrics such as signal strength and frame loss
a host to determine the optimum rate, as well as to determine when to may be used to determine the transmission rate, as well as to
select an alternative point of attachment. In order to enable determine when to select an alternative point of attachment. In
stations to roam prior to encountering packet loss, studies such as order to enable stations to roam prior to encountering packet loss,
studies such as
"An experimental study of IEEE 802.11b handover performance and its "An experimental study of IEEE 802.11b handover performance and its
effect on voice traffic" [Vatn] have suggested using signal strength effect on voice traffic" [Vatn] have suggested using signal strength
as a mechanism for more rapidly detecting loss of connectivity, as a mechanism to more rapidly detect loss of connectivity, rather
rather than frame loss, as suggested in "Techniques to Reduce IEEE than frame loss, as suggested in "Techniques to Reduce IEEE 802.11b
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 negotiated rate, due to the potential predictors of frame loss or throughput, due to the potential effects
effects of multi-path interference. As a result a link brought up of multi-path interference. As a result a link brought up due to
due to good signal strength may subsequently exhibit significant good signal strength may subsequently exhibit significant frame loss,
frame loss, and a low negotiated rate. Similarly, an AP and a low throughput. Similarly, an AP demonstrating low utilization
demonstrating low utilization may not necessarily be the best choice, may not necessarily be the best choice, since utilization may be low
since utilization may be low due to hardware or software problems. due to hardware or software problems. "OSPF Optimized Multipath
"OSPF Optimized Multipath (OSPF-OMP)" [Villamizar] notes that link (OSPF-OMP)" [Villamizar] notes that link utilization-based routing
utilization-based routing metrics have a history of instability, so metrics have a history of instability.
that they are rarely deployed.
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 re-establishment; 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 EAP exchange may be used for For example, in [EAPIKEv2], a link layer Extensible Authentication
the purpose of IP address assignment, potentially bypassing Internet Protocol (EAP) [RFC3748] exchange may be used for the purpose of IP
layer configuration. Within [PEAP], it is proposed that a link layer address assignment, potentially bypassing Internet layer
EAP exchange be used for the purpose of carrying Mobile IPv6 Binding configuration. Within [PEAP], it is proposed that a link layer EAP
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,
skipping to change at page 25, line 18 skipping to change at page 25, line 32
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. For example, by utilizing the local routing parameter estimates. While absence of positive feedback that the
table, the Transport layer can determine that segment loss was due to path is sending data end-to-end must be heeded, where a route that
loss of a route, not congestion. While this enables transported link had previously been absent is recovered, this may be used to trigger
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 are
preferred to explicit transport of link indications since they do preferred to explicit transport of link indications since they do
not require participation in the routing mesh, add no new packets not require participation in the routing mesh, add no new packets
in times of network distress, operate more reliably in the presence in times of network distress, operate more reliably in the presence
of middle boxes such as NA(P)Ts, are more likely to be backward of middle boxes such as NA(P)Ts, are more likely to be backward
compatible, and are less likely to result in security compatible, and are less likely to result in security
vulnerabilities. As a result, explicit signaling proposals must vulnerabilities. As a result, explicit signaling proposals must
prove that implicit signals are inadequate. prove that implicit signals are inadequate.
[b] Mitigation of security vulnerabilities. Transported link (b) Mitigation of security vulnerabilities. Transported link
indications that modify the local routing table represent routing indications should not introduce new security vulnerabilities.
protocols, and unless security is provided they will introduce the Link indications that result in modifications to the local routing
vulnerabilities associated with unsecured routing protocols. For table represent a routing protocol, so that the vulnerabilities
example, unless schemes such as SEND [RFC3971] are used, a host associated with unsecured routing protocols apply, including
receiving a link indication from a router will not be able to spoofing by off-link attackers. While mechanisms such as "SEcure
authenticate the indication. Where indications can be transported Neighbor Discovery (SEND)" [RFC3971] may enable authentication and
over the Internet, this allows an attack to be launched without integrity protection of router-originated messages, protecting
requiring access to the link. against forgery of transported 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 link
indication can be authenticated, if the indication is sent by a indication can be integrity protected and authenticated, if the
host off the local link, it may not be clear that the sender is on indication is sent by a host off the local link, it may not be
the actual path in use, or which transport connection(s) the clear that the sender is on the actual path in use, or which
indication relates to. Proposals need to describe how the transport connection(s) the indication relates to. Proposals need
receiving host can validate the transported link indication. to describe how the receiving host can validate the transported
link indication.
[d] Mapping of Identifiers. When link indications are transported, it (d) Mapping of Identifiers. When link indications are transported, it
is generally for the purposes of saying something about Internet, is generally for the purposes of providing information about
Transport or Application layer operations at a remote element. Internet, Transport or Application layer operations at a remote
These layers use different identifiers, and so it is necessary to element. However application layer sessions or transport
match the link indication with relevant higher layer state. connections may not be visible to the remote element due to factors
Therefore proposals need to demonstrate how the link indication can such as load sharing between links, or use of IPsec, tunneling
be mapped to the right higher layer state. For example, if a protocols or nested headers. As a result, proposals need to
presence server is receiving remote indications of "Link Up"/"Link demonstrate how the link indication can be mapped to the relevant
Down" status for a particular MAC address, the presence server will higher layer state. For example, on receipt of a link indication,
need to associate that MAC address with the identity of the user the Transport layer will need to identify the set of transport
(pres:user@example.com) to whom that link status change is sessions (source address, destination address, source port,
relevant. destination port, transport) that are affected. If a presence
server is receiving remote indications of "Link Up"/"Link Down"
status for a particular Media Access Control (MAC) address, the
presence server will need to associate that MAC address with the
identity of the user (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.
At the Link and Internet layers, more work is needed to reconcile More work is needed to understand the connection between link
handoff metrics (e.g. signal strength and link utilization) with
routing metrics based on link indications (e.g. frame loss and
negotiated rate).
More work is also 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. the development of revised routing metrics for ad-hoc networks. More
work is also needed to reconcile handoff metrics (e.g. signal
strength and link utilization) with routing metrics based on link
indications (e.g. frame error rate and negotiated rate).
A better understanding of the relationship between rate negotiation A better understanding of the use of physical and link layer metrics
algorithms and link-layer congestion control is required. For in rate negotiation is required. For example, recent work
example, it is possible that signal strength measurements may be [Robust][CARA] has suggested that frame loss due to contention (which
useful in preventing rapid downward rate negotiation (and congestive would be exacerbated by rate reduction) can be distinguished from
collapse) in situations where frame loss is caused by congestion, not loss due to channel conditions (which may be improved via rate
signal attenuation. 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. For example, it may make sense for the table and path changes. More work is also needed in utilization of
Transport layer to adjust transport parameter estimates in response link layer indications in transport parameter estimation, including
to route loss, "Link Up"/"Link Down" indications and/or frame loss. rate changes, "Link Up"/"Link Down" indications, link layer
This way transport parameters are not adjusted as though congestion retransmissions and frame loss of various types (due to contention or
were detected when loss is occurring due to other factors such as channel conditions).
radio propagation effects or loss of a route (such as can occur on
receipt of a "Link Down" indication).
More work is 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.
More work is also needed on application layer uses of link
indications such as rate and frame loss.
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
security vulnerabilities. These include: security vulnerabilities. These include:
Spoofing Spoofing
Indication validation Indication validation
Denial of service Denial of service
4.1. Spoofing 4.1. Spoofing
skipping to change at page 29, line 22 skipping to change at page 29, line 37
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. establishing radio contact with the target network. However, attacks
that can be mounted from a distance, either by an attacker on another
However, attacks that can be mounted from a distance, either by an point of attachment within the same network or by an off-link
attacker on another point of attachment within the same network, or attacker, expand the level of vulnerability.
by an off-link attacker, greatly expand the level of vulnerability.
By enabling the transport of link indications, it is possible to
transform an attack that might otherwise be restricted to attackers
on the local link into one which can be executed across the Internet.
Similarly, by integrating link indications with upper layers, The transport of link indications can increase risk by enabling
proposals may enable a spoofed link layer frame to consume more vulnerabilities exploitable only by attackers on the local link to be
resources on the host than might otherwise be the case. As a result, executed across the Internet. Similarly, by integrating link
while it is important for upper layers to validate link indications, indications with upper layers, proposals may enable a spoofed link
they should not expend excessive resources in doing so. layer frame to consume more resources on the host than might
otherwise be the case. As a result, while it is important for upper
layers to validate link indications, they should not expend excessive
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, either by generating multiple responses or a
single larger response. For example, link indication proposals single larger response. For example, proposals should not enable
should not enable multiple hosts to respond to a frame with a multiple hosts to respond to a frame with a multicast destination
multicast destination address. address.
5. IANA Considerations 5. IANA Considerations
This document has no actions for IANA. This document has no actions for IANA.
6. References 6. References
6.1. Informative References 6.1. Informative References
[RFC816] Clark, D., "Fault Isolation and Recovery", RFC 816, July [RFC816] Clark, D., "Fault Isolation and Recovery", RFC 816, July
skipping to change at page 30, line 40 skipping to change at page 30, line 50
[RFC1661] Simpson, W., "The Point-to-Point Protocol (PPP)", STD 51, [RFC1661] Simpson, W., "The Point-to-Point Protocol (PPP)", STD 51,
RFC 1661, July 1994. RFC 1661, July 1994.
[RFC1812] Baker, F., "Requirements for IP Version 4 Routers", RFC [RFC1812] Baker, F., "Requirements for IP Version 4 Routers", RFC
1812, June 1995. 1812, June 1995.
[RFC1918] Rekhter, Y., Moskowitz, B., Karrenberg, D., de Groot, D. [RFC1918] Rekhter, Y., Moskowitz, B., Karrenberg, D., de Groot, D.
and E. Lear, "Address Allocation for Private Internets", and E. Lear, "Address Allocation for Private Internets",
RFC 1918, February 1996. RFC 1918, February 1996.
[RFC1981] McCann, J., Deering, S. and J. Mogul, "Path MTU Discovery
for IP version 6", RFC 1981, June 1996.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
[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 [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, BCP
41, September 2000. 41, September 2000.
[RFC2923] Lahey, K., "TCP Problems with Path MTU Discovery", RFC
2923, September 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., et al., "Dynamic Host Configuration Protocol
for IPv6 (DHCPv6)", RFC 3315, July 2003. for IPv6 (DHCPv6)", RFC 3315, July 2003.
[RFC3366] Fairhurst, G. and L. Wood, "Advice to link designers on
link Automatic Repeat reQuest (ARQ)", RFC 3366, August
2002.
[RFC3428] Campbell, B., Rosenberg, J., Schulzrinne, H., Huitema, C. [RFC3428] Campbell, B., Rosenberg, J., Schulzrinne, H., Huitema, C.
and D. Gurle, "Session Initiation Protocol (SIP) 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.
Lefkowetz, "Extensible Authentication Protocol (EAP)",
RFC 3748, June 2004.
[RFC3775] Johnson, D., Perkins, C. and J. Arkko, "Mobility Support [RFC3775] Johnson, D., Perkins, C. and J. Arkko, "Mobility Support
in IPv6", RFC 3775, June 2004. 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, "SEcure
Neighbor Discovery (SEND)", RFC 3971, March 2005. 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.
[RFC4429] Moore, N., "Optimistic Duplicate Address Detection (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
Discovery", draft-ietf-pmtud-method-11, Internet draft
(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",
skipping to change at page 32, line 20 skipping to change at page 32, line 50
[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", draft-ietf-bfd-base-05.txt, Internet draft
(work in progress), June 2006. (work in progress), June 2006.
[Biaz] Biaz, S. and N. Vaidya, "Discriminating Congestion Losses [Biaz] Biaz, S. and N. Vaidya, "Discriminating Congestion Losses
from Wireless Losses Using Interarrival Times at the from Wireless Losses Using Interarrival Times at the
Receiver", Proc. IEEE Symposium on Application-Specific Receiver", Proc. IEEE Symposium on Application-Specific
Systems and Software Engineering and Technology, Systems and Software Engineering and Technology,
Richardson, TX, Mar 1999. Richardson, TX, Mar 1999.
[CARA] Kim, J., Kim, S. and S. Choi, "CARA: Collision-Aware Rate
Adaptation for IEEE 802.11 WLANs", Korean Institute of
Communication Sciences (KICS) Journal, Feb. 2006
[Chandran] Chandran, K., Raghunathan, S., Venkatesan, S. and R. [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 of
the 18th International Conference on Distributed 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-03.txt, Internet draft (DNAv6)", draft-ietf-dna-protocol-04.txt, Internet draft
(work in progress), October 2006. (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 'Link-
Up' Notification", draft-dawkins-trigtran-linkup-01.txt, Up' Notification", draft-dawkins-trigtran-linkup-01.txt,
Internet draft (work in progress), October 2003. Internet draft (work in progress), October 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", draft-tschofenig-
eap-ikev2-12.txt, Internet draft (work in progress), eap-ikev2-12.txt, Internet draft (work in progress),
October 2006. October 2006.
[Eckhardt] Eckhardt, D. and P. Steenkiste, "Measurement and Analysis [Eckhardt] Eckhardt, D. and P. Steenkiste, "Measurement and Analysis
of the Error Characteristics of an In-Building Wireless of the Error Characteristics of an In-Building Wireless
Network", SIGCOMM '96, August 1996, Stanford, CA. 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-213838,
NASA Glenn Research Center, July 2005. NASA Glenn Research Center, July 2005.
[EfficientEthernet]
Gunaratne, C. and K. Christensen, "Ethernet Adaptive Link
Rate: System Design and Performance Evaluation",
Proceedings of the IEEE Conference on Local Computer
Networks, pp. 28-35, November 2006.
[Eggert] Eggert, L., Schuetz, S. and S. Schmid, "TCP Extensions [Eggert] Eggert, L., Schuetz, S. and S. Schmid, "TCP Extensions
for Immediate Retransmissions", draft-eggert-tcpm-tcp- for Immediate Retransmissions", draft-eggert-tcpm-tcp-
retransmit-now-02.txt, Internet draft (work in progress), retransmit-now-02.txt, Internet draft (work in 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 Francisco,
CA. CA.
[ETX] Douglas S. J. De Couto, Daniel Aguayo, John Bicket, and [ETX] Douglas S. J. De Couto, Daniel Aguayo, John Bicket, and
skipping to change at page 35, line 18 skipping to change at page 36, line 5
11: Wireless LAN Medium Access Control (MAC) and Physical 11: Wireless LAN Medium Access Control (MAC) and Physical
Layer (PHY) Specifications - Amendment 7: Radio Resource Layer (PHY) Specifications - Amendment 7: Radio Resource
Management", IEEE 802.11k/D7.0, January 2007. 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, "Draft
Standard for Telecommunications and Information Exchange Standard for Telecommunications and Information Exchange
Between Systems - LAN/MAN Specific Requirements - Part Between Systems - LAN/MAN Specific Requirements - Part
21: Media Independent Handover", IEEE 802.21D0, June 21: Media Independent Handover", IEEE 802.21D0, June
2005. 2005.
[Kamerman] Kamerman, A. and L. Monteban, "Wavelan ii: A [Kamerman] Kamerman, A. and L. Monteban, "WaveLAN II: A High-
highperformance wireless lan for unlicensed band", Bell Performance Wireless LAN for the Unlicensed Band", Bell
Labs Technical Journal, 1997. 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-trigger
method for improving TCP performance over Mobile IPv6", method for improving TCP performance over Mobile IPv6",
draft-kim-tsvwg-butrigger-00.txt, Internet draft (work in draft-kim-tsvwg-butrigger-00.txt, Internet draft (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 axioms
of wireless-network research", Dartmouth College Computer of wireless-network research", Dartmouth College Computer
Science Technical Report TR2003-467, July 2003. Science Technical Report TR2003-467, July 2003.
skipping to change at page 36, line 13 skipping to change at page 36, line 49
mip6-authorization-eap-04.txt, Internet draft (work in mip6-authorization-eap-04.txt, Internet draft (work in
progress), 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 Process",
CS-TR-4395, University of Maryland Department of Computer CS-TR-4395, University of Maryland Department of Computer
Science, September 2002. 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", Technical
Memorandum, AT&T Bell Laboratoies, October 1994. 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", draft-mun-mobileip-layer2-handoff-
mipv4-01.txt, Internet draft (work in progress), March mipv4-01.txt, Internet draft (work in progress), March
2004. 2004.
[PEAP] Palekar, A., Simon, D., Salowey, J., Zhou, H., Zorn, G. [ONOE] Onoe Rate Control,
and S. Josefsson, "Protected EAP Protocol (PEAP) Version http://madwifi.org/browser/trunk/ath_rate/onoe
2", draft-josefsson-pppext-eap-tls-eap-10.txt, Internet
draft (work in progress), October 2004.
[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 802.11/GPRS
Example", draft-daniel-mip6-optimized-vertical- Example", draft-daniel-mip6-optimized-vertical-
handover-00.txt, 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-1113, Anchorage, Alaska, USA, May 2003. 1108-1113, Anchorage, Alaska, USA, May 2003.
[PEAP] Palekar, A., Simon, D., Salowey, J., Zhou, H., Zorn, G.
and S. Josefsson, "Protected EAP Protocol (PEAP) Version
2", draft-josefsson-pppext-eap-tls-eap-10.txt, Internet
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 network
protocols", Proceedings of the IEEE, 75(1), January 1987. 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: An
Optimal Low-Energy Transmission Strategy for IEEE 802.11 Optimal Low-Energy Transmission Strategy for IEEE 802.11
a/h", in Proc. ACM MobiCom'03, San Diego, CA, September a/h", in Proc. ACM MobiCom'03, San Diego, CA, September
2003. 2003.
[RBAR] Holland, G., Vaidya, N. and P. Bahl, "A Rate-Adaptive MAC [RBAR] Holland, G., Vaidya, N. and P. Bahl, "A Rate-Adaptive MAC
Protocol for Multi-Hop Wireless Networks", Proceedings Protocol for Multi-Hop Wireless Networks", Proceedings
ACM MOBICOM, July 2001. 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", Proceedings
of the IEEE InfoCon 2005, March 2005. of the IEEE InfoCon 2005, March 2005.
[Robust] Wong, S., Yang, H ., Lu, S. and V. Bharghavan, "Robust
Rate Adaptation for 802.11 Wireless Networks", ACM
MobiCom'06, Los Angeles, CA, September 2006.
[SampleRate] Bicket, J., "Bit-rate Selection in Wireless networks",
MIT Master's Thesis, 2005.
[Scott] Scott, J., Mapp, G., "Link Layer Based TCP Optimisation [Scott] Scott, J., Mapp, G., "Link Layer Based TCP Optimisation
for Disconnecting Networks", ACM SIGCOMM Computer for Disconnecting Networks", ACM SIGCOMM Computer
Communication Review, 33(5), October 2003. 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.
skipping to change at page 38, line 5 skipping to change at page 39, line 5
[Xylomenos] Xylomenos, G., "Multi Service Link Layers: An Approach to [Xylomenos] Xylomenos, G., "Multi Service Link Layers: An Approach to
Enhancing Internet Performance over Wireless Links", Enhancing Internet Performance over Wireless Links",
Ph.D. thesis, University of California at San Diego, Ph.D. thesis, University of California at San Diego,
1999. 1999.
[Yegin] Yegin, A., "Link-layer Triggers Protocol", draft-yegin- [Yegin] Yegin, A., "Link-layer Triggers Protocol", draft-yegin-
l2-triggers-00.txt, Internet Draft (work in progress), l2-triggers-00.txt, Internet Draft (work in progress),
June 2002. June 2002.
Acknowledgments
The authors would like to acknowledge James Kempf, Phil Roberts,
Gorry Fairhurst, John Wroclawski, Aaron Falk, Sally Floyd, Pekka
Savola, Pekka Nikander, Yogesh Swami, Wesley Eddy and 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.0 Terminology A.0 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 802.11
Distribution System), via the wireless medium (WM) for associated Distribution System), via the wireless medium (WM) for associated
skipping to change at page 39, line 23 skipping to change at page 41, line 23
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 In-
Building Wireless Network" [Eckhardt], the authors characterize the Building Wireless Network" [Eckhardt], the authors characterize the
performance of an AT&T Wavelan 2 Mbps in-building WLAN operating in performance of an AT&T Wavelan 2 Mbps in-building WLAN operating in
Infrastructure mode on the Carnegie-Mellon Campus. In this study, 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 either
be assumed to operate very well or not at all. be assumed to operate very well or not at all.
"Link-level Measurements from an 802.11b Mesh Network" [Aguayo] the In "Link-level Measurements from an 802.11b Mesh Network" [Aguayo],
authors analyze the causes of frame loss in a 38-node urban multi-hop the authors analyze the causes of frame loss in a 38-node urban
802.11 ad-hoc network. In most cases, links that are very bad in multi-hop 802.11 ad-hoc network. In most cases, links that are very
one direction tend to be bad in both directions, and links that are bad in one direction tend to be bad in both directions, and links
very good in one direction tend to be good in both directions. that are very good in one direction tend to be good in both
However, 30 percent of links exhibited loss rates differing directions. However, 30 percent of links exhibited loss rates
substantially in each direction. differing substantially in each direction.
Signal to noise ratio and distance showed little value in predicting Signal to noise ratio and distance showed little value in predicting
loss rates, and rather than exhibiting a step-function transition loss rates, and rather than exhibiting a step-function transition
between "up" (low loss) or "down" (high loss) states, inter-node between "up" (low loss) or "down" (high loss) states, inter-node
loss rates varied widely, demonstrating a nearly uniform distribution loss rates varied widely, demonstrating a nearly uniform distribution
over the range at the lower rates. The authors attribute the over the range at the lower rates. The authors attribute the
observed effects to multi-path fading, rather than attenuation or observed effects to multi-path fading, rather than attenuation or
interference. interference.
The findings of [Eckhardt] and [Aguayo] demonstrate the diversity of The findings of [Eckhardt] and [Aguayo] demonstrate the diversity of
skipping to change at page 43, line 35 skipping to change at page 45, line 35
[RFC2131] or RS/RA may be triggered prior to when the link is usable [RFC2131] or RS/RA may be triggered prior to when the link is usable
by the Internet layer, resulting in configuration delays or failures. by the Internet layer, resulting in configuration delays or failures.
Similarly, Transport layer connections will encounter packet loss, Similarly, Transport layer connections will encounter packet loss,
resulting in back-off of retransmission timers. resulting in back-off 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)"
[RFC3366] provides advice to the designers of digital communication
equipment and link-layer protocols employing link-layer Automatic
Repeat reQuest (ARQ) techniques for IP. It discusses the use of ARQ,
timers, persistency in retransmission and the challenges that arise
from sharing links between multiple flows and in differentiation
transport flow 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 GSM reliable and unreliable link layer modes
can be simultaneously utilized without higher layer control. Where a can be simultaneously utilized without higher layer control. Where a
reliable link layer protocol is required (where reliable transports reliable link layer protocol is required (where reliable transports
such TCP and SCTP are used), the Radio Link Protocol (RLP) can be such TCP and SCTP are used), the Radio Link Protocol (RLP) can be
engaged; with delay sensitive applications such as those based on engaged; with delay sensitive applications such as those based on
UDP, the transparent mode (no RLP) can be used. The authors also UDP, the transparent mode (no RLP) can be used. The authors also
describe how PPP negotiation can be optimized over high latency GSM describe how PPP negotiation can be optimized over high latency GSM
links using "Quickstart-PPP". links using "Quickstart-PPP".
skipping to change at page 44, line 51 skipping to change at page 47, line 10
out of sequence RLP performed best in this scenario. Since the out of sequence RLP performed best in this scenario. Since the
results indicate that no single link layer recovery scheme is optimal results indicate that no single link layer recovery scheme is optimal
for all applications, the authors propose that the link layer for all applications, the authors propose that the link layer
implement multiple recovery schemes. Simulations of the multi- implement multiple recovery schemes. Simulations of the multi-
service architecture showed that the combination of a low-error rate service architecture showed that the combination of a low-error rate
recovery scheme for TCP (such as Karn's RLP) and a low-delay scheme recovery scheme for TCP (such as Karn's RLP) and a low-delay scheme
for UDP traffic (such as out of sequence RLP) provides for good for UDP traffic (such as out of sequence RLP) provides for good
performance in all scenarios. The authors then describe how a multi- performance in all scenarios. The authors then describe how a multi-
service link layer can be integrated with Differentiated Services. service link layer can be integrated with Differentiated Services.
In "Wavelan ii: A highperformance wireless lan for the unlicensed In "WaveLAN-II: A High-Performance Wireless LAN for the Unlicensed
band" [Kamerman] the authors propose a rate adaptation algorithm Band" [Kamerman], the authors propose an open-loop rate adaptation
(ARF) in which the sender adjusts the rate upwards after a fixed algorithm known as Automatic Rate Fallback (ARF). In ARF, the sender
number of successful transmissions, and adjusts the rate downwards adjusts the rate upwards after a fixed number of successful
after one or two consecutive failures. If after an upwards rate transmissions, and adjusts the rate downwards after one or two
adjustment the transmission fails, the rate is immediately readjusted consecutive failures. If after an upwards rate adjustment the
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 rate adaptation approach that requires [RBAR], the authors propose a closed loop rate adaptation approach
incompatible changes to the IEEE 802.11 MAC. In order to enable the that requires incompatible changes to the IEEE 802.11 MAC. In order
sender to better determine the transmission rate, the receiver to enable the sender to better determine the transmission rate, the
determines the packet length and Signal/Noise Ratio (SNR) of a receiver determines the packet length and Signal/Noise Ratio (SNR) of
received RTS frame and calculates the corresponding rate based on a a received RTS frame and calculates the corresponding rate based on a
theoretical channel model, rather than channel usage statistics. The theoretical channel model, rather than channel usage statistics. The
recommended rate is sent back in the CTS frame. This allows the rate recommended rate is sent back in the CTS frame. This allows the rate
(and potentially the transmit power) to be optimized on each (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. However, this approach also utilizes a theoretical model full power. The authors utilize a theoretical channel model rather
rather than determining the model 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.
skipping to change at page 46, line 9 skipping to change at page 48, line 16
algorithm, the authors utilized ns-2 simulations as well as algorithm, the authors utilized ns-2 simulations as well as
implementing a version of AARF adapted to a high latency implementing a version of AARF adapted to a high latency
implementation, the AR 5212 chipset. The Multiband Atheros Driver implementation, the AR 5212 chipset. The Multiband Atheros Driver
for WiFi (MADWIFI) driver enables a fixed schedule of rates and for WiFi (MADWIFI) driver enables a fixed schedule of rates and
retries to be provided when a frame is queued for transmission. The retries to be provided when a frame is queued for transmission. The
adapted algorithm, known as the Adaptive Multi Rate Retry (AMRR), adapted algorithm, known as the Adaptive Multi Rate Retry (AMRR),
requests only one transmission at each of three rates, the last of requests only one transmission at each of three rates, the last of
which is the minimum available rate. This enables adaptation to which is the minimum available rate. This enables adaptation to
short-term fluctuations in the channel with minimal latency. The short-term fluctuations in the channel with minimal latency. The
AMRR algorithm provides performance considerably better than the AMRR algorithm provides performance considerably better than the
existing Madwifi driver and close to that of the RBAR algorithm, existing Madwifi driver.
while enabling practical implementation.
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 the transmission is successful or not. In
order to validate the algorithm, the authors utilized an OPNET order to validate the algorithm, the authors utilized an OPNET
skipping to change at page 46, line 44 skipping to change at page 48, line 50
This technique, which was chosen as the statistics-based technique This technique, which was chosen as the statistics-based technique
in the hybrid scheme, sends a fraction of data at adjacent rates in the hybrid scheme, sends a fraction of data at adjacent rates
in order to estimate which rate provides the maximum throughput. in order to estimate which rate provides the maximum throughput.
Since accurate estimation of throughput requires a minimum number Since accurate estimation of throughput requires a minimum number
of frames to be sent at each rate, and only a fraction of frames of frames to be sent at each rate, and only a fraction of frames
are utilized for this purpose, this technique adapts more slowly are utilized for this purpose, this technique adapts more slowly
at lower rates; with 802.11b rates, the adaptation time scale is at lower rates; with 802.11b rates, the adaptation time scale is
typically on the order of a second. Depending on how many rates typically on the order of a second. Depending on how many rates
are tested, this technique can enable adaptation beyond adjacent are tested, this technique can enable adaptation beyond adjacent
rates. rates. However, where maximum rate and low frame loss are already
being encountered, 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 FER moves above, decrease rate). Since this technique can (if FER moves above, decrease rate). Since this technique can
utilize all the transmitted data, it can respond faster than utilize all the transmitted data, it can respond faster than
maximum throughput techniques. However, there is a tradeoff of maximum throughput techniques. However, there is a tradeoff of
reaction time versus FER estimation accuracy; at lower rates reaction time versus FER estimation accuracy; at lower rates
either reaction times slow or FER estimation accuracy will suffer. either reaction times slow or FER estimation accuracy will suffer.
skipping to change at page 47, line 18 skipping to change at page 49, line 25
can only enable adaptation to adjacent rates. can only enable 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 re-
transmissions. Since fewer packets are required, the sensitivity transmissions. 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 proceeds more slowly since it is based on collection of adaptation proceeds more slowly since it is based on collection of
FERdata. This technique is limited to adaptation to adjacent FERdata. This technique is limited to adaptation to adjacent
rates. rates, and has the disadvantage of potentially worsening frame
loss due to contention.
While statistics-based techniques are robust against short-lived While statistics-based techniques are robust against short-lived link
link quality changes, they do not respond quickly to long-lived quality changes, they do not respond quickly to long-lived changes.
changes. By constraining the rate selected by statistics-based By constraining the rate selected by statistics-based techniques
techniques based on ACK SSI versus rate data (not theoretical based on ACK SSI versus rate data (not theoretical curves), more
curves), more rapid link adaptation was enabled. In order to rapid link adaptation was enabled. In order to ensure rapid
ensure rapid adaptation during rapidly varying conditions, the adaptation during rapidly varying conditions, the rate constraints
rate constraints are tightened when the SSI values are changing are tightened when the SSI values are changing rapidly, encouraging
rapidly, encouraging rate transitions. The authors validated rate transitions. The authors validated their algorithms by
their algorithms by implementing a driver for the Atheros AR5000 implementing a driver for the Atheros AR5000 chipset, and then
chipset, and then testing its response to insertion and removal testing its response to insertion and removal from a microwave oven
from a microwave oven acting as a Faraday cage. The hybrid acting as a Faraday cage. The hybrid algorithm dropped many fewer
algorithm dropped many fewer packets than the maximum throughput packets than the maximum throughput technique by itself.
technique by itself.
In order to estimate the SSI of data at the receiver, the SSI of In order to estimate the SSI of data at the receiver, the ACK SSI was
ACKs received at the sender was used. This approach did not used. This approach does not require the receiver to provide the
require the receiver to provide the sender with the received SSI, sender with the received power, so that it can be implemented without
so that it could be implemented without changing the IEEE 802.11 changing the IEEE 802.11 MAC. Callibration of the rate versus ACK
MAC. This scheme assumes that transmit power remains constant on SSI curves does not require a symmetric channel, but it does require
the sender and receiver and that channel properties in both that channel properties in both directions vary in a proportional way
directions vary slowly, so that the SSI of the received ACKs and and that the ACK transmit power remains constant. The authors
sent data remain in proportion. Actual data was used to determine checked the proportionality assumption and found that the SSI of
the relationship between the ACK SSI and rate, so that the received data correlated highly (74%) with the SSI of received ACKs.
proportion itself does not matter, just as long as it varies Low pass filtering and monotonicity constraints were applied to
slowly. The authors checked the proportionality assumption and remove noise in the rate versus SSI curves. The resulting hybrid
found that the SSI of received data correlated highly (74%) with rate adaptation algorithm demonstrated the ability to respond to
the SSI of received ACKs. Low pass filtering and monotonicity rapid deterioration (and improvement) in channel properties, since it
constraints were applied to remove the considerable noise in the is not restricted to moving to adjacent rates.
SSI versus rate curves.
In "Efficient Mobility Management for Vertical Handoff between In "CARA: Collision-Aware Rate Adaptation for IEEE 802.11 WLANs"
WWAN and WLAN" [Vertical] the authors propose use of signal [CARA], the authors propose Collision-Aware Rate Adaptation (CARA).
strength and link utilization in order to optimize vertical This involves utilization of Clear Channel Assessment (CCA) along
handoff. WLAN to WWAN handoff is driven by SSI decay. When IEEE with adaptation of the Request-to-Send/Clear-to-Send (RTS/CTS)
802.11 SSI falls below a threshold (S1), FFT-based decay detection mechanism to differentiate losses caused by frame collisions from
is undertaken to determine if the signal is likely to continue to losses caused by channel conditions. Rather than decreasing rate as
decay. If so, then handoff to the WWAN is initiated when the the result of frame loss due to collisions, which leads to increased
signal falls below the minimum acceptable level (S2). WWAN to contention, CARA selectively enables RTS/CTS (e.g. after a frame
WLAN handoff is driven by both PHY and MAC characteristics of the loss), reducing the likelihood of frame loss due to hidden stations.
IEEE 802.11 target network. At the PHY layer, characteristics CARA can also utilize CCA to determine whether a collision has
such as SSI are examined to determine if the signal strength is occurred after a transmission; however since CCA may not detect a
greater than a minimum value (S3); at the MAC layer the IEEE significant fraction of all collisions (particularly when
802.11 Network Allocation Vector (NAV) occupation is examined in transmitting at low rate), its use is optional. As compared with
order to estimate the maximum available bandwidth and mean access ARF, in simulations the authors show large improvements in aggregate
delay. Note that depending on the value of S3, it is possible for throughput due to addition of adaptive RTS/CTS, and additional modest
the negotiated rate to be less than the available bandwidth. In improvements with the additional help of CCA.
order to prevent premature handoff between WLAN and WWAN, S1 and
S2 are separated by 6 dB; in order to prevent oscillation between In "Robust Rate Adaptation for 802.11 Wireless Networks" [Robust] the
WLAN and WWAN media, S3 needs to be greater than S1 by an authors implemented the ARF, AARF and SampleRate [SampleRate]
appropriate margin. algorithms on a programmable Access Point platform, and
experimentally examined the performance of these algorithms as well
as the ONOE [ONOE] algorithm implemented in MADWiFi. Based on their
experiments, the authors critically examine the assumptions
underlying existing rate negotiation algorithms:
Decrease transmission rate upon severe frame loss
Where severe frame loss is due to channel conditions, rate
reduction can improve throughput. However, where frame loss is due
to contention (such as from hidden stations), reducing transmission
rate increases congestion, lowering throughput and potentially
leading to congestive collapse. Instead, the authors propose
adaptive enabling of RTS/CTS so as to reduce contention due to
hidden stations. Once RTS/CTS is enabled, remaining losses are
more likely to be due to channel conditions, providing more
reliable guidance on increasing or decreasing transmission rate.
Use probe frames to assess possible new rates
Probe frames reliably estimate frame loss at a given rate unless
the sample size is sufficient and the probe frames are of
comparable length to data frames. The authors argue that rate
adaptation schemes such as SampleRate are too sensitive to loss of
probe packets. In order to satisfy sample size constraints, a
significant number of probe frames are required. This can increase
frame loss if the probed rate is too high, and can lower throughput
if the probed rate is too low. Instead, the authors propose
assessment of the channel condition by tracking the frame loss
ratio within a window of 5 to 40 frames.
Use consecutive transmission successes/losses to increase/decrease rate
The authors argue that consecutive successes or losses are not a
reliable basis for rate increases or decreases; greater sample size
is needed.
Use PHY metrics like SNR to infer new transmission rate
The authors argue that received signal/noise ratio routinely varies
5 dB per packet and that variations of 10-14 dB are common. As a
result, rate decisions based on signal/noise ratio or signal
strength can cause transmission rate to vary rapidly. The authors
question the value of such rapid variation, since studies such as
[Aguayo] show little correlation between signal to noise ratio and
frame loss probability. As a result, the authors argue that
neither received signal strength indication (RSSI) nor background
energy level can be used to distinguish losses due to contention
from those due to channel conditions. While multi-path
interference can simultaneously result in high signal strength and
frame loss, the relationship between low signal strength and high
frame loss is stronger. Therefore transmission rate decreases due
to low received signal strength probably do reflect sudden
worsening in channel conditions, although sudden increases may not
necessarily indicate that channel conditions have improved.
Long-term smoothened operation produces best average performance
The authors present evidence that frame losses more than 150 ms
apart are uncorrelated. Therefore collection of statistical data
over intervals of 1 second or greater reduce responsiveness, but do
not improve the quality of transmission rate decisions. Rather,
the authors argue that a sampling period of 100 ms provides the
best average performance. Such small sampling periods also argue
against use of probes, since probe packets can only represent a
fraction of all data frames and probes collected more than 150ms
apart may not provide reliable information on channel conditions.
Based on these flaws, the authors propose the Robust Rate Adaptation
Algorithm (RRAA). RRAA utilizes only the frame loss ratio at the
current transmission rate to determine whether to increase or
decrease the transmission rate; PHY layer information or probe
packets are not used. Each transmission rate is associated with an
estimation window, a maximum tolerable loss threshold (MTL) and an
opportunistic rate increase threshold (ORI). If the loss ratio is
larger than the MTL, the transmission rate is decreased and if it is
smaller than ORI, transmission rate is increased; otherwise
transmission rate remains the same. The thresholds are selected in
order to maximize throughput. Although RRAA only allows movement
between adjacent transmission rates, the algorithm does not require
collection of an entire estimation window prior to increasing or
decreasing transmission rates; if additional data collection would
not change the decision, the change is made immediately.
The authors validate the RRAA algorithm using experiments and field
trials; the results indicate that RRAA without adaptive RTS/CTS
outperforms the ARF, AARF and Sample Rate algorithms. This occurs
because RRAA is not as sensitive to transient frame loss and does not
use probing, enabling it to more frequently utilize higher
transmission rates. Where there are no hidden stations, turning on
adaptive RTS/CTS reduces performance by at most a few percent.
However, where there is substantial contention from hidden stations,
adaptive RTS/CTS provides large performance gains, due to reduction
in frame loss which enables selection of a higher transmission rate.
In "Efficient Mobility Management for Vertical Handoff between WWAN
and WLAN" [Vertical], the authors propose use of signal strength and
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
threshold (S1), FFT-based decay detection is undertaken to determine
if the signal is likely to continue to decay. If so, then handoff to
the WWAN is initiated when the signal falls below the minimum
acceptable level (S2). WWAN to WLAN handoff is driven by both PHY
and MAC characteristics of the IEEE 802.11 target network. At the
PHY layer, characteristics such as SSI are examined to determine if
the signal strength is greater than a minimum value (S3); at the MAC
layer the IEEE 802.11 Network Allocation Vector (NAV) occupation is
examined in order to estimate the maximum available bandwidth and
mean access delay. Note that depending on the value of S3, it is
possible for the negotiated rate to be less than the available
bandwidth. In order to prevent premature handoff between WLAN and
WWAN, S1 and S2 are separated by 6 dB; in order to prevent
oscillation between WLAN and WWAN media, S3 needs to be 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 usefulness of routing metrics, and to optimize aspects of Mobile IP
IP handoff. handoff.
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- that has moved to a new point of attachment utilizes a bi-directional
directional reachability test in parallel with DHCP [RFC2131] to reachability test in parallel with DHCP [RFC2131] to rapidly
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 802.11/GPRS Example" [Park], the authors propose that the mobile node
node send a router solicitation on receipt of a "Link Up" send a router solicitation on receipt of a "Link Up" indication in
indication in order provide lower handoff latency than would be order provide lower handoff latency than would be possible using
possible using generic movement detection [RFC3775]. The authors generic movement detection [RFC3775]. The authors also suggest
also suggest immediate invalidation of the Care-Of-Address (CoA) immediate invalidation of the Care-Of-Address (CoA) on receipt of a
on receipt of a "Link Down" indication. However, this is "Link Down" indication. However, this is problematic where a "Link
problematic where a "Link Down" indication can be followed by a Down" indication can be followed by a "Link Up" indication without a
"Link Up" indication without a resulting change in IP resulting change in IP configuration, as described in [RFC4436].
configuration, as described in [RFC4436].
In "Layer 2 Handoff for Mobile-IPv4 with 802.11" [Mun], the In "Layer 2 Handoff for Mobile-IPv4 with 802.11" [Mun], the authors
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 Information Elements of IEEE 802.11 Association/Reassociation frames,
frames, in order to minimize handoff delays. This requires in order to minimize handoff delays. This requires modification to
modification to the mobile node as well as 802.11 APs. However, the mobile node as well as 802.11 APs. However, prior to detecting
prior to detecting network attachment, it is difficult for the network attachment, it is difficult for the mobile node to determine
mobile node to determine whether the new point of attachment whether the new point of attachment represents a change of network or
represents a change of network or not. For example, even where a not. For example, even where a station remains within the same ESS,
station remains within the same ESS, it is possible that the it is possible that the network will change. Where no change of
network will change. Where no change of network results, sending network results, sending a MIPv4 Registration message with each
a MIPv4 Registration message with each Association/Reassociation Association/Reassociation is unnecessary. Where a change of network
is unnecessary. Where a change of network results, it is results, it is typically not possible for the mobile node to
typically not possible for the mobile node to anticipate its new anticipate its new CoA at Association/Reassociation; for example, a
CoA at Association/Reassociation; for example, a DHCP server may DHCP server may assign a CoA not previously given to the mobile node.
assign a CoA not previously given to the mobile node. When When dynamic VLAN assignment is used, the VLAN assignment is not even
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 after Association/Reassociation in [IEEE-802.11i].
is 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 characteristics are included in registration/binding update messages
messages sent by the mobile node to the home agent and sent by the mobile node to the home agent and correspondent node.
correspondent node. Where the mobile node is acting as a Where the mobile node is acting as a receiver, this allows the
receiver, this allows the correspondent node to adjust its correspondent node to adjust its transport parameters window more
transport parameters window more rapidly than might otherwise be rapidly than might otherwise be possible. Link characteristics that
possible. Link characteristics that may be communicated include may be communicated include the link type (e.g. 802.11b, CDMA, GPRS,
the link type (e.g. 802.11b, CDMA, GPRS, etc.) and link bandwidth. etc.) and link bandwidth. While the document suggests that the
While the document suggests that the correspondent node should correspondent node should adjust its sending rate based on the
adjust its sending rate based on the advertised link bandwidth, advertised link bandwidth, this may not be wise in some
this may not be wise in some circumstances. For example, where circumstances. For example, where the mobile node link is not the
the mobile node link is not the bottleneck, adjusting the sending bottleneck, adjusting the sending rate based on the link bandwidth
rate based on the link bandwidth could cause in congestion. Also, could cause in congestion. Also, where the transmission rate changes
where link rates change frequently, sending registration messages frequently, sending registration messages on each transmission rate
on each rate change could by itself consume significant bandwidth. change could by itself consume significant bandwidth. Even where the
Even where the advertised link characteristics indicate the need advertised link characteristics indicate the need for a smaller
for a smaller congestion window, it may be non-trivial to adjust congestion window, it may be non-trivial to adjust the sending rates
the sending rates of individual connections where there are of individual connections where there are multiple connections open
multiple connections open between a mobile node and correspondent between a mobile node and correspondent node. A more conservative
node. A more conservative approach would be to trigger parameter approach would be to trigger parameter re-estimation and slow start
re-estimation and slow start based on the receipt of a based on the receipt of a registration message or binding update.
registration message or binding update.
In "Hotspot Mitigation Protocol (HMP)" [HMP], it is noted that In "Hotspot Mitigation Protocol (HMP)" [HMP], it is noted that MANET
MANET routing protocols have a tendency to concentrate traffic routing protocols have a tendency to concentrate traffic since they
since they utilize shortest path metrics and allow nodes to utilize shortest path metrics and allow nodes to respond to route
respond to route queries with cached routes. The authors propose queries with cached routes. The authors propose that nodes
that nodes participating in an ad-hoc wireless mesh monitor local participating in an ad-hoc wireless mesh monitor local conditions
conditions such as MAC delay, buffer consumption and packets loss. such as MAC delay, buffer consumption and packets loss. Where
Where congestion is detected, this is communicated to neighboring congestion is detected, this is communicated to neighboring nodes via
nodes via an IP option. In response to moderate congestion, nodes an IP option. In response to moderate congestion, nodes suppress
suppress route requests; where major congestion is detected, nodes route requests; where major congestion is detected, nodes throttle
throttle TCP connections flowing through them. The authors argue TCP connections flowing through them. The authors argue that for ad-
that for ad-hoc networks throttling by intermediate nodes is more hoc networks throttling by intermediate nodes is more effective than
effective than end-to-end congestion control mechanisms. end-to-end congestion control mechanisms.
A.3 Transport Layer A.3 Transport Layer
Within the Transport layer, proposals have focused on countering Within the Transport layer, proposals have focused on countering the
the effects of handoff-induced packet loss and non-congestive loss effects of handoff-induced packet loss and non-congestive loss caused
caused by lossy wireless links. by lossy wireless links.
Where a mobile host moves to a new network, the transport Where a mobile host moves to a new network, the transport parameters
parameters (including the RTT, RTO and congestion window) may no (including the RTT, RTO and congestion window) may no longer be
longer be valid. Where the path change occurs on the sender (e.g. valid. Where the path change occurs on the sender (e.g. change in
change in outgoing or incoming interface), the sender can reset outgoing or incoming interface), the sender can reset its congestion
its congestion window and parameter estimates. However, where it window and parameter estimates. However, where it occurs on the
occurs on the receiver, the sender may not be aware of the path receiver, the sender may not be aware of the path change.
change.
In "The BU-trigger method for improving TCP performance over In "The BU-trigger method for improving TCP performance over Mobile
Mobile IPv6" [Kim], the authors note that handoff-related packet IPv6" [Kim], the authors note that handoff-related packet loss is
loss is interpreted as congestion by the Transport layer. In the interpreted as congestion by the Transport layer. In the case where
case where the correspondent node is sending to the mobile node, the correspondent node is sending to the mobile node, it is proposed
it is proposed that receipt of a Binding Update by the that receipt of a Binding Update by the correspondent node be used as
correspondent node be used as a signal to the Transport layer to a signal to the Transport layer to adjust cwnd and ssthresh values,
adjust cwnd and ssthresh values, which may have been reduced due which may have been reduced due to handoff-induced packet loss. The
to handoff-induced packet loss. The authors recommend that cwnd authors recommend that cwnd and ssthresh be recovered to pre-timeout
and ssthresh be recovered to pre-timeout values, regardless of values, regardless of whether the link parameters have changed. The
whether the link parameters have changed. The paper does not paper does not discuss the behavior of a mobile node sending a
discuss the behavior of a mobile node sending a Binding Update, in Binding Update, in the case where the mobile node is sending to the
the case where the mobile node is sending to the correspondent correspondent node.
node.
In "Effect of Vertical Handovers on Performance of TCP-Friendly In "Effect of Vertical Handovers on Performance of TCP-Friendly Rate
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. Where handover notifications on TCP-friendly rate control. Where explicit
explicit handover notification includes information on the loss handover notification includes information on the loss rate and
rate and throughput of the new link, this can be used to throughput of the new link, this can be used to instantaneously
instantaneously change the transmission rate of the sender. The change the transmission rate of the sender. The authors also found
authors also found that resetting the TFRC receiver state after that resetting the TFRC receiver state after handover enabled
handover enabled parameter estimates to adjust more quickly. parameter estimates to adjust more quickly.
In "Adapting End Host Congestion Control for Mobility" [Eddy], the In "Adapting End Host Congestion Control for Mobility" [Eddy], the
authors note that while MIPv6 with route optimization allows a authors note that while MIPv6 with route optimization allows a
receiver to communicate a subnet change to the sender via a receiver to communicate a subnet change to the sender via a Binding
Binding Update, this is not available within MIPv4. To provide a Update, this is not available within MIPv4. To provide a
communication vehicle that can be universally employed, the communication vehicle that can be universally employed, the authors
authors propose a TCP option that allows a connection endpoint to propose a TCP option that allows a connection endpoint to inform a
inform a peer of a subnet change. The document does not advocate peer of a subnet change. The document does not advocate utilization
utilization of "Link Up" or "Link Down" events since these events of "Link Up" or "Link Down" events since these events are not
are not necessarily indicative of subnet change. On detection of necessarily indicative of subnet change. On detection of subnet
subnet change, it is advocated that the congestion window be reset change, it is advocated that the congestion window be reset to
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 In "Efficient Mobility Management for Vertical Handoff between WWAN
WWAN and WLAN" [Vertical] the authors propose a "Virtual and WLAN" [Vertical], the authors propose a "Virtual Connectivity
Connectivity Manager" which utilizes local connection translation Manager" which utilizes local connection translation (LCT) and a
(LCT) and a subscription/notification service supporting subscription/notification service supporting simultaneous movement in
simultaneous movement in order to enable end-to-end mobility and order to enable end-to-end mobility and maintain TCP throughput
maintain TCP throughput during vertical handovers. during vertical handovers.
In an early draft of [RFC4340], a "Reset Congestion State" option In an early draft of "Datagram Congestion Control Protocol (DCCP)"
was proposed in Section 4. This option was removed in part [RFC4340], a "Reset Congestion State" option was proposed in Section
because the use conditions were not fully understood: 4. This option was removed in part because the use conditions were
not fully understood:
An Half-Connection Receiver sends the Reset Congestion State An Half-Connection Receiver sends the Reset Congestion State
option to its sender to force the sender to reset its option to its sender to force the sender to reset its congestion
congestion state -- that is, to "slow start", as if the state -- that is, to "slow start", as if the connection were
connection were beginning again. beginning again.
... The Reset Congestion State option is reserved for the ...
very few cases when an endpoint knows that the congestion The Reset Congestion State option is reserved for the very few
properties of a path have changed. Currently, this reduces to cases when an endpoint knows that the congestion properties of a
mobility: a DCCP endpoint on a mobile host MUST send Reset path have changed. Currently, this reduces to mobility: a DCCP
Congestion State to its peer after the mobile host changes endpoint on a mobile host MUST send Reset Congestion State to its
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" was down. "End-to-end, Implicit 'Link-Up' Notification" [E2ELinkup]
[E2ELinkup] describes methods by which a TCP implementation that describes methods by which a TCP implementation that has backed off
has backed off its retransmission timer due to frame loss on a its retransmission timer due to frame loss on a remote link can learn
remote link can learn that the link has once again become that the link has once again become operational. This enables
operational. This enables retransmission to be attempted prior to retransmission to be attempted prior to expiration of the backed off
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 arising from lack of host awareness of link conditions on downstream
downstream Access Points and routers. Transport of link layer Access Points and routers. Transport of link layer triggers is
triggers is proposed to address the issue. proposed to address the issue.
"TCP Extensions for Immediate Retransmissions" [Eggert], describes "TCP Extensions for Immediate Retransmissions" [Eggert] describes how
how a Transport layer implementation may utilize existing "end-to- a Transport layer implementation may utilize existing "end-to-end
end connectivity restored" indications. It is proposed that in connectivity restored" indications. It is proposed that in addition
addition to regularly scheduled retransmissions that to regularly scheduled retransmissions that retransmission be
retransmission be attempted by the Transport layer on receipt of attempted by the Transport layer on receipt of an indication that
an indication that connectivity to a peer node may have been connectivity to a peer node may have been restored. End-to-end
restored. End-to-end connectivity restoration indications include connectivity restoration indications include "Link Up", confirmation
"Link Up", confirmation of first-hop router reachability, of first-hop router reachability, confirmation of Internet layer
confirmation of Internet layer configuration, and receipt of other configuration, and receipt of other traffic from the peer.
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 transmission losses based on inter-arrival times. Where the loss is
is due to wireless transmission rather than congestion, congestive due to wireless transmission rather than congestion, congestive
backoff and cwnd adjustment is omitted. However, the scheme backoff and cwnd adjustment is omitted. However, the scheme appears
appears to assume equal spacing between packets, which is not to assume equal spacing between packets, which is not realistic in an
realistic in an environment exhibiting link layer frame loss. The environment exhibiting link layer frame loss. The scheme is shown to
scheme is shown to function well only when the wireless link is function well only when the wireless link is the bottleneck, which is
the bottleneck, which is often the case with cellular networks, often the case with cellular networks, but not with IEEE 802.11
but not with IEEE 802.11 deployment scenarios such as home or deployment scenarios such as home or hotspot use.
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 within ns-2, utilizing a two-state Markov model, representing "good"
"good" and "bad" states. Where the receiver is connected over a and "bad" states. Where the receiver is connected over a wireless
wireless link, the authors simulate the effect of an Explicit Bad link, the authors simulate the effect of an Explicit Bad State
State Notification (EBSN) sent by an access point unable to reach Notification (EBSN) sent by an access point unable to reach the
the receiver. In response to an EBSN, it is advocated that the receiver. In response to an EBSN, it is advocated that the existing
existing retransmission timer be canceled and replaced by a new retransmission timer be canceled and replaced by a new dynamically
dynamically estimated timeout, rather than being backed off. In estimated timeout, rather than being backed off. In the simulations,
the simulations, EBSN prevents unnecessary timeouts, decreasing EBSN prevents unnecessary timeouts, decreasing RTT variance and
RTT variance and improving throughput. improving throughput.
In "A Feedback-Based Scheme for Improving TCP Performance in Ad- In "A Feedback-Based Scheme for Improving TCP Performance in Ad-Hoc
Hoc Wireless Networks" [Chandran], the authors proposed an Wireless Networks" [Chandran], the authors proposed an explicit Route
explicit Route Failure Notification (RFN), allowing the sender to Failure Notification (RFN), allowing the sender to stop its
stop its retransmission timers when the receiver becomes retransmission timers when the receiver becomes unreachable. On
unreachable. On route reestablishment, a Route Reestablishment route reestablishment, a Route Reestablishment Notification (RRN) is
Notification (RRN) is sent, unfreezing the timer. Simulations sent, unfreezing the timer. Simulations indicate that the scheme
indicate that the scheme significantly improves throughput and significantly improves throughput and reduces unnecessary
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 [Holland], the authors explore how explicit link failure notification
notification (ELFN) can improve the performance of TCP in mobile (ELFN) can improve the performance of TCP in mobile ad hoc networks.
ad hoc networks. ELFN informs the TCP sender about link and route ELFN informs the TCP sender about link and route failures so that it
failures so that it need not treat the ensuing packet loss as due need not treat the ensuing packet loss as due to congestion. Using
to congestion. Using an ns-2 simulation of TCP-Reno over 802.11 an ns-2 simulation of TCP-Reno over 802.11 with routing provided by
with routing provided by the Dynamic Source Routing (DSR) the Dynamic Source Routing (DSR) protocol, it is demonstrated that
protocol, it is demonstrated that TCP performance falls TCP performance falls considerably short of expected throughput based
considerably short of expected throughput based on the percentage on the percentage of the time that the network is partitioned. A
of the time that the network is partitioned. A portion of the portion of the problem was attributed to the inability of the routing
problem was attributed to the inability of the routing protocol to protocol to quickly recognize and purge stale routes, leading to
quickly recognize and purge stale routes, leading to excessive excessive link failures; performance improved dramatically when route
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 transport retransmission timers were also noted. Where the route
and transport retransmission timers were also noted. Where the request timer is too large, new routes cannot be supplied in time to
route request timer is too large, new routes cannot be supplied in prevent the transport timer from expiring, and where the route
time to prevent the transport timer from expiring, and where the request timer is too small, network congestion may result.
route request timer is too small, network congestion may result.
For their implementation of ELFN, the authors piggybacked For their implementation of ELFN, the authors piggybacked additional
additional information on an existing "route failure" notice information on an existing "route failure" notice (sender and
(sender and receiver addresses and ports, the TCP sequence number) receiver addresses and ports, the TCP sequence number) to enable the
to enable the sender to identify the affected connection. Where a sender to identify the affected connection. Where a TCP receives an
TCP receives an ELFN, it disables the retransmission timer and ELFN, it disables the retransmission timer and enters "stand-by"
enters "stand-by" mode, where packets are sent at periodic mode, where packets are sent at periodic intervals to determine if
intervals to determine if the route has been reestablished. If an the route has been reestablished. If an acknowledgment is received
acknowledgment is received then the retransmission timers are then the retransmission timers are restored. Simulations show that
restored. Simulations show that performance is sensitive to the performance is sensitive to the probe interval, with intervals of 30
probe interval, with intervals of 30 seconds or greater giving seconds or greater giving worse performance than TCP-Reno. The
worse performance than TCP-Reno. The affect of resetting the affect of resetting the congestion window and RTO values was also
congestion window and RTO values was also investigated. In the investigated. In the study, resetting congestion window to one did
study, resetting congestion window to one did not have much of an not have much of an effect on throughput, since the bandwidth/delay
effect on throughput, since the bandwidth/delay of the network was of the network was only a few packets. However, resetting the RTO to
only a few packets. However, resetting the RTO to a high initial a high initial value (6 seconds) did have a substantial detrimental
value (6 seconds) did have a substantial detrimental effect, effect, particularly at high speed. In terms of the probe packet
particularly at high speed. In terms of the probe packet sent, sent, the simulations showed little difference between sending the
the simulations showed little difference between sending the first first packet in the congestion window, or retransmitting the packet
packet in the congestion window, or retransmitting the packet with with the lowest sequence number among those signaled as lost via the
the lowest sequence number among those signaled as lost via the
ELFNs. 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 access point on failure of a transmission attempt. After exhaustion
exhaustion of retransmission attempts, an ICMP-RETRANSMIT message of retransmission attempts, an ICMP-RETRANSMIT message is sent. On
is sent. On receipt of an ICMP-DEFER message, the expiry of the receipt of an ICMP-DEFER message, the expiry of the retransmission
retransmission timer is postponed by the current RTO estimate. On timer is postponed by the current RTO estimate. On receipt of an
receipt of an ICMP-RETRANSMIT message, the segment is ICMP-RETRANSMIT message, the segment is retransmitted. On
retransmitted. On retransmission, the congestion window is not retransmission, the congestion window is not reduced; when coming out
reduced; when coming out of fast recovery, the congestion window of fast recovery, the congestion window is reset to its value prior
is reset to its value prior to fast retransmission and fast to fast retransmission and fast recovery. Using a two-state Markov
recovery. Using a two-state Markov model, simulated using ns-2, model, simulated using ns-2, the authors show that the scheme
the authors show that the scheme improves throughput. improves throughput.
In "Explicit Transport Error Notification (ETEN) for Error-Prone In "Explicit Transport Error Notification (ETEN) for Error-Prone
Wireless and Satellite Networks" [Krishnan], the authors examine Wireless and Satellite Networks" [Krishnan], the authors examine the
the use of explicit transport error notification (ETEN) to aid TCP use of explicit transport error notification (ETEN) to aid TCP in
in distinguishing congestive losses from those due to corruption. distinguishing congestive losses from those due to corruption. Both
per-packet and cumulative ETEN mechanisms were simulated in ns-2,
Both per-packet and cumulative ETEN mechanisms were simulated in using both TCP Reno and TCP SACK over a wide range of bit error rates
ns-2, using both TCP Reno and TCP SACK over a wide range of bit and traffic conditions. While per-packet ETEN mechanisms provided
error rates and traffic conditions. While per-packet ETEN substantial gains in TCP goodput without congestion, where congestion
mechanisms provided substantial gains in TCP goodput without was also present, the gains were not significant. Cumulative ETEN
congestion, where congestion was also present, the gains were not mechanisms did not perform as well in the study. The authors point
significant. Cumulative ETEN mechanisms did not perform as well out that ETEN faces significant deployment barriers since it can
in the study. The authors point out that ETEN faces significant create new security vulnerabilities and requires implementations to
deployment barriers since it can create new security obtain reliable information from the headers of corrupt packets.
vulnerabilities and requires implementations to obtain reliable
information from the headers of corrupt packets.
In "Towards More Expressive Transport-Layer Interfaces" [Eggert2] In "Towards More Expressive Transport-Layer Interfaces" [Eggert2],
the authors propose extensions to existing network/transport and the authors propose extensions to existing network/transport and
transport/application interfaces to improve the performance of the transport/application interfaces to improve the performance of the
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 [Schuetz], the authors note that intermittent connectivity can lead
lead to poor performance and connectivity failures. To address to poor performance and connectivity failures. To address these
these problems, the authors combine the use of the Host Identity problems, the authors combine the use of the Host Identity Protocol
Protocol (HIP) with a TCP User Timeout Option and TCP (HIP) with a TCP User Timeout Option and TCP Retransmission trigger,
Retransmission trigger, demonstrating significant improvement. 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 [Haratcherev2], rate information generated by a link layer utilizing
utilizing improved rate adaptation algorithms is provided to a improved rate adaptation algorithms is provided to a video
video application, and used for codec adaptation. Coupling the application, and used for codec adaptation. Coupling the link and
link and application layers results in major improvements in the application layers results in major improvements in the Peak
Peak Signal/Noise Ratio (PSNR). Signal/Noise Ratio (PSNR). Since this approach assumes that the link
represents the path bottleneck bandwidth, it is not universally
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, been proposed to augment presence systems. In such systems, client
client devices periodically refresh their presence state using devices periodically refresh their presence state using application
application layer protocols such as SIMPLE [RFC3428] or XMPP layer protocols such as SIMPLE [RFC3428] or XMPP [RFC3921]. If the
[RFC3921]. If the client should become disconnected, their client should become disconnected, their unavailability will not be
unavailability will not be detected until the presence status detected until the presence status times out, which can take many
times out, which can take many minutes. However, if a link goes minutes. However, if a link goes down, and a disconnect indication
down, and a disconnect indication can be sent to the presence can be sent to the presence server (presumably by the access point,
server (presumably by the access point, which remains connected), which remains connected), the status of the user's communication
the status of the user's communication application can be updated application can be updated nearly instantaneously.
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
 End of changes. 148 change blocks. 
719 lines changed or deleted 886 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/