draft-iab-link-indications-08.txt   draft-iab-link-indications-09.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-08.txt> <draft-iab-link-indications-09.txt>
19 February 2007 28 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 26, 2007. This Internet-Draft will expire on September 1, 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 15 skipping to change at page 2, line 15
Table of Contents Table of Contents
1. Introduction.............................................. 3 1. Introduction.............................................. 3
1.1 Requirements ....................................... 3 1.1 Requirements ....................................... 3
1.2 Terminology ........................................ 3 1.2 Terminology ........................................ 3
1.3 Overview ........................................... 5 1.3 Overview ........................................... 5
1.4 Layered Indication Model ........................... 6 1.4 Layered Indication Model ........................... 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 .................................. 15
2.3 Robustness ......................................... 16 2.3 Robustness ......................................... 17
2.4 Congestion Control ................................. 19 2.4 Congestion Control ................................. 20
2.5 Effectiveness ...................................... 21 2.5 Effectiveness ...................................... 21
2.6 Interoperability ................................... 21 2.6 Interoperability ................................... 21
2.7 Race Conditions .................................... 21 2.7 Race Conditions .................................... 21
2.8 Layer Compression .................................. 24 2.8 Layer Compression .................................. 24
2.9 Transport of Link Indications ...................... 25 2.9 Transport of Link Indications ...................... 25
3. Future Work .............................................. 26 3. Future Work .............................................. 26
4. Security Considerations .................................. 27 4. Security Considerations .................................. 27
4.1 Spoofing ........................................... 27 4.1 Spoofing ........................................... 27
4.2 Indication Validation .............................. 28 4.2 Indication Validation .............................. 28
4.3 Denial of Service .................................. 29 4.3 Denial of Service .................................. 29
5. IANA Considerations ...................................... 30 5. IANA Considerations ...................................... 30
6. References ............................................... 30 6. References ............................................... 30
6.1 Informative References ............................. 30 6.1 Informative References ............................. 30
Acknowledgments .............................................. 39 Acknowledgments .............................................. 39
Appendix A - Literature Review ............................... 40 Appendix A - Literature Review ............................... 40
A.0 Terminology ........................................ 40
A.1 Link Layer ......................................... 40 A.1 Link Layer ......................................... 40
A.2 Internet Layer ..................................... 52 A.2 Internet Layer ..................................... 52
A.3 Transport Layer .................................... 54 A.3 Transport Layer .................................... 53
A.4 Application Layer .................................. 58 A.4 Application Layer .................................. 58
Appendix B - IAB Members ..................................... 59 Appendix B - IAB Members ..................................... 59
Authors' Addresses ........................................... 59 Authors' Addresses ........................................... 59
Full Copyright Statement ..................................... 60 Full Copyright Statement ..................................... 59
Intellectual Property ........................................ 60 Intellectual Property ........................................ 60
1. Introduction 1. Introduction
A link indication represents information provided by the link layer A link indication represents information provided by the link layer
to higher layers regarding the state of the link. While the to higher layers regarding the state of the link. While the
judicious use of link indications can provide performance benefits, judicious use of link indications can provide performance benefits,
inappropriate use can degrade both robustness and performance. inappropriate use can degrade both robustness and performance.
This document summarizes the current understanding of the role of This document summarizes the current understanding of the role of
skipping to change at page 3, line 33 skipping to change at page 3, line 33
Area Networks (WLANs). Area Networks (WLANs).
1.1. Requirements 1.1. Requirements
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119]. document are to be interpreted as described in [RFC2119].
1.2. Terminology 1.2. Terminology
Access Point (AP)
A station that provides access to the fixed network (e.g. an 802.11
Distribution System), via the wireless medium (WM) for associated
stations.
Asymmetric Asymmetric
A link with transmission characteristics that are different A link with transmission characteristics that are different
depending upon the relative position or design characteristics of depending upon the relative position or design characteristics of
the transmitter and the receiver is said to be asymmetric. For the transmitter and the receiver is said to be asymmetric. For
instance, the range of one transmitter may be much higher than the instance, the range of one transmitter may be much higher than the
range of another transmitter on the same medium. range of another transmitter on the same medium.
Beacon
A control message broadcast by a station (typically an Access
Point), informing stations in the neighborhood of its continuing
presence, possibly along with additional status or configuration
information.
Binding Update (BU)
A message indicating a mobile node's current mobility binding, and
in particular its care-of address.
Correspondent Node
A peer node with which a mobile node is communicating. The
correspondent node may be either mobile or stationary.
Link A communication facility or medium over which nodes can communicate Link A communication facility or medium over which nodes can communicate
at the link layer, i.e., the layer immediately below the Internet at the link layer, i.e., the layer immediately below the Internet
Protocol (IP). Protocol (IP).
Link Down Link Down
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.
skipping to change at page 4, line 24 skipping to change at page 4, line 43
associated with the interface becoming capable of communicating associated with the interface becoming capable of communicating
data frames. data frames.
Maximum Segment Size (MSS) Maximum Segment Size (MSS)
The maximum payload size available to the Transport layer. The maximum payload size available to the Transport layer.
Maximum Transmission Unit (MTU) Maximum Transmission Unit (MTU)
The size in octets of the largest IP packet, including the IP The size in octets of the largest IP packet, including the IP
header and payload, that can be transmitted on a link or path. header and payload, that can be transmitted on a link or path.
Mobile Node
A node that can change its point of attachment from one link to
another, while still being reachable via its home address.
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
A static or dynamically assigned address which has not been A static or dynamically assigned address which has not been
relinquished, and has not expired. relinquished, and has not expired.
Routable Address Routable Address
Any IP address other than a Link-Local address. This includes Any IP address for which routers will forward packets. This
private addresses as specified in "Address Allocation for Private includes private addresses as specified in "Address Allocation for
Internets" [RFC1918]. Private Internets" [RFC1918].
Station (STA)
Any device that contains an IEEE 802.11 conformant medium access
control (MAC) and physical layer (PHY) interface to the wireless
medium (WM).
Strong End System Model Strong End System Model
The Strong End System model emphasizes the host/router distinction, The Strong End System model emphasizes the host/router distinction,
tending to model a multihomed host as a set of logical hosts within tending to model a multihomed host as a set of logical hosts within
the same physical host. In the Strong End System model, addresses the same physical host. In the Strong End System model, addresses
refer to an interface, rather than to the host to which they refer to an interface, rather than to the host to which they
attach. As a result, packets sent on an outgoing interface have a attach. As a result, packets sent on an outgoing interface have a
source address configured on that interface and incoming packets source address configured on that interface and incoming packets
whose destination address does not correspond to the physical whose destination address does not correspond to the physical
interface through which it is received are silently discarded. The interface through which it is received are silently discarded.
Strong End System model is very commonly implemented at the link
layer, but rarely at the Internet layer.
Weak End System Model Weak End System Model
In the Weak End System model, addresses refer to a host. As a In the Weak End System model, addresses refer to a host. As a
result, packets sent on an outgoing interface need not necessarily result, packets sent on an outgoing interface need not necessarily
have a source address configured on that interface, and incoming have a source address configured on that interface, and incoming
packets whose destination address does not correspond to the packets whose destination address does not correspond to the
physical interface through which it is received are accepted. The physical interface through which it is received are accepted.
Weak End System model is very commonly implemented at the Internet
layer, but rarely at the link layer.
1.3. Overview 1.3. Overview
The use of link indications within the Internet architecture has a The use of link indications within the Internet architecture has a
long history. In response to an attempt to send to a host that was long history. In response to an attempt to send to a host that was
off-line, the ARPANET link layer protocol provided a "Destination off-line, the ARPANET link layer protocol provided a "Destination
Dead" indication, described in "Fault Isolation and Recovery" Dead" indication, described in "Fault Isolation and Recovery"
[RFC816]. The ARPANET packet radio experiment [PRNET] incorporated [RFC816]. The ARPANET packet radio experiment [PRNET] incorporated
frame loss in the calculation of routing metrics, a precursor to more frame loss in the calculation of routing metrics, a precursor to more
recent link-aware routing metrics such as Expected Transmission Count recent link-aware routing metrics such as Expected Transmission Count
skipping to change at page 6, line 42 skipping to change at page 7, line 18
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 routers. This enables the state of account information provided by routers. This enables the state of
the local routing table to reflect link conditions on both local and the local routing table to reflect link conditions on both local and
remote links. For example, prefixes to be added or removed from the remote links. For example, prefixes to be added or removed from the
routing table may be determined from DHCP [RFC2131][RFC3315], Router routing table may be determined from Dynamic Host Configuration
Advertisements [RFC1256][RFC2461], re-direct messages or route Protocol (DHCP) [RFC2131][RFC3315], Router Advertisements
updates incorporating information on the state of links multiple hops [RFC1256][RFC2461], re-direct messages or route updates incorporating
away. information on the state of links multiple hops away.
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
skipping to change at page 7, line 28 skipping to change at page 8, line 5
is declared operational when bi-directional reachability has been is declared operational when bi-directional reachability has been
confirmed. confirmed.
As described in "Packetization Layer Path MTU Discovery" [PMTUDRFC], As described in "Packetization Layer Path MTU Discovery" [PMTUDRFC],
the Internet layer may maintain a path information cache, enabling the Internet layer may maintain a path information cache, enabling
sharing of path MTU information between concurrent or subsequent sharing of path MTU information between concurrent or subsequent
connections. The shared cache is accessed and updated by connections. The shared cache is accessed and updated by
packetization protocols implementing packetization layer path MTU packetization protocols implementing packetization layer path MTU
discovery. discovery.
The Internet layer also utilizes link indications in order to
optimize aspects of Internet Protocol (IP) configuration and
mobility. After receipt of a "Link Up" indication, hosts validate
potential IP configurations by Detecting Network Attachment (DNA)
[RFC4436]. Once the IP configuration is confirmed, it may be
determined that an address change has occurred. However, "Link Up"
indications may not necessarily result in a change to Internet layer
configuration.
In "Detecting Network Attachment in IPv4" [RFC4436], after receipt of
a "Link Up" indication, potential IP configurations are validated
using a bi-directional reachability test. In "Detecting Network
Attachment in IPv6 Networks (DNAv6)" [DNAv6] IP configuration is
validated using reachability detection and Router
Solicitation/Advertisement.
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Application | | Application | |
Layer | | Layer | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
^ ^ ^ ^ ^ ^
! ! ! ! ! !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-!-+-+-!-+-!-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-!-+-+-!-+-!-+-+-+-+
| ! ! ! | | ! ! ! |
| ! ^ ^ | | ! ^ ^ |
| Connection Management ! ! Teardown | | Connection Management ! ! Teardown |
skipping to change at page 8, line 34 skipping to change at page 8, line 34
! ! ! ! ! ! ! ! ! ! ! !
+-!-+-!-+-+-+-+-+-!-+-+-+-!-+-!-+-+-!-+-+-+-+-+-+ +-!-+-!-+-+-+-+-+-!-+-+-+-!-+-!-+-+-!-+-+-+-+-+-+
| ! ! 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 ! ! ! |
+-!-+-+-+-+-+-+-+-+-+-+-+-!-+-!-+-+-!-+-+-+-+-+-+ +-!-+-+-+-+-+-+-+-+-+-+-+-!-+-!-+-+-!-+-+-+-+-+-+
| ! ! v ! IP | | ! ! v ! IP |
| ! ! Path ! Address | | ! ! Path ! Address |
| ! IP Configuration ^ Info ^ Config/ | | ! IP Configuration ^ Info ^ Config/ |
| ! ! Cache Changes | | ! ! Cache Changes |
+-!-+-+-+-+-+-+-+-+-+-+-+-!-+-+-+-+-+-+-+-+-+-+-+ +-!-+-+-+-+-+-+-+-+-+-+-+-!-+-+-+-+-+-+-+-+-+-+-+
! ! ! !
! ! ! !
+-!-+-+-+-+-+-+-+-+-+-+-+-!-+-+-+-+-+-+-+-+-+-+-+ +-!-+-+-+-+-+-+-+-+-+-+-+-!-+-+-+-+-+-+-+-+-+-+-+
| ! ! | | ! ! |
Link | v ^ | Link | ^ ^ |
Layer | Rate, FER, Link | Layer | Rate, FER, Link |
| Delay Up/Down | | Delay Up/Down |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 1. Layered Indication Model Figure 1. Layered Indication Model
The Internet layer also utilizes link indications in order to
optimize aspects of Internet Protocol (IP) configuration and
mobility. After receipt of a "Link Up" indication, hosts validate
potential IP configurations by Detecting Network Attachment (DNA)
[RFC4436]. Once the IP configuration is confirmed, it may be
determined that an address change has occurred. However, "Link Up"
indications may not necessarily result in a change to Internet layer
configuration.
In "Detecting Network Attachment in IPv4" [RFC4436], after receipt of
a "Link Up" indication, potential IP configurations are validated
using a bi-directional reachability test. In "Detecting Network
Attachment in IPv6 Networks (DNAv6)" [DNAv6] IP configuration is
validated using reachability detection and Router
Solicitation/Advertisement.
The routing sub-layer may utilize link indications in order to enable The routing sub-layer may utilize link indications in order to enable
more rapid response to changes in link state and effective more rapid response to changes in link state and effective
throughput. Link rate is often used in computing routing metrics. throughput. Link rate is often used in computing routing metrics.
However, in wired networks the transmission rate may be negotiated in However, in wired networks the transmission rate may be negotiated in
order to enhance energy efficiency [EfficientEthernet]. In wireless order to enhance energy efficiency [EfficientEthernet]. In wireless
networks, the negotiated rate and Frame Error Rate (FER) may change networks, the negotiated rate and Frame Error Rate (FER) may change
with link conditions so that effective throughput may vary on a with link conditions so that effective throughput may vary on a
packet by packet basis. In such situations, routing metrics may also packet by packet basis. In such situations, routing metrics may also
exhibit rapid variation. exhibit rapid variation.
skipping to change at page 9, line 33 skipping to change at page 9, line 49
and link state may result in a change in the outgoing interface for and link state may result in a change in the outgoing interface for
one or more transport connections. Routes may also be added or one or more transport connections. Routes may also be added or
withdrawn, resulting in loss or gain of peer connectivity. However, withdrawn, resulting in loss or gain of peer connectivity. However,
link indications such as changes in transmission rate or frame loss link indications such as changes in transmission rate or frame loss
do not necessarily result in a change of outgoing interface. do not necessarily result in a change of outgoing interface.
The Internet layer may also become aware of path changes by other The Internet layer may also become aware of path changes by other
mechanisms, such as receipt of updates from a routing protocol, mechanisms, such as receipt of updates from a routing protocol,
receipt of a Router Advertisement, dead gateway detection [RFC816] or receipt of a Router Advertisement, dead gateway detection [RFC816] or
network unreachability detection [RFC2461], ICMP re-directs, or a network unreachability detection [RFC2461], ICMP re-directs, or a
change in the IP TTL of received packets. A change in the outgoing change in the IPv4 TTL/IPv6 Hop Limit of received packets. A change
interface may in turn influence the mobility sub-layer, causing a in the outgoing interface may in turn influence the mobility sub-
change in the incoming interface. The mobility sub-layer may also layer, causing a change in the incoming interface. The mobility sub-
become aware of a change in the incoming interface of a peer (via layer may also become aware of a change in the incoming interface of
receipt of a Mobile IP binding update). a peer (via receipt of a Mobile IP binding update [RFC3775]).
1.4.2. Transport Layer 1.4.2. Transport Layer
The Transport layer processes received link indications differently The Transport layer processes received link indications differently
for the purposes of transport parameter estimation and connection for the purposes of transport parameter estimation and connection
management. management.
For the purposes of parameter estimation, the Transport layer is For the purposes of parameter estimation, the Transport layer is
primarily interested in path properties that impact performance, and primarily interested in path properties that impact performance, and
where link indications may be determined to be relevant to path where link indications may be determined to be relevant to path
properties they may be utilized directly. Link indications such as properties they may be utilized directly. Link indications such as
"Link Up"/"Link Down" or changes in rate, delay and frame loss may "Link Up"/"Link Down" or changes in rate, delay and frame loss may
prove relevant. This will not always be the case, however; where the prove relevant. This will not always be the case, however; where the
bandwidth of the bottleneck on the end-to-end path is already much bandwidth of the bottleneck on the end-to-end path is already much
lower than the transmission rate, an increase in transmission rate lower than the transmission rate, an increase in transmission rate
may not materially affect path properties. As described in Appendix may not materially affect path properties. As described in Appendix
A.3, the algorithms for utilizing link layer indications to improve A.3, the algorithms for utilizing link layer indications to improve
transport parameter estimates are still under development. transport parameter estimates are still under development.
For the purposes of transport parameter estimation, strict layering Strict layering considerations do not apply in transport path
considerations do not apply since they may hide useful information. parameter estimation in order to enable the transport layer to make
For example, if the Transport layer can determine that link use of all available information. For example, if the Transport
indication came from a link forming part of the path, it may utilize layer may determine that a link indication came from a link forming
the receipt of a "Link Down" indication followed by a subsequent part of a path of one or more connections. In this case, it may
"Link Up" indication to infer the possibility of non-congestive utilize the receipt of a "Link Down" indication followed by a
packet loss during the period between the indications, even if the IP subsequent "Link Up" indication to infer the possibility of non-
configuration does not change as a result, so that no Internet layer congestive packet loss during the period between the indications,
indication would be sent. even if the IP configuration does not change as a result, so that no
Internet layer indication would be sent.
For the purposes of parameter estimation, the Transport layer may The Transport layer may also find Internet layer indications useful
also wish to use Internet layer indications. For example, path for path parameter estimation. For example, path change indications
change indications can be used as a signal to reset parameter can be used as a signal to reset path parameter estimates; Where
estimates. Changes in the routing table may also be useful; loss of there is no default route, loss of segments sent to a destination
segments sent to a destination with no prefix in the routing table lacking a prefix in the local routing table may be assumed to be due
may be assumed to be due to causes other than congestion, regardless to causes other than congestion, regardless of the reason for the
of the reason for the removal (either because local link conditions removal (either because local link conditions caused it to be removed
caused it to be removed or because the route was withdrawn by a or because the route was withdrawn by a remote router).
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 may tear down a connection based
layer indications such as changes in the incoming/outgoing interface on Internet layer indications (such as a endpoint address changes),
and IP configuration changes. but does not take link indications into account. Just as a "Link Up"
event may not result in a configuration change, and a configuration
Just as a "Link Up" event may not result in a configuration change, change may not result in connection teardown, the Transport layer
and a configuration change may not result in connection teardown, the does not tear down connections on receipt of a "Link Down"
Transport layer does not tear down connections on receipt of a "Link 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. indication.
Even where the "Link Down" indication results from an explicit Even where the "Link Down" indication results from an explicit
exchange such as receipt of a Point-to-Point Protocol (PPP) Link exchange such as receipt of a Point-to-Point Protocol (PPP) Link
Control Protocol (LCP)-Terminate or an IEEE 802.11 Disassociate or Control Protocol (LCP)-Terminate or an IEEE 802.11 Disassociate or
Deauthenticate frame, an alternative point of attachment may be Deauthenticate frame, an alternative point of attachment may be
available, allowing connectivity to be quickly restored. As a available, allowing connectivity to be quickly restored. As a
result, robustness is best achieved by allowing connections to remain result, robustness is best achieved by allowing connections to remain
up until an endpoint address changes, or the connection is torn down up until an endpoint address changes, or the connection is torn down
due to lack of response to repeated retransmission attempts. due to lack of response to repeated retransmission attempts.
For the purposes of connection management, the Transport layer is For the purposes of connection management, the Transport layer is
cautious with the use of Internet layer indications as well. Changes cautious with the use of Internet layer indications. Changes in the
in the routing table are not relevant for the purposes of connection routing table are not relevant for the purposes of connection
management, since it is desirable for connections to remain up during management, since it is desirable for connections to remain up during
transitory routing flaps. The Transport layer may utilize a change transitory routing flaps. However, the transport layer may tear down
in incoming/outgoing change as a path change indication, or tear down
transport connections due to invalidation of a connection endpoint IP transport connections due to invalidation of a connection endpoint IP
address. Where the connection has been established based on the home address. Where the connection has been established based on a Mobile
address, a change in the care-of-address need not result in IP home address, a change in the care-of-address need not result in
connection teardown, since the configuration change is masked by the connection teardown, since the configuration change is masked by the
mobility functionality within the Internet layer, and is therefore mobility functionality within the Internet layer, and is therefore
transparent to the Transport layer. transparent to the Transport layer.
"Requirements for Internet Hosts - Communication Layers" [RFC1122] "Requirements for Internet Hosts - Communication Layers" [RFC1122]
[RFC1122] Section 2.4 requires Destination Unreachable, Source [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. Transmission Control Protocol (TCP) to react to an Internet Control
Message Protocol (ICMP) Source Quench by slowing transmission.
[RFC1122] Section 4.2.3.9 distinguishes between ICMP messages [RFC1122] Section 4.2.3.9 distinguishes between ICMP messages
indicating soft error conditions, which must not cause TCP to abort a indicating soft error conditions, which must not cause TCP to abort a
connection, and hard error conditions, which should cause an abort. connection, and hard error conditions, which should cause an abort.
ICMP messages indicating soft error conditions include Destination ICMP messages indicating soft error conditions include Destination
Unreachable codes 0 (Net), 1 (Host) and 5 (Source Route Failed), Unreachable codes 0 (Net), 1 (Host) and 5 (Source Route Failed),
which may result from routing transients; Time Exceeded; and which may result from routing transients; Time Exceeded; and
Parameter Problem. ICMP messages indicating hard error conditions Parameter Problem. ICMP messages indicating hard error conditions
include Destination Unreachable codes 2 (Protocol Unreachable), 3 include Destination Unreachable codes 2 (Protocol Unreachable), 3
(Port Unreachable), and 4 (Fragmentation Needed and Don't Fragment (Port Unreachable), and 4 (Fragmentation Needed and Don't Fragment
skipping to change at page 12, line 28 skipping to change at page 12, line 43
"ICMP attacks against TCP" [Gont] argues that accepting ICMP messages "ICMP attacks against TCP" [Gont] argues that accepting ICMP messages
based on a correct four-tuple without additional security checks is based on a correct four-tuple without additional security checks is
ill-advised. For example, an attacker forging an ICMP hard error ill-advised. For example, an attacker forging an ICMP hard error
message can cause one or more transport connections to abort. The message can cause one or more transport connections to abort. The
authors discuss a number of precautions, including mechanisms for authors discuss a number of precautions, including mechanisms for
validating ICMP messages and ignoring or delaying response to hard validating ICMP messages and ignoring or delaying response to hard
error messages under various conditions. They also recommend that error messages under various conditions. They also recommend that
hosts ignore ICMP Source Quench messages. hosts ignore ICMP Source Quench messages.
The Transport layer may also provide information to the link layer.
For example, the Transport layer may wish to control the maximum
number of times that a link layer frame may be retransmitted, so that
the link layer does not continue to retransmit after a Transport
layer timeout. In IEEE 802.11, this can be achieved by adjusting the
Management Information Base (MIB) [IEEE-802.11] variables
dot11ShortRetryLimit (default: 7) and dot11LongRetryLimit (default:
4), which control the maximum number of retries for frames shorter
and longer in length than dot11RTSThreshold, respectively. However,
since these variables control link behavior as a whole they cannot be
used to separately adjust behavior on a per-transport connection
basis. In situations where the link layer retransmission timeout is
of the same order as the path round trip timeout, link layer control
may not be possible at all.
1.4.3. Application Layer 1.4.3. Application Layer
The Transport layer provides indications to the Application layer by The Transport layer provides indications to the Application layer by
propagating Internet layer indications (such as IP address propagating Internet layer indications (such as IP address
configuration and changes), as well as providing its own indications, configuration and changes), as well as providing its own indications,
such as connection teardown. such as connection teardown.
The Transport layer may also provide indications to the link layer.
For example, where the link layer retransmission timeout is
significantly less than the path round-trip timeout, the Transport
layer may wish to control the maximum number of times that a link
layer frame may be retransmitted, so that the link layer does not
continue to retransmit after a Transport layer timeout. In IEEE
802.11, this can be achieved by adjusting the Management Information
Base (MIB) variables dot11ShortRetryLimit (default: 7) and
dot11LongRetryLimit (default: 4), which control the maximum number of
retries for frames shorter and longer in length than
dot11RTSThreshold, respectively. However, since these variables
control link behavior as a whole they cannot be used to separately
adjust behavior on a per-transport connection basis. In situations
where the link layer retransmission timeout is of the same order as
the path round trip timeout, link layer control may not be possible
at all.
Since applications can typically obtain the information they need Since applications can typically obtain the information they need
more reliably from the Internet and Transport layers, they will more reliably from the Internet and Transport layers, they will
typically not need to utilize link indications. A "Link Up" typically not need to utilize link indications. A "Link Up"
indication implies that the link is capable of communicating IP indication implies that the link is capable of communicating IP
packets, but does not indicate that it has been configured; packets, but does not indicate that it has been configured;
applications should use an Internet layer "IP Address Configured" applications should use an Internet layer "IP Address Configured"
event instead. "Link Down" indications are typically not useful to event instead. "Link Down" indications are typically not useful to
applications, since they can be rapidly followed by a "Link Up" applications, since they can be rapidly followed by a "Link Up"
indication; applications should respond to Transport layer teardown indication; applications should respond to Transport layer teardown
indications instead. Similarly, changes in the transmission rate may indications instead. Similarly, changes in the transmission rate may
skipping to change at page 17, line 35 skipping to change at page 17, line 44
reachability, since it could have been generated after exchange of reachability, since it could have been generated after exchange of
small frames at low rates, which might not imply bi-directional small frames at low rates, which might not imply bi-directional
connectivity for large frames exchanged at higher rates. connectivity for large frames exchanged at higher rates.
Where multi-path interference or hidden nodes are encountered, signal Where multi-path interference or hidden nodes are encountered, signal
strength may vary widely over a short distance. Several techniques strength may vary widely over a short distance. Several techniques
may be used to reduce potential disruptions. Multiple transmitting may be used to reduce potential disruptions. Multiple transmitting
and receiving antennas may be used to reduce multi-path effects; and receiving antennas may be used to reduce multi-path effects;
transmission rate adaptation can be used to find a more satisfactory transmission rate adaptation can be used to find a more satisfactory
transmission rate; transmit power adjustment can be used to improve transmission rate; transmit power adjustment can be used to improve
signal quality and reduce interference; Ready-to-Send/Clear-to-Send signal quality and reduce interference; Request-to-Send/Clear-to-Send
(RTS/CTS) signaling can be used to reduce hidden node problems. (RTS/CTS) signaling can be used to reduce hidden node problems.
These techniques may not be completely effective, so that high frame These techniques may not be completely effective, so that high frame
loss may be encountered, causing the link to cycle between "up" and loss may be encountered, causing the link to cycle between "up" and
"down" states. "down" states.
To improve robustness against spurious link indications, it is To improve robustness against spurious link indications, it is
recommended that upper layers treat the indication as a "hint" recommended that upper layers treat the indication as a "hint"
(advisory in nature), rather than a "trigger" dictating a particular (advisory in nature), rather than a "trigger" dictating a particular
action. Upper layers may then attempt to validate the hint. action. Upper layers may then attempt to validate the hint.
skipping to change at page 18, line 31 skipping to change at page 18, line 40
from link indications determined to be invalid after they have been from link indications determined to be invalid after they have been
acted on. acted on.
In DNAv4 [RFC4436], reachability tests are carried out coincident In DNAv4 [RFC4436], reachability tests are carried out coincident
with a request for configuration via DHCP. Therefore if the bi- with a request for configuration via DHCP. Therefore if the bi-
directional reachability test times out, the host can still obtain an directional reachability test times out, the host can still obtain an
IP configuration via DHCP, and if that fails, the host can still IP configuration via DHCP, and if that fails, the host can still
continue to use an existing valid address if it has one. continue to use an existing valid address if it has one.
Where a proposal involves recovery at the transport layer, the Where a proposal involves recovery at the transport layer, the
recovered transport parameters (such as the MSS, RTT, RTO, congestion recovered transport parameters (such as the Maximum Segment Size
window, etc.) should be demonstrated to remain valid. Congestion (MSS), RoundTrip Time (RTT), Retransmission TimeOut (RTO), Bandwidth
window validation is discussed in "TCP Congestion Window Validation" (bw), congestion window (cwnd), etc.) should be demonstrated to
[RFC2861]. remain valid. Congestion window validation is discussed in "TCP
Congestion Window Validation" [RFC2861].
Where timely recovery is not supported, unexpected consequences may Where timely recovery is not supported, unexpected consequences may
result. As described in [RFC3927], early IPv4 Link-Local result. As described in [RFC3927], early IPv4 Link-Local
implementations would wait five minutes before attempting to obtain a implementations would wait five minutes before attempting to obtain a
routable address after assigning an IPv4 Link-Local address. In one routable address after assigning an IPv4 Link-Local address. In one
implementation, it was observed that where mobile hosts changed their implementation, it was observed that where mobile hosts changed their
point of attachment more frequently than every five minutes, they point of attachment more frequently than every five minutes, they
would never obtain a routable address. The problem was caused by an would never obtain a routable address. The problem was caused by an
invalid link indication (signaling of "Link Up" prior to completion invalid link indication (signaling of "Link Up" prior to completion
of link layer authentication), resulting in an initial failure to of link layer authentication), resulting in an initial failure to
skipping to change at page 21, line 26 skipping to change at page 21, line 31
configuration is a lengthy timeout. As a result, the recommended configuration is a lengthy timeout. As a result, the recommended
strategy is to test multiple potential configurations in parallel in strategy is to test multiple potential configurations in parallel in
addition to attempting configuration via DHCP. This virtually addition to attempting configuration via DHCP. This virtually
guarantees that DNAv4 will always result in performance equal to or guarantees that DNAv4 will always result in performance equal to or
better than use of DHCP alone. better than use of DHCP alone.
2.6. Interoperability 2.6. Interoperability
While link indications can be utilized where available, they should While link indications can be utilized where available, they should
not be required by upper layers, in order to maintain link layer not be required by upper layers, in order to maintain link layer
independence. For example, if link layer prefix hints are provided, independence. For example, if information on supported prefixes is
hosts not understanding those hints must still be able to obtain an provided at the link layer, hosts not understanding those hints must
IP address. still be able to obtain an IP address.
Where link indications are proposed to optimize Internet layer Where link indications are proposed to optimize Internet layer
configuration, proposals must demonstrate that they do not compromise configuration, proposals must demonstrate that they do not compromise
robustness by interfering with address assignment or routing protocol robustness by interfering with address assignment or routing protocol
behavior, making address collisions more likely, or compromising behavior, making address collisions more likely, or compromising
Duplicate Address Detection (DAD) [RFC4429]. Duplicate Address Detection (DAD) [RFC4429].
To avoid compromising interoperability in the pursuit of performance To avoid compromising interoperability in the pursuit of performance
optimization, proposals must demonstrate that interoperability optimization, proposals must demonstrate that interoperability
remains possible (potentially with degraded performance) even if one remains possible (potentially with degraded performance) even if one
skipping to change at page 22, line 35 skipping to change at page 22, line 42
Path change re-estimation Path change re-estimation
Layering Layering
Metric consistency Metric consistency
2.7.1. Path Change Re-estimation 2.7.1. Path Change Re-estimation
When the Internet layer detects a path change, such as a major change When the Internet layer detects a path change, such as a major change
in transmission rate, a change in the outgoing or incoming interface in transmission rate, a change in the outgoing or incoming interface
of the host or the incoming interface of a peer, or perhaps even a of the host or the incoming interface of a peer, or perhaps even a
substantial change in the TTL of received IP packets, it may be worth substantial change in the IPv4 TTL/IPv6 Hop Limit of received
considering whether to reset transport parameters (RTT, RTO, cwnd, packets, it may be worth considering whether to reset transport
bw, MSS) to their initial values so as to allow them to be re- parameters (RTT, RTO, cwnd, bw, MSS) to their initial values so as to
estimated. This ensures that estimates based on the former path do allow them to be re-estimated. This ensures that estimates based on
not persist after they have become invalid. Appendix A.3 summarizes the former path do not persist after they have become invalid.
the research on this topic. Appendix A.3 summarizes the research on this topic.
2.7.2. Layering 2.7.2. Layering
Another technique to avoid race conditions is to rely on layering to Another technique to avoid race conditions is to rely on layering to
damp transient link indications and provide greater link layer damp transient link indications and provide greater link layer
independence. independence.
The Internet layer is responsible for routing as well as IP The Internet layer is responsible for routing as well as IP
configuration and mobility, providing higher layers with an configuration and mobility, providing higher layers with an
abstraction that is independent of link layer technologies. abstraction that is independent of link layer technologies.
skipping to change at page 23, line 46 skipping to change at page 23, line 51
measured by a packet pair [Morgan]. However, ETT assumes that the measured by a packet pair [Morgan]. However, ETT assumes that the
loss fraction of small probe frames sent at 1 Mbps data rate is loss fraction of small probe frames sent at 1 Mbps data rate is
indicative of the loss fraction of larger data frames at higher indicative of the loss fraction of larger data frames at higher
rates, which tends to under-estimate the ETT at higher rates, where rates, which tends to under-estimate the ETT at higher rates, where
frame loss typically increases. In "A Radio Aware Routing Protocol frame loss typically increases. In "A Radio Aware Routing Protocol
for Wireless Mesh Networks" [ETX-Radio] the authors refine the ETT for Wireless Mesh Networks" [ETX-Radio] the authors refine the ETT
metric further by estimating the loss fraction as a function of metric further by estimating the loss fraction as a function of
transmission rate. transmission rate.
However, prior to sending data packets over the link, the appropriate However, prior to sending data packets over the link, the appropriate
routing metric may not be easily be predicted. As noted in routing metric may not easily be predicted. As noted in [Shortest],
[Shortest], a link that can successfully transmit the short frames a link that can successfully transmit the short frames utilized for
utilized for control, management or routing may not necessarily be control, management or routing may not necessarily be able to
able to reliably transport larger data packets. reliably transport larger data packets.
Therefore it may be necessary to utilize alternative metrics (such as Therefore it may be necessary to utilize alternative metrics (such 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 24, line 26 skipping to change at page 24, line 32
"An experimental study of IEEE 802.11b handover performance and its "An experimental study of IEEE 802.11b handover performance and its
effect on voice traffic" [Vatn] have suggested using signal strength effect on voice traffic" [Vatn] have suggested using signal strength
as a mechanism to more rapidly detect loss of connectivity, rather as a mechanism to more rapidly detect loss of connectivity, rather
than frame loss, as suggested in "Techniques to Reduce IEEE 802.11b than frame loss, as suggested in "Techniques to Reduce IEEE 802.11b
MAC Layer Handover Time" [Velayos]. MAC Layer Handover Time" [Velayos].
[Aguayo] notes that signal strength and distance are not good [Aguayo] notes that signal strength and distance are not good
predictors of frame loss or throughput, due to the potential effects predictors of frame loss or throughput, due to the potential effects
of multi-path interference. As a result a link brought up due to of multi-path interference. As a result a link brought up due to
good signal strength may subsequently exhibit significant frame loss, good signal strength may subsequently exhibit significant frame loss,
and a low throughput. Similarly, an AP demonstrating low utilization and a low throughput. Similarly, an Access Point (AP) demonstrating
may not necessarily be the best choice, since utilization may be low low utilization may not necessarily be the best choice, since
due to hardware or software problems. "OSPF Optimized Multipath utilization may be low due to hardware or software problems. "OSPF
(OSPF-OMP)" [Villamizar] notes that link utilization-based routing Optimized Multipath (OSPF-OMP)" [Villamizar] notes that link
metrics have a history of instability. utilization-based routing metrics have a history of instability.
2.8. Layer compression 2.8. Layer compression
In many situations, the exchanges required for a host to complete a In many situations, the exchanges required for a host to complete a
handoff and reestablish connectivity are considerable, leading to handoff and reestablish connectivity are considerable, leading to
proposals to combine exchanges occurring within multiple layers in proposals to combine exchanges occurring within multiple layers in
order to reduce overhead. While overhead reduction is a laudable order to reduce overhead. While overhead reduction is a laudable
goal, proposals need to avoid compromising interoperability and goal, proposals need to avoid compromising interoperability and
introducing link layer dependencies into the Internet and Transport introducing link layer dependencies into the Internet and Transport
layers. layers.
skipping to change at page 27, line 49 skipping to change at page 28, line 7
4.1. Spoofing 4.1. Spoofing
Where link layer control frames are unprotected, they may be spoofed Where link layer control frames are unprotected, they may be spoofed
by an attacker. For example, PPP does not protect LCP frames such as by an attacker. For example, PPP does not protect LCP frames such as
LCP-Terminate, and [IEEE-802.11] does not protect management frames LCP-Terminate, and [IEEE-802.11] does not protect management frames
such as Associate/ Reassociate, Disassociate, or Deauthenticate. such as Associate/ Reassociate, Disassociate, or Deauthenticate.
Spoofing of link layer control traffic may enable attackers to Spoofing of link layer control traffic may enable attackers to
exploit weaknesses in link indication proposals. For example, exploit weaknesses in link indication proposals. For example,
proposals that do not implement congestion avoidance can be enable proposals that do not implement congestion avoidance can enable
attackers to mount denial of service attacks. attackers to mount denial of service attacks.
However, even where the link layer incorporates security, attacks may However, even where the link layer incorporates security, attacks may
still be possible if the security model is not consistent. For still be possible if the security model is not consistent. For
example, wireless LANs implementing [IEEE-802.11i] do not enable example, wireless LANs implementing [IEEE-802.11i] do not enable
stations to send or receive IP packets on the link until completion stations to send or receive IP packets on the link until completion
of an authenticated key exchange protocol known as the "4-way of an authenticated key exchange protocol known as the "4-way
handshake". As a result, a link implementing [IEEE-802.11i] cannot handshake". As a result, a link implementing [IEEE-802.11i] cannot
be considered usable at the Internet layer ("Link Up") until be considered usable at the Internet layer ("Link Up") until
completion of the authenticated key exchange. completion of the authenticated key exchange.
skipping to change at page 30, line 37 skipping to change at page 30, line 42
[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.
[RFC1305] Mills, D., "Network Time Protocol (Version 3)
Specification, Implementation and Analysis", RFC 1305,
March 1992.
[RFC1307] Young, J. and A. Nicholson, "Dynamically Switched Link [RFC1307] Young, J. and A. Nicholson, "Dynamically Switched Link
Control Protocol", RFC 1307, March 1992. Control Protocol", RFC 1307, March 1992.
[RFC1661] Simpson, W., "The Point-to-Point Protocol (PPP)", STD 51, [RFC1661] Simpson, W., "The Point-to-Point Protocol (PPP)", STD 51,
RFC 1661, July 1994. RFC 1661, July 1994.
[RFC1812] Baker, F., "Requirements for IP Version 4 Routers", RFC [RFC1812] Baker, F., "Requirements for IP Version 4 Routers", RFC
1812, June 1995. 1812, June 1995.
[RFC1918] Rekhter, Y., Moskowitz, B., Karrenberg, D., de Groot, D. [RFC1918] Rekhter, Y., Moskowitz, B., Karrenberg, D., de Groot, D.
skipping to change at page 32, line 16 skipping to change at page 32, line 27
Configuration of Link-Local IPv4 Addresses", RFC 3927, Configuration of Link-Local IPv4 Addresses", RFC 3927,
May 2005. May 2005.
[RFC3971] Arkko, J., Kempf, J., Zill, B. and P. Nikander, "SEcure [RFC3971] Arkko, J., Kempf, J., Zill, B. and P. Nikander, "SEcure
Neighbor Discovery (SEND)", RFC 3971, March 2005. Neighbor Discovery (SEND)", RFC 3971, March 2005.
[RFC4340] Kohler, E., Handley, M. and S. Floyd, "Datagram [RFC4340] Kohler, E., Handley, M. and S. Floyd, "Datagram
Congestion Control Protocol (DCCP)", RFC 4340, March Congestion Control Protocol (DCCP)", RFC 4340, March
2006. 2006.
[RFC4423] Moskowitz, R. and P. Nikander, "Host Identity Protocol
(HIP) Architecture", RFC 4423, May 2006.
[RFC4429] Moore, N., "Optimistic Duplicate Address Detection (DAD) [RFC4429] Moore, N., "Optimistic Duplicate Address Detection (DAD)
for IPv6", RFC 4429, April 2006. for IPv6", RFC 4429, April 2006.
[RFC4436] Aboba, B., Carlson, J. and S. Cheshire, "Detecting [RFC4436] Aboba, B., Carlson, J. and S. Cheshire, "Detecting
Network Attachment in IPv4 (DNAv4)", RFC 4436, March Network Attachment in IPv4 (DNAv4)", RFC 4436, March
2006. 2006.
[PMTUDRFC] Mathis, M. and J. Heffner, "Packetization Layer Path MTU [PMTUDRFC] Mathis, M. and J. Heffner, "Packetization Layer Path MTU
Discovery", draft-ietf-pmtud-method-11, Internet draft Discovery", draft-ietf-pmtud-method-11, Internet draft
(work in progress), December 2006. (work in progress), December 2006.
skipping to change at page 39, line 9 skipping to change at page 39, line 23
1999. 1999.
[Yegin] Yegin, A., "Link-layer Triggers Protocol", draft-yegin- [Yegin] Yegin, A., "Link-layer Triggers Protocol", draft-yegin-
l2-triggers-00.txt, Internet Draft (work in progress), l2-triggers-00.txt, Internet Draft (work in progress),
June 2002. June 2002.
Acknowledgments Acknowledgments
The authors would like to acknowledge James Kempf, Phil Roberts, The authors would like to acknowledge James Kempf, Phil Roberts,
Gorry Fairhurst, John Wroclawski, Aaron Falk, Sally Floyd, Pekka Gorry Fairhurst, John Wroclawski, Aaron Falk, Sally Floyd, Pekka
Savola, Pekka Nikander, Yogesh Swami, Wesley Eddy and Janne Peisa for Savola, Pekka Nikander, Dave Thaler, Yogesh Swami, Wesley Eddy and
contributions to this document. Janne Peisa for contributions to this document.
Appendix A - Literature Review Appendix A - Literature Review
This Appendix summarizes the literature with respect to link This Appendix summarizes the literature with respect to link
indications on wireless local area networks. indications on wireless local area networks.
A.0 Terminology
Access Point (AP)
A station that provides access to the fixed network (e.g. an 802.11
Distribution System), via the wireless medium (WM) for associated
stations.
Beacon
A control message broadcast by a station (typically an Access
Point), informing stations in the neighborhood of its continuing
presence, possibly along with additional status or configuration
information.
Binding Update (BU)
A message indicating a mobile node's current mobility binding, and
in particular its care-of address.
Correspondent Node
A peer node with which a mobile node is communicating. The
correspondent node may be either mobile or stationary.
Mobile Node
A node that can change its point of attachment from one link to
another, while still being reachable via its home address.
Station (STA)
Any device that contains an IEEE 802.11 conformant medium access
control (MAC) and physical layer (PHY) interface to the wireless
medium (WM).
A.1 Link Layer A.1 Link Layer
The characteristics of wireless links have been found to vary The characteristics of wireless links have been found to vary
considerably depending on the environment. considerably depending on the environment.
In "Performance of Multihop Wireless Networks: Shortest Path is Not In "Performance of Multihop Wireless Networks: Shortest Path is Not
Enough" [Shortest] the authors studied the performance of both an Enough" [Shortest] the authors studied the performance of both an
indoor and outdoor mesh network. By measuring inter-node throughput, indoor and outdoor mesh network. By measuring inter-node throughput,
the best path between nodes was computed. The throughput of the best the best path between nodes was computed. The throughput of the best
path was compared with the throughput of the shortest path computed path was compared with the throughput of the shortest path computed
skipping to change at page 41, line 51 skipping to change at page 41, line 20
infrastructure networks site surveys and careful measurement can infrastructure networks site surveys and careful measurement can
assist in promoting ideal behavior, in ad-hoc/mesh networks node assist in promoting ideal behavior, in ad-hoc/mesh networks node
mobility and external factors such as weather may not be easily mobility and external factors such as weather may not be easily
controlled. controlled.
Considerable diversity in behavior is also observed due to Considerable diversity in behavior is also observed due to
implementation effects. "Techniques to reduce IEEE 802.11b MAC layer implementation effects. "Techniques to reduce IEEE 802.11b MAC layer
handover time" [Velayos] measured handover times for a stationary STA handover time" [Velayos] measured handover times for a stationary STA
after the AP was turned off. This study divided handover times into after the AP was turned off. This study divided handover times into
detection (determination of disconnection from the existing point of detection (determination of disconnection from the existing point of
attachment) search (discovery of alternative attachment points), and attachment), search (discovery of alternative attachment points), and
execution phases (connection to an alternative point of attachment). execution phases (connection to an alternative point of attachment).
These measurements indicated that the duration of the detection phase These measurements indicated that the duration of the detection phase
(the largest component of handoff delay) is determined by the number (the largest component of handoff delay) is determined by the number
of non-acknowledged frames triggering the search phase and delays due of non-acknowledged frames triggering the search phase and delays due
to precursors such as RTS/CTS and rate adaptation. to precursors such as RTS/CTS and rate adaptation.
Detection behavior varied widely between implementations. For Detection behavior varied widely between implementations. For
example, NICs designed for desktops attempted more retransmissions example, NICs designed for desktops attempted more retransmissions
prior to triggering search as compared with laptop designs, since prior to triggering search as compared with laptop designs, since
they assumed that the AP was always in range, regardless of whether they assumed that the AP was always in range, regardless of whether
the Beacon was received. the Beacon was received.
skipping to change at page 42, line 31 skipping to change at page 41, line 48
interference than monitoring of the S/N ratio. Where the STA is not interference than monitoring of the S/N ratio. Where the STA is not
sending or receiving frames, it is recommended that Beacon reception sending or receiving frames, it is recommended that Beacon reception
be tracked in order to detect disconnection, and that Beacon spacing be tracked in order to detect disconnection, and that Beacon spacing
be reduced to 60 ms in order to reduce detection times. In order to be reduced to 60 ms in order to reduce detection times. In order to
compensate for more frequent triggering of the search phase, the compensate for more frequent triggering of the search phase, the
authors recommend algorithms for wait time reduction, as well as authors recommend algorithms for wait time reduction, as well as
interleaving of search and data frame transmission. interleaving of search and data frame transmission.
"An Empirical Analysis of the IEEE 802.11 MAC Layer Handoff Process" "An Empirical Analysis of the IEEE 802.11 MAC Layer Handoff Process"
[Mishra] investigates handoff latencies obtained with three mobile [Mishra] investigates handoff latencies obtained with three mobile
STAs implementations communicating with two APs. The study found STA implementations communicating with two APs. The study found that
that there is large variation in handoff latency among STA and AP there is large variation in handoff latency among STA and AP
implementations and that implementations utilize different message implementations and that implementations utilize different message
sequences. For example, one STA sends a Reassociation Request prior sequences. For example, one STA sends a Reassociation Request prior
to authentication, which results in receipt of a Deauthenticate to authentication, which results in receipt of a Deauthenticate
message. The study divided handoff latency into discovery, message. The study divided handoff latency into discovery,
authentication and reassociation exchanges, concluding that the authentication and reassociation exchanges, concluding that the
discovery phase was the dominant component of handoff delay. Latency discovery phase was the dominant component of handoff delay. Latency
in the detection phase was not investigated. in the detection phase was not investigated.
"SyncScan: Practical Fast Handoff for 802.11 Infrastructure Networks" "SyncScan: Practical Fast Handoff for 802.11 Infrastructure Networks"
[Ramani] weighs the pros and cons of active versus passive scanning. [Ramani] weighs the pros and cons of active versus passive scanning.
skipping to change at page 43, line 10 skipping to change at page 42, line 27
subsequent responses to a broadcast Probe Response (MinChannelTime subsequent responses to a broadcast Probe Response (MinChannelTime
and MaxChannelTime, respectively), performance is comparable to what and MaxChannelTime, respectively), performance is comparable to what
is achievable with 802.11k Neighbor Reports and unicast Probe is achievable with 802.11k Neighbor Reports and unicast Probe
Requests. Requests.
The authors measure the channel switching delay, the time it takes to The authors measure the channel switching delay, the time it takes to
switch to a new frequency, and begin receiving frames. Measurements switch to a new frequency, and begin receiving frames. Measurements
ranged from 5 ms to 19 ms per channel; where timed Beacon reception ranged from 5 ms to 19 ms per channel; where timed Beacon reception
or interleaved active scanning is used, switching time contributes or interleaved active scanning is used, switching time contributes
significantly to overall handoff latency. The authors propose significantly to overall handoff latency. The authors propose
deployment of APs with Beacons synchronized via NTP, enabling a deployment of APs with Beacons synchronized via Network Time Protocol
driver implementing SyncScan to work with legacy APs without (NTP) [RFC1305], enabling a driver implementing SyncScan to work with
requiring implementation of new protocols. The authors measure the legacy APs without requiring implementation of new protocols. The
distribution of inter-arrival times for stations implementing authors measure the distribution of inter-arrival times for stations
SyncScan, with excellent results. implementing SyncScan, with excellent results.
"Roaming Interval Measurements" [Alimian] presents data on stationary "Roaming Interval Measurements" [Alimian] presents data on the
STAs after the AP signal has been shut off. This study highlighted behavior of stationary STAs after the AP signal has been shut off.
implementation differences in rate adaptation as well as detection, This study highlighted implementation differences in rate adaptation
scanning and handoff. As in [Velayos], performance varied widely as well as detection, scanning and handoff. As in [Velayos],
between implementations, from half an order of magnitude variation in performance varied widely between implementations, from half an order
rate adaptation to an order of magnitude difference in detection of magnitude variation in rate adaptation to an order of magnitude
times, two orders of magnitude in scanning, and one and a half orders difference in detection times, two orders of magnitude in scanning,
of magnitude in handoff times. and one and a half orders of magnitude in handoff times.
"An experimental study of IEEE 802.11b handoff performance and its "An experimental study of IEEE 802.11b handoff performance and its
effect on voice traffic" [Vatn] describes handover behavior observed effect on voice traffic" [Vatn] describes handover behavior observed
when the signal from AP is gradually attenuated, which is more when the signal from the AP is gradually attenuated, which is more
representative of field experience than the shutoff techniques used representative of field experience than the shutoff techniques used
in [Velayos]. Stations were configured to initiate handover when in [Velayos]. Stations were configured to initiate handover when
signal strength dipped below a threshold, rather than purely based on signal strength dipped below a threshold, rather than purely based on
frame loss, so that they could begin handover while still connected frame loss, so that they could begin handover while still connected
to the current AP. It was noted that stations continue to receive to the current AP. It was noted that stations continue to receive
data frames during the search phase. Station-initiated data frames during the search phase. Station-initiated
Disassociation and pre-authentication were not observed in this Disassociation and pre-authentication were not observed in this
study. study.
A.1.1 Link Indications A.1.1 Link Indications
skipping to change at page 45, line 25 skipping to change at page 44, line 44
access point. Rather than registering a "Link Down" indication with access point. Rather than registering a "Link Down" indication with
each move, the station may instead register a series of "Link Up" each move, the station may instead register a series of "Link Up"
indications. indications.
In [IEEE-802.11i] forwarding of frames from the station to the In [IEEE-802.11i] forwarding of frames from the station to the
distribution system is only feasible after the completion of the distribution system is only feasible after the completion of the
4-way handshake and group-key handshake, so that entering State 3 is 4-way handshake and group-key handshake, so that entering State 3 is
no longer sufficient. This has resulted in several observed no longer sufficient. This has resulted in several observed
problems. For example, where a "Link Up" indication is triggered on problems. For example, where a "Link Up" indication is triggered on
the station by receipt of an Association/Reassociation Response, DHCP the station by receipt of an Association/Reassociation Response, DHCP
[RFC2131] or RS/RA may be triggered prior to when the link is usable [RFC2131] or Router Solicitation/Router Advertisement (RS/RA) may be
by the Internet layer, resulting in configuration delays or failures. triggered prior to when the link is usable by the Internet layer,
Similarly, Transport layer connections will encounter packet loss, resulting in configuration delays or failures. Similarly, Transport
resulting in back-off of retransmission timers. layer connections will encounter packet loss, resulting in back-off
of retransmission timers.
A.1.2 Smart Link Layer Proposals A.1.2 Smart Link Layer Proposals
In order to improve link layer performance, several studies have In order to improve link layer performance, several studies have
investigated "smart link layer" proposals. investigated "smart link layer" proposals.
"Advice to link designers on link Automatic Repeat reQuest (ARQ)" "Advice to link designers on link Automatic Repeat reQuest (ARQ)"
[RFC3366] provides advice to the designers of digital communication [RFC3366] provides advice to the designers of digital communication
equipment and link-layer protocols employing link-layer Automatic equipment and link-layer protocols employing link-layer Automatic
Repeat reQuest (ARQ) techniques for IP. It discusses the use of ARQ, Repeat reQuest (ARQ) techniques for IP. It discusses the use of ARQ,
timers, persistency in retransmission and the challenges that arise timers, persistency in retransmission and the challenges that arise
from sharing links between multiple flows and in differentiation from sharing links between multiple flows and in differentiation
transport flow requirements. transport flow requirements.
skipping to change at page 45, line 47 skipping to change at page 45, line 19
equipment and link-layer protocols employing link-layer Automatic equipment and link-layer protocols employing link-layer Automatic
Repeat reQuest (ARQ) techniques for IP. It discusses the use of ARQ, Repeat reQuest (ARQ) techniques for IP. It discusses the use of ARQ,
timers, persistency in retransmission and the challenges that arise timers, persistency in retransmission and the challenges that arise
from sharing links between multiple flows and in differentiation from sharing links between multiple flows and in differentiation
transport flow requirements. transport flow requirements.
In "Link-layer Enhancements for TCP/IP over GSM" [Ludwig], the In "Link-layer Enhancements for TCP/IP over GSM" [Ludwig], the
authors describe how the GSM reliable and unreliable link layer modes authors describe how the GSM reliable and unreliable link layer modes
can be simultaneously utilized without higher layer control. Where a can be simultaneously utilized without higher layer control. Where a
reliable link layer protocol is required (where reliable transports reliable link layer protocol is required (where reliable transports
such TCP and SCTP are used), the Radio Link Protocol (RLP) can be such TCP and Stream Control Transmission Protocol (SCTP) are used),
engaged; with delay sensitive applications such as those based on the Radio Link Protocol (RLP) can be engaged; with delay sensitive
UDP, the transparent mode (no RLP) can be used. The authors also applications such as those based on UDP, the transparent mode (no
describe how PPP negotiation can be optimized over high latency GSM RLP) can be used. The authors also describe how PPP negotiation can
links using "Quickstart-PPP". be optimized over high latency GSM links using "Quickstart-PPP".
In "Link Layer Based TCP Optimisation for Disconnecting Networks" In "Link Layer Based TCP Optimisation for Disconnecting Networks"
[Scott], the authors describe performance problems that occur with [Scott], the authors describe performance problems that occur with
reliable transport protocols facing periodic network disconnections, reliable transport protocols facing periodic network disconnections,
such as those due to signal fading or handoff. The authors define a such as those due to signal fading or handoff. The authors define a
disconnection as a period of connectivity loss that exceeds a disconnection as a period of connectivity loss that exceeds a
retransmission timeout, but is shorter than the connection lifetime. retransmission timeout, but is shorter than the connection lifetime.
One issue is that link-unaware senders continue to backoff during One issue is that link-unaware senders continue to backoff during
periods of disconnection. The authors suggest that a link-aware periods of disconnection. The authors suggest that a link-aware
reliable transport implementation halt retransmission after receiving reliable transport implementation halt retransmission after receiving
skipping to change at page 46, line 28 skipping to change at page 45, line 48
stores the first packet that was not successfully transmitted on a stores the first packet that was not successfully transmitted on a
connection, then retransmits it upon receipt of a "Link Up" connection, then retransmits it upon receipt of a "Link Up"
indication. Since a disconnection can result in hosts experiencing indication. Since a disconnection can result in hosts experiencing
different network conditions upon reconnection, the authors do not different network conditions upon reconnection, the authors do not
advocate bypassing slowstart or attempting to raise the congestion advocate bypassing slowstart or attempting to raise the congestion
window. Where IPsec is used and connections cannot be differentiated window. Where IPsec is used and connections cannot be differentiated
because transport headers are not visible, the first untransmitted because transport headers are not visible, the first untransmitted
packet for a given sender and destination IP address can be packet for a given sender and destination IP address can be
retransmitted. In addition to looking at retransmission of a single retransmitted. In addition to looking at retransmission of a single
packet per connection, the authors also examined other schemes such packet per connection, the authors also examined other schemes such
as retransmission of multiple packets and rereception of single or as retransmission of multiple packets and simulated duplicate
multiple packets. reception of single or multiple packets (known as rereception).
In general, retransmission schemes were superior to rereception In general, retransmission schemes were superior to rereception
schemes, since rereception cannot stimulate fast retransmit after a schemes, since rereception cannot stimulate fast retransmit after a
timeout. Retransmission of multiple packets did not appreciably timeout. Retransmission of multiple packets did not appreciably
improve performance over retransmission of a single packet. Since improve performance over retransmission of a single packet. Since
the focus of the research was on disconnection rather than just lossy the focus of the research was on disconnection rather than just lossy
channels, a two state Markov model was used, with the "up" state channels, a two state Markov model was used, with the "up" state
representing no loss, and the "down" state representing one hundred representing no loss, and the "down" state representing one hundred
percent loss. percent loss.
skipping to change at page 49, line 22 skipping to change at page 48, line 44
reaction time versus FER estimation accuracy; at lower rates reaction time versus FER estimation accuracy; at lower rates
either reaction times slow or FER estimation accuracy will suffer. either reaction times slow or FER estimation accuracy will suffer.
Since this technique only measures the FER at the current rate, it Since this technique only measures the FER at the current rate, it
can only enable adaptation to adjacent rates. can only enable adaptation to adjacent rates.
Retry-based Retry-based
This technique modifies FER control techniques by enabling rapid This technique modifies FER control techniques by enabling rapid
downward rate adaptation after a number (5-10) of unsuccessful re- downward rate adaptation after a number (5-10) of unsuccessful re-
transmissions. Since fewer packets are required, the sensitivity transmissions. Since fewer packets are required, the sensitivity
of reaction time to rate is reduced.. However, upward rate of reaction time to rate is reduced. However, upward rate
adaptation proceeds more slowly since it is based on collection of adaptation proceeds more slowly since it is based on collection of
FER data. This technique is limited to adaptation to adjacent FER data. This technique is limited to adaptation to adjacent
rates, and has the disadvantage of potentially worsening frame rates, and has the disadvantage of potentially worsening frame
loss due to contention. loss due to contention.
While statistics-based techniques are robust against short-lived link While statistics-based techniques are robust against short-lived link
quality changes, they do not respond quickly to long-lived changes. quality changes, they do not respond quickly to long-lived changes.
By constraining the rate selected by statistics-based techniques By constraining the rate selected by statistics-based techniques
based on ACK SSI versus rate data (not theoretical curves), more based on ACK SSI versus rate data (not theoretical curves), more
rapid link adaptation was enabled. In order to ensure rapid rapid link adaptation was enabled. In order to ensure rapid
skipping to change at page 53, line 8 skipping to change at page 52, line 29
handoff. handoff.
In "Detecting Network Attachment (DNA) in IPv4" [RFC4436], a host In "Detecting Network Attachment (DNA) in IPv4" [RFC4436], a host
that has moved to a new point of attachment utilizes a bi-directional that has moved to a new point of attachment utilizes a bi-directional
reachability test in parallel with DHCP [RFC2131] to rapidly reachability test in parallel with DHCP [RFC2131] to rapidly
reconfirm an operable configuration. reconfirm an operable configuration.
In "L2 Triggers Optimized Mobile IPv6 Vertical Handover: The In "L2 Triggers Optimized Mobile IPv6 Vertical Handover: The
802.11/GPRS Example" [Park], the authors propose that the mobile node 802.11/GPRS Example" [Park], the authors propose that the mobile node
send a router solicitation on receipt of a "Link Up" indication in send a router solicitation on receipt of a "Link Up" indication in
order provide lower handoff latency than would be possible using order to provide lower handoff latency than would be possible using
generic movement detection [RFC3775]. The authors also suggest generic movement detection [RFC3775]. The authors also suggest
immediate invalidation of the Care-Of-Address (CoA) on receipt of a immediate invalidation of the Care-Of-Address (CoA) on receipt of a
"Link Down" indication. However, this is problematic where a "Link "Link Down" indication. However, this is problematic where a "Link
Down" indication can be followed by a "Link Up" indication without a Down" indication can be followed by a "Link Up" indication without a
resulting change in IP configuration, as described in [RFC4436]. resulting change in IP configuration, as described in [RFC4436].
In "Layer 2 Handoff for Mobile-IPv4 with 802.11" [Mun], the authors In "Layer 2 Handoff for Mobile-IPv4 with 802.11" [Mun], the authors
suggest that MIPv4 Registration messages be carried within suggest that MIPv4 Registration messages be carried within
Information Elements of IEEE 802.11 Association/Reassociation frames, Information Elements of IEEE 802.11 Association/Reassociation frames,
in order to minimize handoff delays. This requires modification to in order to minimize handoff delays. This requires modification to
skipping to change at page 54, line 6 skipping to change at page 53, line 28
could cause in congestion. Also, where the transmission rate changes could cause in congestion. Also, where the transmission rate changes
frequently, sending registration messages on each transmission rate frequently, sending registration messages on each transmission rate
change could by itself consume significant bandwidth. Even where the change could by itself consume significant bandwidth. Even where the
advertised link characteristics indicate the need for a smaller advertised link characteristics indicate the need for a smaller
congestion window, it may be non-trivial to adjust the sending rates congestion window, it may be non-trivial to adjust the sending rates
of individual connections where there are multiple connections open of individual connections where there are multiple connections open
between a mobile node and correspondent node. A more conservative between a mobile node and correspondent node. A more conservative
approach would be to trigger parameter re-estimation and slow start approach would be to trigger parameter re-estimation and slow start
based on the receipt of a registration message or binding update. based on the receipt of a registration message or binding update.
In "Hotspot Mitigation Protocol (HMP)" [HMP], it is noted that MANET In "Hotspot Mitigation Protocol (HMP)" [HMP], it is noted that Mobile
routing protocols have a tendency to concentrate traffic since they Ad-hoc NETwork (MANET) routing protocols have a tendency to
utilize shortest path metrics and allow nodes to respond to route concentrate traffic since they utilize shortest path metrics and
queries with cached routes. The authors propose that nodes allow nodes to respond to route queries with cached routes. The
participating in an ad-hoc wireless mesh monitor local conditions authors propose that nodes participating in an ad-hoc wireless mesh
such as MAC delay, buffer consumption and packets loss. Where monitor local conditions such as MAC delay, buffer consumption and
congestion is detected, this is communicated to neighboring nodes via packets loss. Where congestion is detected, this is communicated to
an IP option. In response to moderate congestion, nodes suppress neighboring nodes via an IP option. In response to moderate
route requests; where major congestion is detected, nodes throttle congestion, nodes suppress route requests; where major congestion is
TCP connections flowing through them. The authors argue that for ad- detected, nodes rate control transport connections flowing through
hoc networks throttling by intermediate nodes is more effective than them. The authors argue that for ad-hoc networks, throttling by
end-to-end congestion control mechanisms. intermediate nodes is more 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 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 57, line 26 skipping to change at page 56, line 49
portion of the problem was attributed to the inability of the routing portion of the problem was attributed to the inability of the routing
protocol to quickly recognize and purge stale routes, leading to protocol to quickly recognize and purge stale routes, leading to
excessive link failures; performance improved dramatically when route excessive link failures; performance improved dramatically when route
caching was turned off. Interactions between the route request and caching was turned off. Interactions between the route request and
transport retransmission timers were also noted. Where the route transport retransmission timers were also noted. Where the route
request timer is too large, new routes cannot be supplied in time to request timer is too large, new routes cannot be supplied in time to
prevent the transport timer from expiring, and where the route prevent the transport timer from expiring, and where the route
request timer is too small, network congestion may result. request timer is too small, network congestion may result.
For their implementation of ELFN, the authors piggybacked additional For their implementation of ELFN, the authors piggybacked additional
information on an existing "route failure" notice (sender and information (sender and receiver addresses and ports, the TCP
receiver addresses and ports, the TCP sequence number) to enable the sequence number) on an existing "route failure" notice to enable the
sender to identify the affected connection. Where a TCP receives an sender to identify the affected connection. Where a TCP receives an
ELFN, it disables the retransmission timer and enters "stand-by" ELFN, it disables the retransmission timer and enters "stand-by"
mode, where packets are sent at periodic intervals to determine if mode, where packets are sent at periodic intervals to determine if
the route has been reestablished. If an acknowledgment is received the route has been reestablished. If an acknowledgment is received
then the retransmission timers are restored. Simulations show that then the retransmission timers are restored. Simulations show that
performance is sensitive to the probe interval, with intervals of 30 performance is sensitive to the probe interval, with intervals of 30
seconds or greater giving worse performance than TCP-Reno. The seconds or greater giving worse performance than TCP-Reno. The
affect of resetting the congestion window and RTO values was also 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 the congestion window to one
not have much of an effect on throughput, since the bandwidth/delay did not have much of an effect on throughput, since the
of the network was only a few packets. However, resetting the RTO to bandwidth/delay of the network was only a few packets. However,
a high initial value (6 seconds) did have a substantial detrimental resetting the RTO to a high initial value (6 seconds) did have a
effect, particularly at high speed. In terms of the probe packet substantial detrimental effect, particularly at high speed. In terms
sent, the simulations showed little difference between sending the of the probe packet sent, the simulations showed little difference
first packet in the congestion window, or retransmitting the packet between sending the first packet in the congestion window, or
with the lowest sequence number among those signaled as lost via the retransmitting the packet with the lowest sequence number among those
ELFNs. signaled as lost via the ELFNs.
In "Improving TCP Performance over Wireless Links" [Goel], the In "Improving TCP Performance over Wireless Links" [Goel], the
authors propose use of an ICMP-DEFER message, sent by a wireless authors propose use of an ICMP-DEFER message, sent by a wireless
access point on failure of a transmission attempt. After exhaustion access point on failure of a transmission attempt. After exhaustion
of retransmission attempts, an ICMP-RETRANSMIT message is sent. On of retransmission attempts, an ICMP-RETRANSMIT message is sent. On
receipt of an ICMP-DEFER message, the expiry of the retransmission receipt of an ICMP-DEFER message, the expiry of the retransmission
timer is postponed by the current RTO estimate. On receipt of an timer is postponed by the current RTO estimate. On receipt of an
ICMP-RETRANSMIT message, the segment is retransmitted. On ICMP-RETRANSMIT message, the segment is retransmitted. On
retransmission, the congestion window is not reduced; when coming out retransmission, the congestion window is not reduced; when coming out
of fast recovery, the congestion window is reset to its value prior of fast recovery, the congestion window is reset to its value prior
skipping to change at page 58, line 35 skipping to change at page 58, line 10
In "Towards More Expressive Transport-Layer Interfaces" [Eggert2], In "Towards More Expressive Transport-Layer Interfaces" [Eggert2],
the authors propose extensions to existing network/transport and the authors propose extensions to existing network/transport and
transport/application interfaces to improve the performance of the transport/application interfaces to improve the performance of the
transport layer in the face of changes in path characteristics transport layer in the face of changes in path characteristics
varying more quickly than the round-trip time. varying more quickly than the round-trip time.
In "Protocol Enhancements for Intermittently Connected Hosts" In "Protocol Enhancements for Intermittently Connected Hosts"
[Schuetz], the authors note that intermittent connectivity can lead [Schuetz], the authors note that intermittent connectivity can lead
to poor performance and connectivity failures. To address these to poor performance and connectivity failures. To address these
problems, the authors combine the use of the Host Identity Protocol problems, the authors combine the use of the Host Identity Protocol
(HIP) with a TCP User Timeout Option and TCP Retransmission trigger, (HIP) [RFC4423] with a TCP User Timeout Option and TCP Retransmission
demonstrating significant improvement. trigger, demonstrating significant improvement.
A.4 Application Layer A.4 Application Layer
In "Application-oriented Link Adaptation for IEEE 802.11" In "Application-oriented Link Adaptation for IEEE 802.11"
[Haratcherev2], rate information generated by a link layer utilizing [Haratcherev2], rate information generated by a link layer utilizing
improved rate adaptation algorithms is provided to a video improved rate adaptation algorithms is provided to a video
application, and used for codec adaptation. Coupling the link and application, and used for codec adaptation. Coupling the link and
application layers results in major improvements in the Peak application layers results in major improvements in the Peak
Signal/Noise Ratio (PSNR). Since this approach assumes that the link Signal/Noise Ratio (PSNR). Since this approach assumes that the link
represents the path bottleneck bandwidth, it is not universally represents the path bottleneck bandwidth, it is not universally
 End of changes. 55 change blocks. 
208 lines changed or deleted 206 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/