draft-iab-link-indications-06.txt   draft-iab-link-indications-07.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-06.txt> <draft-iab-link-indications-07.txt>
2 February 2007 6 February 2007
Architectural Implications of Link Indications Architectural Implications of Link Indications
By submitting this Internet-Draft, each author represents that any By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79. aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
skipping to change at page 1, line 32 skipping to change at page 1, line 32
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt. http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
This Internet-Draft will expire on August 2, 2007. This Internet-Draft will expire on August 8, 2007.
Copyright Notice Copyright Notice
Copyright (C) The IETF Trust (2007). Copyright (C) The IETF Trust (2007).
Abstract Abstract
A link indication represents information provided by the link layer A link indication represents information provided by the link layer
to higher layers regarding the state of the link. This document to higher layers regarding the state of the link. This document
describes the role of link indications within the Internet describes the role of link indications within the Internet
skipping to change at page 2, line 39 skipping to change at page 2, line 39
6.1 Informative 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 ..................................... 55 Appendix B - IAB Members ..................................... 55
Authors' Addresses ........................................... 55 Authors' Addresses ........................................... 55
Full Copyright Statement ..................................... 55 Full Copyright Statement ..................................... 55
Intellectual Property Statement .............................. 56 Intellectual Property ........................................ 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. While the to higher layers regarding the state of the link. While the
judicious use of link indications can provide performance benefits, judicious use of link indications can provide performance benefits,
inappropriate use can degrade both robustness and performance. inappropriate use can degrade both robustness and performance.
This document summarizes the current understanding of the role of This document summarizes the current understanding of the role of
link indications, and provides advice to document authors about the link indications, and provides advice to document authors about the
skipping to change at page 4, line 36 skipping to change at page 4, line 36
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].
Strong End System Model Strong End System Model
In the Strong End System model, packets sent out an interface have In the Strong End System model, packets sent out an interface have
a source address configured on that interface and incoming packets a source address configured on that interface and incoming packets
whose destination does not correspond to the physical interface whose destination does not correspond to the physical interface
through which it is received are silently discarded. In general, through which it is received are silently discarded. In general,
the Strong End System model emphasizes the host/gateway the Strong End System model emphasizes the host/router distinction,
distinction, tending to model a multihomed host as a set of logical tending to model a multihomed host as a set of logical hosts within
hosts within the same physical host. the same physical host.
Weak End System Model Weak End System Model
In the Weak End System Model, packets sent out an interface need In the Weak End System Model, packets sent out an interface need
not necessarily have a source address configured on that interface, not necessarily have a source address configured on that interface,
and incoming packets whose destination does not correspond to the and incoming packets whose destination does not correspond to the
physical interface through which it is received are accepted. 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
skipping to change at page 6, line 31 skipping to change at page 6, line 31
1.4.1. Internet Layer 1.4.1. Internet Layer
One of the functions of the Internet layer is to shield higher layers 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 from the specifics of link behavior. As a result, the Internet layer
validates and filters link indications and selects outgoing and validates and filters link indications and selects outgoing and
incoming interfaces based on routing metrics. incoming interfaces based on routing metrics.
The Internet layer composes its routing table based on information The Internet layer composes its routing table based on information
available from local interfaces as well as potentially by taking into available from local interfaces as well as potentially by taking into
account information provided by gateways. This enables the state of account information provided by routers. This enables the state of
the local routing table to reflect link conditions on both local and the local routing table to reflect link conditions on both local and
remote links. For example, prefixes to be added or removed from the remote links. For example, prefixes to be added or removed from the
routing table may be determined from DHCP [RFC2131][RFC3315], Router routing table may be determined from DHCP [RFC2131][RFC3315], Router
Advertisements [RFC1256][RFC2461], re-direct messages or route Advertisements [RFC1256][RFC2461], re-direct messages or route
updates incorporating information on the state of links multiple hops updates incorporating information on the state of links multiple hops
away. away.
The Internet layer also utilizes link indications in order to The Internet layer also utilizes link indications in order to
optimize aspects of Internet Protocol (IP) configuration and optimize aspects of Internet Protocol (IP) configuration and
mobility. After receipt of a "Link Up" indication, hosts validate mobility. After receipt of a "Link Up" indication, hosts validate
skipping to change at page 8, line 20 skipping to change at page 8, line 20
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 receives processes link indications differently The Transport layer processes link indications differently for the
for the purposes of transport parameter estimation and connection purposes of transport parameter estimation and connection management.
management.
For the purposes of parameter estimation, the Transport layer is For the purposes of parameter estimation, the Transport layer is
primarily interested in path properties that impact performance, and primarily interested in path properties that impact performance, and
where link indications may be determined to be relevant to path where link indications may be determined to be relevant to path
properties they may be utilized directly. Link indications such properties they may be utilized directly. Link indications such
"Link Up"/"Link Down" or changes in rate, delay and frame loss may "Link Up"/"Link Down" or changes in rate, delay and frame loss may
prove relevant. This will not always be the case, however; where the prove relevant. This will not always be the case, however; where the
bottleneck bandwidth is already much lower than the link rate, an bottleneck bandwidth is already much lower than the link rate, an
increase in link rate may not materially affect path properties. As increase in link rate may not materially affect path properties. As
described in Appendix A.3, the algorithms for utilizing link layer described in Appendix A.3, the algorithms for utilizing link layer
skipping to change at page 9, line 4 skipping to change at page 8, line 51
as a result, so that no Internet layer indication would be sent. as a result, so that no Internet layer indication would be sent.
For the purposes of parameter estimation, the Transport layer may For the purposes of parameter estimation, the Transport layer may
also wish to use Internet layer indications. For example, path also wish to use Internet layer indications. For example, path
change indications can be used as a signal to reset parameter change indications can be used as a signal to reset parameter
estimates. Changes in the routing table may also be useful; loss of estimates. Changes in the routing table may also be useful; loss of
segments sent to a destination with no prefix in the routing table segments sent to a destination with no prefix in the routing table
may be assumed to be due to causes other than congestion, regardless may be assumed to be due to causes other than congestion, regardless
of the reason for the removal (either because local link conditions of the reason for the removal (either because local link conditions
caused it to be removed or because the route was withdrawn by a caused it to be removed or because the route was withdrawn by a
remote gateway). remote router).
For the purposes of connection management, layering considerations For the purposes of connection management, layering considerations
are important; the Transport layer typically only utilizes Internet are important; the Transport layer typically only utilizes Internet
layer indications such as changes in the incoming/outgoing interface layer indications such as changes in the incoming/outgoing interface
and IP configuration changes. 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"
skipping to change at page 15, line 37 skipping to change at page 15, line 37
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 common such as multi-path interference, conditions. Due to common effects such as multi-path interference,
signal strength and signal/noise ratio (SNR) may vary rapidly over signal strength and signal/noise ratio (SNR) may vary rapidly over
a short distance, causing erratic behavior of link indications a short distance, causing erratic behavior of link indications
based on unfiltered measurements. As noted in [Haratcherev], based on unfiltered measurements. As noted in [Haratcherev],
signal strength may prove most useful when utilized in combination signal strength may prove most useful when utilized in combination
with other measurements, such as frame loss. with other measurements, such as frame loss.
[3] Where possible, design link indications with built-in damping. By [3] Where possible, design link indications with built-in damping. By
design, the "Link Up" and "Link Down" events relate to changes in design, the "Link Up" and "Link Down" events relate to changes in
the state of the link layer that make it able and unable to the state of the link layer that make it able and unable to
communicate IP packets. These changes are either generated by the communicate IP packets. These changes are either generated by the
link layer state machine based on link layer exchanges (e.g. link layer state machine based on link layer exchanges (e.g.
completion of the IEEE 802.11i four-way handshake for "Link Up", or completion of the IEEE 802.11i four-way handshake for "Link Up", or
receipt of a PPP LCP-Terminate for "Link Down") or by protracted receipt of a PPP LCP-Terminate for "Link Down") or by protracted
frame loss, so that the link layer concludes that the link is no frame loss, so that the link layer concludes that the link is no
longer usable. As a result, these link indications are typically longer usable. As a result, these link indications are typically
less sensitive to changes in transient link conditions. less sensitive to changes in transient link conditions.
[4] Do not assume that a "Link Down" event will be sent at all, or that [4] Do not assume that a "Link Down" event will be sent at all, or that
if sent, that it will received in a timely way. A good link layer if sent, that it will be received in a timely way. A good link
implementation will both rapidly detect connectivity failure (such layer implementation will both rapidly detect connectivity failure
as by tracking missing Beacons) while sending a "Link Down" event (such as by tracking missing Beacons) while sending a "Link Down"
only when it concludes the link is unusable, not due to transient event only when it concludes the link is unusable, not due to
frame loss. transient frame loss.
However, existing wireless LAN implementations often do not do a However, existing wireless LAN implementations often do not do a
good job of detecting link failure. During a lengthy detection good job of detecting link failure. During a lengthy detection
phase, a "Link Down" event is not sent by the link layer, yet IP phase, a "Link Down" event is not sent by the link layer, yet IP
packets cannot be transmitted or received on the link. Initiation packets cannot be transmitted or received on the link. Initiation
of a scan may be delayed so that the station cannot find another of a scan may be delayed so that the station cannot find another
point of 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. This is not as much of a problem for cellular networks problems. This is not as much of a problem for cellular networks
which utilize transmit power adjustment. which utilize transmit power adjustment.
skipping to change at page 16, line 42 skipping to change at page 16, line 42
2.3.1. Implementation Variation 2.3.1. Implementation Variation
Variations in link layer implementations may have a substantial Variations in link layer implementations may have a substantial
impact on the behavior of link indications. These variations need to impact on the behavior of link indications. These variations need to
be taken into account in evaluating the performance of proposals. be taken into account in evaluating the performance of proposals.
For example, radio propagation and implementation differences can For example, radio propagation and implementation differences can
impact the reliability of Link indications. impact the reliability of Link indications.
In "Link-level Measurements from an 802.11b Mesh Network" [Aguayo] In "Link-level Measurements from an 802.11b Mesh Network" [Aguayo]
analyzes the causes of frame loss in a 38-node urban multi-hop IEEE the authors analyze the cause of frame loss in a 38-node urban multi-
802.11 ad-hoc network. In most cases, links that are very bad in hop IEEE 802.11 ad-hoc network. In most cases, links that are very
one direction tend to be bad in both directions, and links that are bad in one direction tend to be bad in both directions, and links
very good in one direction tend to be good in both directions. that are very good in one direction tend to be good in both
However, 30 percent of links exhibited loss rates differing directions. However, 30 percent of links exhibited loss rates
substantially in each direction. differing substantially in each direction.
As described in [Aguayo], wireless LAN links often exhibit loss rates As described in [Aguayo], wireless LAN links often exhibit loss rates
intermediate between "up" (low loss) and "down" (high loss) states, intermediate between "up" (low loss) and "down" (high loss) states,
as well as substantial asymmetry. As a result, receipt of a "Link as well as substantial asymmetry. As a result, receipt of a "Link
Up" indication may not necessarily indicate bi-directional Up" indication may not necessarily indicate bi-directional
reachability, since it could have been generated after exchange of reachability, since it could have been generated after exchange of
small frames at low rates, which might not imply bi-directional small frames at low rates, which might not imply bi-directional
connectivity for large frames exchanged at higher rates. connectivity for large frames exchanged at higher rates.
Where multi-path interference or hidden nodes are encountered, signal Where multi-path interference or hidden nodes are encountered, signal
skipping to change at page 23, line 18 skipping to change at page 23, line 18
maximizing effective throughput. Where the negotiated rate is maximizing effective throughput. Where the negotiated rate is
constant, the expected transmission time is proportional to ETX, so constant, the expected transmission time is proportional to ETX, so
that minimizing ETX also minimizes expected transmission time. that minimizing ETX also minimizes expected transmission time.
However, where the negotiated rate may vary, ETX may not represent a However, where the negotiated rate may vary, ETX may not represent a
good estimate of the estimated transmission time. In "Routing in good estimate of the estimated transmission time. In "Routing in
multi-radio, multi-hop wireless mesh networks" [ETX-Rate] the authors multi-radio, multi-hop wireless mesh networks" [ETX-Rate] the authors
define a new metric called Expected Transmission Time (ETT). This is define a new metric called Expected Transmission Time (ETT). This is
described as a "bandwidth adjusted ETX" since ETT = ETX * S/B where S described as a "bandwidth adjusted ETX" since ETT = ETX * S/B where S
is the size of the probe packet and B is the bandwidth of the link as is the size of the probe packet and B is the bandwidth of the link as
measured by packet pair [Morgan]. However, ETT assumed that the loss measured by a packet pair [Morgan]. However, ETT assumed that the
fraction of small probe frames sent at 1 Mbps data rate is indicative loss fraction of small probe frames sent at 1 Mbps data rate is
of the loss fraction of larger data frames at higher rates, which indicative of the loss fraction of larger data frames at higher
tends to under-estimate the ETT at higher rates, where frame loss rates, which tends to under-estimate the ETT at higher rates, where
typically increases. In "A Radio Aware Routing Protocol for Wireless frame loss typically increases. In "A Radio Aware Routing Protocol
Mesh Networks" [ETX-Radio] the authors refine the ETT metric further for Wireless Mesh Networks" [ETX-Radio] the authors refine the ETT
by estimating the loss fraction as a function of data rate. metric further by estimating the loss fraction as a function of data
rate.
However, prior to sending data packets over the link, the appropriate However, prior to sending data packets over the link, the appropriate
routing metric may not be easily be predicted. As noted in routing metric may not be easily be predicted. As noted in
[Shortest], a link that can successfully transmit the short frames [Shortest], a link that can successfully transmit the short frames
utilized for control, management or routing may not necessarily be utilized for control, management or routing may not necessarily be
able to reliably transport larger data packets. The rate adaptation able to reliably transport larger data packets. 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 be available before a
is used for the first time. link is used for the first time.
Therefore it may be necessary to utilize alternative metrics (such as Therefore it may be necessary to utilize alternative metrics (such as
signal strength or access point load) in order to assist in signal strength or access point load) in order to assist in
attachment/handoff decisions. However, unless the new interface is attachment/handoff decisions. However, unless the new interface is
the preferred route for one or more destination prefixes, a Weak End the preferred route for one or more destination prefixes, a Weak End
System implementation will not use the new interface for outgoing System implementation will not use the new interface for outgoing
traffic. Where "idle timeout" functionality is implemented, the traffic. Where "idle timeout" functionality is implemented, the
unused interface will be brought down, only to be brought up again by unused interface will be brought down, only to be brought up again by
the link enablement algorithm. the link enablement algorithm.
skipping to change at page 28, line 17 skipping to change at page 28, line 17
frame with the station's source address to a multicast address, frame with the station's source address to a multicast address,
thereby causing switches within the Distribution System (DS) to learn thereby causing switches within the Distribution System (DS) to learn
the station's MAC address. While this enables forwarding of frames the station's MAC address. While this enables forwarding of frames
to the station at the new point of attachment, it also permits an to the station at the new point of attachment, it also permits an
attacker to disassociate a station located anywhere within the ESS, attacker to disassociate a station located anywhere within the ESS,
by sending an unauthenticated Reassociation Request frame. by sending an unauthenticated Reassociation Request frame.
4.2. Indication Validation 4.2. Indication Validation
"Fault Isolation and Recovery" [RFC816] Section 3 describes how hosts "Fault Isolation and Recovery" [RFC816] Section 3 describes how hosts
interact with gateways for the purpose of fault recovery: interact with routers for the purpose of fault recovery:
Since the gateways always attempt to have a consistent and correct Since the gateways always attempt to have a consistent and correct
model of the internetwork topology, the host strategy for fault model of the internetwork topology, the host strategy for fault
recovery is very simple. Whenever the host feels that something recovery is very simple. Whenever the host feels that something
is wrong, it asks the gateway for advice, and, assuming the advice is wrong, it asks the gateway for advice, and, assuming the advice
is forthcoming, it believes the advice completely. The advice is forthcoming, it believes the advice completely. The advice
will be wrong only during the transient period of negotiation, will be wrong only during the transient period of negotiation,
which immediately follows an outage, but will otherwise be which immediately follows an outage, but will otherwise be
reliably correct. reliably correct.
skipping to change at page 28, line 45 skipping to change at page 28, line 45
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 for revise its routing table to have a different immediate address for
this net. The ICMP "destination unreachable" message indicates this net. The ICMP "destination unreachable" message indicates
that as a result of an outage, it is currently impossible to reach that as a result of an outage, it is currently impossible to reach
the addressed net or host in any manner. On receipt of this the addressed net or host in any manner. On receipt of this
message, a host can either abandon the connection immediately message, a host can either abandon the connection immediately
without any further retransmission, or resend slowly to see if the without any further retransmission, or resend slowly to see if the
fault is corrected in reasonable time. fault is corrected in reasonable time.
Given today's security environment, it is inadvisable for hosts to Given today's security environment, it is inadvisable for hosts to
act on indications provided by gateways without careful act on indications provided by routers without careful consideration.
consideration. As noted in "ICMP attacks against TCP" [Gont], As noted in "ICMP attacks against TCP" [Gont], existing ICMP error
existing ICMP error messages may be exploited by attackers in order messages may be exploited by attackers in order to abort connections
to abort connections in progress, prevent setup of new connections, in progress, prevent setup of new connections, or reduce throughput
or reduce throughput of ongoing connections. Similar attacks may of ongoing connections. Similar attacks may also be launched against
also be launched against the Internet layer via forging of ICMP the Internet layer via forging of ICMP redirects.
redirects.
Proposals for transported link indications need to demonstrate that Proposals for transported link indications need to demonstrate that
they will not add a new set of similar vulnerabilities. Since they will not add a new set of similar vulnerabilities. Since
transported link indications are typically unauthenticated, hosts transported link indications are typically unauthenticated, hosts
receiving them may not be able to determine whether they are receiving them may not be able to determine whether they are
authentic, or even plausible. authentic, or even plausible.
Where link indication proposals may respond to unauthenticated link Where link indication proposals may respond to unauthenticated link
layer frames, they should be utilize upper layer security mechanisms, layer frames, they should utilize upper layer security mechanisms,
where possible. For example, even though a host might utilize an where possible. For example, even though a host might utilize an
unauthenticated link layer control frame to conclude that a link has unauthenticated link layer control frame to conclude that a link has
become operational, it can use SEND [RFC3971] or authenticated DHCP become operational, it can use SEND [RFC3971] or authenticated DHCP
[RFC3118] in order to obtain secure Internet layer configuration. [RFC3118] in order to obtain secure Internet layer configuration.
4.3. Denial of Service 4.3. Denial of Service
Link indication proposals need to be particularly careful to avoid Link indication proposals need to be particularly careful to avoid
enabling denial of service attacks that can mounted at a distance. enabling denial of service attacks that can be mounted at a distance.
While wireless links are naturally vulnerable to interference, such While wireless links are naturally vulnerable to interference, such
attacks can only be perpetrated by an attacker capable of attacks can only be perpetrated by an attacker capable of
establishing radio contact with the target network. establishing radio contact with the target network.
However, attacks that can be mounted from a distance, either by an However, attacks that can be mounted from a distance, either by an
attacker on another point of attachment within the same network, or attacker on another point of attachment within the same network, or
by an off-link attacker, greatly expand the level of vulnerability. by an off-link attacker, greatly expand the level of vulnerability.
By enabling the transport of link indications, it is possible to By enabling the transport of link indications, it is possible to
transform an attack that might otherwise be restricted to attackers transform an attack that might otherwise be restricted to attackers
skipping to change at page 36, line 13 skipping to change at page 36, line 13
mip6-authorization-eap-04.txt, Internet draft (work in mip6-authorization-eap-04.txt, Internet draft (work in
progress), October 2006. progress), October 2006.
[Mishra] Mitra, A., Shin, M., and W. Arbaugh, "An Empirical [Mishra] Mitra, A., Shin, M., and W. Arbaugh, "An Empirical
Analysis of the IEEE 802.11 MAC Layer Handoff Process", Analysis of the IEEE 802.11 MAC Layer Handoff Process",
CS-TR-4395, University of Maryland Department of Computer CS-TR-4395, University of Maryland Department of Computer
Science, September 2002. Science, September 2002.
[Morgan] Morgan, S. and S. Keshav, "Packet-Pair Rate Control - [Morgan] Morgan, S. and S. Keshav, "Packet-Pair Rate Control -
Buffer Requirements and Overload Performance", Technical Buffer Requirements and Overload Performance", Technical
Memorandum, AT&T Bell Laaboratoies, October 1994. Memorandum, AT&T Bell Laboratoies, 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.
and S. Josefsson, "Protected EAP Protocol (PEAP) Version and S. Josefsson, "Protected EAP Protocol (PEAP) Version
2", draft-josefsson-pppext-eap-tls-eap-10.txt, Internet 2", draft-josefsson-pppext-eap-tls-eap-10.txt, Internet
draft (work in progress), October 2004. draft (work in progress), October 2004.
skipping to change at page 37, line 31 skipping to change at page 37, line 31
[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-IMIT- performance and its effect on voice traffic", TRITA-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-
l2-triggers-00.txt, Internet Draft (work in progress),
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.
[Vertical] Zhang, Q., Guo, C., Guo, Z. and W. Zhu, "Efficient [Vertical] Zhang, Q., Guo, C., Guo, Z. and W. Zhu, "Efficient
Mobility Management for Vertical Handoff between WWAN and Mobility Management for Vertical Handoff between WWAN and
WLAN", IEEE Communications Magazine, November 2003. WLAN", IEEE Communications Magazine, November 2003.
[Villamizar] Villamizar, C., "OSPF Optimized Multipath (OSPF-OMP)", [Villamizar] Villamizar, C., "OSPF Optimized Multipath (OSPF-OMP)",
draft-ietf-ospf-omp-02.txt, Internet draft (work in draft-ietf-ospf-omp-02.txt, Internet draft (work in
progress), February 1999. progress), February 1999.
[Xylomenos] Xylomenos, G., "Multi Service Link Layers: An Approach to [Xylomenos] Xylomenos, G., "Multi Service Link Layers: An Approach to
Enhancing Internet Performance over Wireless Links", Enhancing Internet Performance over Wireless Links",
Ph.D. thesis, University of California at San Diego, Ph.D. thesis, University of California at San Diego,
1999. 1999.
[Yegin] Yegin, A., "Link-layer Triggers Protocol", draft-yegin-
l2-triggers-00.txt, Internet Draft (work in progress),
June 2002.
Appendix A - Literature Review Appendix A - Literature Review
This Appendix summarizes the literature with respect to link This Appendix summarizes the literature with respect to link
indications on wireless local area networks. indications on wireless local area networks.
A.0 Terminology A.0 Terminology
Access Point (AP) Access Point (AP)
A station that provides access to the fixed network (e.g. an 802.11 A station that provides access to the fixed network (e.g. an 802.11
Distribution System), via the wireless medium (WM) for associated Distribution System), via the wireless medium (WM) for associated
skipping to change at page 39, line 23 skipping to change at page 39, line 23
necessarily an indication that the link is useful for delivery of necessarily an indication that the link is useful for delivery of
data. data.
In "Measurement and Analysis of the Error Characteristics of an In- In "Measurement and Analysis of the Error Characteristics of an In-
Building Wireless Network" [Eckhardt], the authors characterize the Building Wireless Network" [Eckhardt], the authors characterize the
performance of an AT&T Wavelan 2 Mbps in-building WLAN operating in performance of an AT&T Wavelan 2 Mbps in-building WLAN operating in
Infrastructure mode on the Carnegie-Mellon Campus. In this study, Infrastructure mode on the Carnegie-Mellon Campus. In this study,
very low frame loss was experienced. As a result, links could either very low frame loss was experienced. As a result, links could either
be assumed to operate very well or not at all. be assumed to operate very well or not at all.
"Link-level Measurements from an 802.11b Mesh Network" [Aguayo] "Link-level Measurements from an 802.11b Mesh Network" [Aguayo] the
analyzes the causes of frame loss in a 38-node urban multi-hop 802.11 authors analyze the causes of frame loss in a 38-node urban multi-hop
ad-hoc network. In most cases, links that are very bad in one 802.11 ad-hoc network. In most cases, links that are very bad in
direction tend to be bad in both directions, and links that are very one direction tend to be bad in both directions, and links that are
good in one direction tend to be good in both directions. However, very good in one direction tend to be good in both directions.
30 percent of links exhibited loss rates differing substantially in However, 30 percent of links exhibited loss rates differing
each direction. substantially in each direction.
Signal to noise ratio and distance showed little value in predicting Signal to noise ratio and distance showed little value in predicting
loss rates, and rather than exhibiting a step-function transition loss rates, and rather than exhibiting a step-function transition
between "up" (low loss) or "down" (high loss) states, inter-node between "up" (low loss) or "down" (high loss) states, inter-node
loss rates varied widely, demonstrating a nearly uniform distribution loss rates varied widely, demonstrating a nearly uniform distribution
over the range at the lower rates. The authors attribute the over the range at the lower rates. The authors attribute the
observed effects to multi-path fading, rather than attenuation or observed effects to multi-path fading, rather than attenuation or
interference. interference.
The findings of [Eckhardt] and [Aguayo] demonstrate the diversity of The findings of [Eckhardt] and [Aguayo] demonstrate the diversity of
skipping to change at page 46, line 33 skipping to change at page 46, line 33
the simulation results closely matched the maximum throughput the simulation results closely matched the maximum throughput
achievable for a given signal/noise ratio, based on the ideal BER vs. achievable for a given signal/noise ratio, based on the ideal BER vs.
SNR curve. SNR curve.
In "Hybrid Rate Control for IEEE 802.11" [Haratcherev], the authors In "Hybrid Rate Control for IEEE 802.11" [Haratcherev], the authors
describe a hybrid technique utilizing Signal Strength Indication describe a hybrid technique utilizing Signal Strength Indication
(SSI) data to constrain the potential rates selected by statistics- (SSI) data to constrain the potential rates selected by statistics-
based automatic rate control. Statistics-based rate control based automatic rate control. Statistics-based rate control
techniques include: techniques include:
Maximum throughput Maximum Throughput
This technique, which was chosen as the statistics-based technique This technique, which was chosen as the statistics-based technique
in the hybrid scheme, sends a fraction of data at adjacent rates in in the hybrid scheme, sends a fraction of data at adjacent rates
order to estimate which rate provides the maximum throughput. in order to estimate which rate provides the maximum throughput.
Since accurate estimation of throughput requires a minimum number Since accurate estimation of throughput requires a minimum number
of frames to be sent at each rate, and only a fraction of frames of frames to be sent at each rate, and only a fraction of frames
are utilized for this purpose, this technique adapts more slowly at are utilized for this purpose, this technique adapts more slowly
lower rates; with 802.11b rates, the adaptation time scale is at lower rates; with 802.11b rates, the adaptation time scale is
typically on the order of a second. Depending on how many rates typically on the order of a second. Depending on how many rates
are tested, this technique can enable adaptation beyond adjacent are tested, this technique can enable adaptation beyond adjacent
rates. rates.
Frame Error Rate (FER) control Frame Error Rate (FER) Control
This technique estimates the FER, attempting to keep it between a This technique estimates the FER, attempting to keep it between a
lower limit (if FER moves below, increase rate) and upper limit (if lower limit (if FER moves below, increase rate) and upper limit
FER moves above, decrease rate). Since this technique can utilize (if FER moves above, decrease rate). Since this technique can
all the transmitted data, it can respond faster than maximum utilize all the transmitted data, it can respond faster than
throughput techniques. However, there is a tradeoff of reaction maximum throughput techniques. However, there is a tradeoff of
time versus FER estimation accuracy; at lower rates either reaction reaction time versus FER estimation accuracy; at lower rates
times slow or FER estimation accuracy will suffer. Since this either reaction times slow or FER estimation accuracy will suffer.
technique only measures the FER at the current rate, it can only Since this technique only measures the FER at the current rate, it
enable adaptation to adjacent rates. can only enable adaptation to adjacent rates.
Retry-based Retry-based
This technique modifies FER control techniques by enabling rapid This technique modifies FER control techniques by enabling rapid
downward rate adaptation after a number (5-10) of unsuccessful re- downward rate adaptation after a number (5-10) of unsuccessful re-
transmissions. Since fewer packets are required, the sensitivity transmissions. Since fewer packets are required, the sensitivity
of reaction time to rate is reduced.. However, upward rate of reaction time to rate is reduced.. However, upward rate
adaptation proceeds more slowly since it is based on collection of adaptation proceeds more slowly since it is based on collection of
FERdata. This technique is limited to adaptation to adjacent FERdata. This technique is limited to adaptation to adjacent
rates. rates.
While statistics-based techniques are robust against short-lived link While statistics-based techniques are robust against short-lived
quality changes, they do not respond quickly to long-lived changes. link quality changes, they do not respond quickly to long-lived
By constraining the rate selected by statistics-based techniques changes. By constraining the rate selected by statistics-based
based on ACK SSI versus rate data (not theoretical curves), more techniques based on ACK SSI versus rate data (not theoretical
rapid link adaptation was enabled. In order to ensure rapid curves), more rapid link adaptation was enabled. In order to
adaptation during rapidly varying conditions, the rate constraints ensure rapid adaptation during rapidly varying conditions, the
are tightened when the SSI values are changing rapidly, encouraging rate constraints are tightened when the SSI values are changing
rate transitions. The authors validated their algorithms by rapidly, encouraging rate transitions. The authors validated
implementing a driver for the Atheros AR5000 chipset, and then their algorithms by implementing a driver for the Atheros AR5000
testing its response to insertion and removal from a microwave oven chipset, and then testing its response to insertion and removal
acting as a Faraday cage. The hybrid algorithm dropped many fewer from a microwave oven acting as a Faraday cage. The hybrid
packets than the maximum throughput technique by itself. algorithm dropped many fewer 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
received at the sender was used. This approach did not require the ACKs received at the sender was used. This approach did not
receiver to provide the sender with the received SSI, so that it require the receiver to provide the sender with the received SSI,
could be implemented without changing the IEEE 802.11 MAC. This so that it could be implemented without changing the IEEE 802.11
scheme assumes that transmit power remains constant on the sender and MAC. This scheme assumes that transmit power remains constant on
receiver and that channel properties in both directions vary slowly, the sender and receiver and that channel properties in both
so that the SSI of the received ACKs and sent data remain in directions vary slowly, so that the SSI of the received ACKs and
proportion. Actual data was used to determine the relationship sent data remain in proportion. Actual data was used to determine
between the ACK SSI and rate, so that the proportion itself does not the relationship between the ACK SSI and rate, so that the
matter, just as long as it varies slowly. The authors checked the proportion itself does not matter, just as long as it varies
proportionality assumption and found that the SSI of received data slowly. The authors checked the proportionality assumption and
correlated highly (74%) with the SSI of received ACKs. Low pass found that the SSI of received data correlated highly (74%) with
filtering and monotonicity constraints were applied to remove the the SSI of received ACKs. Low pass filtering and monotonicity
considerable noise in the SSI versus rate curves. constraints were applied to remove the 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
and WLAN" [Vertical] the authors propose use of signal strength and WWAN and WLAN" [Vertical] the authors propose use of signal
link utilization in order to optimize vertical handoff. WLAN to WWAN strength and link utilization in order to optimize vertical
handoff is driven by SSI decay. When IEEE 802.11 SSI falls below a handoff. WLAN to WWAN handoff is driven by SSI decay. When IEEE
threshold (S1), FFT-based decay detection is undertaken to determine 802.11 SSI falls below a threshold (S1), FFT-based decay detection
if the signal is likely to continue to decay. If so, then handoff to is undertaken to determine if the signal is likely to continue to
the WWAN is initiated when the signal falls below the minimum decay. If so, then handoff to the WWAN is initiated when the
acceptable level (S2). WWAN to WLAN handoff is driven by both PHY signal falls below the minimum acceptable level (S2). WWAN to
and MAC characteristics of the IEEE 802.11 target network. At the WLAN handoff is driven by both PHY and MAC characteristics of the
PHY layer, characteristics such as SSI are examined to determine if IEEE 802.11 target network. At the PHY layer, characteristics
the signal strength is greater than a minimum value (S3); at the MAC such as SSI are examined to determine if the signal strength is
layer the IEEE 802.11 Network Allocation Vector (NAV) occupation is greater than a minimum value (S3); at the MAC layer the IEEE
examined in order to estimate the maximum available bandwidth and 802.11 Network Allocation Vector (NAV) occupation is examined in
mean access delay. Note that depending on the value of S3, it is order to estimate the maximum available bandwidth and mean access
possible for the negotiated rate to be less than the available delay. Note that depending on the value of S3, it is possible for
bandwidth. In order to prevent premature handoff between WLAN and the negotiated rate to be less than the available bandwidth. In
WWAN, S1 and S2 are separated by 6 dB; in order to prevent order to prevent premature handoff between WLAN and WWAN, S1 and
oscillation between WLAN and WWAN media, S3 needs to be greater than S2 are separated by 6 dB; in order to prevent oscillation between
S1 by an appropriate margin. WLAN and WWAN media, S3 needs to be greater than S1 by an
appropriate margin.
A.2 Internet Layer A.2 Internet Layer
Within the Internet layer, proposals have been made for utilizing Within the Internet layer, proposals have been made for utilizing
link indications to optimize IP configuration, to improve the link indications to optimize IP configuration, to improve the
usefulness of routing metrics, and to optimize aspects of Mobile IP usefulness of routing metrics, and to optimize aspects of Mobile
handoff. IP handoff.
In "Detecting Network Attachment (DNA) in IPv4" [RFC4436], a host In "Detecting Network Attachment (DNA) in IPv4" [RFC4436], a host
that has moved to a new point of attachment utilizes a bi-directional that has moved to a new point of attachment utilizes a bi-
reachability test in parallel with DHCP [RFC2131] to rapidly directional reachability test in parallel with DHCP [RFC2131] to
reconfirm an operable configuration. rapidly reconfirm an operable configuration.
In "L2 Triggers Optimized Mobile IPv6 Vertical Handover: The In "L2 Triggers Optimized Mobile IPv6 Vertical Handover: The
802.11/GPRS Example" [Park] the authors propose that the mobile node 802.11/GPRS Example" [Park] the authors propose that the mobile
send a router solicitation on receipt of a "Link Up" indication in node send a router solicitation on receipt of a "Link Up"
order provide lower handoff latency than would be possible using indication in order provide lower handoff latency than would be
generic movement detection [RFC3775]. The authors also suggest possible using generic movement detection [RFC3775]. The authors
immediate invalidation of the Care-Of-Address (CoA) on receipt of a also suggest immediate invalidation of the Care-Of-Address (CoA)
"Link Down" indication. However, this is problematic where a "Link on receipt of a "Link Down" indication. However, this is
Down" indication can be followed by a "Link Up" indication without a problematic where a "Link Down" indication can be followed by a
resulting change in IP configuration, as described in [RFC4436]. "Link Up" indication without a resulting change in IP
configuration, as described in [RFC4436].
In "Layer 2 Handoff for Mobile-IPv4 with 802.11" [Mun], the authors In "Layer 2 Handoff for Mobile-IPv4 with 802.11" [Mun], the
suggest that MIPv4 Registration messages be carried within authors suggest that MIPv4 Registration messages be carried within
Information Elements of IEEE 802.11 Association/Reassociation frames, Information Elements of IEEE 802.11 Association/Reassociation
in order to minimize handoff delays. This requires modification to frames, in order to minimize handoff delays. This requires
the mobile node as well as 802.11 APs. However, prior to detecting modification to the mobile node as well as 802.11 APs. However,
network attachment, it is difficult for the mobile node to determine prior to detecting network attachment, it is difficult for the
whether the new point of attachment represents a change of network or mobile node to determine whether the new point of attachment
not. For example, even where a station remains within the same ESS, represents a change of network or not. For example, even where a
it is possible that the network will change. Where no change of station remains within the same ESS, it is possible that the
network results, sending a MIPv4 Registration message with each network will change. Where no change of network results, sending
Association/Reassociation is unnecessary. Where a change of network a MIPv4 Registration message with each Association/Reassociation
results, it is typically not possible for the mobile node to is unnecessary. Where a change of network results, it is
anticipate its new CoA at Association/Reassociation; for example, a typically not possible for the mobile node to anticipate its new
DHCP server may assign a CoA not previously given to the mobile node. CoA at Association/Reassociation; for example, a DHCP server may
When dynamic VLAN assignment is used, the VLAN assignment is not even assign a CoA not previously given to the mobile node. When
determined until IEEE 802.1X authentication has completed, which is dynamic VLAN assignment is used, the VLAN assignment is not even
after Association/Reassociation in [IEEE-802.11i]. determined until IEEE 802.1X authentication has completed, which
is after Association/Reassociation in [IEEE-802.11i].
In "Link Characteristics Information for Mobile IP" [Lee], link In "Link Characteristics Information for Mobile IP" [Lee], link
characteristics are included in registration/binding update messages characteristics are included in registration/binding update
sent by the mobile node to the home agent and correspondent node. messages sent by the mobile node to the home agent and
Where the mobile node is acting as a receiver, this allows the correspondent node. Where the mobile node is acting as a
correspondent node to adjust its transport parameters window more receiver, this allows the correspondent node to adjust its
rapidly than might otherwise be possible. Link characteristics that transport parameters window more rapidly than might otherwise be
may be communicated include the link type (e.g. 802.11b, CDMA, GPRS, possible. Link characteristics that may be communicated include
etc.) and link bandwidth. While the document suggests that the the link type (e.g. 802.11b, CDMA, GPRS, etc.) and link bandwidth.
correspondent node should adjust its sending rate based on the While the document suggests that the correspondent node should
advertised link bandwidth, this may not be wise in some adjust its sending rate based on the advertised link bandwidth,
circumstances. For example, where the mobile node link is not the this may not be wise in some circumstances. For example, where
bottleneck, adjusting the sending rate based on the link bandwidth the mobile node link is not the bottleneck, adjusting the sending
could cause in congestion. Also, where link rates change frequently, rate based on the link bandwidth could cause in congestion. Also,
sending registration messages on each rate change could by itself where link rates change frequently, sending registration messages
consume significant bandwidth. Even where the advertised link on each rate change could by itself consume significant bandwidth.
characteristics indicate the need for a smaller congestion window, it Even where the advertised link characteristics indicate the need
may be non-trivial to adjust the sending rates of individual for a smaller congestion window, it may be non-trivial to adjust
connections where there are multiple connections open between a the sending rates of individual connections where there are
mobile node and correspondent node. A more conservative approach multiple connections open between a mobile node and correspondent
would be to trigger parameter re-estimation and slow start based on node. A more conservative approach would be to trigger parameter
the receipt of a registration message or binding update. re-estimation and slow start based on 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
routing protocols have a tendency to concentrate traffic since they MANET routing protocols have a tendency to concentrate traffic
utilize shortest path metrics and allow nodes to respond to route since they utilize shortest path metrics and allow nodes to
queries with cached routes. The authors propose that nodes respond to route queries with cached routes. The authors propose
participating in an ad-hoc wireless mesh monitor local conditions that nodes participating in an ad-hoc wireless mesh monitor local
such as MAC delay, buffer consumption and packets loss. Where conditions such as MAC delay, buffer consumption and packets loss.
congestion is detected, this is communicated to neighboring nodes via Where congestion is detected, this is communicated to neighboring
an IP option. In response to moderate congestion, nodes suppress nodes via an IP option. In response to moderate congestion, nodes
route requests; where major congestion is detected, nodes throttle suppress route requests; where major congestion is detected, nodes
TCP connections flowing through them. The authors argue that for ad- throttle TCP connections flowing through them. The authors argue
hoc networks throttling by intermediate nodes is more effective than that for ad-hoc networks throttling by intermediate nodes is more
end-to-end congestion control mechanisms. effective than 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
effects of handoff-induced packet loss and non-congestive loss caused the effects of handoff-induced packet loss and non-congestive loss
by lossy wireless links. caused 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
(including the RTT, RTO and congestion window) may no longer be parameters (including the RTT, RTO and congestion window) may no
valid. Where the path change occurs on the sender (e.g. change in longer be valid. Where the path change occurs on the sender (e.g.
outgoing or incoming interface), the sender can reset its congestion change in outgoing or incoming interface), the sender can reset
window and parameter estimates. However, where it occurs on the its congestion window and parameter estimates. However, where it
receiver, the sender may not be aware of the path change. occurs on the receiver, the sender may not be aware of the path
change.
In "The BU-trigger method for improving TCP performance over Mobile In "The BU-trigger method for improving TCP performance over
IPv6" [Kim], the authors note that handoff-related packet loss is Mobile IPv6" [Kim], the authors note that handoff-related packet
interpreted as congestion by the Transport layer. In the case where loss is interpreted as congestion by the Transport layer. In the
the correspondent node is sending to the mobile node, it is proposed case where the correspondent node is sending to the mobile node,
that receipt of a Binding Update by the correspondent node be used as it is proposed that receipt of a Binding Update by the
a signal to the Transport layer to adjust cwnd and ssthresh values, correspondent node be used as a signal to the Transport layer to
which may have been reduced due to handoff-induced packet loss. The adjust cwnd and ssthresh values, which may have been reduced due
authors recommend that cwnd and ssthresh be recovered to pre-timeout to handoff-induced packet loss. The authors recommend that cwnd
values, regardless of whether the link parameters have changed. The and ssthresh be recovered to pre-timeout values, regardless of
paper does not discuss the behavior of a mobile node sending a whether the link parameters have changed. The paper does not
Binding Update, in the case where the mobile node is sending to the discuss the behavior of a mobile node sending a Binding Update, in
correspondent node. the case where the mobile node is sending to the correspondent
node.
In "Effect of Vertical Handovers on Performance of TCP-Friendly Rate In "Effect of Vertical Handovers on Performance of TCP-Friendly
Control" [Gurtov], the authors examine the effect of explicit Rate Control" [Gurtov], the authors examine the effect of explicit
handover notifications on TCP-friendly rate control. Where explicit handover notifications on TCP-friendly rate control. Where
handover notification includes information on the loss rate and explicit handover notification includes information on the loss
throughput of the new link, this can be used to instantaneously rate and throughput of the new link, this can be used to
change the transmission rate of the sender. The authors also found instantaneously change the transmission rate of the sender. The
that resetting the TFRC receiver state after handover enabled authors also found that resetting the TFRC receiver state after
parameter estimates to adjust more quickly. handover enabled parameter estimates to adjust more quickly.
In "Adapting End Host Congestion Control for Mobility" [Eddy], the In "Adapting End Host Congestion Control for Mobility" [Eddy], the
authors note that while MIPv6 with route optimization allows a authors note that while MIPv6 with route optimization allows a
receiver to communicate a subnet change to the sender via a Binding receiver to communicate a subnet change to the sender via a
Update, this is not available within MIPv4. To provide a Binding 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
propose a TCP option that allows a connection endpoint to inform a authors propose a TCP option that allows a connection endpoint to
peer of a subnet change. The document does not advocate utilization inform a peer of a subnet change. The document does not advocate
of "Link Up" or "Link Down" events since these events are not utilization of "Link Up" or "Link Down" events since these events
necessarily indicative of subnet change. On detection of subnet are not necessarily indicative of subnet change. On detection of
change, it is advocated that the congestion window be reset to subnet change, it is advocated that the congestion window be reset
INIT_WINDOW and that transport parameters be re-estimated. The to 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
and WLAN" [Vertical] the authors propose a "Virtual Connectivity WWAN and WLAN" [Vertical] the authors propose a "Virtual
Manager" which utilizes local connection translation (LCT) and a Connectivity Manager" which utilizes local connection translation
subscription/notification service supporting simultaneous movement in (LCT) and a subscription/notification service supporting
order to enable end-to-end mobility and maintain TCP throughput simultaneous movement in order to enable end-to-end mobility and
during vertical handovers. maintain TCP throughput 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
proposed in Section 4. This option was removed in part because the was proposed in Section 4. This option was removed in part
use conditions were not fully understood: because the use conditions were not fully understood:
An Half-Connection Receiver sends the Reset Congestion State An Half-Connection Receiver sends the Reset Congestion State
option to its sender to force the sender to reset its congestion option to its sender to force the sender to reset its
state -- that is, to "slow start", as if the connection were congestion state -- that is, to "slow start", as if the
beginning again. connection were beginning again.
... The Reset Congestion State option is reserved for the very ... The Reset Congestion State option is reserved for the
few cases when an endpoint knows that the congestion properties of very few cases when an endpoint knows that the congestion
a path have changed. Currently, this reduces to mobility: a DCCP properties of a path have changed. Currently, this reduces to
endpoint on a mobile host MUST send Reset Congestion State to its mobility: a DCCP endpoint on a mobile host MUST send Reset
peer after the mobile host changes address or path. Congestion State to its 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"
describes methods by which a TCP implementation that has backed off [E2ELinkup] describes methods by which a TCP implementation that
its retransmission timer due to frame loss on a remote link can learn has backed off its retransmission timer due to frame loss on a
that the link has once again become operational. This enables remote link can learn that the link has once again become
retransmission to be attempted prior to expiration of the backed off operational. This enables retransmission to be attempted prior to
retransmission timer. expiration of the backed off retransmission timer.
"Link-layer Triggers Protocol" [Yegin] describes transport issues "Link-layer Triggers Protocol" [Yegin] describes transport issues
arising from lack of host awareness of link conditions on downstream arising from lack of host awareness of link conditions on
Access Points and routers. Transport of link layer triggers is downstream Access Points and routers. Transport of link layer
proposed to address the issue. triggers is proposed to address the issue.
"TCP Extensions for Immediate Retransmissions" [Eggert], describes "TCP Extensions for Immediate Retransmissions" [Eggert], describes
how a Transport layer implementation may utilize existing "end-to-end how a Transport layer implementation may utilize existing "end-to-
connectivity restored" indications. It is proposed that in addition end connectivity restored" indications. It is proposed that in
to regularly scheduled retransmissions that retransmission be addition to regularly scheduled retransmissions that
attempted by the Transport layer on receipt of an indication that retransmission be attempted by the Transport layer on receipt of
connectivity to a peer node may have been restored. End-to-end an indication that connectivity to a peer node may have been
connectivity restoration indications include "Link Up", confirmation restored. End-to-end connectivity restoration indications include
of first-hop router reachability, confirmation of Internet layer "Link Up", confirmation of first-hop router reachability,
configuration, and receipt of other traffic from the peer. confirmation of Internet layer configuration, and receipt of other
traffic from the peer.
In "Discriminating Congestion Losses from Wireless Losses Using In "Discriminating Congestion Losses from Wireless Losses Using
Interarrival Times at the Receiver" [Biaz], the authors propose a Interarrival Times at the Receiver" [Biaz], the authors propose a
scheme for differentiating congestive losses from wireless scheme for differentiating congestive losses from wireless
transmission losses based on inter-arrival times. Where the loss is transmission losses based on inter-arrival times. Where the loss
due to wireless transmission rather than congestion, congestive is 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
to assume equal spacing between packets, which is not realistic in an appears to assume equal spacing between packets, which is not
environment exhibiting link layer frame loss. The scheme is shown to realistic in an environment exhibiting link layer frame loss. The
function well only when the wireless link is the bottleneck, which is scheme is shown to function well only when the wireless link is
often the case with cellular networks, but not with IEEE 802.11 the bottleneck, which is often the case with cellular networks,
deployment scenarios such as home or hotspot use. but not with IEEE 802.11 deployment scenarios such as home or
hotspot use.
In "Improving Performance of TCP over Wireless Networks" [Bakshi], In "Improving Performance of TCP over Wireless Networks" [Bakshi],
the authors focus on the performance of TCP over wireless networks the authors focus on the performance of TCP over wireless networks
with burst losses. The authors simulate performance of TCP Tahoe with burst losses. The authors simulate performance of TCP Tahoe
within ns-2, utilizing a two-state Markov model, representing "good" within ns-2, utilizing a two-state Markov model, representing
and "bad" states. Where the receiver is connected over a wireless "good" and "bad" states. Where the receiver is connected over a
link, the authors simulate the effect of an Explicit Bad State wireless link, the authors simulate the effect of an Explicit Bad
Notification (EBSN) sent by an access point unable to reach the State Notification (EBSN) sent by an access point unable to reach
receiver. In response to an EBSN, it is advocated that the existing the receiver. In response to an EBSN, it is advocated that the
retransmission timer be canceled and replaced by a new dynamically existing retransmission timer be canceled and replaced by a new
estimated timeout, rather than being backed off. In the simulations, dynamically estimated timeout, rather than being backed off. In
EBSN prevents unnecessary timeouts, decreasing RTT variance and the simulations, EBSN prevents unnecessary timeouts, decreasing
improving throughput. RTT variance and improving throughput.
In "A Feedback-Based Scheme for Improving TCP Performance in Ad-Hoc In "A Feedback-Based Scheme for Improving TCP Performance in Ad-
Wireless Networks" [Chandran], the authors proposed an explicit Route Hoc Wireless Networks" [Chandran], the authors proposed an
Failure Notification (RFN), allowing the sender to stop its explicit Route Failure Notification (RFN), allowing the sender to
retransmission timers when the receiver becomes unreachable. On stop its retransmission timers when the receiver becomes
route reestablishment, a Route Reestablishment Notification (RRN) is unreachable. On route reestablishment, a Route Reestablishment
sent, unfreezing the timer. Simulations indicate that the scheme Notification (RRN) is sent, unfreezing the timer. Simulations
significantly improves throughput and reduces unnecessary indicate that the scheme significantly improves throughput and
retransmissions. reduces unnecessary retransmissions.
In "Analysis of TCP Performance over Mobile Ad Hoc Networks" In "Analysis of TCP Performance over Mobile Ad Hoc Networks"
[Holland], the authors explore how explicit link failure notification [Holland], the authors explore how explicit link failure
(ELFN) can improve the performance of TCP in mobile ad hoc networks. notification (ELFN) can improve the performance of TCP in mobile
ELFN informs the TCP sender about link and route failures so that it ad hoc networks. ELFN informs the TCP sender about link and route
need not treat the ensuing packet loss as due to congestion. Using failures so that it need not treat the ensuing packet loss as due
an ns-2 simulation of TCP-Reno over 802.11 with routing provided by to congestion. Using an ns-2 simulation of TCP-Reno over 802.11
the Dynamic Source Routing (DSR) protocol, it is demonstrated that with routing provided by the Dynamic Source Routing (DSR)
TCP performance falls considerably short of expected throughput based protocol, it is demonstrated that TCP performance falls
on the percentage of the time that the network is partitioned. A considerably short of expected throughput based on the percentage
portion of the problem was attributed to the inability of the routing of the time that the network is partitioned. A portion of the
protocol to quickly recognize and purge stale routes, leading to problem was attributed to the inability of the routing protocol to
excessive link failures; performance improved dramatically when route quickly recognize and purge stale routes, leading to excessive
caching was turned off. Interactions between the route request and link failures; performance improved dramatically when route
transport retransmission timers were also noted. Where the route caching was turned off. Interactions between the route request
request timer is too large, new routes cannot be supplied in time to and transport retransmission timers were also noted. Where the
prevent the transport timer from expiring, and where the route route request timer is too large, new routes cannot be supplied in
request timer is too small, network congestion may result. For their time to prevent the transport timer from expiring, and where the
implementation of ELFN, the authors piggybacked additional route request timer is too small, network congestion may result.
information on an existing "route failure" notice (sender and For their implementation of ELFN, the authors piggybacked
receiver addresses and ports, the TCP sequence number) to enable the additional information on an existing "route failure" notice
sender to identify the affected connection. Where a TCP receives an (sender and receiver addresses and ports, the TCP sequence number)
ELFN, it disables the retransmission timer and enters "stand-by" to enable the sender to identify the affected connection. Where a
mode, where packets are sent at periodic intervals to determine if TCP receives an ELFN, it disables the retransmission timer and
the route has been reestablished. If an acknowledgment is received enters "stand-by" mode, where packets are sent at periodic
then the retransmission timers are restored. Simulations show that intervals to determine if the route has been reestablished. If an
performance is sensitive to the probe interval, with intervals of 30 acknowledgment is received then the retransmission timers are
seconds or greater giving worse performance than TCP-Reno. The restored. Simulations show that performance is sensitive to the
affect of resetting the congestion window and RTO values was also probe interval, with intervals of 30 seconds or greater giving
investigated. In the study, resetting congestion window to one did worse performance than TCP-Reno. The affect of resetting the
not have much of an effect on throughput, since the bandwidth/delay congestion window and RTO values was also investigated. In the
of the network was only a few packets. However, resetting the RTO to study, resetting congestion window to one did not have much of an
a high initial value (6 seconds) did have a substantial detrimental effect on throughput, since the bandwidth/delay of the network was
effect, particularly at high speed. In terms of the probe packet only a few packets. However, resetting the RTO to a high initial
sent, the simulations showed little difference between sending the value (6 seconds) did have a substantial detrimental effect,
first packet in the congestion window, or retransmitting the packet particularly at high speed. In terms of the probe packet sent,
with the lowest sequence number among those signaled as lost via the the simulations showed little difference between sending the first
packet in the congestion window, or retransmitting the packet 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
of retransmission attempts, an ICMP-RETRANSMIT message is sent. On exhaustion of retransmission attempts, an ICMP-RETRANSMIT message
receipt of an ICMP-DEFER message, the expiry of the retransmission is sent. On receipt of an ICMP-DEFER message, the expiry of the
timer is postponed by the current RTO estimate. On receipt of an retransmission timer is postponed by the current RTO estimate. On
ICMP-RETRANSMIT message, the segment is retransmitted. On receipt of an ICMP-RETRANSMIT message, the segment is
retransmission, the congestion window is not reduced; when coming out retransmitted. On retransmission, the congestion window is not
of fast recovery, the congestion window is reset to its value prior reduced; when coming out of fast recovery, the congestion window
to fast retransmission and fast recovery. Using a two-state Markov is reset to its value prior to fast retransmission and fast
model, simulated using ns-2, the authors show that the scheme recovery. Using a two-state Markov model, simulated using ns-2,
improves throughput. the authors show that the scheme improves throughput.
In "Explicit Transport Error Notification (ETEN) for Error-Prone In "Explicit Transport Error Notification (ETEN) for Error-Prone
Wireless and Satellite Networks" [Krishnan], the authors examine the Wireless and Satellite Networks" [Krishnan], the authors examine
use of explicit transport error notification (ETEN) to aid TCP in the use of explicit transport error notification (ETEN) to aid TCP
distinguishing congestive losses from those due to corruption. Both in distinguishing congestive losses from those due to corruption.
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
and traffic conditions. While per-packet ETEN mechanisms provided
substantial gains in TCP goodput without congestion, where congestion
was also present, the gains were not significant. Cumulative ETEN
mechanisms did not perform as well in the study. The authors point
out that ETEN faces significant deployment barriers since it can
create new security vulnerabilities and requires implementations to
obtain reliable information from the headers of corrupt packets.
In "Towards More Expressive Transport-Layer Interfaces" [Eggert2] the Both per-packet and cumulative ETEN mechanisms were simulated in
authors propose extensions to existing network/transport and ns-2, using both TCP Reno and TCP SACK over a wide range of bit
error rates and traffic conditions. While per-packet ETEN
mechanisms provided substantial gains in TCP goodput without
congestion, where congestion was also present, the gains were not
significant. Cumulative ETEN mechanisms did not perform as well
in the study. The authors point out that ETEN faces significant
deployment barriers since it can create new security
vulnerabilities and requires implementations to 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/application interfaces to improve the performance of the
transport layer in the face of changes in path characteristics transport layer in the face of changes in path characteristics
varying more quickly than the round-trip time. varying more quickly than the round-trip time.
In "Protocol Enhancements for Intermittently Connected Hosts" In "Protocol Enhancements for Intermittently Connected Hosts"
[Schuetz], the authors note that intermittent connectivity can lead [Schuetz], the authors note that intermittent connectivity can
to poor performance and connectivity failures. To address these lead to poor performance and connectivity failures. To address
problems, the authors combine the use of the Host Identity Protocol these problems, the authors combine the use of the Host Identity
(HIP) with a TCP User Timeout Option and TCP Retransmission trigger, Protocol (HIP) with a TCP User Timeout Option and TCP
demonstrating significant improvement. 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
improved rate adaptation algorithms is provided to a video utilizing improved rate adaptation algorithms is provided to a
application, and used for codec adaptation. Coupling the link and video application, and used for codec adaptation. Coupling the
application layers results in major improvements in the Peak link and application layers results in major improvements in the
Signal/Noise Ratio (PSNR). Peak 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,
devices periodically refresh their presence state using application client devices periodically refresh their presence state using
layer protocols such as SIMPLE [RFC3428] or XMPP [RFC3921]. If the application layer protocols such as SIMPLE [RFC3428] or XMPP
client should become disconnected, their unavailability will not be [RFC3921]. If the client should become disconnected, their
detected until the presence status times out, which can take many unavailability will not be detected until the presence status
minutes. However, if a link goes down, and a disconnect indication times out, which can take many minutes. However, if a link goes
can be sent to the presence server (presumably by the access point, down, and a disconnect indication can be sent to the presence
which remains connected), the status of the user's communication server (presumably by the access point, which remains connected),
application can be updated nearly instantaneously. the status of the user's communication application can be updated
nearly instantaneously.
Appendix B - IAB Members at the time of this writing Appendix B - IAB Members at the time of this writing
Bernard Aboba Bernard Aboba
Loa Andersson Loa Andersson
Brian Carpenter Brian Carpenter
Leslie Daigle Leslie Daigle
Elwyn Davies Elwyn Davies
Kevin Fall Kevin Fall
Olaf Kolkman Olaf Kolkman
skipping to change at page 56, line 31 skipping to change at page 56, line 46
http://www.ietf.org/ipr. http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at this standard. Please address the information to the IETF at
ietf-ipr@ietf.org. ietf-ipr@ietf.org.
Acknowledgment Acknowledgment
Funding for the RFC Editor function is currently provided by the Funding for the RFC Editor function is provided by the IETF
Internet Society. Administrative Support Activity (IASA).
 End of changes. 57 change blocks. 
351 lines changed or deleted 369 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/