idnits 2.17.1 draft-iab-link-indications-02.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 13. -- Found old boilerplate from RFC 3978, Section 5.5 on line 2240. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 2217. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 2224. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 2230. ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == The page length should not exceed 58 lines per page, but there was 48 longer pages, the longest (page 2) being 60 lines == It seems as if not all pages are separated by form feeds - found 0 form feeds but 49 pages Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack an Authors' Addresses Section. ** There are 5 instances of too long lines in the document, the longest one being 2 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == Line 293 has weird spacing: '... Since the g...' == Line 296 has weird spacing: '...mething is w...' == Line 363 has weird spacing: '...link is usefu...' == Line 413 has weird spacing: '... Since the g...' == Line 416 has weird spacing: '...mething is w...' == (27 more instances...) -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (2 July 2005) is 6872 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Missing Reference: 'PRNET' is mentioned on line 1566, but not defined == Missing Reference: 'RFC826' is mentioned on line 1205, but not defined -- Looks like a reference, but probably isn't: '1' on line 654 -- Looks like a reference, but probably isn't: '2' on line 706 -- Looks like a reference, but probably isn't: '3' on line 714 -- Looks like a reference, but probably isn't: '4' on line 746 == Missing Reference: 'Krishan' is mentioned on line 2167, but not defined == Unused Reference: 'Krishnan' is defined on line 1525, but no explicit reference was found in the text == Unused Reference: 'Mitani' is defined on line 1549, but no explicit reference was found in the text -- Obsolete informational reference (is this intentional?): RFC 816 (Obsoleted by RFC 7805) -- Obsolete informational reference (is this intentional?): RFC 1131 (Obsoleted by RFC 1247) -- Obsolete informational reference (is this intentional?): RFC 2861 (Obsoleted by RFC 7661) -- Obsolete informational reference (is this intentional?): RFC 3775 (Obsoleted by RFC 6275) -- Obsolete informational reference (is this intentional?): RFC 3921 (Obsoleted by RFC 6121) == Outdated reference: A later version (-11) exists of draft-ietf-bfd-base-02 == Outdated reference: A later version (-13) exists of draft-ietf-dccp-spec-08 == Outdated reference: A later version (-18) exists of draft-ietf-dhc-dna-ipv4-13 == Outdated reference: A later version (-15) exists of draft-tschofenig-eap-ikev2-05 == Outdated reference: A later version (-02) exists of draft-eggert-tcpm-tcp-retransmit-now-01 == Outdated reference: A later version (-03) exists of draft-daniel-mip-link-characteristic-01 == Outdated reference: A later version (-04) exists of draft-giaretta-mip6-authorization-eap-02 == Outdated reference: A later version (-05) exists of draft-koki-mobopts-l2-abstractions-02 == Outdated reference: A later version (-07) exists of draft-swami-tcp-lmdr-05 == Outdated reference: A later version (-01) exists of draft-yegin-l2-triggers-00 Summary: 6 errors (**), 0 flaws (~~), 24 warnings (==), 16 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group B. Aboba, Ed. 3 INTERNET-DRAFT Internet Architecture Board 4 Category: Informational IAB 5 6 2 July 2005 8 Architectural Implications of Link Indications 10 By submitting this Internet-Draft, each author represents that any 11 applicable patent or other IPR claims of which he or she is aware 12 have been or will be disclosed, and any of which he or she becomes 13 aware will be disclosed, in accordance with Section 6 of BCP 79. 15 Internet-Drafts are working documents of the Internet Engineering 16 Task Force (IETF), its areas, and its working groups. Note that 17 other groups may also distribute working documents as Internet- 18 Drafts. 20 Internet-Drafts are draft documents valid for a maximum of six months 21 and may be updated, replaced, or obsoleted by other documents at any 22 time. It is inappropriate to use Internet-Drafts as reference 23 material or to cite them other than as "work in progress." 25 The list of current Internet-Drafts can be accessed at 26 http://www.ietf.org/ietf/1id-abstracts.txt. 28 The list of Internet-Draft Shadow Directories can be accessed at 29 http://www.ietf.org/shadow.html. 31 This Internet-Draft will expire on December 10, 2005. 33 Copyright Notice 35 Copyright (C) The Internet Society (2005). 37 Abstract 39 This document describes the role of link indications within the 40 Internet Architecture. While the judicious use of link indications 41 can provide performance benefits, inappropriate use can degrade both 42 robustness and performance. This document summarizes current 43 proposals, describes the architectural issues and provides examples 44 of appropriate and inappropriate uses of link layer indications. 46 Table of Contents 48 1. Introduction.............................................. 3 49 1.1 Requirements ....................................... 3 50 1.2 Terminology ........................................ 3 51 1.3 Overview ........................................... 6 52 1.4 Layered Indication Model ........................... 9 53 2. Architectural Considerations ............................. 14 54 2.1 Model Validation ................................... 14 55 2.2 Clear Definitions .................................. 15 56 2.3 Robustness ......................................... 16 57 2.4 Stability .......................................... 20 58 2.5 Effectiveness ...................................... 21 59 2.6 Interoperability ................................... 22 60 2.7 Race Conditions .................................... 22 61 2.8 Layer Compression .................................. 25 62 2.9 Transport of Link Indications ...................... 26 63 3. Future Work .............................................. 27 64 4. Security Considerations .................................. 28 65 5. References ............................................... 29 66 5.1 Informative References ............................. 29 67 Appendix A - Literature Review ............................... 36 68 A.1 Link Layer ......................................... 36 69 A.2 Internet Layer ..................................... 41 70 A.3 Transport Layer .................................... 43 71 A.4 Application Layer .................................. 47 72 Appendix B - IAB Members ..................................... 48 73 Intellectual Property Statement .............................. 48 74 Disclaimer of Validity ....................................... 48 75 Copyright Statement .......................................... 49 76 1. Introduction 78 A link indication represents information provided by the link layer 79 to higher layers regarding the state of the link. 81 This document provides an overview of the role of link indications 82 within the Internet Architecture. While the judicious use of link 83 indications can provide performance benefits, experience has also 84 shown that that inappropriate use can degrade both robustness and 85 performance. 87 This document summarizes the current understanding of the role of 88 link indications, and provides advice to document authors about the 89 appropriate use of link indications. 91 In Section 1 describes the history of link indication usage within 92 the Internet architecture and provides a model for the utilization of 93 link indications. Section 2 provides advice to document authors. 94 Section 3 describes recommendations and future work. Appendix A 95 presents a summary of the literature on link indication utilization. 97 1.1. Requirements 99 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 100 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 101 document are to be interpreted as described in [RFC2119]. 103 1.2. Terminology 105 Access Point (AP) 106 A station that provides access to the distribution services, via 107 the wireless medium (WM) for associated stations. 109 Association 110 The service used to establish an access point/station (AP/STA) 111 mapping and enable STA access to the Distribution System. 113 Basic Service Set (BSS) 114 A set of stations controlled by a single coordination function, 115 where the coordination function may be centralized (e.g., in a 116 single AP) or distributed (e.g., for an ad-hoc network). The BSS 117 can be thought of as the coverage area of a single AP. 119 Beacon 120 A control message broadcast by a node (especially, a base station) 121 informing all the other nodes in its neighborhood of the continuing 122 presence of the broadcasting node, possibly along with additional 123 status or configuration information. 125 Binding Update (BU) 126 A message indicating a mobile node's current mobility binding, and 127 in particular its care-of address. 129 Care of Address (CoA) 130 A unicast routable address associated with a mobile node while 131 visiting a foreign link; the subnet prefix of this IP address is a 132 foreign subnet prefix. Among the multiple care-of addresses that a 133 mobile node may have at any given time (e.g., with different subnet 134 prefixes), the one registered with the mobile node's home agent for 135 a given home address is called its "primary" care-of address. 137 Correspondent Node 138 A peer node with which a mobile node is communicating. The 139 correspondent node may be either mobile or stationary. 141 Distribution System (DS) 142 A system used to interconnect a set of basic service sets (BSSs) 143 and integrated local area networks (LANs) to create an extended 144 service set (ESS). 146 Dynamic Host Configuration Protocol (DHCP) client 147 A DHCP client is an Internet host using DHCP to obtain 148 configuration parameters such as a network address. 150 DHCP server 151 A DHCP server or "server" is an Internet host that returns 152 configuration parameters to DHCP clients. 154 Extended Service Set (ESS) 155 A set of one or more interconnected basic service sets (BSSs) and 156 integrated local area networks (LANs) that appears as a single BSS 157 to the logical link control layer at any station associated with 158 one of those BSSs. The ESS can be thought of as the coverage area 159 provided by a collection of APs all interconnected by the 160 Distribution System. It may consist of one or more prefixes. 162 Home Address (HoA) 163 A unicast routable address assigned to a mobile node, used as the 164 permanent address of the mobile node. This address is within the 165 mobile node's home link. Standard IP routing mechanisms will 166 deliver packets destined for a mobile node's home address to its 167 home link. Mobile nodes can have multiple home addresses, for 168 instance when there are multiple home prefixes on the home link. 170 Home Agent (HA) 171 A router on a mobile node's home link with which the mobile node 172 has registered its current care-of address. While the mobile node 173 is away from home, the home agent intercepts packets on the home 174 link destined to the mobile node's home address, encapsulates them, 175 and tunnels them to the mobile node's registered care-of address. 177 Inter-Access Point Protocol (IAPP) 178 A protocol used between access points that assures that the station 179 may only be connected to a single AP within the ESS at a time, and 180 also provides for transfer of context to the new AP. 182 Link A communication facility or physical medium that can sustain data 183 communications between multiple network nodes, such as an Ethernet 184 (simple or bridged). A link is the layer immediately below IP. In 185 a layered network stack model, the Link Layer (Layer 2) is normally 186 below the Network (IP) Layer (Layer 3), and above the Physical 187 Layer (Layer 1). Each link is associated with a minimum of two 188 endpoints. Each link endpoint has a unique link-layer identifier. 190 Asymmetric link 191 A link with transmission characteristics which are different 192 depending upon the relative position or design characteristics of 193 the transmitter and the receiver of data on the link. For 194 instance, the range of one transmitter may be much higher than the 195 range of another transmitter on the same medium. 197 Link Down 198 An event provided by the link layer that signifies a state change 199 associated with the interface no longer being capable of 200 communicating data frames; transient periods of high frame loss are 201 not sufficient. 203 Link Layer 204 Conceptual layer of control or processing logic that is responsible 205 for maintaining control of the data link. The data link layer 206 functions provide an interface between the higher-layer logic and 207 the data link. The link layer is the layer immediately below IP. 209 Link identifier 210 An indication provided by the link layer as to which network(s) a 211 host has connected to. Examples include the SSID with IEEE 802.11. 212 For details, see [DNAv4] Appendix A. 214 Link indication 215 Information provided by the link layer to higher layers regarding 216 the state of the link. In addition to "Link Up" and "Link Down" 217 indications, other relevant link information may include the 218 current link rate (which may vary with time and location), link 219 identifiers (e.g. SSID, BSSID in 802.11), and statistics relating 220 to link performance (such as the delay or loss rate). 222 Link Up 223 An event provided by the link layer that signifies a state change 224 associated with the interface becoming capable of communicating 225 data frames. 227 Most Likely Network (MLN) 228 The attached network heuristically determined by the host to be 229 most likely, based on hints. 231 Point of Attachment 232 The link endpoint on the link to which the host is currently 233 connected. 235 Medium Access Protocol (MAC) 236 A protocol for mediating access to, and possibly allocation of, the 237 physical communications medium. Nodes participating in the medium 238 access protocol can communicate only when they have uncontested 239 access to the medium, so that there will be no interference. When 240 the physical medium is a radio channel, the MAC is the same as the 241 Channel Access Protocol. 243 Mobile Node 244 A node that can change its point of attachment from one link to 245 another, while still being reachable via its home address. 247 Routable address 248 In this specification, the term "routable address" refers to any 249 address other than an IPv4 Link-Local address [RFC3927]. This 250 includes private addresses as specified in [RFC1918]. 252 Station (STA) 253 Any device that contains an IEEE 802.11 conformant medium access 254 control (MAC) and physical layer (PHY) interface to the wireless 255 medium (WM). 257 Operable address 258 The term "operable address" refers to either a static address, or a 259 dynamically assigned address which has not been relinquished, and 260 has not expired. 262 Weak End-System Model 263 In the Weak End-System Model, packets sent out an interface need 264 not necessarily have a source address configured on that interface. 266 1.3. Overview 268 Link status was first taken into account in computer routing within 269 the ARPANET as early as 1969. In response to an attempt to send to a 270 host that was off-line, the ARPANET link layer protocol provided a 271 "Destination Dead" indication [RFC816]. The ARPANET packet radio 272 experiment [PRNET] incorporated frame loss in the calculation of 273 routing metrics, a precursor to more recent link-aware routing 274 metrics such as [ETX]. 276 "Routing Information Protocol" [RFC1058] defines RIP, which is 277 descended from the Xerox Network Systems (XNS) Routing Information 278 Protocol. "The Open Shortest Path First Specification" [RFC1131] 279 defines OSPF, which uses Link State Advertisements (LSAs) in order to 280 flood information relating to link status within an OSPF area. As 281 noted in "Requirements for IP Version 4 Routers" [RFC1812]: 283 It is crucial that routers have workable mechanisms for 284 determining that their network connections are functioning 285 properly. Failure to detect link loss, or failure to take the 286 proper actions when a problem is detected, can lead to black 287 holes. 289 "Fault Isolation and Recovery" [RFC826] Section 3 describes how hosts 290 interact with gateways for the purpose of fault detection and 291 recovery: 293 Since the gateways always attempt to have a consistent and 294 correct model of the internetwork topology, the host strategy for 295 fault recovery is very simple. Whenever the host feels that 296 something is wrong, it asks the gateway for advice, and, 297 assuming the advice is forthcoming, it believes the advice 298 completely. The advice will be wrong only during the transient 299 period of negotiation, which immediately follows an outage, but 300 will otherwise be reliably correct. 302 In ideal conditions, links in the "up" state experience low frame 303 loss in both directions and are immediately ready to send and receive 304 data frames; links in the "down" state are unsuitable for sending and 305 receiving data frames in either direction. Unfortunately links 306 frequently exhibit non-ideal behavior. Wired links may fail in half- 307 duplex mode, or exhibit partial impairment resulting in intermediate 308 loss rates. Wireless links may exhibit asymmetry or frame loss due 309 to interference or signal fading. In both wired and wireless links, 310 the link state may rapidly flap between the "up" and "down" states. 312 Routing protocol implementations have had to take real-world wired 313 link behavior into account in order to maintain robustness. In 314 "Analysis of link failures in an IP backbone" [Iannaccone] the 315 authors investigate link failures in Sprint's IP backbone. They 316 identify the causes of convergence delay, including delays in 317 detection of whether an interface is down or up. While it is fastest 318 for a router to utilize link indications if available, there are 319 situations in which it is necessary to depend on loss of routing 320 packets to determine the state of the link. Once the link state has 321 been determined, a delay may occur within the routing protocol in 322 order to dampen link flaps. Finally, another delay may be introduced 323 in propagating the link state change, in order to rate limit link 324 state advertisements. 326 "Bidirectional Forwarding Detection" [BFD] notes that link layers may 327 provide only limited failure indications, and that relatively slow 328 "Hello" mechanisms are used in routing protocols to detect failures 329 when no link layer indications are available. This results in 330 failure detection times of the order of a second, which is too long 331 for some applications. The authors describe a mechanism that can be 332 used for liveness detection over any media, enabling rapid detection 333 of failures in the path between adjacent forwarding engines. A path 334 is declared operational when bi-directional reachability has been 335 confirmed. 337 More recently, the importance of realistic wireless link models has 338 become better appreciated. In "The mistaken axioms of wireless- 339 network research" [Kotz], the authors conclude that mistaken 340 assumptions relating to link behavior may lead to the design of 341 network protocols that may not work in practice. For example, [Kotz] 342 notes that the three-dimensional nature of wireless propagation can 343 result in large signal strength changes over short distances. This 344 can result in rapid changes in link indications such as rate, frame 345 loss, signal and signal/noise ratio. 347 In "Performance of Multihop Wireless Networks: Shortest Path is Not 348 Enough" [Shortest] the authors studied the performance of both an 349 indoor and outdoor mesh network. By measuring inter-node throughput, 350 the best path between nodes was computed. The throughput of the best 351 path was compared with the throughput of the shortest path computed 352 based on a hop-count metric. In almost all cases, the shortest path 353 route offered considerably lower throughput than the best path. 355 In examining link behavior, the authors found that rather than 356 exhibiting a bi-modal distribution between "up" (low loss rate) and 357 "down" (high loss rates), many links exhibited intermediate loss 358 rates. Asymmetry was also common, with 30 percent of links 359 demonstrating substantial differences between in the loss rates in 360 each direction. As a result, on wireless networks the measured 361 throughput can differ substantially from the negotiated rate due to 362 retransmissions, and successful delivery of routing packets is not 363 necessarily an indication that the link is useful for delivery of 364 data. 366 The complexity of real-world link behavior poses a challenge to the 367 integration of link indications within the Internet architecture. 368 While the judicious use of link indications can provide performance 369 benefits, inappropriate use can degrade both robustness and 370 performance. This document provides guidance on the incorporation of 371 link indications within the Internet, Transport and Application 372 layers. 374 1.4. Layered Indication Model 376 A layered indication model is shown in Figure 1 which includes both 377 internally generated link indications and indications arising from 378 external interactions such as receipt of Mobile IP Binding Updates, 379 and path change detection. 381 In this model, link indications include frame loss (before 382 retransmissions), the current link rate, the link state (up/down), 383 and link identifiers. These indications may be inter-dependent, 384 since rate adjustment and detection algorithms are typically 385 influenced by frame loss, and a "Link Down" indication may be 386 influenced by the detection and search process. Link identifiers are 387 typically obtained in the process of bringing the link up. 389 The Internet layer is the primary user of link indications, since one 390 of its functions is to shield applications from the specifics of link 391 behavior. The Internet layer utilizes link indications in order to 392 to optimize aspects of IP configuration, routing and mobility. By 393 validating and filtering link indications and selecting outgoing and 394 incoming interfaces based on routing metrics, the Internet layer 395 enables upper layers to avoid dependency on link indications. 397 In "Detecting Network Attachment" [DNAv4], "Link Up" indications and 398 link identifiers are used as hints for validating an existing IP 399 configuration. Once the IP configuration is confirmed, it may be 400 determined that an address change has occurred. However, "Link Up" 401 indications often do not result in a change to Internet layer 402 configuration. 404 The routing sub-layer utilizes link indications in order to calculate 405 routing metrics and determine changes in link state. As described in 406 [Iannaccone], damping of link flaps and rate limiting of link state 407 advertisements are examples of how the routing sub-layer validates 408 and filters link indications. 410 "Fault Isolation and Recovery" [RFC826] describes how hosts interact 411 with gateways for the purpose of fault recovery: 413 Since the gateways always attempt to have a consistent and 414 correct model of the internetwork topology, the host strategy for 415 fault recovery is very simple. Whenever the host feels that 416 something is wrong, it asks the gateway for advice, and, 417 assuming the advice is forthcoming, it believes the advice 418 completely. The advice will be wrong only during the transient 419 period of negotiation, which immediately follows an outage, 420 but will otherwise be reliably correct. 422 In fact, it is never necessary for a host to explicitly ask 423 a gateway for advice, because the gateway will provide it as 424 appropriate. 426 Within "Weak End-System Model" implementations, changes in routing 427 metrics and link state may result in a change in the outgoing 428 interface for one or more transport connections. Routes may also be 429 added or withdrawn, resulting in loss or gain of peer connectivity. 430 However, link indications such as changes in link rate or frame loss 431 do not necessarily result in a change of outgoing interface. 433 The Internet layer may also become aware of path changes by other 434 mechanisms, such as by running a routing protocol, receipt of a 435 Router Advertisement, dead gateway detection [RFC826] or a change in 436 the IP TTL of received packets. A change in the outgoing interface 437 may in turn influence the mobility sub-layer, causing a change in the 438 incoming interface. The mobility sub-layer may also become aware of 439 a change in the incoming interface of a peer (via receipt of a Mobile 440 IP binding update). 442 The Transport layer processes Internet layer and link indications 443 differently for the purposes of transport parameter estimation and 444 connection management. For the purposes of parameter estimation, the 445 Transport layer may be interested in a wide range of Internet and 446 link layer indications. The Transport layer may wish to use path 447 change indications from the Internet layer in order to reset 448 parameter estimates. It may also be useful for the Transport layer 449 to utilize link layer indications such as link rate, frame loss rate 450 and "Link Up"/"Link Down" in order to improve transport parameter 451 estimates. 453 As described in Section A.3, the algorithms for improving transport 454 parameter estimates using link layer indications are still under 455 development. In transport parameter estimation, layering 456 considerations do not exist to the same extent as in connection 457 management. For example, the Internet layer may receive a "Link 458 Down" indication followed by a subsequent "Link Up" indication. This 459 information may useful for transport parameter estimation even if IP 460 configuration does not change, since it may indicate the potential 461 for non-congestive packet loss during the period between the 462 indications. 464 For the purposes of connection management, the Transport layer 465 typically only utilizes Internet layer indications such as changes in 466 the incoming/outgoing interface and IP configuration changes. For 467 example, the Transport layer may tear down transport connections due 468 to invalidation of a connection endpoint IP address. However, before 469 this can occur, the Internet layer must determine that a 470 configuration change has occurred. 472 Nevertheless, the Transport layer does not respond to all Internet 473 layer indications. For example, an Internet layer configuration 474 change may not be relevant for the purposes of connection management. 475 Where the connection has been established based on the home address, 476 a change in the care-of-address need not result in connection 477 teardown, since the configuration change is masked by the mobility 478 functionality within the Internet layer, and is therefore transparent 479 to the Transport layer. 481 Just as a "Link Up" event may not result in a configuration change, 482 and a configuration change may not result in connection teardown, the 483 Transport layer does not tear down connections on receipt of a "Link 484 Down" indication, regardless of the cause. Where the "Link Down" 485 indication results from frame loss rather than an explicit exchange, 486 the indication may be transient, to be soon followed by a "Link Up" 487 indication. 489 Even where the "Link Down" indication results from an explicit 490 exchange such as receipt of a PPP LCP-Terminate or an 802.11 491 Disassociate or Deauthenticate frame, an alternative point of 492 attachment may be available, allowing connectivity to be quickly 493 restored. As a result, robustness is best achieved by allowing 494 connections to remain up until an endpoint address changes, or the 495 connection is torn down due to lack of response to repeated 496 retransmission attempts. 498 For the purposes of connection management, the Transport layer is 499 cautious even with the use of Internet layer indications. As noted 500 in [RFC826], Section 6: 502 It is not obvious, when error messages such as ICMP Destination 503 Unreachable arrive, whether TCP should abandon the connection. 504 The reason that error messages are difficult to interpret is 505 that, as discussed above, after a failure of a gateway or network, 506 there is a transient period during which the gateways may have 507 incorrect information, so that irrelevant or incorrect error 508 messages may sometimes return. An isolated ICMP Destination 509 Unreachable may arrive at a host, for example, if a packet is sent 510 during the period when the gateways are trying to find a new 511 route. To abandon a TCP connection based on such a message 512 arriving would be to ignore the valuable feature of the Internet 513 that for many internal failures it reconstructs its function 514 without any disruption of the end points. 516 In addition to Internet layer indications propagated to the 517 Application layer (such as IP address configuration and changes), the 518 Transport layer provides its own indications to the Application 519 layer, such as connection teardown. The Transport layer may also 520 provide indications to the link layer. For example, to prevent 521 excessive retransmissions within the link layer, where the link layer 522 retransmission timeout is significantly less than the path round-trip 523 timeout, the Transport layer may wish to control the maximum number 524 of times that a link layer frame may be retransmitted, so that the 525 link layer does not continue to retransmit after a Transport layer 526 timeout. In 802.11, this can be achieved by adjusting the MIB 527 variables dot11ShortRetryLimit (default: 7) and dot11LongRetryLimit 528 (default: 4), which control the maximum number of retries for frames 529 shorter and longer in length than dot11RTSThreshold, respectively. 530 However, since these variables control link behavior as a whole they 531 cannot be used to separately adjust behavior on a per-transport 532 connection basis. Also, in situations where the link layer 533 retransmission timeout is of the same order as the path round trip 534 timeout, link layer control may not be possible at all. 536 Since applications can obtain the information they need from Internet 537 and Transport layer indications they should not utilize link 538 indications. A "Link Up" indication implies that the link is capable 539 of communicating IP packets, but does not indicate that it has been 540 configured. As a result, applications will should utilize an 541 Internet layer "IP Address Configured" event instead of a "Link Up" 542 indication. Similarly, applications should not utilize "Link Down" 543 indications, since they can be rapidly followed by a "Link Up" 544 indication; instead, they should respond to Transport layer teardown 545 indications. 547 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 548 Application | | 549 Layer | | 550 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 551 ^ ^ 552 ! ! 553 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-!-+-!-+-+-+-+ 554 | ! ! | 555 | ^ ^ | 556 | Connection Management ! Teardown | 557 Transport | ! | 558 Layer +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-!-+-+-+-+-+-+ 559 | ! | 560 | Transport Parameter Estimation ! | 561 | Estimation (MTU, RTT, RTO, cwnd, ! ssthresh) 562 | ^ | 563 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-!-+-+-+-+-+-+ 564 ^ ^ ^ ! 565 ! ! ! ! 566 +-+-+-!-+-+-+-+-+-!-+-+-+-!-+-+-+-+-!-+-+-+-+-+-+ 567 | ! Incoming !MIP ! ! | 568 | ! Interface !BU ! ! | 569 | ! Change !Receipt! ! | 570 | ^ ^ ^ ^ | 571 Internet | ! Mobility ! ! ! | 572 Layer +-+-+-!-+-+-+-+-+-!-+-+-+-!-+-+-+-+-!-+-+-+-+-+-+ 573 | ! Outgoing ! Path ! ! | 574 | ! Interface ! Change! ! | 575 | ^ Change ^ ^ ^ | 576 | ! ! | 577 | Routing ! ! | 578 | ^ ^ ! ! | 579 +-!-+-+-+-+-!-+-+-+-+-+-+-!-+-+-+-+-!-+-+-+-+-+-+ 580 | ! ! ! ! IP | 581 | ! ! ! ! Address | 582 | ! IP !Configuration^ ^ Config/ | 583 | ! ! ! Changes | 584 +-!-+-+-+-+-!-+-+-+-+-+-+-!-+-+-+-+-+-+-+-+-+-+-+ 585 ! ! ! ^ 586 ! ! ! ! 587 +-!-+-+-+-+-!-+-+-+-+-+-+-!-+-+-+-!-+-+-+-+-+-+-+ 588 | ! ! ! ! | 589 Link | ^ ^ ^ ^ | 590 Layer | Frame Rate Link Link | 591 | Loss Adjustment Up/Down Identifiers | 592 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 594 Figure 1. Layered Indication Model 596 2. Architectural Considerations 598 While the literature provides persuasive evidence of utility of link 599 indications, difficulties can arise in making effective use of them. 600 These include: 602 a. Model validation 603 b. Clear definitions 604 c. Robustness 605 d. Stability 606 e. Effectiveness 607 f. Interoperability 608 g. Race conditions 609 h. Layer compression 610 i. Transport of link indications 612 The sections that follow discuss each of these issues in turn. 614 2.1. Model Validation 616 Authors need to be careful to avoid use of simplified link models in 617 circumstances where they do not apply. 619 In "Modeling Wireless Links for Transport Protocols" [GurtovFloyd], 620 the authors provide examples of modeling mistakes and examples of how 621 to improve modeling of link characteristics. To accompany the paper 622 the authors provide simulation scenarios in ns-2. 624 In order to avoid the pitfalls described in [Kotz] [GurtovFloyd], 625 documents dependent on link indications should explicitly articulate 626 the assumptions of the link model and describe the circumstances in 627 which it applies. 629 For example, generic "trigger" models often include implicit 630 assumptions which may prove invalid in outdoor or mesh deployments. 631 For example, two-state Markov models where the link is either in a 632 state experiencing low frame loss ("up") or in a state where few 633 frames are successfully delivered ("down") have frequently been used. 634 In these models, symmetry is also typically assumed, so that the link 635 is either "up" in both directions or "down" in both directions. In 636 situations where intermediate loss rates are experienced, these 637 assumptions may be invalid. 639 Link indications based on signal quality "Link Quality Crosses 640 Threshold" typically assume the absence of multi-path interference, 641 so that signal to noise ratio varies smoothly in space, and frame 642 loss is well predicted by signal strength and distance. 644 However, where multi-path interference is present, signal strength 645 and signal/noise ratio can vary rapidly and high signal/noise ratio 646 can co-exist with high frame loss. Where links may exist in 647 intermediate states between "up" and "down" or asymmetry is 648 encountered, a "Link Quality Crosses Threshold" indication may 649 exhibit excessive jitter and may prove to be unreliable predictors of 650 future link performance. 652 In particular, authors should be mindful of the following: 654 [1] Do not assume symmetric link performance or frame loss that is 655 either low ("up") or high ("down"). 657 In wired networks, links in the "up" state typically experience low 658 frame loss in both directions and are ready to send and receive 659 data frames; links in the "down" state are unsuitable for sending 660 and receiving data frames in either direction. Therefore, a link 661 providing a "Link Up" indication will typically experience low 662 frame loss in both directions, and high frame loss in any direction 663 can only be experienced after a link provides a "Link Down" 664 indication. However, these assumptions may not hold true for 665 wireless networks. 667 Specifications utilizing a "Link Up" indication should not assume 668 that receipt of this indication means that the link is experiencing 669 symmetric link conditions or low frame loss in either direction. 670 In general, a "Link Up" event should not be sent due to transient 671 changes in link conditions, but only due to a change in link layer 672 state. It is best to assume that a "Link Up" event may not be sent 673 in a timely way. Large handoff latencies can result in a delay in 674 the generation of a "Link Up" event as movement to an alternative 675 point of attachment is delayed. 677 2.2. Clear Definitions 679 Once the network model is defined, considerable effort may be 680 required to define the meaning of link indications and clarify their 681 usage on different link layers. For example, considerable work has 682 been required in order to come up with the definitions of "Link Up" 683 and "Link Down", and to define when these indications are sent on 684 various link layers. 686 Attempts have also been made to define link indications other than 687 "Link Up" and "Link Down". "Dynamically Switched Link Control 688 Protocol" [RFC1307] defines an experimental protocol for control of 689 links, incorporating "Down", "Coming Up", "Up", "Going Down", "Bring 690 Down" and "Bring Up" states. 692 [GenTrig] defines "generic triggers", including "Link Up", "Link 693 Down", "Link Going Down", "Link Going Up", "Link Quality Crosses 694 Threshold", "Trigger Rollback", and "Better Signal Quality AP 695 Available". 697 [IEEE-802.21] defines a Media Independent Handover Event Service 698 (MIH-ES) that provides event reporting relating to link 699 characteristics, link status, and link quality. Events defined 700 include "Link Down", "Link Up", "Link Going Down", "Link Signal 701 Strength" and "Link Signal/Noise Ratio". 703 Document authors defining new link indications should heed the 704 following advice: 706 [2] Think carefully about the sensitivity of link indications to 707 transient link conditions. Due to effects such as multi-path 708 interference, signal strength and signal/noise ratio may vary 709 rapidly over a short distance, causing rapid variations in 710 frame loss and rate, and jitter in link indications based on 711 these metrics. This can create problems for upper layers that 712 act on these indications without sufficient damping. 714 [3] Where possible, design link indications with built-in damping. 715 By design, the "Link Up" and "Link Down" events relate to 716 changes in the state of the link layer that make it able and 717 unable to communicate IP packets. These changes are either 718 generated by the link layer state machine based on link layer 719 exchanges (e.g. completion of the IEEE 802.11i four-way 720 handshake for "Link Up", or receipt of a PPP LCP-Terminate for 721 "Link Down") or by protracted frame loss, so that the link 722 layer concludes that the link is no longer usable. As a 723 result, these link indications are typically less sensitive to 724 changes in transient link conditions. 726 2.3. Robustness 728 In some situations, improper use of Link indications can result in 729 operational malfunctions. Given the potential problems, proposals 730 for consideration of link indications must demonstrate robustness 731 against misleading indications. Elements to consider include: 733 a. Implementation effects 734 b. Indication validation 735 c. Recovery from invalid indications 736 d. Damping and hysteresis 738 2.3.1. Implementation Effects 740 Variations in link layer implementations may have a substantial 741 impact on the behavior of link indications. These variations need to 742 be taken into account in evaluating the performance of proposals. 744 Authors should consider the following advice: 746 [4] Do not assume that a "Link Down" event will be sent at all, or 747 that if sent, that it will received in a timely way. A good 748 link layer implementation will both rapidly detect 749 connectivity failure (such as by tracking missing Beacons) 750 while sending a "Link Down" event only when it concludes the 751 link is unusable, not due to transient frame loss. 753 However, existing implementations often do not do a good job 754 of detecting link failure. During a lengthy detection phase, 755 a "Link Down" event is not sent by the link layer, yet IP 756 packets cannot be transmitted or received on the link. 757 Initiation of a scan may be delayed so that the station cannot 758 find another point of attachment. This can result in 759 inappropriate backoff of retransmission timers within the 760 transport layer, among other problems. 762 2.3.2. Indication Validation 764 Radio propagation and implementation differences can impact the 765 reliability of Link indications. 767 As described in [Aguayo], wireless links often exhibit loss rates 768 intermediate between "up" (low loss) and "down" (high loss) states, 769 as well as substantial asymmetry. In these circumstances, a "Link 770 Up" indication may not imply bi-directional reachability. Also, a 771 reachability demonstration based on small packets may not mean that 772 the link is suitable for carrying larger data packets. As a result, 773 "Link Up" and "Link Down" indications may not reliably determine 774 whether a link is suitable for carrying IP data packets. 776 Where multi-path interference or hidden nodes are encountered, frame 777 loss may vary widely over a short distance. While techniques such as 778 use of multiple antennas may be used to reduce multi-path effects and 779 RTS/CTS signaling can be used to address hidden node problems, these 780 techniques may not be completely effective. As a result, a mobile 781 host may find itself experiencing widely varying link conditions, 782 causing the link to rapidly cycle between "up" and "down" states, 783 with "Going down" or "Going up" indications providing little 784 predictive value. 786 Where the reliability of a link layer indication is suspect, it is 787 best for upper layers to treat the indication as a "hint" (advisory 788 in nature), rather than a "trigger" forcing a given action. In order 789 to provide increased robustness, heuristics can be developed to 790 assist upper layers in determining whether the "hint" is valid or 791 should be discarded. 793 To provide robustness in the face of potentially misleading link 794 indications, in [DNAv4] "Link Up" indications are assumed to be 795 inherently unreliable, so that bi-directional reachability needs to 796 be demonstrated in the process of validating an existing IPv4 797 configuration. However, where a link exhibits an intermediate loss 798 rate, the success of the [DNAv4] reachability test does not guarantee 799 that the link is suitable for carrying IP data packets. 801 Another example of link indication validation occurs in IPv4 Link- 802 Local address configuration [RFC3927]. Prior to configuration of an 803 IPv4 Link-Local address, it is necessary to run a claim and defend 804 protocol. Since a host needs to be present to defend its address 805 against another claimant, and address conflicts are relatively 806 likely, a host returning from sleep mode or receiving a "Link Up" 807 indication could encounter an address conflict were it to utilize a 808 formerly configured IPv4 Link-Local address without rerunning claim 809 and defend. 811 2.3.3. Recovery From Invalid Indications 813 Upper layers should utilize a timely recovery step so as to limit the 814 potential damage from link indications determined to be invalid after 815 they have been acted on. 817 Recovery is supported within [DNAv4] in the case where link 818 indications may lead a host to erroneously conclude that the link 819 prefix remains unchanged when the host has in fact changed networks. 820 In this case, the bi-directional reachability test times out, and the 821 host will eventually realize its mistake and obtain an IP address by 822 normal means. 824 Where a proposal involves recovery at the transport layer, the 825 recovered transport parameters (such as the MTU, RTT, RTO, congestion 826 window, etc.) must be demonstrated to remain valid. Congestion 827 window validation is discussed in [RFC2861]. 829 Where timely recovery is not supported, unexpected consequences may 830 result. As described in [RFC3927], early IPv4 Link-Local 831 implementations would wait five minutes before attempting to obtain a 832 routable address after assigning an IPv4 Link-Local address. In one 833 implementation, it was observed that where mobile hosts changed their 834 point of attachment more frequently than every five minutes, they 835 would never obtain a routable address. 837 The problem was caused by an invalid link indication (signaling of 838 "Link Up" prior to completion of link layer authentication), 839 resulting in an initial failure to obtain a routable address using 840 DHCP. As a result, [RFC3927] recommends against modification of the 841 maximum retransmission timeout (64 seconds) provided in [RFC2131]. 843 2.3.4. Damping and Hysteresis 845 Damping and hysteresis can be utilized to ensure that stability is 846 maintained in the face of jittery link indications. These limits 847 typically place constraints on the number of times a given action can 848 be performed within a time period or introduce damping mechanisms to 849 prevent instability. 851 While [Aguayo] found that frame loss was relatively stable for 852 stationary stations, obstacles to radio propagation and multi-path 853 interference can result in rapid changes in signal strength for a 854 mobile station. As a result, it is possible for mobile stations to 855 encounter rapid changes in link performance, including changes in the 856 negotiated rate, frame loss and even "Link Up"/"Link Down" 857 indications. 859 Where link-aware routing metrics are implemented, this can result in 860 rapid metric changes, potentially resulting in frequent changes in 861 the outgoing interface for "Weak End-System" implementations. As a 862 result, it may be necessary to introduce route flap dampening. 864 However, the benefits of damping need to be weighed against the 865 additional latency that can be introduced. For example, in order to 866 filter out spurious "Link Down" indications, these indications may be 867 delayed until it can be determined that a "Link Up" indication will 868 not follow shortly thereafter. However, in situations where multiple 869 Beacons are missed such a delay may not be needed, since there is no 870 evidence of a suitable point of attachment in the vicinity. 872 In many cases it is desirable to ignore link indications entirely. 873 Since it is possible for a host to transition from an ad-hoc network 874 to a network with centralized address management, a host receiving a 875 "Link Up" indication cannot necessarily conclude that it is 876 appropriate to configure a IPv4 Link-Local address prior to 877 determining whether a DHCP server is available [RFC3927]. 879 As noted in Section 1.4, the Transport layer does not utilize "Link 880 Up" and "Link Down" indications for the purposes of connection 881 management. Since applications can obtain the information they need 882 from Internet and Transport layer indications they should not utilize 883 link indications. 885 2.4. Stability 887 Link indication proposals must demonstrate that effective congestion 888 control is maintained [RFC2914]. 890 For example, algorithms that adjust rate based on frame loss need to 891 demonstrate conservatism in the face of congestion. The large 892 variance in rate adaptation behavior of existing 802.11 893 implementations is worrisome since implementations that rapidly 894 decrease the negotiated rate in response to frame loss can cause 895 congestive collapse in the link layer, even where backoff is 896 correctly implemented. For example, an implementation that decreases 897 rate by a factor of two while backing off the retransmission timer by 898 a factor of two has not really reduced consumption of the critical 899 resource, namely available slots within the MAC. 901 Consider a proposal where a "Link Up" indication is used by a host to 902 trigger retransmission of the last previously sent packet, in order 903 to enable ACK reception prior to expiration of the host's 904 retransmission timer. On a rapidly moving mobile node where "Link 905 Up" indications follow in rapid succession, this could result in a 906 burst of retransmitted packets, violating the principle of 907 "conservation of packets". 909 At the Application Layer, Link indications have been utilized by 910 applications such as Presence [RFC2778] in order to optimize 911 registration and user interface update operations. For example, 912 implementations may attempt presence registration on receipt of a 913 "Link Up" indication, and presence de-registration by a surrogate 914 receiving a "Link Down" indication. 916 Presence implementations using "Link Up"/"Link Down" indications this 917 way violate the principle of "conservation of packets" when link 918 indications are generated on a time scale of RTO or less. The 919 problem is magnified since for each presence update, notifications 920 can be delivered to many watchers. In addition, use of a "Link Up" 921 indication in this manner is unwise since the interface may not yet 922 have an operable Internet layer configuration. 924 The issue can be addressed by one or more of the following 925 techniques: 927 [a] Rate limiting. A limit of one packet per RTO can be imposed on 928 packets generated from receipt of link indications. 930 [b] Utilization of upper layer indications. Instead of utilizing a 931 "Link Up" indication, applications can instead depend on upper 932 layer indications such as an IP address configuration/change 933 notifications. 935 [c] Keepalives. Instead of utilizing a "Link Down" indication, an 936 application can utilize an application keepalive or Transport 937 layer indications such as connection teardown. 939 [d] Stability analysis. Proposals must be analyzed to determine 940 whether they result in congestive collapse either in the transport 941 layer or at the link layer. 943 2.5. Effectiveness 945 While link indications may show promise, it may be difficult to prove 946 that processing of a given indication provides benefits in a wide 947 variety of circumstances. Where link indications are utilized for 948 the purpose of optimization, proposals need to carefully analyze the 949 effectiveness of the optimizations in the face of unreliable link 950 indications. Since optimizations typically bring with them increased 951 complexity, an optimization that does not bring about a performance 952 improvement is not useful. 954 As with any optimization, the usefulness of link indications lies in 955 demonstrated effectiveness of the optimization under consideration. 956 This in turn may depend heavily on the penalty to be paid for false 957 positives and false negatives. 959 As noted in [DNAv4], it is simultaneously possible for a link 960 indication to be highly reliable and provide no net benefit, 961 depending on the probability of a false indication and the penalty 962 paid for the false indication. In the case of [DNAv4], the benefits 963 of successful optimization are modest, but the penalty for falsely 964 concluding that the network remains unchanged is a lengthy timeout. 965 The result is that link indications may not be worth considering if 966 they are incorrect more than a small fraction of the time. 968 For example, it can be argued that a change in the Service Set 969 Identifier (SSID) in [IEEE-802.11] is not a sufficiently reliable 970 indication of a prefix change. Within IEEE 802.11, the Service Set 971 Identifier (SSID) functions as a non-unique identifier of the 972 administrative domain of a Wireless LAN. Since the SSID is non- 973 unique, many different operators may share the same SSID, and Access 974 Points typically ship with a default value for the SSID (e.g. 975 "default"). Since the SSID relates to the administrative domain and 976 not the network topology, multiple SSIDs may provide access to the 977 same prefix, and a single SSID may provide access to multiple 978 prefixes at one or multiple locations. 980 Given this, it is unreliable to use the SSID alone for the purpose of 981 movement detection. A host moving from one point of attachment to 982 another, both with the same SSID, may have remained within the same 983 network, or may have changed networks. Similarly, a host 984 discovering that the SSID has changed may have changed networks, or 985 it may not have. Moreover, where private address space is in use, it 986 is possible for the SSID, the prefix (e.g. 192.168/16) and even the 987 default gateway IP address to remain unchanged, yet for the host to 988 have moved to a different network. Were the host to make decisions 989 relating to configuration of the IP layer (such as address 990 assignment) based solely on the SSID, address conflicts are likely. 992 2.6. Interoperability 994 In general, link indications should only be incorporated by upper 995 layers for performance optimization, but should not be required in 996 order to main link independence. 998 To avoid compromising interoperability in the pursuit of performance 999 optimization, proposals must demonstrate that interoperability 1000 remains possible (though potentially with degraded performance) even 1001 if one or more participants do not implement the proposal. 1003 For example, if link layer prefix hints are provided as a substitute 1004 for Internet layer configuration, hosts not understanding those hints 1005 would be unable to obtain an IP address. 1007 Where link indications are proposed to optimize Internet layer 1008 configuration, proposals must demonstrate that they do not compromise 1009 robustness by interfering with address assignment or routing protocol 1010 behavior, making address collisions more likely, or compromising 1011 Duplicate Address Detection (DAD). 1013 2.7. Race Conditions 1015 It is possible for link indications to be utilized directly by 1016 multiple layers of the stack in situations in which strict layering 1017 may not be observed. In these situations, it is possible for race 1018 conditions to occur. 1020 For example, as discussed earlier, link indications have been shown 1021 to be useful in optimizing aspects of Internet Protocol layer 1022 addressing and configuration as well as routing. Although [Kim] 1023 describes situations in which link indications are first processed by 1024 the Internet Protocol layer (e.g. MIPv6) before being utilized by the 1025 Transport layer, for the purposes of parameter estimation, it may be 1026 desirable for the Transport layer to utilize link indications 1027 directly. 1029 For example, in situations where the "Weak End-System Model" is 1030 implemented, a change of outgoing interface may occur at the same 1031 time the Transport layer is modifying transport parameters based on 1032 other link indications. As a result, transport behavior may differ 1033 depending on the order in which the link indications are processed. 1035 Where a multi-homed host experiences increasing frame loss on one of 1036 its interfaces, a routing metric taking frame loss into account will 1037 rise, potentially causing a change in the outgoing interface for one 1038 or more transport connections. This may trigger Mobile IP signaling 1039 so as to cause a change in the incoming path as well. As a result, 1040 the transport parameters for the original interface (MTU, congestion 1041 state) may no longer be valid for the new outgoing and incoming 1042 paths. 1044 To avoid race conditions, the following measures are recommended: 1046 a. Path change processing 1047 b. Layering 1048 c. Metric consistency 1050 2.7.1. Path Change Processing 1052 When the Internet layer detects a path change, such as a change in 1053 the outgoing or incoming interface of the host or the incoming 1054 interface of a peer, or perhaps a substantial change in the TTL of 1055 received IP packets, it may be worth considering whether to reset 1056 transport parameters (RTT, RTO, cwnd, MTU) to their initial values 1057 and allow them to be re-estimated. This ensures that estimates based 1058 on the former path do not persist after they have become invalid. 1059 Appendix A.3 summarizes the research on this topic. 1061 2.7.2. Layering 1063 Another technique to avoid race conditions is to rely on layering to 1064 damp transient link indications and provide greater link layer 1065 independence. 1067 The Internet layer is responsible for routing as well as IP 1068 configuration, and mobility, providing higher layers with an 1069 abstraction that is independent of link layer technologies. Since 1070 one of the major objectives of the Internet layer is maintaining link 1071 layer independence, upper layers relying on Internet layer 1072 indications rather than consuming link indications directly can avoid 1073 link layer dependencies. 1075 In general, it is advisable for applications to utilize indications 1076 from the Internet or Transport layers rather than consuming link 1077 indications directly. 1079 2.7.3. Metric Consistency 1081 Once a link is in the "up" state, its effectiveness in transmission 1082 of data packets can be determined. For example, frame loss may be 1083 used to assist in rate adjustment and to determine when to select an 1084 alternative point of attachment. Also, the effective throughput 1085 depends on the negotiated rate and frame loss, and can be used in 1086 calculation of the routing metric, as described in [ETX]. 1088 However, prior to sending data packets over the link, other metrics 1089 are required to determine suitability. As noted in [Shortest], a 1090 link that can successfully transmit the short frames utilized for 1091 control, management or routing may not necessarily be able to 1092 reliably transport data packets. 1094 Since the negotiated rate and frame loss typically cannot be 1095 predicted prior to utilizing the link for data traffic, existing 1096 implementations often utilize metrics such as signal strength and 1097 access point load in handoff decisions. The "Link Going Down", 1098 "Link Going Up", "Link Quality Crosses Threshold" indications were 1099 developed primarily to assist with handoff between interfaces, and 1100 are oriented toward inferred rather than measured suitability. 1102 Research indicates that this approach may have some promise. In 1103 order to enable stations to roam prior to encountering packet loss, 1104 studies such as [Vatn] have suggested using signal strength as a 1105 detection mechanism, rather than frame loss, as suggested in 1106 [Velayos]. [Vertical] proposes use of signal strength and link 1107 utilization in order to optimize vertical handoff and demonstrates 1108 improved TCP throughput. 1110 However, without careful design, potential differences between link 1111 indications used in routing and those used in roaming and/or link 1112 enablement can result in instability, particularly in multi-homed 1113 hosts. For example, receipt of "Link Going Down" or "Link Quality 1114 Crosses Threshold" indications could be used as a signal to enable 1115 another interface. However, unless the new interface is the 1116 preferred route for one or more destination prefixes, a "Weak End- 1117 System" implementation will not use the new interface for outgoing 1118 traffic. Where "idle timeout" functionality is implemented, the 1119 unused interface will be brought down, only to be brought up again by 1120 the link enablement algorithm. 1122 As noted in [Aguayo], signal strength and distance are not good 1123 predictors of frame loss or negotiated rate, due to the potential 1124 effects of multi-path interference. As a result a link brought up 1125 due to good signal strength may subsequently exhibit significant 1126 frame loss, and a low negotiated rate. Similarly, an AP 1127 demonstrating low utilization may not necessarily be the best choice, 1128 since utilization may be low due to hardware or software problems. 1129 [Villamizar] notes that link utilization-based routing metrics have a 1130 history of instability, so that they are rarely deployed. 1132 2.8. Layer compression 1134 In many situations, the exchanges required for a host to complete a 1135 handoff and reestablish connectivity are considerable. This includes 1136 link layer scanning, authentication and connectivity establishment; 1137 Internet layer configuration, routing and mobility exchanges; 1138 Transport layer retransmission and recovery; security association re- 1139 establishment; application protocol re-authentication and re- 1140 registration exchanges, etc. It is therefore natural to consider 1141 combining exchanges occurring within multiple layers in order to 1142 reduce overhead. 1144 Often this combined exchange occurs within the link layer. For 1145 example, in [EAPIKEv2], a link layer EAP exchange may be used for the 1146 purpose of IP address assignment, potentially bypassing Internet 1147 layer configuration. Within [PEAP], it is proposed that a link layer 1148 EAP exchange be used for the purpose of carrying Mobile IPv6 Binding 1149 Updates. [MIPEAP] proposes that EAP exchanges be used for 1150 configuration of Mobile IPv6. 1152 While the goals of layer compression are laudable, care needs to be 1153 taken to avoid compromising interoperability and introducing link 1154 layer dependencies into the Internet and Transport layers. For 1155 example, where link, Internet or Transport layer mechanisms are 1156 combined, hosts need to maintain backward compatibility to permit 1157 operation on networks where compression schemes are not available. 1159 Layer compression schemes may also negatively impact robustness. For 1160 example, in order to optimize IP address assignment, it has been 1161 proposed that prefixes be advertised at the link layer, such as 1162 within the 802.11 Beacon and Probe Response frames. However, 1163 [IEEE-802.1X] enables the VLANID to be assigned dynamically, so that 1164 prefix(es) advertised within the Beacon and/or Probe Response may not 1165 correspond to the prefix(es) configured by the Internet layer after 1166 the host completes link layer authentication. Were the host to 1167 handle IP configuration at the link layer rather than within the 1168 Internet layer, the host might be unable to communicate due to 1169 assignment of the wrong IP address. 1171 2.9. Transport of Link Indications 1173 Proposals including the transport of link indications beyond the 1174 local host need to carefully consider the layering, security and 1175 transport implications. 1177 In general, implicit signals are preferred to explicit transport of 1178 link indications since they add no new packets in times of network 1179 distress, operate more reliably in the presence of middle boxes such 1180 as NA(P)Ts, and are more likely to be backward compatible. 1182 While facilities such as ICMP "source quench" were originally 1183 provided at the Internet layer, these facilities have fallen into 1184 disuse due to their questionable value for the Transport layer. In 1185 general, the Transport layer is able to determine an appropriate (and 1186 conservative) response to congestion based on packet loss or explicit 1187 congestion notification, so that ICMP "source quench" indications are 1188 not needed, and in fact the sending of additional "source quench" 1189 packets during periods of congestion may be detrimental. 1191 Routing metrics incorporating link layer indications enable gateways 1192 to obtain knowledge of path changes and take remote link conditions 1193 into account for the purposes of route selection. When a link 1194 experiences frame loss, routing metrics incorporating frame loss such 1195 as the metric described in [ETX] increase, possibly resulting in 1196 selection of an alternate route. If a troubled link represents the 1197 only path to a prefix and the link experiences high frame loss 1198 ("down"), the route will be withdrawn or the metric will become 1199 infinite. Similarly, when the link becomes operational, the route 1200 will appear again. Where routing protocol security is implemented, 1201 this information can be securely propagated. 1203 Where explicit signaling is required, existing facilities should be 1204 used rather than creating new ones. "Fault Isolation and Recovery" 1205 [RFC826] Section 3 describes how hosts can make use of ICMP messages: 1207 In fact, it is never necessary for a host to explicitly ask a 1208 gateway for advice, because the gateway will provide it as 1209 appropriate. When a host sends a datagram to some distant net, 1210 the host should be prepared to receive back either of two advisory 1211 messages which the gateway may send. The ICMP "redirect" message 1212 indicates that the gateway to which the host sent the datagram is 1213 not longer the best gateway to reach the net in question. The 1214 gateway will have forwarded the datagram, but the host should 1215 revise its routing table to have a different immediate address 1216 for this net. The ICMP "destination unreachable" message 1217 indicates that as a result of an outage, it is currently 1218 impossible to reach the addressed net or host in any manner. On 1219 receipt of this message, a host can either abandon the connection 1220 immediately without any further retransmission, or resend slowly 1221 to see if the fault is corrected in reasonable time. 1223 "TCP Extensions for Immediate Retransmissions" [Eggert] describes how 1224 a Transport layer implementation may utilize existing "end-to-end 1225 connectivity restored" indications. 1227 Proposals involving transport of link indications need to demonstrate 1228 the following: 1230 [a] Absence of alternatives. By default, alternatives not requiring 1231 explicit signaling are preferred. Where these solutions are shown 1232 to be inadequate, proposals must prove that existing explicit 1233 signaling mechanisms (such as path change processing and link- 1234 aware routing metrics) are inadequate. 1236 [b] Conservative behavior. Due to experience with ICMP "source 1237 quench", proposals must demonstrate that they do not violate 1238 conservation of packets. 1240 [c] Security. Proposals need to describe how security issues can be 1241 addressed. Where link indications are transported over the 1242 Internet, an attack can be launched without requiring access to 1243 the link. 1245 [d] Identifiers. When link indications are transported, it is 1246 generally for the purposes of saying something about Internet, 1247 Transport or Application layer operations at a remote element. 1248 These layers use different identifiers, and so it is necessary to 1249 match the link indication with relevant higher layer state. 1250 Therefore proposals need to demonstrate how the link indication 1251 can be mapped to the right higher layer state. 1253 For example, if a presence server is receiving remote indications 1254 of "Link Up"/"Link Down" status for a particular MAC address, the 1255 presence server will need to associate that MAC address with the 1256 identity of the user (pres:user@example.com) to whom that link 1257 status change is relevant. 1259 3. Future Work 1261 While Figure 1 presents an overview of how link indications are 1262 utilized by the Internet, Transport and Application layers, further 1263 work is needed to investigate this in more detail. 1265 More work is needed in the area of link-aware routing metrics. For 1266 example, since recent proposals such as [IEEE-802.11e] incorporate 1267 burst ACKs, the relationship between 802.11 link throughput and frame 1268 loss is growing more complex. This may necessitate the development 1269 of revised routing metrics, taking the more complex retransmission 1270 behavior into account, as well as the negotiated rate. 1272 At the Link and Internet layers, more work is needed to reconcile pre 1273 and post-connection metrics, such as reconciling metrics utilized in 1274 handoff (e.g. signal strength and link utilization) with link-aware 1275 routing metrics (e.g. frame loss and negotiated rate). 1277 At the Transport layer, more work is needed to understand how to 1278 react to Internet layer indications such as path changes. It may 1279 also make sense for the Transport layer to adjust transport parameter 1280 estimates in response to "Link Up"/"Link Down" indications and frame 1281 loss. For example, it is unclear that the Transport layer should 1282 adjust transport parameters as though congestion were detected when 1283 loss is occurring in the link layer or a "Link Down" indication has 1284 been received. 1286 Finally, more work is needed to determine how link layers may utilize 1287 information from the Transport layer. For example, it is undesirable 1288 for a link layer to retransmit so aggressively that the link layer 1289 round-trip time approaches that of the end-to-end transport 1290 connection. 1292 4. Security Considerations 1294 Since link indications are typically insecure, proposals 1295 incorporating them need to consider the potential security 1296 implications of spoofed or modified link indications, as well as 1297 potential denial of service attacks. This is particularly important 1298 in situations where insecure link indications are used as a 1299 substitute for secure mechanisms operating at a higher layer. 1301 For example, within [IEEE-802.11F], "Link Up" is considered to occur 1302 when an Access Point sends a Reassociation Response. At that point, 1303 the AP sends a frame with the station's source address to a multicast 1304 address, thereby causing switches within the Distribution System to 1305 learn the station's MAC address, enabling forwarding of frames to the 1306 station at the new point of attachment. Unfortunately, this does not 1307 take security into account, since the station is not capable of 1308 sending and receiving IP packets on the link until completion of the 1309 key exchange protocol defined in [IEEE-802.11i]. As a result, link 1310 indications as implemented in [IEEE-802.11F] enable an attacker to 1311 disassociate a station located anywhere within the ESS, by sending a 1312 Reassociation Request frame. 1314 Another example of the potential security implications of link 1315 indications occurs within DNAv4, where link indications are used for 1316 optimization of IP configuration, rather than using a secured 1317 configuration mechanism such as authenticated DHCP [RFC3118], thereby 1318 increasing vulnerability to spoofing. 1320 5. References 1322 5.1. Informative References 1324 [RFC816] Clark, D., "Fault Isolation and Recovery", RFC 816, July 1982. 1326 [RFC1058] Hedrick, C., "Routing Information Protocol", RFC 1058, June 1327 1988. 1329 [RFC1131] Moy, J., "The OSPF Specification", RFC 1131, October 1989. 1331 [RFC1307] Young, J. and A. Nicholson, "Dynamically Switched Link Control 1332 Protocol", RFC 1307, March 1992. 1334 [RFC1661] Simpson, W., "The Point-to-Point Protocol (PPP)", STD 51, RFC 1335 1661, July 1994. 1337 [RFC1812] Baker, F., "Requirements for IP Version 4 Routers", RFC 1812, 1338 June 1995. 1340 [RFC1918] Rekhter, Y., Moskowitz, B., Karrenberg, D., de Groot, D. and 1341 E. Lear, "Address Allocation for Private Internets", RFC 1918, 1342 February 1996. 1344 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1345 Requirement Levels", BCP 14, RFC 2119, March 1997. 1347 [RFC2131] Droms, R., "Dynamic Host Configuration Protocol", RFC 2131, 1348 March 1997. 1350 [RFC2778] Day, M., Rosenberg, J. and H. Sugano, "A Model for Presence 1351 and Instant Messaging", RFC 2778, February 2000. 1353 [RFC2861] Handley, M., Padhye, J. and S. Floyd, "TCP Congestion Window 1354 Validation", RFC 2861, June 2000. 1356 [RFC2914] Floyd, S., "Congestion Control Principles", RFC 2914, BCP 41, 1357 September 2000. 1359 [RFC3118] Droms, R. and B. Arbaugh, "Authentication for DHCP Messages", 1360 RFC 3118, June 2001. 1362 [RFC3428] Campbell, B., Rosenberg, J., Schulzrinne, H., Huitema, C. and 1363 D. Gurle, "Session Initiation Protocol (SIP) Extension for 1364 Instant Messaging", RFC 3428, December 2002. 1366 [RFC3775] Johnson, D., Perkins, C. and J. Arkko, "Mobility Support in 1367 IPv6", RFC 3775, June 2004. 1369 [RFC3921] Saint-Andre, P., "Extensible Messaging and Presence protocol 1370 (XMPP): Instant Messaging and Presence", RFC 3921, October 1371 2004. 1373 [RFC3927] Cheshire, S., Aboba, B. and E. Guttman, "Dynamic Configuration 1374 of Link-Local IPv4 Addresses", RFC 3927, May 2005. 1376 [Alimian] Alimian, A., "Roaming Interval Measurements", 1377 11-04-0378-00-roaming-intervals-measurements.ppt, IEEE 802.11 1378 submission (work in progress), March 2004. 1380 [Aguayo] Aguayo, D., Bicket, J., Biswas, S., Judd, G. and R. Morris, 1381 "Link-level Measurements from an 802.11b Mesh Network", 1382 SIGCOMM '04, September 2004, Portland, Oregon. 1384 [Bakshi] Bakshi, B., Krishna, P., Vadiya, N. and D.Pradhan, "Improving 1385 Performance of TCP over Wireless Networks", Proceedings of the 1386 1997 International Conference on Distributed Computer Systems, 1387 Baltimore, May 1997. 1389 [BFD] Katz, D. and D. Ward, "Bidirectional Forwarding Detection", 1390 draft-ietf-bfd-base-02.txt, Internet draft (work in progress), 1391 March 2005. 1393 [Biaz] Biaz, S. and N. Vaidya, "Discriminating Congestion Losses from 1394 Wireless Losses Using Interarrival Times at the Receiver", 1395 Proc. IEEE Symposium on Application-Specific Systems and 1396 Software Engineering and Technology, Richardson, TX, Mar 1999. 1398 [Chandran] 1399 Chandran, K., Raghunathan, S., Venkatesan, S. and R. Prakash, 1400 "A Feedback-Based Scheme for Improving TCP Performance in Ad- 1401 Hoc Wireless Networks", Proceedings of the 18th International 1402 Conference on Distributed Computing Systems (ICDCS), 1403 Amsterdam, May 1998. 1405 [DCCP] Kohler, E., Handley, M. and S. Floyd, "Datagram Congestion 1406 Control Protocol (DCCP)", Internet drafts (work in progress), 1407 draft-ietf-dccp-spec-08.txt, October 2004. 1409 [DNAv4] Aboba, B., "Detection of Network Attachment in IPv4", draft- 1410 ietf-dhc-dna-ipv4-13.txt, Internet draft (work in progress), 1411 June 2005. 1413 [E2ELinkup] 1414 Dawkins, S. and C. Williams, "End-to-end, Implicit 'Link-Up' 1415 Notification", draft-dawkins-trigtran-linkup-01.txt, Internet 1416 draft (work in progress), October 2003. 1418 [EAPIKEv2] 1419 Tschofenig, H., D. Kroeselberg and Y. Ohba, "EAP IKEv2 1420 Method", draft-tschofenig-eap-ikev2-05.txt, Internet draft 1421 (work in progress), October 2004. 1423 [Eckhardt] 1424 Eckhardt, D. and P. Steenkiste, "Measurement and Analysis of 1425 the Error Characteristics of an In-Building Wireless Network", 1426 SIGCOMM '96, August 1996, Stanford, CA. 1428 [Eggert] Eggert, L., Schuetz, S. and S. Schmid, "TCP Extensions for 1429 Immediate Retransmissions", draft-eggert-tcpm-tcp-retransmit- 1430 now-01.txt, Internet draft (work in progress), September 2004. 1432 [ETX] Douglas S. J. De Couto, Daniel Aguayo, John Bicket, and Robert 1433 Morris, "A High-Throughput Path Metric for Multi-Hop Wireless 1434 Routing", Proceedings of the 9th ACM International Conference 1435 on Mobile Computing and Networking (MobiCom '03), San Diego, 1436 California, September 2003. 1438 [GenTrig] Gupta, V. and D. Johnston, "A Generalized Model for Link Layer 1439 Triggers", submission to IEEE 802.21 (work in progress), March 1440 2004, available at: 1441 http://www.ieee802.org/handoff/march04_meeting_docs/ 1442 Generalized_triggers-02.pdf 1444 [Goel] Goel, S. and D. Sanghi, "Improving TCP Performance over 1445 Wireless Links", Proceedings of TENCON'98, pages 332-335. 1446 IEEE, December 1998. 1448 [Gurtov] Gurtov, A. and J. Korhonen, "Effect of Vertical Handovers on 1449 Performance of TCP-Friendly Rate Control", to appear in ACM 1450 MCCR, 2004. 1452 [GurtovFloyd] 1453 Gurtov, A. and S. Floyd, "Modeling Wireless Links for 1454 Transport Protocols", Computer Communications Review (CCR) 34, 1455 2 (2003). 1457 [HMP] Lee, S., Cho, J. and A. Campbell, "Hotspot Mitigation Protocol 1458 (HMP)", draft-lee-hmp-00.txt, Internet draft (work in 1459 progress), October 2003. 1461 [Holland] Holland, G. and N. Vaidya, "Analysis of TCP Performance over 1462 Mobile Ad Hoc Networks", Proceedings of the Fifth 1463 International Conference on Mobile Computing and Networking, 1464 pages 219-230. ACM/IEEE, Seattle, August 1999. 1466 [Iannaccone] 1467 Iannaccone, G., Chuah, C., Mortier, R., Bhattacharyya, S. and 1468 C. Diot, "Analysis of link failures in an IP backbone", Proc. 1469 of ACM Sigcomm Internet Measurement Workshop, November, 2002. 1471 [IEEE-802.1X] 1472 Institute of Electrical and Electronics Engineers, "Local and 1473 Metropolitan Area Networks: Port-Based Network Access 1474 Control", IEEE Standard 802.1X, December 2004. 1476 [IEEE-802.11] 1477 Institute of Electrical and Electronics Engineers, "Wireless 1478 LAN Medium Access Control (MAC) and Physical Layer (PHY) 1479 Specifications", IEEE Standard 802.11, 2003. 1481 [IEEE-802.11e] 1482 Institute of Electrical and Electronics Engineers, "Draft 1483 Amendment 7: Medium Access Control (MAC) Quality of Service 1484 (QoS) Enhancements", IEEE 802.11e Draft 10.0, October 2004. 1486 [IEEE-802.11F] 1487 Institute of Electrical and Electronics Engineers, "IEEE 1488 Trial-Use Recommended Practice for Multi-Vendor Access Point 1489 Interoperability via an Inter-Access Point Protocol Across 1490 Distribution Systems Supporting IEEE 802.11 Operation", IEEE 1491 802.11F, June 2003. 1493 [IEEE-802.11i] 1494 Institute of Electrical and Electronics Engineers, "Supplement 1495 to Standard for Telecommunications and Information Exchange 1496 Between Systems - LAN/MAN Specific Requirements - Part 11: 1497 Wireless LAN Medium Access Control (MAC) and Physical Layer 1498 (PHY) Specifications: Specification for Enhanced Security", 1499 IEEE 802.11i, July 2004. 1501 [IEEE-802.11k] 1502 Institute of Electrical and Electronics Engineers, "Draft 1503 Amendment to Telecommunications and Information Exchange 1504 Between Systems - LAN/MAN Specific Requirements - Part 11: 1506 Wireless LAN Medium Access Control (MAC) and Physical Layer 1507 (PHY) Specifications - Amendment 7: Radio Resource 1508 Management", IEEE 802.11k/D2.0, February 2005. 1510 [IEEE-802.21] 1511 Institute of Electrical and Electronics Engineers, "Draft 1512 Standard for Telecommunications and Information Exchange 1513 Between Systems - LAN/MAN Specific Requirements - Part 21: 1514 Media Independent Handover", IEEE 802.21D0, June 2005. 1516 [Kim] Kim, K., Park, Y., Suh, K., and Y. Park, "The BU-trigger 1517 method for improving TCP performance over Mobile IPv6", draft- 1518 kim-tsvwg-butrigger-00.txt, Internet draft (work in progress), 1519 August 2004. 1521 [Kotz] Kotz, D., Newport, C. and C. Elliot, "The mistaken axioms of 1522 wireless-network research", Dartmouth College Computer Science 1523 Technical Report TR2003-467, July 2003. 1525 [Krishnan] 1526 Krishnan, R., Allman, M., Partridge, P. and J. Sterbenz, 1527 "Explicit Transport Error Notification (ETEN) for Error-Prone 1528 Wireless and Satellite Networks", Technical Report No. 8333, 1529 BBN Technologies, March 2002. 1531 [Lee] Park, S., Lee, M. and J. Korhonen, "Link Characteristics 1532 Information for Mobile IP", draft-daniel-mip-link- 1533 characteristic-01.txt, Internet draft (work in progress), 1534 April 2005. 1536 [Ludwig] Ludwig, R. and B. Rathonyi, "Link-layer Enhancements for 1537 TCP/IP over GSM", Proceedings of IEEE Infocom '99, March 1999. 1539 [MIPEAP] Giaretta, C., Guardini, I., Demaria, E., Bournelle, J. and M. 1540 Laurent-Maknavicius, "MIPv6 Authorization and Configuration 1541 based on EAP", draft-giaretta-mip6-authorization-eap-02.txt, 1542 Internet draft (work in progress), October 2004. 1544 [Mishra] Mitra, A., Shin, M., and W. Arbaugh, "An Empirical Analysis of 1545 the IEEE 802.11 MAC Layer Handoff Process", CS-TR-4395, 1546 University of Maryland Department of Computer Science, 1547 September 2002. 1549 [Mitani] Mitani, K., Shibui, R., Gogo, K. and F. Teraoka, "Unified L2 1550 Abstractions for L3-Driven Fast Handover", draft-koki-mobopts- 1551 l2-abstractions-02.txt, Internet draft (work in progress), 1552 February 2005. 1554 [Mun] Mun, Y. and J. Park, "Layer 2 Handoff for Mobile-IPv4 with 1555 802.11", draft-mun-mobileip-layer2-handoff-mipv4-01.txt, 1556 Internet draft (work in progress), March 2004. 1558 [PEAP] Palekar, A., Simon, D., Salowey, J., Zhou, H., Zorn, G. and S. 1559 Josefsson, "Protected EAP Protocol (PEAP) Version 2", draft- 1560 josefsson-pppext-eap-tls-eap-10.txt, Internet draft (work in 1561 progress), October 2004. 1563 [Park] Park, S., Njedjou, E. and N. Montavont, "L2 Triggers Optimized 1564 Mobile IPv6 Vertical Handover: The 802.11/GPRS Example", 1565 draft-daniel-mip6-optimized-vertical-handover-00.txt, July 1566 2004. ,IP [PRNET] Jubin, J. and J. Tornow, "The DARPA packet 1567 radio network protocols", Proceedings of the IEEE, 75(1), 1568 January 1987. 1570 [Ramani] Ramani, I. and S. Savage, "SyncScan: Practical Fast Handoff 1571 for 802.11 Infrastructure Networks", Proceedings of the IEEE 1572 InfoCon 2005, March 2005. 1574 [Scott] Scott, J., Mapp, G., "Link Layer Based TCP Optimisation for 1575 Disconnecting Networks", ACM SIGCOMM Computer Communication 1576 Review, 33(5), October 2003. 1578 [Shortest] 1579 Douglas S. J. De Couto, Daniel Aguayo, Benjamin A. Chambers 1580 and Robert Morris, "Performance of Multihop Wireless Networks: 1581 Shortest Path is Not Enough", Proceedings of the First 1582 Workshop on Hot Topics in Networking (HotNets-I), Princeton, 1583 New Jersey, October 2002. 1585 [Swami] Swami, Y., Le, K., Eddy, W., "Lightweight Mobility Detection 1586 and Response (LMDR) Algorithm for TCP", draft-swami-tcp- 1587 lmdr-05, Internet draft (work in progress), February 2005. 1589 [TRIGTRAN] 1590 Dawkins, S., Williams, C. and A. Yegin, "Framework and 1591 Requirements for TRIGTRAN", draft-dawkins-trigtran- 1592 framework-00.txt, Internet draft (work in progress), August 1593 2003. 1595 [Vatn] Vatn, J., "An experimental study of IEEE 802.11b handover 1596 performance and its effect on voice traffic", TRITA-IMIT- 1597 TSLAB R 03:01, KTH Royal Institute of Technology, Stockholm, 1598 Sweden, July 2003. 1600 [Yegin] Yegin, A., "Link-layer Triggers Protocol", draft-yegin- 1601 l2-triggers-00.txt, Internet Draft (work in progress), June 1602 2002. 1604 [Velayos] Velayos, H. and G. Karlsson, "Techniques to Reduce IEEE 1605 802.11b MAC Layer Handover Time", TRITA-IMIT-LCN R 03:02, KTH 1606 Royal Institute of Technology, Stockholm, Sweden, April 2003. 1608 [Vertical] 1609 Zhang, Q., Guo, C., Guo, Z. and W. Zhu, "Efficient Mobility 1610 Management for Vertical Handoff between WWAN and WLAN", IEEE 1611 Communications Magazine, November 2003. 1613 [Villamizar] 1614 Villamizar, C., "OSPF Optimized Multipath (OSPF-OMP)", draft- 1615 ietf-ospf-omp-02.txt, Internet draft (work in progress), 1616 February 1999. 1618 [Xylomenos] 1619 Xylomenos, G., "Multi Service Link Layers: An Approach to 1620 Enhancing Internet Performance over Wireless Links", Ph.D. 1621 thesis, University of California at San Diego, 1999. 1623 Appendix A - Literature Review 1625 This Appendix summarizes the literature on utilization of link 1626 indications within the Link, Internet, Transport and Application 1627 layers. 1629 A.1 Link Layer 1631 The characteristics of wireless links have been found to vary 1632 considerably depending on the environment. In "Measurement and 1633 Analysis of the Error Characteristics of an In-Building Wireless 1634 Network" [Eckhardt], the authors characterize the performance of an 1635 AT&T Wavelan 2 Mbps in-building WLAN operating in Infrastructure mode 1636 on the Carnegie-Mellon Campus. In this study, very low frame loss 1637 was experienced. As a result, links could either be assumed to 1638 operate very well or not at all. 1640 "Link-level Measurements from an 802.11b Mesh Network" [Aguayo] 1641 analyzes the causes of frame loss in a 38-node urban multi-hop 802.11 1642 ad-hoc network. In most cases, links that are very bad in one 1643 direction tend to be bad in both directions, and links that are very 1644 good in one direction tend to be good in both directions. However, 1645 30 percent of links exhibited loss rates differing substantially in 1646 each direction. 1648 Signal to noise ratio and distance showed little value in predicting 1649 loss rates, and rather than exhibiting a step-function transition 1650 between "up" (low loss) or "down" (high loss) states, inter-node 1651 loss rates varied widely, demonstrating a nearly uniform distribution 1652 over the range at the lower rates. The authors attribute the 1653 observed effects to multi-path fading, rather than attenuation or 1654 interference. 1656 The findings of [Eckhardt] and [Aguayo] demonstrate the diversity of 1657 link conditions observed in practice. While for indoor 1658 infrastructure networks site surveys and careful measurement can 1659 assist in promoting ideal behavior, in ad-hoc/mesh networks node 1660 mobility and external factors such as weather may not be easily 1661 controlled. 1663 Considerable diversity in behavior is also observed due to 1664 implementation effects. "Techniques to reduce IEEE 802.11b MAC layer 1665 handover time" [Velayos] measured handover times for a stationary STA 1666 after the AP was turned off. This study divided handover times into 1667 detection (determination of disconnection from the existing point of 1668 attachment) search (discovery of alternative attachment points), and 1669 execution phases (connection to an alternative point of attachment). 1670 These measurements indicated that the duration of the detection phase 1671 (the largest component of handoff delay) is determined by the number 1672 of non-acknowledged frames triggering the search phase and delays due 1673 to precursors such as RTS/CTS and rate adaptation. 1675 Detection behavior varied widely between implementations. For 1676 example, NICs designed for desktops attempted more retransmissions 1677 prior to triggering search as compared with laptop designs, since 1678 they assumed that the AP was always in range, regardless of whether 1679 the Beacon was received. 1681 The study recommends that the duration of the detection phase be 1682 reduced by initiating the search phase as soon as collisions can be 1683 excluded as the cause of non-acknowledged transmissions; the authors 1684 recommend three consecutive transmission failures as the cutoff. 1685 This approach is both quicker and more immune to multi-path 1686 interference than monitoring of the S/N ratio. Where the STA is not 1687 sending or receiving frames, it is recommended that Beacon reception 1688 be tracked in order to detect disconnection, and that Beacon spacing 1689 be reduced to 60 ms in order to reduce detection times. In order to 1690 compensate for more frequent triggering of the search phase, the 1691 authors recommend algorithms for wait time reduction, as well as 1692 interleaving of search and data frame transmission. 1694 "An Empirical Analysis of the IEEE 802.11 MAC Layer Handoff Process" 1695 [Mishra] investigates handoff latencies obtained with three mobile 1696 STAs implementations communicating with two APs. The study found 1697 that there is large variation in handoff latency among STA and AP 1698 implementations and that implementations utilize different message 1699 sequences. For example, one STA sends a Reassociation Request prior 1700 to authentication, which results in receipt of a Deauthenticate 1701 message. The study divided handoff latency into discovery, 1702 authentication and reassociation exchanges, concluding that the 1703 discovery phase was the dominant component of handoff delay. Latency 1704 in the detection phase was not investigated. 1706 "SyncScan: Practical Fast Handoff for 802.11 Infrastructure Networks" 1707 [Ramani] weighs the pros and cons of active versus passive scanning. 1708 The authors point out the advantages of timed beacon reception, which 1709 had previously been incorporated into [IEEE-802.11k]. Timed beacon 1710 reception allows the station to continually keep up to date on the 1711 S/N ratio of neighboring APs, allowing handoff to occur earlier. 1712 Since the station does not need to wait for initial and subsequent 1713 responses to a broadcast Probe Response (MinChannelTime and 1714 MaxChannelTime, respectively), performance is comparable to what is 1715 achievable with 802.11k Neighbor Reports and unicast Probe Requests. 1717 The authors measure the channel switching delay, the time it takes to 1718 switch to a new frequency, and begin receiving frames. Measurements 1719 ranged from 5 ms to 19 ms per channel; where timed Beacon reception 1720 or interleaved active scanning is used, switching time contributes 1721 significantly to overall handoff latency. The authors propose 1722 deployment of APs with Beacons synchronized via NTP, enabling a 1723 driver implementing SyncScan to work with legacy APs without 1724 requiring implementation of new protocols. The authors measure the 1725 distribution of inter-arrival times for stations implementing 1726 SyncScan, with excellent results. 1728 "Roaming Interval Measurements" [Alimian] presents data on stationary 1729 STAs after the AP signal has been shut off. This study highlighted 1730 implementation differences in rate adaptation as well as detection, 1731 scanning and handoff. As in [Velayos], performance varied widely 1732 between implementations, from half an order of magnitude variation 1733 in rate adaptation to an order of magnitude difference in detection 1734 times, two orders of magnitude in scanning, and one and a half orders 1735 of magnitude in handoff times. 1737 "An experimental study of IEEE 802.11b handoff performance and its 1738 effect on voice traffic" [Vatn] describes handover behavior observed 1739 when the signal from AP is gradually attenuated, which is more 1740 representative of field experience than the shutoff techniques used 1741 in [Velayos]. Stations were configured to initiate handover when 1742 signal strength dipped below a threshold, rather than purely based on 1743 frame loss, so that they could begin handover while still connected 1744 to the current AP. It was noted that stations continue to receive 1745 data frames during the search phase. Station-initiated 1746 Disassociation and pre-authentication were not observed in this 1747 study. 1749 A.1.1 Link Indications 1751 Within a link layer, the definition of "Link Up" and "Link Down" may 1752 vary according to the deployment scenario. For example, within PPP 1753 [RFC1661], either peer may send an LCP-Terminate frame in order to 1754 terminate the PPP link layer, and a link may only be assumed to be 1755 usable for sending network protocol packets once NCP negotiation has 1756 completed for that protocol. 1758 Unlike PPP, IEEE 802 does not include facilities for network layer 1759 configuration, and the definition of "Link Up" and "Link Down" varies 1760 by implementation. Empirical evidence suggests that the definition 1761 of "Link Up" and "Link Down" may depend whether the station is mobile 1762 or stationary, whether infrastructure or ad-hoc mode is in use, and 1763 whether security and Inter-Access Point Protocol (IAPP) is 1764 implemented. 1766 Where a mobile 802.11 STA encounters a series of consecutive non- 1767 acknowledged frames, the most likely cause is that the station has 1768 moved out of range of the AP. As a result, [Velayos] recommends that 1769 the station begin the search phase after collisions can be ruled out, 1770 after three consecutive non-acknowledged frames. Only when no 1771 alternative point of attachment is found is a "Link Down" indication 1772 returned. 1774 In a stationary point-to-point installation, the most likely cause of 1775 an outage is that the link has become impaired, and alternative 1776 points of attachment may not be available. As a result, 1777 implementations configured to operate in this mode tend to be more 1778 persistent. For example, within 802.11 the short interframe space 1779 (SIFS) interval may be increased and MIB variables relating to 1780 timeouts (such as dot11AuthenticationResponseTimeout, 1781 dot11AssociationResponseTimeout, dot11ShortRetryLimit, and 1782 dot11LongRetryLimit) may be set to larger values. In addition a 1783 "Link Down" indication may be returned later. 1785 In 802.11 ad-hoc mode with no security, reception of data frames is 1786 enabled in State 1 ("Unauthenticated" and "Unassociated"). As a 1787 result, reception of data frames is enabled at any time, and no 1788 explicit "Link Up" indication exists. 1790 In Infrastructure mode, IEEE 802.11-2003 enables reception of data 1791 frames only in State 3 ("Authenticated" and "Associated"). As a 1792 result, a transition to State 3 (e.g. completion of a successful 1793 Association or Reassociation exchange) enables sending and receiving 1794 of network protocol packets and a transition from State 3 to State 2 1795 (reception of a "Disassociate" frame) or State 1 (reception of a 1796 "Deauthenticate" frame) disables sending and receiving of network 1797 protocol packets. As a result, IEEE 802.11 stations typically signal 1798 "Link Up" on receipt of a successful Association/Reassociation 1799 Response. 1801 As described within [IEEE-802.11F], after sending a Reassociation 1802 Response, an Access Point will send a frame with the station's source 1803 address to a multicast destination. This causes switches within the 1804 Distribution System (DS) to update their learning tables, readying 1805 the DS to forward frames to the station at its new point of 1806 attachment. Were the AP to not send this "spoofed" frame, the 1807 station's location would not be updated within the distribution 1808 system until it sends its first frame at the new location. Thus the 1809 purpose of spoofing is to equalize uplink and downlink handover 1810 times. This enables an attacker to deny service to authenticated and 1811 associated stations by spoofing a Reassociation Request using the 1812 victim's MAC address, from anywhere within the ESS. Without 1813 spoofing, such an attack would only be able to disassociate stations 1814 on the AP to which the Reassociation Request was sent. 1816 The signaling of "Link Down" is considerably more complex. Even 1817 though a transition to State 2 or State 1 results in the station 1818 being unable to send or receive IP packets, this does not necessarily 1819 imply that such a transition should be considered a "Link Down" 1820 indication. In an infrastructure network, a station may have a 1821 choice of multiple access points offering connection to the same 1822 network. In such an environment, a station that is unable to reach 1823 State 3 with one access point may instead choose to attach to another 1824 access point. Rather than registering a "Link Down" indication with 1825 each move, the station may instead register a series of "Link Up" 1826 indications. 1828 In [IEEE-802.11i] forwarding of frames from the station to the 1829 distribution system is only feasible after the completion of the 1830 4-way handshake and group-key handshake, so that entering State 3 is 1831 no longer sufficient. This has resulted in several observed 1832 problems. For example, where a "Link Up" indication is triggered on 1833 the station by receipt of an Association/Reassociation Response, DHCP 1834 [RFC2131] or RS/RA may be triggered prior to when the link is usable 1835 by the Internet layer, resulting in configuration delays or failures. 1836 Similarly, Transport layer connections will encounter packet loss, 1837 resulting in back-off of retransmission timers. 1839 A.1.2 Smart Link Layer Proposals 1841 In order to improve link layer performance, several studies have 1842 investigated "smart link layer" proposals. 1844 In "Link-layer Enhancements for TCP/IP over GSM" [Ludwig], the 1845 authors describe how the GSM reliable and unreliable link layer modes 1846 can be simultaneously utilized without higher layer control. Where a 1847 reliable link layer protocol is required (where reliable transports 1848 such TCP and SCTP are used), the Radio Link Protocol (RLP) can be 1849 engaged; with delay sensitive applications such as those based on 1850 UDP, the transparent mode (no RLP) can be used. The authors also 1851 describe how PPP negotiation can be optimized over high latency GSM 1852 links using "Quickstart-PPP". 1854 In "Link Layer Based TCP Optimisation for Disconnecting Networks" 1855 [Scott], the authors describe performance problems that occur with 1856 reliable transport protocols facing periodic network disconnections, 1857 such as those due to signal fading or handoff. The authors define a 1858 disconnection as a period of connectivity loss that exceeds a 1859 retransmission timeout, but is shorter than the connection lifetime. 1860 One issue is that link-unaware senders continue to backoff during 1861 periods of disconnection. The authors suggest that a link-aware 1862 reliable transport implementation halt retransmission after receiving 1863 a "Link Down" indication. Another issue is that on reconnection the 1864 lengthened retransmission times cause delays in utilizing the link. 1866 To improve performance, a "smart link layer" is proposed, which 1867 stores the first packet that was not successfully transmitted on a 1868 connection, then retransmits it upon receipt of a "Link Up" 1869 indication. Since a disconnection can result in hosts experiencing 1870 different network conditions upon reconnection, the authors do not 1871 advocate bypassing slowstart or attempting to raise the congestion 1872 window. Where IPsec is used and connections cannot be differentiated 1873 because transport headers are not visible, the first untransmitted 1874 packet for a given sender and destination IP address can be 1875 retransmitted. In addition to looking at retransmission of a single 1876 packet per connection, the authors also examined other schemes such 1877 as retransmission of multiple packets and rereception of single or 1878 multiple packets. 1880 In general, retransmission schemes were superior to rereception 1881 schemes, since rereception cannot stimulate fast retransmit after a 1882 timeout. Retransmission of multiple packets did not appreciably 1883 improve performance over retransmission of a single packet. Since 1884 the focus of the research was on disconnection rather than just lossy 1885 channels, a two state Markov model was used, with the "up" state 1886 representing no loss, and the "down" state representing one hundred 1887 percent loss. 1889 In "Multi Service Link Layers: An Approach to Enhancing Internet 1890 Performance over Wireless Links", [Xylomenos], the authors use ns-2 1891 to simulate the performance of various link layer recovery schemes 1892 (raw link without retransmission, go back N, XOR based FEC, selective 1893 repeat, Karn's RLP, out of sequence RLP and Berkeley Snoop) in stand- 1894 alone file transfer, web browsing and continuous media distribution. 1895 While selective repeat and Karn's RLP provide the highest throughput 1896 for file transfer and web browsing scenarios, continuous media 1897 distribution requires a combination of low delay and low loss and the 1898 out of sequence RLP performed best in this scenario. Since the 1899 results indicate that no single link layer recovery scheme is optimal 1900 for all applications, the authors propose that the link layer 1901 implement multiple recovery schemes. Simulations of the multi- 1902 service architecture showed that the combination of a low-error rate 1903 recovery scheme for TCP (such as Karn's RLP) and a low-delay scheme 1904 for UDP traffic (such as out of sequence RLP) provides for good 1905 performance in all scenarios. The authors then describe how a multi- 1906 service link layer can be integrated with Differentiated Services. 1908 A.2 Internet Layer 1910 Within the Internet layer, proposals have been made for utilizing 1911 link indications to optimize IP configuration, to improve the 1912 usefulness of routing metrics, and to optimize aspects of Mobile IP 1913 handoff. 1915 In "Detection of Network Attachment (DNA) in IPv4" [DNAv4], link 1916 indications are utilized to enable a host that has moved to a new 1917 point of attachment to rapidly confirm a currently operable 1918 configuration, rather than utilizing the DHCP protocol [RFC2131]. 1920 "A High-Throughput Path Metric for Multi-Hop Wireless Routing" [ETX] 1921 describes how routing metrics can be improved by taking link layer 1922 frame loss rates into account, enabling the selection of routes 1923 maximizing available throughput. While the proposed routing metric 1924 utilizes the Expected Transmission Count (ETX), it does not take the 1925 negotiated rate into account, although this was noted as a subject 1926 for further study. 1928 In "L2 Triggers Optimized Mobile IPv6 Vertical Handover: The 1929 802.11/GPRS Example" [Park] the authors propose that the mobile node 1930 send a router solicitation on receipt of a "Link Up" indication in 1931 order provide lower handoff latency than would be possible using 1932 generic movement detection [RFC3775]. The authors also suggest 1933 immediate invalidation of the Care-Of-Address (CoA) on receipt of a 1934 "Link Down" indication. However, this is problematic where a "Link 1935 Down" indication can be followed by a "Link Up" indication without a 1936 resulting change in IP configuration, such as is described in 1937 [DNAv4]. 1939 In "Layer 2 Handoff for Mobile-IPv4 with 802.11" [Mun], the authors 1940 suggest that MIPv4 Registration messages be carried within 1941 Information Elements of IEEE 802.11 Association/Reassociation frames, 1942 in order to minimize handoff delays. This requires modification to 1943 the mobile node as well as 802.11 APs. However, prior to detecting 1944 network attachment, it is difficult for the mobile node to determine 1945 whether the new point of attachment represents a change of network or 1946 not. For example, even where a station remains within the same ESS, 1947 it is possible that the network will change. Where no change of 1948 network results, sending a MIPv4 Registration message with each 1949 Association/Reassociation is unnecessary. Where a change of network 1950 results, it is typically not possible for the mobile node to 1951 anticipate its new CoA at Association/Reassociation; for example, a 1952 DHCP server may assign a CoA not previously given to the mobile node. 1953 When dynamic VLAN assignment is used, the VLAN assignment is not even 1954 determined until IEEE 802.1X authentication has completed, which is 1955 after Association/Reassociation in [IEEE-802.11i]. 1957 In "Link Characteristics Information for Mobile IP" [Lee], link 1958 characteristics are included in registration/binding update messages 1959 sent by the mobile node to the home agent and correspondent node. 1961 Where the mobile node is acting as a receiver, this allows the 1962 correspondent node to adjust its transport parameters window more 1963 rapidly than might otherwise be possible. Link characteristics that 1964 may be communicated include the link type (e.g. 802.11b, CDMA, GPRS, 1965 etc.) and link bandwidth. While the document suggests that the 1966 correspondent node should adjust its sending rate based on the 1967 advertised link bandwidth, this may not be wise in some 1968 circumstances. For example, where the mobile node link is not the 1969 bottleneck, adjusting the sending rate based on the link bandwidth 1970 could cause in congestion. Also, where link rates change frequently, 1971 sending registration messages on each rate change could by itself 1972 consume significant bandwidth. Even where the advertised link 1973 characteristics indicate the need for a smaller congestion window, it 1974 may be non-trivial to adjust the sending rates of individual 1975 connections where there are multiple connections open between a 1976 mobile node and correspondent node. A more conservative approach 1977 would be to trigger parameter re-estimation and slow start based on 1978 the receipt of a registration message or binding update. 1980 In "Hotspot Mitigation Protocol (HMP)" [HMP], it is noted that MANET 1981 routing protocols have a tendency to concentrate traffic since they 1982 utilize shortest path metrics and allow nodes to respond to route 1983 queries with cached routes. The authors propose that nodes 1984 participating in an adhoc wireless mesh monitor local conditions such 1985 as MAC delay, buffer consumption and packets loss. Where congestion 1986 is detected, this is communicated to neighboring nodes via an IP 1987 option. In response to moderate congestion, nodes suppress route 1988 requests; where major congestion is detected, nodes throttle TCP 1989 connections flowing through them. The authors argue that for adhoc 1990 networks throttling by intermediate nodes is more effective than end- 1991 to-end congestion control mechanisms. 1993 A.3 Transport Layer 1995 Within the Transport layer, proposals have focused on countering the 1996 effects of handoff-induced packet loss and non-congestive loss caused 1997 by lossy wireless links. 1999 Where a mobile host moves to a new network, the transport parameters 2000 (including the RTT, RTO and congestion window) may no longer be 2001 valid. Where the path change occurs on the sender (e.g. change in 2002 outgoing or incoming interface), the sender can reset its congestion 2003 window and parameter estimates. However, where it occurs on the 2004 receiver, the sender may not be aware of the path change. 2006 In "The BU-trigger method for improving TCP performance over Mobile 2007 IPv6" [Kim], the authors note that handoff-related packet loss is 2008 interpreted as congestion by the Transport layer. In the case where 2009 the correspondent node is sending to the mobile node, it is proposed 2010 that receipt of a Binding Update by the correspondent node be used as 2011 a signal to the Transport layer to adjust cwnd and ssthresh values, 2012 which may have been reduced due to handoff-induced packet loss. The 2013 authors recommend that cwnd and ssthresh be recovered to pre-timeout 2014 values, regardless of whether the link parameters have changed. The 2015 paper does not discuss the behavior of a mobile node sending a 2016 Binding Update, in the case where the mobile node is sending to the 2017 correspondent node. 2019 In "Effect of Vertical Handovers on Performance of TCP-Friendly Rate 2020 Control" [Gurtov], the authors examine the effect of explicit 2021 handover notifications on TCP-friendly rate control. Where explicit 2022 handover notification includes information on the loss rate and 2023 throughput of the new link, this can be used to instantaneously 2024 change the transmission rate of the sender. The authors also found 2025 that resetting the TFRC receiver state after handover enabled 2026 parameter estimates to adjust more quickly. 2028 In "Lightweight Mobility Detection and Response (LMDR) Algorithm for 2029 TCP" [Swami], the authors note that while MIPv6 with route 2030 optimization allows a receiver to communicate a subnet change to the 2031 sender via a Binding Update, this is not available within MIPv4. To 2032 provide a communication vehicle that can be universally employed, the 2033 authors propose a TCP option that allows a connection endpoint to 2034 inform a peer of a subnet change. The document does not advocate 2035 utilization of "Link Up" or "Link Down" events since these events are 2036 not necessarily indicative of subnet change. On detection of subnet 2037 change, it is advocated that the congestion window be reset to 2038 INIT_WINDOW and that transport parameters be reestimated. The 2039 authors argue that recovery from slow start results in higher 2040 throughput both when the subnet change results in lower bottleneck 2041 bandwidth as well as when bottleneck bandwidth increases. 2043 In an early draft of [DCCP], a "Reset Congestion State" option was 2044 proposed in Section 4. This option was removed in part because the 2045 use conditions were not fully understood: 2047 An Half-Connection Receiver sends the Reset Congestion State option 2048 to its sender to force the sender to reset its congestion state -- 2049 that is, to "slow start", as if the connection were beginning again. 2050 ... 2051 The Reset Congestion State option is reserved for the very few cases 2052 when an endpoint knows that the congestion properties of a path have 2053 changed. Currently, this reduces to mobility: a DCCP endpoint on a 2054 mobile host MUST send Reset Congestion State to its peer after the 2055 mobile host changes address or path. 2057 "Framework and Requirements for TRIGTRAN" [TRIGTRAN] discusses 2058 optimizations to recover earlier from a retransmission timeout 2059 incurred during a period in which an interface or intervening link 2060 was down. "End-to-end, Implicit 'Link-Up' Notification" [E2ELinkup] 2061 describes methods by which a TCP implementation that has backed off 2062 its retransmission timer due to frame loss on a remote link can learn 2063 that the link has once again become operational. This enables 2064 retransmission to be attempted prior to expiration of the backed off 2065 retransmission timer. 2067 "Link-layer Triggers Protocol" [Yegin] describes transport issues 2068 arising from lack of host awareness of link conditions on downstream 2069 Access Points and routers. Transport of link layer triggers is 2070 proposed to address the issue. 2072 In "TCP Extensions for Immediate Retransmissions" [Eggert], it is 2073 proposed that in addition to regularly scheduled retransmissions that 2074 retransmission be attempted by the Transport layer on receipt of an 2075 indication that connectivity to a peer node may have been restored. 2076 End-to-end connectivity restoration indications include "Link Up", 2077 confirmation of first-hop router reachability, confirmation of 2078 Internet layer configuration, and receipt of other traffic from the 2079 peer. 2081 In "Discriminating Congestion Losses from Wireless Losses Using 2082 Interarrival Times at the Receiver" [Biaz], the authors propose a 2083 scheme for differentiating congestive losses from wireless 2084 transmission losses based on interarrival times. Where the loss is 2085 due to wireless transmission rather than congestion, congestive 2086 backoff and cwnd adjustment is omitted. However, the scheme appears 2087 to assume equal spacing between packets, which is not realistic in an 2088 environment exhibiting link layer frame loss. The scheme is shown to 2089 function well only when the wireless link is the bottleneck, which is 2090 often the case with cellular networks, but not with IEEE 802.11 2091 deployment scenarios such as home or hotspot use. 2093 In "Improving Performance of TCP over Wireless Networks" [Bakshi], 2094 the authors focus on the performance of TCP over wireless networks 2095 with burst losses. The authors simulate performance of TCP Tahoe 2096 within ns-2, utilizing a two-state Markov model, representing "good" 2097 and "bad" states. Where the receiver is connected over a wireless 2098 link, the authors simulate the effect of an Explicit Bad State 2099 Notification (EBSN) sent by a base station unable to reach the 2100 receiver. In response to an EBSN, it is advocated that the existing 2101 retransmission timer be canceled and replaced by a new dynamically 2102 estimated timeout, rather than being backed off. In the simulations, 2103 EBSN prevents unnecessary timeouts, decreasing RTT variance and 2104 improving throughput. 2106 In "A Feedback-Based Scheme for Improving TCP Performance in Ad-Hoc 2107 Wireless Networks" [Chandran], the authors proposed an explicit Route 2108 Failure Notification (RFN), allowing the sender to stop its 2109 retransmission timers when the receiver becomes unreachable. On 2110 route reestablishment, a Route Reestablishment Notification (RRN) is 2111 sent, unfreezing the timer. Simulations indicate that the scheme 2112 significantly improves throughput and reduces unnecessary 2113 retransmissions. 2115 In "Analysis of TCP Performance over Mobile Ad Hoc Networks" 2116 [Holland], the authors explore how explicit link failure notification 2117 (ELFN) can improve the performance of TCP in mobile ad hoc networks. 2118 ELFN informs the TCP sender about link and route failures so that it 2119 need not treat the ensuing packet loss as due to congestion. Using 2120 an ns-2 simulation of TCP-Reno over 802.11 with routing provided by 2121 the Dynamic Source Routing (DSR) protocol, it is demonstrated that 2122 TCP performance falls considerably short of expected throughput based 2123 on the percentage of the time that the network is partitioned. A 2124 portion of the problem was attributed to the inability of the routing 2125 protocol to quickly recognize and purge stale routes, leading to 2126 excessive link failures; performance improved dramatically when route 2127 caching was turned off. Interactions between the route request and 2128 transport retransmission timers were also noted. Where the route 2129 request timer is too large, new routes cannot be supplied in time to 2130 prevent the transport timer from expiring, and where the route 2131 request timer is too small, network congestion may result. For their 2132 implementation of ELFN, the authors piggybacked additional 2133 information on an existing "route failure" notice (sender and 2134 receiver addresses and ports, the TCP sequence number) to enable the 2135 sender to identify the affected connection. Where a TCP receives an 2136 ELFN, it disables the retransmission timer and enters "stand-by" 2137 mode, where packets are sent at periodic intervals to determine if 2138 the route has been reestablished. If an acknowledgement is received 2139 then the retransmission timers are restored. Simulations show that 2140 performance is sensitive to the probe interval, with intervals of 30 2141 seconds or greater giving worse performance than TCP-Reno. The 2142 affect of resetting the congestion window and RTO values was also 2143 investigated. In the study, resetting congestion window to one did 2144 not have much of an effect on throughput, since the bandwidth/delay 2145 of the network was only a few packets. However, resetting the RTO to 2146 a high initial value (6 seconds) did have a substantial detrimental 2147 effect, particularly at high speed. In terms of the probe packet 2148 sent, the simulations showed little difference between sending the 2149 first packet in the congestion window, or retransmitting the packet 2150 with the lowest sequence number among those signalled as lost via the 2151 ELFNs. 2153 In "Improving TCP Performance over Wireless Links" [Goel], the 2154 authors propose use of an ICMP-DEFER message, sent by a wireless base 2155 station on failure of a transmission attempt. After exhaustion of 2156 retransmission attempts, an ICMP-RETRANSMIT message is sent. On 2157 receipt of an ICMP-DEFER message, the expiry of the retransmission 2158 timer is postponed by the current RTO estimate. On receipt of an 2159 ICMP-RETRANSMIT message, the segment is retransmitted. On 2160 retransmission, the congestion window is not reduced; when coming out 2161 of fast recovery, the congestion window is reset to its value prior 2162 to fast retransmission and fast recovery. Using a two-state Markov 2163 model, simulated using ns-2, the authors show that the scheme 2164 improves throughput. 2166 In "Explicit Transport Error Notification (ETEN) for Error-Prone 2167 Wireless and Satellite Networks" [Krishan], the authors examine the 2168 use of explicit transport error notification (ETEN) to aid TCP in 2169 distinguishing congestive losses from those due to corruption. Both 2170 per-packet and cumulative ETEN mechanisms were simulated in ns-2, 2171 using both TCP Reno and TCP SACK over a wide range of bit error rates 2172 and traffic conditions. While per-packet ETEN mechanisms provided 2173 substantial gains in TCP goodput without congestion, where congestion 2174 was also present, the gains were not significant. Cumulative ETEN 2175 mechanisms did not perform as well in the study. The authors point 2176 out that ETEN faces significant deployment barriers since it can 2177 create new security vulnerabilities and requires implementations to 2178 obtain reliable information from the headers of corrupt packets. 2180 A.4 Application Layer 2182 At the Application layer, the usage of "Link Down" indications has 2183 been proposed to augment presence systems. In such systems, client 2184 devices periodically refresh their presence state using application 2185 layer protocols such as SIMPLE [RFC3428] or XMPP [RFC3921]. If the 2186 client should become disconnected, their unavailability will not be 2187 detected until the presence status times out, which can take many 2188 minutes. However, if a link goes down, and a disconnect indication 2189 can be sent to the presence server (presumably by the access point, 2190 which remains connected), the status of the user's communication 2191 application can be updated nearly instantaneously. 2193 Appendix B - IAB Members at the time of this writing 2195 Bernard Aboba 2196 Loa Andersson 2197 Leslie Daigle 2198 Patrik Falstrom 2199 Bob Hinden 2200 Kurtis Lindqvist 2201 David Meyer 2202 Pekka Nikander 2203 Eric Rescorla 2204 Pete Resnick 2205 Jonathan Rosenberg 2206 Lixia Zhang 2208 Intellectual Property Statement 2210 The IETF takes no position regarding the validity or scope of any 2211 Intellectual Property Rights or other rights that might be claimed to 2212 pertain to the implementation or use of the technology described in 2213 this document or the extent to which any license under such rights 2214 might or might not be available; nor does it represent that it has 2215 made any independent effort to identify any such rights. Information 2216 on the procedures with respect to rights in RFC documents can be 2217 found in BCP 78 and BCP 79. 2219 Copies of IPR disclosures made to the IETF Secretariat and any 2220 assurances of licenses to be made available, or the result of an 2221 attempt made to obtain a general license or permission for the use of 2222 such proprietary rights by implementers or users of this 2223 specification can be obtained from the IETF on-line IPR repository at 2224 http://www.ietf.org/ipr. 2226 The IETF invites any interested party to bring to its attention any 2227 copyrights, patents or patent applications, or other proprietary 2228 rights that may cover technology that may be required to implement 2229 this standard. Please address the information to the IETF at ietf- 2230 ipr@ietf.org. 2232 Disclaimer of Validity 2234 This document and the information contained herein are provided on an 2235 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 2236 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 2237 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 2238 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 2239 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 2240 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 2242 Copyright Statement 2244 Copyright (C) The Internet Society (2005). This document is subject 2245 to the rights, licenses and restrictions contained in BCP 78, and 2246 except as set forth therein, the authors retain all their rights. 2248 Acknowledgment 2250 Funding for the RFC Editor function is currently provided by the 2251 Internet Society.