draft-iab-link-indications-05.txt   draft-iab-link-indications-06.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-05.txt> <draft-iab-link-indications-06.txt>
2 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
other groups may also distribute working documents as Internet- other groups may also distribute working documents as Internet-
skipping to change at page 1, line 30 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 January 16, 2007. This Internet-Draft will expire on August 2, 2007.
Copyright Notice Copyright Notice
Copyright (C) The Internet Society (2006). Copyright (C) The IETF Trust (2007).
Abstract Abstract
This document describes the role of link indications within the A link indication represents information provided by the link layer
Internet Architecture. While the judicious use of link indications to higher layers regarding the state of the link. This document
can provide performance benefits, inappropriate use can degrade both describes the role of link indications within the Internet
Architecture. While the judicious use of link indications can
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 layer 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 ........................................... 4
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 .................................. 15 2.2 Clear Definitions .................................. 14
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 ...................................... 20
2.6 Interoperability ................................... 21 2.6 Interoperability ................................... 20
2.7 Race Conditions .................................... 21 2.7 Race Conditions .................................... 21
2.8 Layer Compression .................................. 23 2.8 Layer Compression .................................. 24
2.9 Transport of Link Indications ...................... 24 2.9 Transport of Link Indications ...................... 25
3. Future Work .............................................. 25 3. Future Work .............................................. 26
4. Security Considerations .................................. 26 4. Security Considerations .................................. 27
4.1 Spoofing ........................................... 27 4.1 Spoofing ........................................... 27
4.2 Indication Validation .............................. 27 4.2 Indication Validation .............................. 28
4.3 Denial of Service .................................. 28 4.3 Denial of Service .................................. 29
5. References ............................................... 29 5. IANA Considerations ...................................... 29
5.1 Informative References ............................. 29 6. References ............................................... 29
6.1 Informative References ............................. 29
Appendix A - Literature Review ............................... 38 Appendix A - Literature Review ............................... 38
A.0 Terminology ........................................ 38 A.0 Terminology ........................................ 38
A.1 Link Layer ......................................... 38 A.1 Link Layer ......................................... 38
A.2 Internet Layer ..................................... 48 A.2 Internet Layer ..................................... 48
A.3 Transport Layer .................................... 49 A.3 Transport Layer .................................... 49
A.4 Application Layer .................................. 53 A.4 Application Layer .................................. 53
Appendix B - IAB Members ..................................... 54 Appendix B - IAB Members ..................................... 55
Intellectual Property Statement .............................. 54 Authors' Addresses ........................................... 55
Disclaimer of Validity ....................................... 55 Full Copyright Statement ..................................... 55
Copyright Statement .......................................... 55 Intellectual Property Statement .............................. 56
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. The complexity of to higher layers regarding the state of the link. While the
real-world link behavior poses a challenge to the integration of link judicious use of link indications can provide performance benefits,
indications within the Internet architecture. While the 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, and provides advice to document authors about the
appropriate use of link indications within the Internet, Transport appropriate use of link indications within the Internet, Transport
and Application layers. 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 in wireless Local Area Networks
(LANs).
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
Dynamic Host Configuration Protocol (DHCP) client Asymmetric
A DHCP client is an Internet host using DHCP to obtain
configuration parameters such as a network address.
DHCP server
A DHCP server or "server" is an Internet host that returns
configuration parameters to DHCP clients.
Link A communication facility or physical medium that can sustain data
communications between multiple network nodes, such as an Ethernet.
Asymmetric link
A link with transmission characteristics which are different A link with transmission characteristics which 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 of data on the link. 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
at the link layer, i.e., the layer immediately below the Internet
Protocol (IP).
Link Down Link Down
An event provided by the link layer that signifies a state change An event provided by the link layer that signifies a state change
associated with the interface no longer being capable of associated with the interface no longer being capable of
communicating data frames; transient periods of high frame loss are communicating data frames; transient periods of high frame loss 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 IP. The link layer is the layer immediately below the Internet Protocol
(IP).
Link indication Link indication
Information provided by the link layer to higher layers regarding Information provided by the link layer to higher layers regarding
the state of the link. In addition to "Link Up" and "Link Down", the state of the link.
relevant information may include the current link rate, link
identifiers (e.g. SSID, BSSID in IEEE 802.11), and link performance
statistics (such as the delay or frame loss rate).
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.
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 The term "operable address" refers to either a static address or a
dynamically assigned address which has not been relinquished, and dynamically assigned address which has not been relinquished, and
has not expired. has not expired.
Routable address Routable address
In this specification, the term "routable address" refers to any In this specification, the term "routable address" refers to any
IPv4 address other than an IPv4 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].
Weak End-System Model Strong End System Model
In the Weak End-System Model, packets sent out an interface need In the Strong End System model, packets sent out an interface have
not necessarily have a source address configured on that interface. 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/gateway
distinction, tending to model a multihomed host as a set of logical
hosts within the same physical host.
Weak End System Model
In the Weak End System Model, packets sent out an interface need
not necessarily have 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 accepted.
1.3. Overview 1.3. Overview
The integration of link indications with the Internet architecture The integration of link indications with the Internet architecture
has a long history. Link status was first taken into account in has a long history. Link status was first taken into account in
computer routing within the ARPANET as early as 1969. In response to routing as 1969. In response to an attempt to send to a host that
an attempt to send to a host that was off-line, the ARPANET link was off-line, the ARPANET link layer protocol provided a "Destination
layer protocol provided a "Destination Dead" indication [RFC816]. Dead" indication, described in "Fault Isolation and Recovery"
Link-aware routing metrics also have a long history; the ARPANET [RFC816]. Link-aware routing metrics also have a long history; the
packet radio experiment [PRNET] incorporated frame loss in the ARPANET packet radio experiment [PRNET] incorporated frame loss in
calculation of routing metrics, a precursor to more recent link-aware the calculation of routing metrics, a precursor to more recent link-
routing metrics such as [ETX]. aware routing metrics such as Expected Transmission Count (ETX),
described in "A High-Throughput Path Metric for Multi-Hop Wireless
Routing" [ETX].
"Routing Information Protocol" [RFC1058] defines RIP, which is "Routing Information Protocol" [RFC1058] defines 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]
defines 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
determining that their network connections are functioning determining that their network connections are functioning
properly. Failure to detect link loss, or failure to take the properly. Failure to detect link loss, or failure to take the
proper actions when a problem is detected, can lead to black proper actions when a problem is detected, can lead to black
holes. holes.
Attempts have also been made to define link indications other than Attempts have also been made to define link indications other than
"Link Up" and "Link Down". "Dynamically Switched Link Control "Link Up" and "Link Down". "Dynamically Switched Link Control
Protocol" [RFC1307] defines an experimental protocol for control of Protocol" [RFC1307] defines an experimental protocol for control of
links, incorporating "Down", "Coming Up", "Up", "Going Down", "Bring links, incorporating "Down", "Coming Up", "Up", "Going Down", "Bring
Down" and "Bring Up" states. Down" and "Bring Up" states.
[GenTrig] defines "generic triggers", including "Link Up", "Link "A Generalized Model for Link Layer Triggers" [GenTrig] defines
Down", "Link Going Down", "Link Going Up", "Link Quality Crosses "generic triggers", including "Link Up", "Link Down", "Link Going
Threshold", "Trigger Rollback", and "Better Signal Quality AP Down", "Link Going Up", "Link Quality Crosses Threshold", "Trigger
Available". [IEEE-802.21] defines a Media Independent Handover Event Rollback", and "Better Signal Quality AP Available". IEEE 802.21
Service (MIH-ES) that provides event reporting relating to link [IEEE-802.21] defines a Media Independent Handover Event Service
(MIH-ES) that provides event reporting relating to link
characteristics, link status, and link quality. Events defined characteristics, link status, and link quality. Events defined
include "Link Down", "Link Up", "Link Going Down", "Link Signal include "Link Down", "Link Up", "Link Going Down", "Link Signal
Strength" and "Link Signal/Noise Ratio". Strength" and "Link Signal/Noise Ratio".
Under ideal conditions, links in the "up" state experience low frame Under ideal conditions, links in the "up" state experience low frame
loss in both directions and are immediately ready to send and receive loss in both directions and are immediately ready to send and receive
data frames; links in the "down" state are unsuitable for sending and data frames; links in the "down" state are unsuitable for sending and
receiving data frames in either direction. receiving data frames in either direction.
Unfortunately links frequently exhibit non-ideal behavior. Wired Unfortunately links frequently exhibit non-ideal behavior. Wired
links may fail in half-duplex mode, or exhibit partial impairment links may fail in half-duplex mode, or exhibit partial impairment
resulting in intermediate loss rates. Wireless links may exhibit resulting in intermediate loss rates. Wireless links may exhibit
asymmetry or frame loss due to interference or signal fading. In asymmetry, intermittent frame loss or rapid changes in attainable
both wired and wireless links, the link state may rapidly flap data rate due to interference or signal fading. In both wired and
between the "up" and "down" states. This real world behavior wireless links, the link state may rapidly flap between the "up" and
presents challenges to routing protocol implementations. "down" states. This real world behavior presents challenges to the
integration of link indications with the Internet, Transport and
Application layers.
In "Link-level Measurements from an 802.11b Mesh Network" [Aguayo] 1.4. Layered Indication Model
analyzes the causes of frame loss in a 38-node urban multi-hop IEEE
802.11 ad-hoc network. In most cases, links that are very bad in A layered indication model is shown in Figure 1 which includes both
one direction tend to be bad in both directions, and links that are internally generated link indications (such as link state and rate)
very good in one direction tend to be good in both directions. and indications arising from external interactions such as path
However, 30 percent of links exhibited loss rates differing change detection.
substantially in each direction.
In this model, it is assumed that the link layer provides indications
to higher layers primarily in the form of abstract indications that
are link-technology agnostic.
1.4.1. Internet Layer
One of the functions of the Internet layer is to shield higher layers
from the specifics of link behavior. As a result, the Internet layer
validates and filters link indications and selects outgoing and
incoming interfaces based on routing metrics.
The Internet layer composes its routing table based on information
available from local interfaces as well as potentially by taking into
account information provided by gateways. This enables the state of
the local routing table to reflect link conditions on both local and
remote links. For example, prefixes to be added or removed from the
routing table may be determined from DHCP [RFC2131][RFC3315], Router
Advertisements [RFC1256][RFC2461], re-direct messages or route
updates incorporating information on the state of links multiple hops
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
state advertisements. state advertisements, and guard against instability.
"Bidirectional Forwarding Detection" [BFD] notes that link layers may "Bidirectional Forwarding Detection" [BFD] notes that link layers may
provide only limited failure indications, and that relatively slow provide only limited failure indications, and that relatively slow
"Hello" mechanisms are used in routing protocols to detect failures "Hello" mechanisms are used in routing protocols to detect failures
when no link layer indications are available. This results in when no link layer indications are available. This results in
failure detection times of the order of a second, which is too long failure detection times of the order of a second, which is too long
for some applications. The authors describe a mechanism that can be for some applications. The authors describe a mechanism that can be
used for liveness detection over any media, enabling rapid detection used for liveness detection over any media, enabling rapid detection
of failures in the path between adjacent forwarding engines. A path of failures in the path between adjacent forwarding engines. A path
is declared operational when bi-directional reachability has been is declared operational when bi-directional reachability has been
confirmed. confirmed.
1.4. Layered Indication Model
A layered indication model is shown in Figure 1 which includes both
internally generated link indications (such as link state and
throughput) and indications arising from external interactions such
path change detection.
1.4.1. Internet Layer
The Internet layer is the primary consumer of link indications, as
one of its functions is to shield applications from the specifics of
link behavior. This is accomplished by validating and filtering link
indications and selecting outgoing and incoming interfaces based on
routing metrics.
The Internet layer composes its routing table based on information
available from local interfaces as well as potentially by taking into
account information provided by gateways. This enables the state of
the local routing table to reflect link conditions on both local and
remote links. For example, prefixes to be added or removed from the
routing table may be determined from DHCP [RFC2131][RFC3315], Router
Advertisements [RFC1256][RFC2461], re-direct messages or even
transported link indications.
The Internet layer also utilizes link indications in order to
optimize aspects of IP configuration and mobility. After receipt of
a "Link Up" indication, hosts validate potential IP configurations by
Detecting Network Attachment (DNA). 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 - Best Current Practices for hosts" [DNAv6] IP
configuration is validated using reachability detection and Router
Solicitation/ Advertisement.
The routing sub-layer utilizes link indications in order to determine
changes in link state and calculate routing metrics. As described in
[Iannaccone], damping of link flaps and rate limiting of link state
advertisements may be required in order to guard against instability.
Link rate is often used in computing routing metrics. For wired Link rate is often used in computing routing metrics. For wired
networks, the rate is typically constant. However for wireless networks, the rate is typically constant. However for wireless
networks, the negotiated rate and frame loss may change with link networks, the negotiated rate and frame loss may change with link
conditions so that effective throughput may vary considerably over conditions so that effective throughput may vary on a packet by
time and space. In such situations, routing metrics can benefit by packet basis. In such situations, routing metrics may also exhibit
dynamically estimating effective throughput. rapid variation.
In situations where the transmission time represents a large portion
of the total transit time, minimizing total transmission time is
equivalent to maximizing effective throughput. "A High-Throughput
Path Metric for Multi-Hop Wireless Routing" [ETX] describes a
proposed routing metric based on the Expected Transmission Count
(ETX). The authors demonstrate that ETX, based on link layer frame
loss rates (prior to retransmission), enables the selection of routes
maximizing effective throughput. Where the negotiated rate is
constant, the expected transmission time is proportional to ETX, so
that minimizing ETX also minimizes expected transmission time.
However, where the negotiated rate may vary, ETX may not represent a
good estimate of the estimated transmission time. In "Routing in
multi-radio, multi-hop wireless mesh networks" [ETX-Rate] the authors
define a new metric called Expected Transmission Time (ETT). This is
described as a "bandwidth adjusted ETX" since ETT = ETX * S/B where S
is the size of the probe packet and B is the bandwidth of the link as
measured by packet pair [Morgan]. However, ETT assumed that the loss
fraction of small probe frames sent at 1 Mbps data rate is indicative
of the loss fraction of larger data frames at higher rates, which
tends to under-estimate the ETT at higher rates, where frame loss
typically increases. In "A Radio Aware Routing Protocol for Wireless
Mesh Networks" [ETX-Radio] the authors refine the ETT metric further
by estimating the loss fraction as a function of data rate.
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 decreased rate or high frame loss, the route metric will increase for
for the prefixes that it serves, encouraging use of alternate paths the prefixes that it serves, encouraging use of alternate paths if
if available. When the link condition improves, the route metric available. When the link condition improves, the route metric will
will decrease, encouraging use of the link. decrease, encouraging use of the link.
Within "Weak End-System Model" host implementations, changes in Within Weak End System implementations, changes in routing metrics
routing metrics and link state may result in a change in the outgoing and link state may result in a change in the outgoing interface for
interface for one or more transport connections. Routes may also be one or more transport connections. Routes may also be added or
added or withdrawn, resulting in loss or gain of peer connectivity. withdrawn, resulting in loss or gain of peer connectivity. However,
However, link indications such as changes in link rate or frame loss link indications such as changes in link rate or frame loss do not
do not necessarily result in a change of outgoing interface. 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 by running a routing protocol, receipt of a
Router Advertisement, dead gateway detection [RFC816] or network Router Advertisement, dead gateway detection [RFC816] or network
unreachability detection [RFC2461], ICMP re-directs, or a change in unreachability detection [RFC2461], ICMP re-directs, or a change in
the IP TTL of received packets. A change in the outgoing interface the IP TTL of received packets. A change in the outgoing interface
may in turn influence the mobility sub-layer, causing a change in the may in turn influence the mobility sub-layer, causing a change in the
incoming interface. The mobility sub-layer may also become aware of incoming interface. The mobility sub-layer may also become aware of
a change in the incoming interface of a peer (via receipt of a Mobile a change in the incoming interface of a peer (via receipt of a Mobile
IP binding update). IP binding update).
1.4.2. Transport Layer 1.4.2. Transport Layer
The Transport layer processes Internet layer and link indications The Transport layer receives processes link indications differently
differently for the purposes of transport parameter estimation and for the purposes of transport parameter estimation and connection
connection management. For the purposes of parameter estimation, the management.
Transport layer may be interested in a wide range of Internet and
link layer indications. The Transport layer may wish to use path
change indications from the Internet layer in order to reset
parameter estimates. Changes in the routing table may also be useful
in this regard; for example, loss of segments sent to a destination
with no prefix in the routing table may be assumed to be due to
causes other than congestion. The Transport layer may also utilize
link layer indications such as rate, frame loss and "Link Up"/"Link
Down" in order to improve transport parameter estimates.
As described in Appendix A.3, the algorithms for utilizing link layer For the purposes of parameter estimation, the Transport layer is
primarily interested in path properties that impact performance, and
where link indications may be determined to be relevant to path
properties they may be utilized directly. Link indications such
"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
bottleneck bandwidth is already much lower than the link rate, an
increase in link rate may not materially affect path properties. As
described in Appendix A.3, the algorithms for utilizing link layer
indications to improve transport parameter estimates are still under indications to improve transport parameter estimates are still under
development. In transport parameter estimation, layering development.
considerations do not exist to the same extent as in connection
management. For example, where the host has no entry in its local
routing table for a prefix, either because local link conditions
caused it be removed or because the route was withdrawn by a remote
gateway, the transport layer can conclude that loss of packets
destined to that prefix are not due to congestion. However, the same
information would not be of use for the purposes of connection
management, since it is desirable for connections to remain up during
transitory route flaps. Similarly, the Internet layer may receive a
"Link Down" indication followed by a subsequent "Link Up" indication.
This information may be useful for transport parameter estimation
even if IP configuration does not change, since it may indicates the
potential for non-congestive packet loss during the period between
the indications.
For the purposes of connection management, the Transport layer For the purposes of transport parameter estimation, strict layering
typically only utilizes Internet layer indications such as changes in considerations do not apply since they may hide useful information.
the incoming/outgoing interface and IP configuration changes. For For example, the Transport layer may utilize the receipt of a "Link
example, the Transport layer may tear down transport connections due Down" indication followed by a subsequent "Link Up" indication to
to invalidation of a connection endpoint IP address. However, before infer the possibility of non-congestive packet loss during the period
this can occur, the Internet layer must determine that a between the indications, even if the IP configuration does not change
configuration change has occurred. as a result, so that no Internet layer indication would be sent.
Nevertheless, the Transport layer does not respond to all Internet For the purposes of parameter estimation, the Transport layer may
layer indications. For example, an Internet layer configuration also wish to use Internet layer indications. For example, path
change may not be relevant for the purposes of connection management. change indications can be used as a signal to reset parameter
Where the connection has been established based on the home address, estimates. Changes in the routing table may also be useful; loss of
a change in the care-of-address need not result in connection segments sent to a destination with no prefix in the routing table
teardown, since the configuration change is masked by the mobility may be assumed to be due to causes other than congestion, regardless
functionality within the Internet layer, and is therefore transparent of the reason for the removal (either because local link conditions
to the Transport layer. caused it to be removed or because the route was withdrawn by a
remote gateway).
For the purposes of connection management, layering considerations
are important; the Transport layer typically only utilizes Internet
layer indications such as changes in the incoming/outgoing interface
and IP configuration changes.
Just as a "Link Up" event may not result in a configuration change, Just as a "Link Up" event may not result in a configuration change,
and a configuration change may not result in connection teardown, the and a configuration change may not result in connection teardown, the
Transport layer does not tear down connections on receipt of a "Link Transport layer does not tear down connections on receipt of a "Link
Down" indication, regardless of the cause. Where the "Link Down" Down" indication, regardless of the cause. Where the "Link Down"
indication results from frame loss rather than an explicit exchange, indication results from frame loss rather than an explicit exchange,
the indication may be transient, to be soon followed by a "Link Up" the indication may be transient, to be soon followed by a "Link Up"
indication. Similarly, changes in the routing table do not affect indication.
connection teardown.
Even where the "Link Down" indication results from an explicit Even where the "Link Down" indication results from an explicit
exchange such as receipt of a PPP LCP-Terminate or an IEEE 802.11 exchange such as receipt of a Point-to-Point Protocol (PPP) Link
Disassociate or Deauthenticate frame, an alternative point of Control Protocol (LCP)-Terminate or an IEEE 802.11 Disassociate or
attachment may be available, allowing connectivity to be quickly Deauthenticate frame, an alternative point of attachment may be
restored. As a result, robustness is best achieved by allowing available, allowing connectivity to be quickly restored. As a
connections to remain up until an endpoint address changes, or the result, robustness is best achieved by allowing connections to remain
connection is torn down due to lack of response to repeated up until an endpoint address changes, or the connection is torn down
retransmission attempts. due to lack of response to repeated retransmission attempts.
For the purposes of connection management, the Transport layer is For the purposes of connection management, the Transport layer is
cautious with the use of Internet layer indications as well. cautious with the use of Internet layer indications as well. Changes
in the routing table are not relevant for the purposes of connection
management, since it is desirable for connections to remain up during
transitory routing flaps. The Transport layer may utilize a change
in incoming/outgoing change as a path change indication, or tear down
transport connections due to invalidation of a connection endpoint IP
address. Where the connection has been established based on the home
address, a change in the care-of-address need not result in
connection teardown, since the configuration change is masked by the
mobility functionality within the Internet layer, and is therefore
transparent to the Transport layer.
"Requirements for Internet Hosts - Communication Layers" [RFC1122] "Requirements for Internet Hosts - Communication Layers" [RFC1122]
[RFC1122] Section 2.4 requires Destination Unreachable, Source [RFC1122] Section 2.4 requires Destination Unreachable, Source
Quench, Echo Reply, Timestamp Reply and Time Exceeded ICMP messages Quench, Echo Reply, Timestamp Reply and Time Exceeded ICMP messages
to be passed up to the Transport layer. [RFC1122] 4.2.3.9 requires to be passed up to the Transport layer. [RFC1122] 4.2.3.9 requires
TCP to react to an ICMP Source Quench by slowing transmission. TCP to react to an ICMP Source Quench by slowing transmission.
[RFC1122] Section 4.2.3.9 distinguishes between ICMP messages [RFC1122] Section 4.2.3.9 distinguishes between ICMP messages
indicating soft error conditions, which must not cause TCP to abort a indicating soft error conditions, which must not cause TCP to abort a
connection, and hard error conditions, which should cause an abort. connection, and hard error conditions, which should cause an abort.
ICMP messages indicating soft error conditions include Destination ICMP messages indicating soft error conditions include Destination
skipping to change at page 10, line 39 skipping to change at page 10, line 16
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 "Path MTU Discovery" [RFC1191]
use Destination Unreachable code 4, they do not treat this as a hard use Destination Unreachable code 4, they do not treat this as a hard
error condition. error condition.
However, "Fault Isolation and Recovery" [RFC816], Section 6 states: However, "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 The reason that error messages are difficult to interpret is that,
that, as discussed above, after a failure of a gateway or network, as discussed above, after a failure of a gateway or network, there
there is a transient period during which the gateways may have is a transient period during which the gateways may have incorrect
incorrect information, so that irrelevant or incorrect error information, so that irrelevant or incorrect error messages may
messages may sometimes return. An isolated ICMP Destination sometimes return. An isolated ICMP Destination Unreachable may
Unreachable may arrive at a host, for example, if a packet is sent arrive at a host, for example, if a packet is sent during the
during the period when the gateways are trying to find a new period when the gateways are trying to find a new route. To
route. To abandon a TCP connection based on such a message abandon a TCP connection based on such a message arriving would be
arriving would be to ignore the valuable feature of the Internet to ignore the valuable feature of the Internet that for many
that for many internal failures it reconstructs its function internal failures it reconstructs its function without any
without any disruption of the end points. disruption of the end points.
"Requirements for IP Version 4 Routers" [RFC1812] Section 4.3.3.3 "Requirements for IP Version 4 Routers" [RFC1812] Section 4.3.3.3
states that "Research seems to suggest that Source Quench consumes states that "Research seems to suggest that Source Quench consumes
network bandwidth but is an ineffective (and unfair) antidote to network bandwidth but is an ineffective (and unfair) antidote to
congestion", indicating that routers should not originate them. In congestion", indicating that routers should not originate them. In
general, since the Transport layer is able to determine an general, since the Transport layer is able to determine an
appropriate (and conservative) response to congestion based on packet appropriate (and conservative) response to congestion based on packet
loss or explicit congestion notification, ICMP "source quench" loss or explicit congestion notification, ICMP "source quench"
indications are not needed, and the sending of additional "source indications are not needed, and the sending of additional "source
quench" packets during periods of congestion may be detrimental. quench" packets during periods of congestion may be detrimental.
skipping to change at page 11, line 34 skipping to change at page 11, line 12
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. The Transport layer may also provide
indications to the link layer. For example, where the link layer indications to the link layer. For example, where the link layer
retransmission timeout is significantly less than the path round-trip retransmission timeout is significantly less than the path round-trip
timeout, the Transport layer may wish to control the maximum number timeout, the Transport layer may wish to control the maximum number
of times that a link layer frame may be retransmitted, so that the of times that a link layer frame may be retransmitted, so that the
link layer does not continue to retransmit after a Transport layer link layer does not continue to retransmit after a Transport layer
timeout. timeout.
In IEEE 802.11, this can be achieved by adjusting the MIB variables In IEEE 802.11, this can be achieved by adjusting the Management
dot11ShortRetryLimit (default: 7) and dot11LongRetryLimit (default: Information Base (MIB) variables dot11ShortRetryLimit (default: 7)
4), which control the maximum number of retries for frames shorter and dot11LongRetryLimit (default: 4), which control the maximum
and longer in length than dot11RTSThreshold, respectively. However, number of retries for frames shorter and longer in length than
since these variables control link behavior as a whole they cannot be dot11RTSThreshold, respectively. However, since these variables
used to separately adjust behavior on a per-transport connection control link behavior as a whole they cannot be used to separately
basis. Also, in situations where the link layer retransmission adjust behavior on a per-transport connection basis. In situations
timeout is of the same order as the path round trip timeout, link where the link layer retransmission timeout is of the same order as
layer control may not be possible at all. the path round trip timeout, link layer control may not be possible
at all.
Since applications can typically obtain the information they need
more reliably from the Internet and Transport layers, they will
typically not need to utilize link indications. A "Link Up"
indication implies that the link is capable of communicating IP
packets, but does not indicate that it has been configured;
applications should use an Internet layer "IP Address Configured"
event instead. "Link Down" indications are typically not useful to
applications, since they can be rapidly followed by a "Link Up"
indication; applications should respond to Transport layer teardown
indications instead. Similarly, changes in the link rate may not be
relevant to applications if the bottleneck bandwidth does not change;
the transport layer is best equipped to determine this. As a result,
Figure 1 does not indicate link indications being provided directly
to applications.
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Application | | Application | |
Layer | | Layer | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
^ ^ ^ ^ ^ ^
! ! ! ! ! !
+-!-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-!-+-!-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-!-+-+-!-+-!-+-+-+-+
| ! ! ! | | ! ! ! |
| ! ^ ^ | | ! ^ ^ |
| ! Connection Management ! Teardown | | Connection Management ! ! Teardown |
Transport | ! ! | Transport | ! ! |
Layer +-!-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-!-+-+-+-+-+-+ Layer +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-!-+-+-!-+-+-+-+-+-+
| ! ! | | ^ ! |
| ! Transport Parameter ! | | Rate ! |
| ! Estimation (MTU, RTT, ! | | ! |
| ! RTO, cwnd, bw, ssthresh) ! | | Transport Parameter Estimation ! |
|(MTU, RTT, RTO, cwnd, bw, ssthresh)! |
+-!-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-!-+-+-+-+-+-+ +-!-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-!-+-+-+-+-+-+
^ ^ ^ ^ ! ^ ^ ^ ^ !
! ! ! ! ! ! ! ! ! !
+-!-+-!-+-+-+-+-+-!-+-+-+-!-+-+-+-+-!-+-+-+-+-+-+ +-!-+-!-+-+-+-+-+-!-+-+-+-!-+-+-+-+-!-+-+-+-+-+-+
| ! ! Incoming !MIP ! ! | | ! ! Incoming !MIP ! ! |
| ! ! Interface !BU ! ! | | ! ! Interface !BU ! ! |
| ! ! Change !Receipt! ! | | ! ! Change !Receipt! ! |
| ! ^ ^ ^ ^ | | ! ^ ^ ^ ^ |
Internet | ! ! Mobility ! ! ! | Internet | ! ! Mobility ! ! ! |
Layer +-!-+-!-+-+-+-+-+-!-+-+-+-!-+-+-+-+-!-+-+-+-+-+-+ Layer +-!-+-!-+-+-+-+-+-!-+-+-+-!-+-+-+-+-!-+-+-+-+-+-+
| ! ! Outgoing ! Path ! ! | | ! ! Outgoing ! Path ! ! |
| ! ! Interface ! Change! ! | | ! ! Interface ! Change! ! |
| ! ^ Change ^ ^ ^ | | ! ^ Change ^ ^ ^ |
| ! ! ! | | ! ! ! |
| ! Routing ! ! | | ^ Routing ! ! |
| ^ ! ! |
+-!-+-+-+-+-+-+-+-+-+-+-+-!-+-+-+-+-!-+-+-+-+-+-+ +-!-+-+-+-+-+-+-+-+-+-+-+-!-+-+-+-+-!-+-+-+-+-+-+
| ! ! ! IP | | ! ! ! IP |
| ! ! ! Address | | ! ! ! Address |
| ! IP Configuration ^ ^ Config/ | | ! IP Configuration ^ ^ Config/ |
| ! ! Changes | | ! ! Changes |
+-!-+-+-+-+-+-+-+-+-+-+-+-!-+-+-+-+-+-+-+-+-+-+-+ +-!-+-+-+-+-+-+-+-+-+-+-+-!-+-+-+-+-+-+-+-+-+-+-+
! ! ! !
! ! ! !
+-!-+-+-+-+-+-+-+-+-+-+-+-!-+-+-+-+-+-+-+-+-+-+-+ +-!-+-+-+-+-+-+-+-+-+-+-+-!-+-+-+-+-+-+-+-+-+-+-+
| ! ! | | ! ! |
Link | ^ ^ | Link | ^ ^ |
Layer | Rate, FER Link | Layer | Rate, FER, Link |
| Up/Down | | Delay Up/Down |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 1. Layered Indication Model Figure 1. Layered Indication Model
Since applications can frequently obtain the information they need
more reliably from the Internet and Transport layers they may not
need to utilize link indications. A "Link Up" indication implies
that the link is capable of communicating IP packets, but does not
indicate that it has been configured; applications should use an
Internet layer "IP Address Configured" event instead. Similarly,
"Link Down" indications are typically not useful to applications,
since they can be rapidly followed by a "Link Up" indication;
applications should respond to Transport layer teardown
indications instead. However, there are circumstances in which
link indications can provide information to applications that is
not available in any other way. For example, there may be
situations in which a UDP-based video application may wish to
utilize rate or frame loss information provided by the link layer
in order to adjust the codec [Haratcherev2]. Depending on how
routing metrics are calculated, equivalent information may not be
available from the Internet layer.
2. Architectural Considerations 2. Architectural Considerations
The complexity of real-world link behavior poses a challenge to the
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
skipping to change at page 14, line 10 skipping to change at page 13, line 43
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). Without careful design, potential layer metrics (Section 2.7.3).
differences between link indications used in routing and those used
in roaming and/or link enablement can result in instability,
particularly in multi-homed hosts.
[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 use of link models in circumstances where they
do not apply. 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, signal and signal/noise link indications such as rate, frame loss, and signal strength.
ratio.
In "Modeling Wireless Links for Transport Protocols" [GurtovFloyd], In "Modeling Wireless Links for Transport Protocols" [GurtovFloyd],
the authors provide examples of modeling mistakes and examples of how the authors provide examples of modeling mistakes and examples of how
to improve modeling of link characteristics. To accompany the paper to improve modeling of link characteristics. To accompany the paper
the authors provide simulation scenarios in ns-2. the authors provide simulation scenarios in ns-2.
In order to avoid the pitfalls described in [Kotz] [GurtovFloyd], In order to avoid the pitfalls described in [Kotz] [GurtovFloyd],
documents that describe capabilities that are dependent on link documents that describe capabilities that are dependent on link
indications should explicitly articulate the assumptions of the link indications should explicitly articulate the assumptions of the link
model and describe the circumstances in which it applies. model and describe the circumstances in which they apply.
Generic "trigger" models may include implicit assumptions which may Generic "trigger" models may include implicit assumptions which may
prove invalid in outdoor or mesh deployments. For example, two-state prove invalid in outdoor or mesh wireless LAN deployments. For
Markov models assume that the link is either in a state experiencing example, two-state Markov models assume that the link is either in a
low frame loss ("up") or in a state where few frames are successfully state experiencing low frame loss ("up") or in a state where few
delivered ("down"). In these models, symmetry is also typically frames are successfully delivered ("down"). In these models,
assumed, so that the link is either "up" in both directions or "down" symmetry is also typically assumed, so that the link is either "up"
in both directions. In situations where intermediate loss rates are in both directions or "down" in both directions. In situations where
experienced, these assumptions may be invalid. intermediate loss rates are experienced, these assumptions may be
invalid.
As noted in "Hybrid Rate Control for IEEE 802.11" [Haratcherev] As noted in "Hybrid Rate Control for IEEE 802.11" [Haratcherev]
signal strength data is noisy and sometimes inconsistent, so that it signal strength data is noisy and sometimes inconsistent, so that it
needs to be filtered in order to avoid erratic results. Given this, needs to be filtered in order to avoid erratic results. Given this,
link indications based on raw signal strength data may be unreliable. link indications based on raw signal strength data may be unreliable.
In order to avoid problems, it is best to combine signal strength In order to avoid problems, it is best to combine signal strength
data with other techniques. For example, in developing a "Going data with other techniques. For example, in developing a "Going
Down" indication for use with [IEEE-802.21] it would be advisable to Down" indication for use with [IEEE-802.21] it would be advisable to
validate filtered signal strength measurements with other indications validate filtered signal strength measurements with other indications
of link loss such as lack of beacon reception. of link loss such as lack of beacon reception.
skipping to change at page 15, line 38 skipping to change at page 15, line 20
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
wireless networks. wireless LAN networks. Asymmetry is typically less of a problem
for cellular networks where propagation occurs over longer
distances, multipath effects may be less severe and the base
station can transmit at much higher power than mobile stations
while utilizing a more sensitive antenna.
Specifications utilizing a "Link Up" indication should not assume Specifications utilizing a "Link Up" indication should not 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 effects such as multi-path interference, signal conditions. Due to effects common such as multi-path interference,
strength and signal/noise ratio (SNR) may vary rapidly over a short signal strength and signal/noise ratio (SNR) may vary rapidly over
distance, causing erratic behavior of link indications based on a short distance, causing erratic behavior of link indications
unfiltered measurements. As noted in [Haratcherev], signal based on unfiltered measurements. As noted in [Haratcherev],
strength may prove most useful when utilized in combination with signal strength may prove most useful when utilized in combination
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 received in a timely way. A good link layer if sent, that it will received in a timely way. A good link layer
implementation will both rapidly detect connectivity failure (such implementation will both rapidly detect connectivity failure (such
as by tracking missing Beacons) while sending a "Link Down" event as by tracking missing Beacons) while sending a "Link Down" event
only when it concludes the link is unusable, not due to transient only when it concludes the link is unusable, not due to transient
frame loss. frame loss.
However, existing implementations often do not do a good job of However, existing wireless LAN implementations often do not do a
detecting link failure. During a lengthy detection phase, a "Link good job of detecting link failure. During a lengthy detection
Down" event is not sent by the link layer, yet IP packets cannot be phase, a "Link Down" event is not sent by the link layer, yet IP
transmitted or received on the link. Initiation of a scan may be packets cannot be transmitted or received on the link. Initiation
delayed so that the station cannot find another point of of a scan may be delayed so that the station cannot find another
attachment. This can result in inappropriate backoff of point 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. problems. This is not as much of a problem for cellular networks
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 a. Implementation Variation
b. Recovery from invalid indications b. Recovery from invalid indications
c. Damping and hysteresis c. 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.
As described in [Aguayo], wireless links often exhibit loss rates In "Link-level Measurements from an 802.11b Mesh Network" [Aguayo]
analyzes the causes of frame loss in a 38-node urban multi-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 that are
very good in one direction tend to be good in both directions.
However, 30 percent of links exhibited loss rates differing
substantially in each direction.
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. Depending on the link layer as well as substantial asymmetry. As a result, receipt of a "Link
exchanges required to generate a "Link Up" indication, receipt of Up" indication may not necessarily indicate bi-directional
this indication may not always imply that bi-directional reachability reachability, since it could have been generated after exchange of
has been demonstrated. For example, a "Link Up" indication could be small frames at low rates, which might not imply bi-directional
generated after the exchange of small frames at low rates, and this connectivity for large frames exchanged at higher rates.
may not imply bi-directional 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 antennas may
be used to reduce multi-path effects; rate adaptation can be used to be used to reduce multi-path effects; rate adaptation can be used to
determine if a lower rate will be more satisfactory; transmit power determine if a lower rate will be more satisfactory; transmit power
adjustment can be used to improve signal quality and reduce adjustment can be used to improve signal quality and reduce
interference; RTS/CTS signaling can be used to address hidden node interference; RTS/CTS signaling can be used to address hidden node
problems. However, these techniques may not be completely effective. problems. However, these techniques may not be completely effective.
As a result, periods of high frame loss may be encountered, causing As a result, periods of high frame loss may be encountered, causing
skipping to change at page 19, line 7 skipping to change at page 18, line 47
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 performance, including changes in the
negotiated rate, frame loss and even "Link Up"/"Link Down" negotiated rate, frame loss and even "Link Up"/"Link Down"
indications. indications.
Where link-aware routing metrics are implemented, this can result in Where link-aware routing metrics are implemented, this can result in
rapid metric changes, potentially resulting in frequent changes in rapid metric changes, potentially resulting in frequent changes in
the outgoing interface for "Weak End-System" implementations. As a the outgoing interface for Weak End System implementations. As a
result, it may be necessary to introduce route flap dampening. result, it may be necessary to introduce route flap dampening.
However, the benefits of damping need to be weighed against the However, the benefits of damping need to be weighed against the
additional latency that can be introduced. For example, in order to additional latency that can be introduced. For example, in order to
filter out spurious "Link Down" indications, these indications may be filter out spurious "Link Down" indications, these indications may be
delayed until it can be determined that a "Link Up" indication will delayed until it can be determined that a "Link Up" indication will
not follow shortly thereafter. However, in situations where multiple not follow shortly thereafter. However, in situations where multiple
Beacons are missed such a delay may not be needed, since there is no Beacons are missed such a delay may not be needed, since there is no
evidence of a suitable point of attachment in the vicinity. evidence of a suitable point of attachment in the vicinity.
skipping to change at page 20, line 6 skipping to change at page 19, line 45
[c] Keepalives. In order to improve robustness against spurious link [c] 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 [d] 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 Note that "conservation of packets" may not be sufficient to avoid
link layer congestive collapse. Where rate adjustment is based on congestive collapse in the link layer. Where rate adjustment is
frame loss, it is necessary to demonstrative stability in the face of based on frame loss, it is necessary to demonstrative stability in
congestion. Implementations that rapidly decrease the negotiated the face of congestion. Implementations that rapidly decrease the
rate in response to frame loss can cause congestive collapse in the negotiated rate in response to frame loss can cause congestive
link layer, even where exponential backoff is implemented. For collapse in the link layer, even where exponential backoff is
example, an implementation that decreases rate by a factor of two implemented. For example, an implementation that decreases rate by a
while backing off the retransmission timer by a factor of two has not factor of two while backing off the retransmission timer by a factor
reduced consumption of available slots within the MAC. While such an of two has not reduced the link utilization. While such an
implementation might demonstrate "conservation of packets" it does implementation might demonstrate "conservation of packets" it does
not conserve critical resources. 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 49 skipping to change at page 20, line 40
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 carry a burden of
increased complexity, substantial performance improvement is required increased complexity, substantial performance improvement is required
in order to make a compelling case. in order to make a compelling case.
In the face of unreliable link indications, effectiveness may In the face of unreliable link indications, effectiveness may
strongly depend on the penalty for false positives and false strongly depend on the penalty for false positives and false
negatives. In the case of [RFC4436], the benefits of successful negatives. In the case of DNAv4 [RFC4436], the benefits of
optimization are modest, but the penalty for being unable to confirm successful optimization are modest, but the penalty for being unable
an operable configuration is a lengthy timeout. As a result, the to confirm an operable configuration is a lengthy timeout. As a
recommended strategy is to test multiple potential configurations in result, the recommended strategy is to test multiple potential
parallel in addition to attempting configuration via DHCP. This configurations in parallel in addition to attempting configuration
virtually guaranttees that DNAv4 will always result in performance via DHCP. This virtually guarantees that DNAv4 will always result in
equal to or better than use of DHCP alone. performance equal to or 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
skipping to change at page 21, line 34 skipping to change at page 21, line 26
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 layer addressing and configuration as well as routing. Although "The
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. Similarly, as noted in "Application-
oriented Link Adaptation of IEEE 802.11" [Haratcherev2] there are oriented Link Adaptation of IEEE 802.11" [Haratcherev2] there are
situations in which applications may also wish to consume link situations in which applications may also wish to consume link
indications. 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
skipping to change at page 22, line 44 skipping to change at page 22, line 38
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. Since
one of the major objectives of the Internet layer is maintaining link one of the major objectives of the Internet layer is maintaining link
layer independence, upper layers relying on Internet layer layer independence, upper layers relying on Internet layer
indications rather than consuming link indications directly can avoid indications rather than consuming link indications directly can avoid
link layer dependencies. 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. However, this may not always be possible; for indications directly.
example, a video codec may need to be responsive to changes in rate
provided by the link layer in order to optimize operation.
2.7.3. Metric Consistency 2.7.3. Metric Consistency
Proposals should avoid inconsistencies between link and routing layer Proposals should avoid inconsistencies between link and routing layer
metrics. Without careful design, potential differences between link metrics. Without careful design, potential differences between link
indications used in routing and those used in roaming and/or link indications used in routing and those used in roaming and/or link
enablement can result in instability, particularly in multi-homed enablement can result in instability, particularly in multi-homed
hosts. hosts.
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. However, prior to sending data packets over the link, the metric. In situations where the transmission time represents a large
appropriate routing metric may not be easily be predicted. As noted portion of the total transit time, minimizing total transmission time
in [Shortest], a link that can successfully transmit the short frames is equivalent to maximizing effective throughput. "A High-Throughput
Path Metric for Multi-Hop Wireless Routing" [ETX] describes a
proposed routing metric based on the Expected Transmission Count
(ETX). The authors demonstrate that ETX, based on link layer frame
loss rates (prior to retransmission), enables the selection of routes
maximizing effective throughput. Where the negotiated rate is
constant, the expected transmission time is proportional to ETX, so
that minimizing ETX also minimizes expected transmission time.
However, where the negotiated rate may vary, ETX may not represent a
good estimate of the estimated transmission time. In "Routing in
multi-radio, multi-hop wireless mesh networks" [ETX-Rate] the authors
define a new metric called Expected Transmission Time (ETT). This is
described as a "bandwidth adjusted ETX" since ETT = ETX * S/B where S
is the size of the probe packet and B is the bandwidth of the link as
measured by packet pair [Morgan]. However, ETT assumed that the loss
fraction of small probe frames sent at 1 Mbps data rate is indicative
of the loss fraction of larger data frames at higher rates, which
tends to under-estimate the ETT at higher rates, where frame loss
typically increases. In "A Radio Aware Routing Protocol for Wireless
Mesh Networks" [ETX-Radio] the authors refine the ETT metric further
by estimating the loss fraction as a function of data rate.
However, prior to sending data packets over the link, the appropriate
routing metric may not be easily be predicted. As noted in
[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. The rate adaptation
techniques utilized in [Haratcherev] require data to be accumulated techniques utilized in [Haratcherev] require data to be accumulated
on signal strength and rates based on successful and unsuccessful on signal strength and rates based on successful and unsuccessful
transmissions. However, this data will not available before a link transmissions. However, this data will not available before a link
is used for the first time. 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 the preferred route for one or more destination prefixes, a Weak End
End-System" implementation will not use the new interface for System implementation will not use the new interface for outgoing
outgoing traffic. Where "idle timeout" functionality is implemented, traffic. Where "idle timeout" functionality is implemented, the
the unused interface will be brought down, only to be brought up unused interface will be brought down, only to be brought up again by
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, signal strength and frame loss may be used by
a host to determine the optimum rate, as well as to determine when to a host to determine the optimum rate, as well as to determine when to
select an alternative point of attachment. In order to enable select an alternative point of attachment. In order to enable
stations to roam prior to encountering packet loss, studies such as stations to roam prior to encountering packet loss, studies such as
[Vatn] have suggested using signal strength as a mechanism for more "An experimental study of IEEE 802.11b handover performance and its
rapidly detecting loss of connectivity, rather than frame loss, as effect on voice traffic" [Vatn] have suggested using signal strength
suggested in [Velayos]. as a mechanism for more rapidly detecting loss of connectivity,
rather than frame loss, as suggested in "Techniques to Reduce IEEE
802.11b MAC Layer Handover Time" [Velayos].
[Aguayo] notes that signal strength and distance 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 negotiated rate, due to the potential
effects of multi-path interference. As a result a link brought up effects of multi-path interference. As a result a link brought up
due to good signal strength may subsequently exhibit significant due to good signal strength may subsequently exhibit significant
frame loss, and a low negotiated rate. Similarly, an AP frame loss, and a low negotiated rate. Similarly, an AP
demonstrating low utilization may not necessarily be the best choice, demonstrating low utilization may not necessarily be the best choice,
since utilization may be low due to hardware or software problems. since utilization may be low due to hardware or software problems.
[Villamizar] notes that link utilization-based routing metrics have a "OSPF Optimized Multipath (OSPF-OMP)" [Villamizar] notes that link
history of instability, so that they are rarely deployed. utilization-based routing metrics have a history of instability, so
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.
skipping to change at page 25, line 15 skipping to change at page 25, line 34
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 signalling 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 that modify the local routing table represent routing
protocols, and unless security is provided they will introduce the protocols, and unless security is provided they will introduce the
vulnerabilities associated with unsecured routing protocols. For vulnerabilities associated with unsecured routing protocols. For
example, unless schemes such as SEND [RFC3971] are used, a host example, unless schemes such as SEND [RFC3971] are used, a host
receiving a link indication from a router will not be able to receiving a link indication from a router will not be able to
authenticate the indication. Where indications can be transported authenticate the indication. Where indications can be transported
over the Internet, this allows an attack to be launched without over the Internet, this allows an attack to be launched without
skipping to change at page 26, line 14 skipping to change at page 26, line 33
At the Link and Internet layers, more work is needed to reconcile At the Link and Internet layers, more work is needed to reconcile
handoff metrics (e.g. signal strength and link utilization) with handoff metrics (e.g. signal strength and link utilization) with
routing metrics based on link indications (e.g. frame loss and routing metrics based on link indications (e.g. frame loss and
negotiated rate). negotiated rate).
More work is also needed to understand the connection between link 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 adhoc networks. the development of revised routing metrics for ad-hoc networks.
A better understanding of the relationship between rate negotiation A better understanding of the relationship between rate negotiation
algorithms and link-layer congestion control is required. For algorithms and link-layer congestion control is required. For
example, it is possible that SNR measurements may be useful in example, it is possible that signal strength measurements may be
preventing rapid downward rate negotiation (and congestive collapse) useful in preventing rapid downward rate negotiation (and congestive
in situations where frame loss is caused by congestion, not signal collapse) in situations where frame loss is caused by congestion, not
attenuation. signal attenuation.
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. For example, it may make sense for the
Transport layer to adjust transport parameter estimates in response Transport layer to adjust transport parameter estimates in response
to route loss, "Link Up"/"Link Down" indications and/or frame loss. to route loss, "Link Up"/"Link Down" indications and/or frame loss.
This way transport parameters are not adjusted as though congestion This way transport parameters are not adjusted as though congestion
were detected when loss is occurring due to other factors such as were detected when loss is occurring due to other factors such as
radio propagation effects or loss of a route (such as can occur on radio propagation effects or loss of a route (such as can occur on
receipt of a "Link Down" indication). receipt of a "Link Down" indication).
skipping to change at page 27, line 10 skipping to change at page 27, line 31
Spoofing Spoofing
Indication validation Indication validation
Denial of service Denial of service
4.1. Spoofing 4.1. Spoofing
Where link layer control frames are unprotected, they may be spoofed Where link layer control frames are unprotected, they may be spoofed
by an attacker. For example, PPP does not protect LCP frames such as by an attacker. For example, PPP does not protect LCP frames such as
LCP-Terminate, and [IEEE-802.11] does not protect management frames LCP-Terminate, and [IEEE-802.11] does not protect management frames
such as Associate/ Reasociate, Disassociate, or Deauthenticate. such as Associate/ Reassociate, Disassociate, or Deauthenticate.
Spoofing of link layer control traffic may enable attackers to Spoofing of link layer control traffic may enable attackers to
exploit weaknesses in link indication proposals. For example, exploit weaknesses in link indication proposals. For example,
proposals that do not implement congestion avoidance can be enable proposals that do not implement congestion avoidance can be enable
attackers to mount denial of service attacks. attackers to mount denial of service attacks.
However, even where the link layer incorporates security, attacks may However, even where the link layer incorporates security, attacks may
still be possible if the security model is not consistent. For still be possible if the security model is not consistent. For
example, wireless LANs implementing [IEEE-802.11i] do not enable example, wireless LANs implementing [IEEE-802.11i] do not enable
stations to send or receive IP packets on the link until completion stations to send or receive IP packets on the link until completion
skipping to change at page 27, line 46 skipping to change at page 28, line 19
the station's MAC address. While this enables forwarding of frames the station's MAC address. While this enables forwarding of frames
to the station at the new point of attachment, it also permits an to the station at the new point of attachment, it also permits an
attacker to disassociate a station located anywhere within the ESS, attacker to disassociate a station located anywhere within the ESS,
by sending an unauthenticated Reassociation Request frame. by sending an unauthenticated Reassociation Request frame.
4.2. Indication Validation 4.2. Indication Validation
"Fault Isolation and Recovery" [RFC816] Section 3 describes how hosts "Fault Isolation and Recovery" [RFC816] Section 3 describes how hosts
interact with gateways for the purpose of fault recovery: interact with gateways for the purpose of fault recovery:
Since the gateways always attempt to have a consistent and Since the gateways always attempt to have a consistent and correct
correct model of the internetwork topology, the host strategy for model of the internetwork topology, the host strategy for fault
fault recovery is very simple. Whenever the host feels that recovery is very simple. Whenever the host feels that something
something is wrong, it asks the gateway for advice, and, is wrong, it asks the gateway for advice, and, assuming the advice
assuming the advice is forthcoming, it believes the advice is forthcoming, it believes the advice completely. The advice
completely. The advice will be wrong only during the transient will be wrong only during the transient period of negotiation,
period of negotiation, which immediately follows an outage, which immediately follows an outage, but will otherwise be
but will otherwise be reliably correct. reliably correct.
In fact, it is never necessary for a host to explicitly ask In fact, it is never necessary for a host to explicitly ask a
a gateway for advice, because the gateway will provide it as gateway for advice, because the gateway will provide it as
appropriate. When a host sends a datagram to some distant net, appropriate. When a host sends a datagram to some distant net,
the host should be prepared to receive back either of two advisory the host should be prepared to receive back either of two advisory
messages which the gateway may send. The ICMP "redirect" message messages which the gateway may send. The ICMP "redirect" message
indicates that the gateway to which the host sent the datagram is indicates that the gateway to which the host sent the datagram is
no longer the best gateway to reach the net in question. The no longer the best gateway to reach the net in question. The
gateway will have forwarded the datagram, but the host should gateway will have forwarded the datagram, but the host should
revise its routing table to have a different immediate address revise its routing table to have a different immediate address for
for this net. The ICMP "destination unreachable" message this net. The ICMP "destination unreachable" message indicates
indicates that as a result of an outage, it is currently that as a result of an outage, it is currently impossible to reach
impossible to reach the addressed net or host in any manner. On the addressed net or host in any manner. On receipt of this
receipt of this message, a host can either abandon the connection message, a host can either abandon the connection immediately
immediately without any further retransmission, or resend slowly without any further retransmission, or resend slowly to see if the
to see if the fault is corrected in reasonable time. fault is corrected in reasonable time.
Given today's security environment, it is inadvisable for hosts to Given today's security environment, it is inadvisable for hosts to
act on indications provided by gateways without careful act on indications provided by gateways without careful
consideration. As noted in "ICMP attacks against TCP" [Gont], consideration. As noted in "ICMP attacks against TCP" [Gont],
existing ICMP error messages may be exploited by attackers in order existing ICMP error messages may be exploited by attackers in order
to abort connections in progress, prevent setup of new connections, to abort connections in progress, prevent setup of new connections,
or reduce throughput of ongoing connections. Similar attacks may or reduce throughput of ongoing connections. Similar attacks may
also be launched against the Internet layer via forging of ICMP also be launched against the Internet layer via forging of ICMP
redirects. redirects.
skipping to change at page 29, line 27 skipping to change at page 29, line 48
they should not expend excessive resources in doing so. 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, link indication proposals
should not enable multiple hosts to respond to a frame with a should not enable multiple hosts to respond to a frame with a
multicast destination address. multicast destination address.
5. References 5. IANA Considerations
5.1. Informative References This document has no actions for IANA.
6. 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
1982. 1982.
[RFC1058] Hedrick, C., "Routing Information Protocol", RFC 1058, [RFC1058] Hedrick, C., "Routing Information Protocol", RFC 1058,
June 1988. June 1988.
[RFC1122] Braden, R., "Requirements for Internet Hosts --
Communication Layers", RFC 1122, October 1989.
[RFC1131] Moy, J., "The OSPF Specification", RFC 1131, October [RFC1131] Moy, J., "The OSPF Specification", RFC 1131, October
1989. 1989.
[RFC1191] Mogul, J. and S. Deering, "Path MTU discovery", RFC 1191, [RFC1191] Mogul, J. and S. Deering, "Path MTU discovery", RFC 1191,
November 1990. November 1990.
[RFC1256] Deering, S., "ICMP Router Discovery Messages", RFC 1256, [RFC1256] Deering, S., "ICMP Router Discovery Messages", RFC 1256,
Xerox PARC, September 1991. Xerox PARC, September 1991.
[RFC1307] Young, J. and A. Nicholson, "Dynamically Switched Link [RFC1307] Young, J. and A. Nicholson, "Dynamically Switched Link
skipping to change at page 31, line 45 skipping to change at page 32, line 26
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.
[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., Daley, G. and N. Montavont, "Detecting [DNAv6] Narayanan, S., "Detecting Network Attachment in IPv6
Network Attachment in IPv6 - Best Current Practices for (DNAv6)", draft-ietf-dna-protocol-03.txt, Internet draft
hosts", draft-ietf-dna-hosts-03.txt, Internet draft (work (work in progress), October 2006.
in progress), May 2006.
[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., D. Kroeselberg and Y. Ohba, "EAP IKEv2 [EAPIKEv2] Tschofenig, H., Kroeselberg, D., Pashalidis, A., Ohba,
Method", draft-tschofenig-eap-ikev2-05.txt, Internet Y., and F. Bersani, "EAP IKEv2 Method", draft-tschofenig-
draft (work in progress), October 2004. eap-ikev2-12.txt, Internet draft (work in progress),
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
Control for Mobility", Technical Report CR-2005-213838,
NASA Glenn Research Center, July 2005.
[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-01.txt, Internet draft (work in progress), retransmit-now-02.txt, Internet draft (work in progress),
September 2004. June 2005.
[Eggert2] Eggert, L. and W. Eddy, "Towards More Expressive
Transport-Layer Interfaces", MobiArch '06, San Francisco,
CA.
[ETX] Douglas S. J. De Couto, Daniel Aguayo, John Bicket, and [ETX] Douglas S. J. De Couto, Daniel Aguayo, John Bicket, and
Robert Morris, "A High-Throughput Path Metric for Multi- Robert Morris, "A High-Throughput Path Metric for Multi-
Hop Wireless Routing", Proceedings of the 9th ACM Hop Wireless Routing", Proceedings of the 9th ACM
International Conference on Mobile Computing and International Conference on Mobile Computing and
Networking (MobiCom '03), San Diego, California, Networking (MobiCom '03), San Diego, California,
September 2003. September 2003.
[ETX-Rate] Padhye, J., Draves, R. and B. Zill, "Routing in multi- [ETX-Rate] Padhye, J., Draves, R. and B. Zill, "Routing in multi-
radio, multi-hop wireless mesh networks", Proceedings of radio, multi-hop wireless mesh networks", Proceedings of
skipping to change at page 32, line 43 skipping to change at page 33, line 34
[GenTrig] Gupta, V. and D. Johnston, "A Generalized Model for Link [GenTrig] Gupta, V. and D. Johnston, "A Generalized Model for Link
Layer Triggers", submission to IEEE 802.21 (work in Layer Triggers", submission to IEEE 802.21 (work in
progress), March 2004, available at: progress), March 2004, available at:
http://www.ieee802.org/handoff/march04_meeting_docs/ http://www.ieee802.org/handoff/march04_meeting_docs/
Generalized_triggers-02.pdf Generalized_triggers-02.pdf
[Goel] Goel, S. and D. Sanghi, "Improving TCP Performance over [Goel] Goel, S. and D. Sanghi, "Improving TCP Performance over
Wireless Links", Proceedings of TENCON'98, pages 332-335. Wireless Links", Proceedings of TENCON'98, pages 332-335.
IEEE, December 1998. IEEE, December 1998.
[Gont] Gont, F., "ICMP attacks against TCP", draft-gont-tcpm- [Gont] Gont, F., "ICMP attacks against TCP", draft-ietf-tcpm-
icmp-attacks-05.txt, Internet draft (work in progress), icmp-attacks-01, Internet draft (work in progress),
October 2005. October 2006.
[Gurtov] Gurtov, A. and J. Korhonen, "Effect of Vertical Handovers [Gurtov] Gurtov, A. and J. Korhonen, "Effect of Vertical Handovers
on Performance of TCP-Friendly Rate Control", to appear on Performance of TCP-Friendly Rate Control", to appear
in ACM MCCR, 2004. in ACM MCCR, 2004.
[GurtovFloyd] Gurtov, A. and S. Floyd, "Modeling Wireless Links for [GurtovFloyd] Gurtov, A. and S. Floyd, "Modeling Wireless Links for
Transport Protocols", Computer Communications Review Transport Protocols", Computer Communications Review
(CCR) 34, 2 (2003). (CCR) 34, 2 (2003).
[Haratcherev] Haratcherev, I., Lagendijk, R., Langendoen, K. and H. [Haratcherev] Haratcherev, I., Lagendijk, R., Langendoen, K. and H.
skipping to change at page 34, line 18 skipping to change at page 35, line 10
Requirements - Part 11: Wireless LAN Medium Access Requirements - Part 11: Wireless LAN Medium Access
Control (MAC) and Physical Layer (PHY) Specifications: Control (MAC) and Physical Layer (PHY) Specifications:
Specification for Enhanced Security", IEEE 802.11i, July Specification for Enhanced Security", IEEE 802.11i, July
2004. 2004.
[IEEE-802.11k] Institute of Electrical and Electronics Engineers, "Draft [IEEE-802.11k] Institute of Electrical and Electronics Engineers, "Draft
Amendment to Telecommunications and Information Exchange Amendment to Telecommunications and Information Exchange
Between Systems - LAN/MAN Specific Requirements - Part Between Systems - LAN/MAN Specific Requirements - Part
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/D4.0, March 2006. 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
highperformance wireless lan for unlicensed band", Bell
Labs Technical Journal, 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.
[Krishnan] Krishnan, R., Sterbenz, J., Eddy, W., Partridge, C. and [Krishnan] Krishnan, R., Sterbenz, J., Eddy, W., Partridge, C. and
M. Allman, "Explicit Transport Error Notification (ETEN) M. Allman, "Explicit Transport Error Notification (ETEN)
for Error-Prone Wireless and Satellite Networks", for Error-Prone Wireless and Satellite Networks",
Computer Networks, 46 (3), October 2004. Computer Networks, 46 (3), October 2004.
[Lacage] Lacage, M., Manshaei, M. and T. Turletti, "IEEE 802.11 [Lacage] Lacage, M., Manshaei, M. and T. Turletti, "IEEE 802.11
Rate Adaptation: A Practical Approach", MSWiM '04, Rate Adaptation: A Practical Approach", MSWiM '04,
October 4-6, 2004, Venezia, Italy. October 4-6, 2004, Venezia, Italy.
[Lee] Park, S., Lee, M. and J. Korhonen, "Link Characteristics [Lee] Park, S., Lee, M. and J. Korhonen, "Link Characteristics
Information for Mobile IP", draft-daniel-mip-link- Information for Mobile IP", draft-daniel-mip-link-
characteristic-01.txt, Internet draft (work in progress), characteristic-03.txt, Internet draft (work in progress),
April 2005. January 2007.
[Ludwig] Ludwig, R. and B. Rathonyi, "Link-layer Enhancements for [Ludwig] Ludwig, R. and B. Rathonyi, "Link-layer Enhancements for
TCP/IP over GSM", Proceedings of IEEE Infocom '99, March TCP/IP over GSM", Proceedings of IEEE Infocom '99, March
1999. 1999.
[MIPEAP] Giaretta, C., Guardini, I., Demaria, E., Bournelle, J. [MIPEAP] Giaretta, C., Guardini, I., Demaria, E., Bournelle, J.
and M. Laurent-Maknavicius, "MIPv6 Authorization and and M. Laurent-Maknavicius, "MIPv6 Authorization and
Configuration based on EAP", draft-giaretta- Configuration based on EAP", draft-giaretta-
mip6-authorization-eap-02.txt, Internet draft (work in mip6-authorization-eap-04.txt, Internet draft (work in
progress), October 2004. 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.
[Mitani] Mitani, K., Shibui, R., Gogo, K. and F. Teraoka, "Unified
L2 Abstractions for L3-Driven Fast Handover", draft-koki-
mobopts-l2-abstractions-02.txt, Internet draft (work in
progress), February 2005.
[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 Laaboratoies, October 1994. Memorandum, AT&T Bell Laaboratoies, 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. [PEAP] Palekar, A., Simon, D., Salowey, J., Zhou, H., Zorn, G.
skipping to change at page 36, line 17 skipping to change at page 37, line 9
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.
[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,
"Protocol Enhancements for Intermittently Connected
Hosts", ACM SIGCOMM Computer Communications Review,
Volume 35, Number 2, July 2005.
[Shortest] Douglas S. J. De Couto, Daniel Aguayo, Benjamin A. [Shortest] Douglas S. J. De Couto, Daniel Aguayo, Benjamin A.
Chambers and Robert Morris, "Performance of Multihop Chambers and Robert Morris, "Performance of Multihop
Wireless Networks: Shortest Path is Not Enough", Wireless Networks: Shortest Path is Not Enough",
Proceedings of the First Workshop on Hot Topics in Proceedings of the First Workshop on Hot Topics in
Networking (HotNets-I), Princeton, New Jersey, October Networking (HotNets-I), Princeton, New Jersey, October
2002. 2002.
[Eddy] Eddy, W. and Sami, Y., "Adapting End Host Congestion
Control for Mobility", NASA Glenn Research Center
Technical Report CR-2005-213838, Sept. 2005.
[TRIGTRAN] Dawkins, S., Williams, C. and A. Yegin, "Framework and [TRIGTRAN] Dawkins, S., Williams, C. and A. Yegin, "Framework and
Requirements for TRIGTRAN", draft-dawkins-trigtran- Requirements for TRIGTRAN", draft-dawkins-trigtran-
framework-00.txt, Internet draft (work in progress), framework-00.txt, Internet draft (work in progress),
August 2003. August 2003.
[Vatn] Vatn, J., "An experimental study of IEEE 802.11b handover [Vatn] Vatn, J., "An experimental study of IEEE 802.11b handover
performance and its effect on voice traffic", TRITA- performance and its effect on voice traffic", TRITA-IMIT-
IMIT-TSLAB R 03:01, KTH Royal Institute of Technology, TSLAB R 03:01, KTH Royal Institute of Technology,
Stockholm, Sweden, July 2003. Stockholm, Sweden, July 2003.
[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.
[Velayos] Velayos, H. and G. Karlsson, "Techniques to Reduce IEEE [Velayos] Velayos, H. and G. Karlsson, "Techniques to Reduce IEEE
802.11b MAC Layer Handover Time", TRITA-IMIT-LCN R 03:02, 802.11b MAC Layer Handover Time", TRITA-IMIT-LCN R 03:02,
KTH Royal Institute of Technology, Stockholm, Sweden, KTH Royal Institute of Technology, Stockholm, Sweden,
April 2003. April 2003.
skipping to change at page 38, line 8 skipping to change at page 38, line 8
progress), February 1999. progress), February 1999.
[Xylomenos] Xylomenos, G., "Multi Service Link Layers: An Approach to [Xylomenos] Xylomenos, G., "Multi Service Link Layers: An Approach 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.
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 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
stations. stations.
Beacon Beacon
A control message broadcast by a station (typically an Access A control message broadcast by a station (typically an Access
skipping to change at page 41, line 20 skipping to change at page 41, line 20
deployment of APs with Beacons synchronized via NTP, enabling a deployment of APs with Beacons synchronized via NTP, enabling a
driver implementing SyncScan to work with legacy APs without driver implementing SyncScan to work with legacy APs without
requiring implementation of new protocols. The authors measure the requiring implementation of new protocols. The authors measure the
distribution of inter-arrival times for stations implementing distribution of inter-arrival times for stations implementing
SyncScan, with excellent results. SyncScan, with excellent results.
"Roaming Interval Measurements" [Alimian] presents data on stationary "Roaming Interval Measurements" [Alimian] presents data on stationary
STAs after the AP signal has been shut off. This study highlighted STAs after the AP signal has been shut off. This study highlighted
implementation differences in rate adaptation as well as detection, implementation differences in rate adaptation as well as detection,
scanning and handoff. As in [Velayos], performance varied widely scanning and handoff. As in [Velayos], performance varied widely
between implementations, from half an order of magnitude variation between implementations, from half an order of magnitude variation in
in rate adaptation to an order of magnitude difference in detection rate adaptation to an order of magnitude difference in detection
times, two orders of magnitude in scanning, and one and a half orders times, two orders of magnitude in scanning, and one and a half orders
of magnitude in handoff times. of magnitude in handoff times.
"An experimental study of IEEE 802.11b handoff performance and its "An experimental study of IEEE 802.11b handoff performance and its
effect on voice traffic" [Vatn] describes handover behavior observed effect on voice traffic" [Vatn] describes handover behavior observed
when the signal from AP is gradually attenuated, which is more when the signal from AP is gradually attenuated, which is more
representative of field experience than the shutoff techniques used representative of field experience than the shutoff techniques used
in [Velayos]. Stations were configured to initiate handover when in [Velayos]. Stations were configured to initiate handover when
signal strength dipped below a threshold, rather than purely based on signal strength dipped below a threshold, rather than purely based on
frame loss, so that they could begin handover while still connected frame loss, so that they could begin handover while still connected
skipping to change at page 44, line 33 skipping to change at page 44, line 33
In general, retransmission schemes were superior to rereception In general, retransmission schemes were superior to rereception
schemes, since rereception cannot stimulate fast retransmit after a schemes, since rereception cannot stimulate fast retransmit after a
timeout. Retransmission of multiple packets did not appreciably timeout. Retransmission of multiple packets did not appreciably
improve performance over retransmission of a single packet. Since improve performance over retransmission of a single packet. Since
the focus of the research was on disconnection rather than just lossy the focus of the research was on disconnection rather than just lossy
channels, a two state Markov model was used, with the "up" state channels, a two state Markov model was used, with the "up" state
representing no loss, and the "down" state representing one hundred representing no loss, and the "down" state representing one hundred
percent loss. percent loss.
In "Multi Service Link Layers: An Approach to Enhancing Internet In "Multi Service Link Layers: An Approach to Enhancing Internet
Performance over Wireless Links", [Xylomenos], the authors use ns-2 Performance over Wireless Links" [Xylomenos], the authors use ns-2 to
to simulate the performance of various link layer recovery schemes simulate the performance of various link layer recovery schemes (raw
(raw link without retransmission, go back N, XOR based FEC, selective link without retransmission, go back N, XOR based FEC, selective
repeat, Karn's RLP, out of sequence RLP and Berkeley Snoop) in stand- repeat, Karn's RLP, out of sequence RLP and Berkeley Snoop) in stand-
alone file transfer, web browsing and continuous media distribution. alone file transfer, web browsing and continuous media distribution.
While selective repeat and Karn's RLP provide the highest throughput While selective repeat and Karn's RLP provide the highest throughput
for file transfer and web browsing scenarios, continuous media for file transfer and web browsing scenarios, continuous media
distribution requires a combination of low delay and low loss and the distribution requires a combination of low delay and low loss and the
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 High-performance wireless LAN for the unlicensed In "Wavelan ii: A highperformance wireless lan for the unlicensed
band" [Kamerman] the authors propose a rate adaptation algorithm band" [Kamerman] the authors propose a rate adaptation algorithm
(ARF) in which the sender adjusts the rate upwards after a fixed (ARF) in which the sender adjusts the rate upwards after a fixed
number of successful transmissions, and adjusts the rate downwards number of successful transmissions, and adjusts the rate downwards
after one or two consecutive failures. If after an upwards rate after one or two consecutive failures. If after an upwards rate
adjustment the transmission fails, the rate is immediately readjusted adjustment the transmission fails, the rate is immediately readjusted
downwards. 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 rate adaptation approach that requires
incompatible changes to the IEEE 802.11 MAC. In order to enable the incompatible changes to the IEEE 802.11 MAC. In order to enable the
skipping to change at page 45, line 51 skipping to change at page 45, line 51
low-latency implementations. This enables rapid downward rate low-latency implementations. This enables rapid downward rate
negotiation on failure to receive an ACK, while increasing the amount negotiation on failure to receive an ACK, while increasing the amount
number of successful transmission required for upward rate number of successful transmission required for upward rate
negotiation. The AARF algorithm is therefore highly stable in negotiation. The AARF algorithm is therefore highly stable in
situations where channel properties are changing slowly, but slow to situations where channel properties are changing slowly, but slow to
adapt upwards when channel conditions improve. In order to test the adapt upwards when channel conditions improve. In order to test the
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 transmision. 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 and close to that of the RBAR algorithm,
while enabling practical implementation. 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
skipping to change at page 46, line 45 skipping to change at page 46, line 45
in the hybrid scheme, sends a fraction of data at adjacent rates in in the hybrid scheme, sends a fraction of data at adjacent rates in
order to estimate which rate provides the maximum throughput. 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 at are utilized for this purpose, this technique adapts more slowly at
lower rates; with 802.11b rates, the adaptation time scale is 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.
FER control Frame Error Rate (FER) control
This technique estimates the Frame Error Rate (FER), attempting to This technique estimates the FER, attempting to keep it between a
keep it between a lower limit (if FER moves below, increase rate) lower limit (if FER moves below, increase rate) and upper limit (if
and upper limit (if FER moves above, decrease rate). Since this FER moves above, decrease rate). Since this technique can utilize
technique can utilize all the transmitted data, it can respond all the transmitted data, it can respond faster than maximum
faster than maximum throughput techniques. However, there is a throughput techniques. However, there is a tradeoff of reaction
tradeoff of reaction time versus FER estimation accuracy; at lower time versus FER estimation accuracy; at lower rates either reaction
rates either reaction times slow or FER estimation accuracy will times slow or FER estimation accuracy will suffer. Since this
suffer. Since this technique only measures the FER at the current technique only measures the FER at the current rate, it can only
rate, it can only enable adaptation to adjacent rates. 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.
While statistics-based techniques are robust against short-lived link While statistics-based techniques are robust against short-lived link
quality changes, they do not respond quickly to long-lived changes. quality changes, they do not respond quickly to long-lived changes.
By constraining the rate selected by statistics-based techniques By constraining the rate selected by statistics-based techniques
based on ACK SSI versus rate data (not theoretical curves), more based on ACK SSI versus rate data (not theoretical curves), more
rapid link adaptation was enabled. In order to ensure rapid rapid link adaptation was enabled. In order to ensure rapid
adaptation during rapidly varying conditions, the rate constraints adaptation during rapidly varying conditions, the rate constraints
are tightened when the SSI values are changing rapidly, encouraging are tightened when the SSI values are changing rapidly, encouraging
rate transitions. The authors validated their algorithms by rate transitions. The authors validated their algorithms by
implementing a driver for the Atheros AR5000 chipset, and then implementing a driver for the Atheros AR5000 chipset, and then
testing its response to insertion and removal from a microwave oven testing its response to insertion and removal from a microwave oven
acting as a faraday cage. The hybrid algorithm dropped many fewer acting as a Faraday cage. The hybrid algorithm dropped many fewer
packets than the maximum throughput technique by itself. packets than the maximum throughput technique by itself.
In order to estimate the SSI of data at the receiver, the SSI of ACKs In order to estimate the SSI of data at the receiver, the SSI of ACKs
received at the sender was used. This approach did not require the received at the sender was used. This approach did not require the
receiver to provide the sender with the received SSI, so that it receiver to provide the sender with the received SSI, so that it
could be implemented without changing the IEEE 802.11 MAC. This could be implemented without changing the IEEE 802.11 MAC. This
scheme assumes that transmit power remains constant on the sender and scheme assumes that transmit power remains constant on the sender and
receiver and that channel properties in both direcctions vary slowly, receiver and that channel properties in both directions vary slowly,
so that the SSI of the received ACKs and sent data remain in so that the SSI of the received ACKs and sent data remain in
proportion. Actual data was used to determine the relationship proportion. Actual data was used to determine the relationship
between the ACK SSI and rate, so that the proportion itself does not between the ACK SSI and rate, so that the proportion itself does not
matter, just as long as it varies slowly. The authors checked the matter, just as long as it varies slowly. The authors checked the
proportionality assumption and found that the SSI of received data proportionality assumption and found that the SSI of received data
correlated highly (74%) with the SSI of received ACKs. Low pass correlated highly (74%) with the SSI of received ACKs. Low pass
filtering and monotonicity constraints were applied to remove the filtering and monotonicity constraints were applied to remove the
considerable noise in the SSI versus rate curves. considerable noise in the SSI versus rate curves.
In "Efficient Mobility Management for Vertical Handoff between WWAN In "Efficient Mobility Management for Vertical Handoff between WWAN
skipping to change at page 49, line 35 skipping to change at page 49, line 35
may be non-trivial to adjust the sending rates of individual may be non-trivial to adjust the sending rates of individual
connections where there are multiple connections open between a connections where there are multiple connections open between a
mobile node and correspondent node. A more conservative approach mobile node and correspondent node. A more conservative approach
would be to trigger parameter re-estimation and slow start based on would be to trigger parameter re-estimation and slow start based on
the receipt of a registration message or binding update. the receipt of a registration message or binding update.
In "Hotspot Mitigation Protocol (HMP)" [HMP], it is noted that MANET In "Hotspot Mitigation Protocol (HMP)" [HMP], it is noted that MANET
routing protocols have a tendency to concentrate traffic since they routing protocols have a tendency to concentrate traffic since they
utilize shortest path metrics and allow nodes to respond to route utilize shortest path metrics and allow nodes to respond to route
queries with cached routes. The authors propose that nodes queries with cached routes. The authors propose that nodes
participating in an adhoc wireless mesh monitor local conditions such participating in an ad-hoc wireless mesh monitor local conditions
as MAC delay, buffer consumption and packets loss. Where congestion such as MAC delay, buffer consumption and packets loss. Where
is detected, this is communicated to neighboring nodes via an IP congestion is detected, this is communicated to neighboring nodes via
option. In response to moderate congestion, nodes suppress route an IP option. In response to moderate congestion, nodes suppress
requests; where major congestion is detected, nodes throttle TCP route requests; where major congestion is detected, nodes throttle
connections flowing through them. The authors argue that for adhoc TCP connections flowing through them. The authors argue that for ad-
networks throttling by intermediate nodes is more effective than end- hoc networks throttling by intermediate nodes is more effective than
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 the Within the Transport layer, proposals have focused on countering the
effects of handoff-induced packet loss and non-congestive loss caused effects of handoff-induced packet loss and non-congestive loss caused
by lossy wireless links. by lossy wireless links.
Where a mobile host moves to a new network, the transport parameters Where a mobile host moves to a new network, the transport parameters
(including the RTT, RTO and congestion window) may no longer be (including the RTT, RTO and congestion window) may no longer be
valid. Where the path change occurs on the sender (e.g. change in valid. Where the path change occurs on the sender (e.g. change in
skipping to change at page 50, line 41 skipping to change at page 50, line 41
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 Binding receiver to communicate a subnet change to the sender via a 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 authors communication vehicle that can be universally employed, the authors
propose a TCP option that allows a connection endpoint to inform a propose a TCP option that allows a connection endpoint to inform a
peer of a subnet change. The document does not advocate utilization peer of a subnet change. The document does not advocate utilization
of "Link Up" or "Link Down" events since these events are not of "Link Up" or "Link Down" events since these events are not
necessarily indicative of subnet change. On detection of subnet necessarily indicative of subnet change. On detection of subnet
change, it is advocated that the congestion window be reset to change, it is advocated that the congestion window be reset to
INIT_WINDOW and that transport parameters be reestimated. The INIT_WINDOW and that transport parameters be re-estimated. The
authors argue that recovery from slow start results in higher authors argue that recovery from slow start results in higher
throughput both when the subnet change results in lower bottleneck throughput both when the subnet change results in lower bottleneck
bandwidth as well as when bottleneck bandwidth increases. bandwidth as well as when bottleneck bandwidth increases.
In "Efficient Mobility Management for Vertical Handoff between WWAN In "Efficient Mobility Management for Vertical Handoff between WWAN
and WLAN" [Vertical] the authors propose a "Virtual Connectivity and WLAN" [Vertical] the authors propose a "Virtual Connectivity
Manager" which utilizes local connection translation (LCT) and a Manager" which utilizes local connection translation (LCT) and a
subscription/notification service supporting simultaneous movement in subscription/notification service supporting simultaneous movement in
order to enable end-to-end mobility and maintain TCP throughput order to enable end-to-end mobility and maintain TCP throughput
during vertical handovers. during vertical handovers.
In an early draft of [RFC4340], a "Reset Congestion State" option was In an early draft of [RFC4340], a "Reset Congestion State" option was
proposed in Section 4. This option was removed in part because the proposed in Section 4. This option was removed in part because the
use conditions were not fully understood: use conditions were not fully understood:
An Half-Connection Receiver sends the Reset Congestion State option An Half-Connection Receiver sends the Reset Congestion State
to its sender to force the sender to reset its congestion state -- option to its sender to force the sender to reset its congestion
that is, to "slow start", as if the connection were beginning again. state -- that is, to "slow start", as if the connection were
... beginning again.
The Reset Congestion State option is reserved for the very few cases ... The Reset Congestion State option is reserved for the very
when an endpoint knows that the congestion properties of a path have few cases when an endpoint knows that the congestion properties of
changed. Currently, this reduces to mobility: a DCCP endpoint on a a path have changed. Currently, this reduces to mobility: a DCCP
mobile host MUST send Reset Congestion State to its peer after the endpoint on a mobile host MUST send Reset Congestion State to its
mobile host changes address or path. peer after the mobile host changes address or path.
"Framework and Requirements for TRIGTRAN" [TRIGTRAN] discusses "Framework and Requirements for TRIGTRAN" [TRIGTRAN] discusses
optimizations to recover earlier from a retransmission timeout optimizations to recover earlier from a retransmission timeout
incurred during a period in which an interface or intervening link incurred during a period in which an interface or intervening link
was down. "End-to-end, Implicit 'Link-Up' Notification" [E2ELinkup] was down. "End-to-end, Implicit 'Link-Up' Notification" [E2ELinkup]
describes methods by which a TCP implementation that has backed off describes methods by which a TCP implementation that has backed off
its retransmission timer due to frame loss on a remote link can learn its retransmission timer due to frame loss on a remote link can learn
that the link has once again become operational. This enables that the link has once again become operational. This enables
retransmission to be attempted prior to expiration of the backed off retransmission to be attempted prior to expiration of the backed off
retransmission timer. retransmission timer.
skipping to change at page 51, line 47 skipping to change at page 51, line 47
to regularly scheduled retransmissions that retransmission be to regularly scheduled retransmissions that retransmission be
attempted by the Transport layer on receipt of an indication that attempted by the Transport layer on receipt of an indication that
connectivity to a peer node may have been restored. End-to-end connectivity to a peer node may have been restored. End-to-end
connectivity restoration indications include "Link Up", confirmation connectivity restoration indications include "Link Up", confirmation
of first-hop router reachability, confirmation of Internet layer of first-hop router reachability, confirmation of Internet layer
configuration, and receipt of other traffic from the peer. configuration, and receipt of other traffic from the peer.
In "Discriminating Congestion Losses from Wireless Losses Using In "Discriminating Congestion Losses from Wireless Losses Using
Interarrival Times at the Receiver" [Biaz], the authors propose a Interarrival Times at the Receiver" [Biaz], the authors propose a
scheme for differentiating congestive losses from wireless scheme for differentiating congestive losses from wireless
transmission losses based on interarrival times. Where the loss is transmission losses based on inter-arrival times. Where the loss is
due to wireless transmission rather than congestion, congestive due to wireless transmission rather than congestion, congestive
backoff and cwnd adjustment is omitted. However, the scheme appears backoff and cwnd adjustment is omitted. However, the scheme appears
to assume equal spacing between packets, which is not realistic in an to assume equal spacing between packets, which is not realistic in an
environment exhibiting link layer frame loss. The scheme is shown to environment exhibiting link layer frame loss. The scheme is shown to
function well only when the wireless link is the bottleneck, which is function well only when the wireless link is the bottleneck, which is
often the case with cellular networks, but not with IEEE 802.11 often the case with cellular networks, but not with IEEE 802.11
deployment scenarios such as home or hotspot use. deployment scenarios such as home or hotspot use.
In "Improving Performance of TCP over Wireless Networks" [Bakshi], In "Improving Performance of TCP over Wireless Networks" [Bakshi],
the authors focus on the performance of TCP over wireless networks the authors focus on the performance of TCP over wireless networks
skipping to change at page 53, line 4 skipping to change at page 53, line 4
transport retransmission timers were also noted. Where the route transport retransmission timers were also noted. Where the route
request timer is too large, new routes cannot be supplied in time to request timer is too large, new routes cannot be supplied in time to
prevent the transport timer from expiring, and where the route prevent the transport timer from expiring, and where the route
request timer is too small, network congestion may result. For their request timer is too small, network congestion may result. For their
implementation of ELFN, the authors piggybacked additional implementation of ELFN, the authors piggybacked additional
information on an existing "route failure" notice (sender and information on an existing "route failure" notice (sender and
receiver addresses and ports, the TCP sequence number) to enable the receiver addresses and ports, the TCP sequence number) to enable the
sender to identify the affected connection. Where a TCP receives an sender to identify the affected connection. Where a TCP receives an
ELFN, it disables the retransmission timer and enters "stand-by" ELFN, it disables the retransmission timer and enters "stand-by"
mode, where packets are sent at periodic intervals to determine if mode, where packets are sent at periodic intervals to determine if
the route has been reestablished. If an acknowledgement is received the route has been reestablished. If an acknowledgment is received
then the retransmission timers are restored. Simulations show that then the retransmission timers are restored. Simulations show that
performance is sensitive to the probe interval, with intervals of 30 performance is sensitive to the probe interval, with intervals of 30
seconds or greater giving worse performance than TCP-Reno. The seconds or greater giving worse performance than TCP-Reno. The
affect of resetting the congestion window and RTO values was also affect of resetting the congestion window and RTO values was also
investigated. In the study, resetting congestion window to one did investigated. In the study, resetting congestion window to one did
not have much of an effect on throughput, since the bandwidth/delay not have much of an effect on throughput, since the bandwidth/delay
of the network was only a few packets. However, resetting the RTO to of the network was only a few packets. However, resetting the RTO to
a high initial value (6 seconds) did have a substantial detrimental a high initial value (6 seconds) did have a substantial detrimental
effect, particularly at high speed. In terms of the probe packet effect, particularly at high speed. In terms of the probe packet
sent, the simulations showed little difference between sending the sent, the simulations showed little difference between sending the
first packet in the congestion window, or retransmitting the packet first packet in the congestion window, or retransmitting the packet
with the lowest sequence number among those signalled as lost via the with 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 exhaustion access point on failure of a transmission attempt. After exhaustion
of retransmission attempts, an ICMP-RETRANSMIT message is sent. On of retransmission attempts, an ICMP-RETRANSMIT message is sent. On
receipt of an ICMP-DEFER message, the expiry of the retransmission receipt of an ICMP-DEFER message, the expiry of the retransmission
timer is postponed by the current RTO estimate. On receipt of an timer is postponed by the current RTO estimate. On receipt of an
ICMP-RETRANSMIT message, the segment is retransmitted. On ICMP-RETRANSMIT message, the segment is retransmitted. On
retransmission, the congestion window is not reduced; when coming out retransmission, the congestion window is not reduced; when coming out
of fast recovery, the congestion window is reset to its value prior of fast recovery, the congestion window is reset to its value prior
to fast retransmission and fast recovery. Using a two-state Markov to fast retransmission and fast recovery. Using a two-state Markov
model, simulated using ns-2, the authors show that the scheme model, simulated using ns-2, the authors show that the scheme
improves throughput. improves throughput.
In "Explicit Transport Error Notification (ETEN) for Error-Prone In "Explicit Transport Error Notification (ETEN) for Error-Prone
Wireless and Satellite Networks" [Krishan], the authors examine the Wireless and Satellite Networks" [Krishnan], the authors examine the
use of explicit transport error notification (ETEN) to aid TCP in use of explicit transport error notification (ETEN) to aid TCP in
distinguishing congestive losses from those due to corruption. Both distinguishing congestive losses from those due to corruption. Both
per-packet and cumulative ETEN mechanisms were simulated in ns-2, per-packet and cumulative ETEN mechanisms were simulated in ns-2,
using both TCP Reno and TCP SACK over a wide range of bit error rates using both TCP Reno and TCP SACK over a wide range of bit error rates
and traffic conditions. While per-packet ETEN mechanisms provided and traffic conditions. While per-packet ETEN mechanisms provided
substantial gains in TCP goodput without congestion, where congestion substantial gains in TCP goodput without congestion, where congestion
was also present, the gains were not significant. Cumulative ETEN was also present, the gains were not significant. Cumulative ETEN
mechanisms did not perform as well in the study. The authors point mechanisms did not perform as well in the study. The authors point
out that ETEN faces significant deployment barriers since it can out that ETEN faces significant deployment barriers since it can
create new security vulnerabilities and requires implementations to create new security vulnerabilities and requires implementations to
obtain reliable information from the headers of corrupt packets. obtain reliable information from the headers of corrupt packets.
In "Towards More Expressive Transport-Layer Interfaces" [Eggert2] the
authors propose extensions to existing network/transport and
transport/application interfaces to improve the performance of the
transport layer in the face of changes in path characteristics
varying more quickly than the round-trip time.
In "Protocol Enhancements for Intermittently Connected Hosts"
[Schuetz], the authors note that intermittent connectivity can lead
to poor performance and connectivity failures. To address these
problems, the authors combine the use of the Host Identity Protocol
(HIP) with a TCP User Timeout Option and TCP Retransmission trigger,
demonstrating significant improvement.
A.4 Application Layer A.4 Application Layer
In "Application-oriented Link Adaptation for IEEE 802.11" In "Application-oriented Link Adaptation for IEEE 802.11"
[Haratcherev2], rate information generated by a link layer utilizing [Haratcherev2], rate information generated by a link layer utilizing
improved rate adaptation algorithms is provided to a video improved rate adaptation algorithms is provided to a video
application, and used for codec adaptation. Coupling the MAC and application, and used for codec adaptation. Coupling the link and
application layers results in major improvements in the Peak application layers results in major improvements in the Peak
Signal/Noise Ratio (PSNR). Signal/Noise Ratio (PSNR).
At the Application layer, the usage of "Link Down" indications has At the Application layer, the usage of "Link Down" indications has
been proposed to augment presence systems. In such systems, client been proposed to augment presence systems. In such systems, client
devices periodically refresh their presence state using application devices periodically refresh their presence state using application
layer protocols such as SIMPLE [RFC3428] or XMPP [RFC3921]. If the layer protocols such as SIMPLE [RFC3428] or XMPP [RFC3921]. If the
client should become disconnected, their unavailability will not be client should become disconnected, their unavailability will not be
detected until the presence status times out, which can take many detected until the presence status times out, which can take many
minutes. However, if a link goes down, and a disconnect indication minutes. However, if a link goes down, and a disconnect indication
skipping to change at page 54, line 34 skipping to change at page 55, line 21
Elwyn Davies Elwyn Davies
Kevin Fall Kevin Fall
Olaf Kolkman Olaf Kolkman
Kurtis Lindqvist Kurtis Lindqvist
David Meyer David Meyer
David Oran David Oran
Eric Rescorla Eric Rescorla
Dave Thaler Dave Thaler
Lixia Zhang Lixia Zhang
Intellectual Property Statement Authors' Addresses
Bernard Aboba
Microsoft Corporation
One Microsoft Way
Redmond, WA 98052
EMail: bernarda@microsoft.com
Phone: +1 425 706 6605
Fax: +1 425 936 7329
Full Copyright Statement
Copyright (C) The IETF Trust (2007).
This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors
retain all their rights.
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Intellectual Property
The IETF takes no position regarding the validity or scope of any The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79. found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr. http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at ietf- this standard. Please address the information to the IETF at
ipr@ietf.org. ietf-ipr@ietf.org.
Disclaimer of Validity
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Copyright Statement
Copyright (C) The Internet Society (2006). This document is subject
to the rights, licenses and restrictions contained in BCP 78, and
except as set forth therein, the authors retain all their rights.
Acknowledgment Acknowledgment
Funding for the RFC Editor function is currently provided by the Funding for the RFC Editor function is currently provided by the
Internet Society. Internet Society.
 End of changes. 109 change blocks. 
443 lines changed or deleted 501 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/