idnits 2.17.1 draft-dawkins-trigtran-framework-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 3 longer pages, the longest (page 4) being 59 lines == It seems as if not all pages are separated by form feeds - found 0 form feeds but 14 pages Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack a Security Considerations section. ** 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 separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** There are 7 instances of lines with control characters in the document. ** The abstract seems to contain references ([PILC]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == Line 30 has weird spacing: '...at http://ww...' -- 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.) -- Couldn't find a document date in the document -- date freshness check skipped. Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'RFC793' is mentioned on line 152, but not defined ** Obsolete undefined reference: RFC 793 (Obsoleted by RFC 9293) == Missing Reference: 'RFC2581' is mentioned on line 159, but not defined ** Obsolete undefined reference: RFC 2581 (Obsoleted by RFC 5681) == Unused Reference: 'BAR-BOF' is defined on line 595, but no explicit reference was found in the text == Unused Reference: 'CORSON' is defined on line 604, but no explicit reference was found in the text == Unused Reference: 'YEGIN' is defined on line 611, but no explicit reference was found in the text == Unused Reference: 'GURI' is defined on line 614, but no explicit reference was found in the text == Unused Reference: 'MANYFOLKS' is defined on line 619, but no explicit reference was found in the text == Unused Reference: 'RFC896' is defined on line 628, but no explicit reference was found in the text == Unused Reference: 'RFC792' is defined on line 631, but no explicit reference was found in the text == Unused Reference: 'RFC1016' is defined on line 634, but no explicit reference was found in the text == Unused Reference: 'RFC1009' is defined on line 638, but no explicit reference was found in the text == Unused Reference: 'RFC1812' is defined on line 641, but no explicit reference was found in the text == Unused Reference: 'RFC791' is defined on line 644, but no explicit reference was found in the text == Unused Reference: 'RFC1122' is defined on line 647, but no explicit reference was found in the text == Unused Reference: 'RFC1063' is defined on line 650, but no explicit reference was found in the text == Unused Reference: 'RFC1191' is defined on line 653, but no explicit reference was found in the text == Unused Reference: 'RFC1435' is defined on line 656, but no explicit reference was found in the text == Unused Reference: 'RFC2923' is defined on line 659, but no explicit reference was found in the text -- Possible downref: Non-RFC (?) normative reference: ref. 'BAR-BOF' -- Possible downref: Normative reference to a draft: ref. 'CORSON' == Outdated reference: A later version (-01) exists of draft-yegin-l2-triggers-00 -- Possible downref: Normative reference to a draft: ref. 'YEGIN' -- Possible downref: Normative reference to a draft: ref. 'GURI' -- Possible downref: Normative reference to a draft: ref. 'MANYFOLKS' -- Possible downref: Non-RFC (?) normative reference: ref. 'PILC' ** Obsolete normative reference: RFC 896 (Obsoleted by RFC 7805) ** Downref: Normative reference to an Unknown state RFC: RFC 1016 ** Obsolete normative reference: RFC 1009 (Obsoleted by RFC 1812) ** Obsolete normative reference: RFC 1063 (Obsoleted by RFC 1191) ** Downref: Normative reference to an Informational RFC: RFC 1435 ** Downref: Normative reference to an Informational RFC: RFC 2923 Summary: 15 errors (**), 0 flaws (~~), 23 warnings (==), 8 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Internet Draft Spencer Dawkins 2 Expires: August 2003 Cyneta Networks 3 Carl E. Williams 4 MCSR Labs 5 Alper E. Yegin 6 DoCoMo USA Labs 8 Framework and Requirements for TRIGTRAN 9 draft-dawkins-trigtran-framework-00.txt 11 Status of this Memo 13 This document is an Internet-Draft and is in full conformance 14 with all provisions of Section 10 of RFC2026. 16 Internet-Drafts are working documents of the Internet 17 Engineering Task Force (IETF), its areas, and its working 18 groups. Note that other groups may also distribute working 19 documents as Internet-Drafts. 21 Internet-Drafts are draft documents valid for a maximum of six 22 months and may be updated, replaced, or obsolete by other 23 documents at any time. It is inappropriate to use Internet- 24 Drafts as reference material or to cite them other than as 25 "work in progress." 27 The list of current Internet-Drafts can be accessed at 28 http://www.ietf.org/ietf/1id-abstracts.txt 29 The list of Internet-Draft Shadow Directories can be accessed 30 at http://www.ietf.org/shadow.html. 32 Conventions used in this document: 33 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL 34 NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and 35 "OPTIONAL" in this document are to be interpreted as described 36 in RFC-2119 [ ]. 38 Abstract 40 IETF-standardized unicast transport protocols have been 41 designed to allow two end points to maintain communications by 42 individually reacting to loss or degraded packet arrival times. 43 Historically, those protocols have assumed loss is congestive 44 and have reacted by decreasing the packet transmission rate to 45 ease congestion. There are a number of cases, however, where 46 these assumptions are incorrect, and one or more path segments 47 present losses due to intermittent connectivity, a high 48 uncorrected error rate, or the need for access path changes 49 ("hand-off"s). Previous work [PILC] has addressed these 50 conditions using end-to-end mechanisms. This draft examines the 51 use of an on-path signaling mechanisms capable of providing 52 advisory notifications for use in modifying the behavior of the 53 transport in order to better respond to actual network 54 conditions. This draft serves to create discussion in this area 55 as there are many ways to skin the cat. We are interested in 56 hearing about them through open discussion. 58 List of Abbreviations 60 TRIGTRAN Triggers for the Transport 61 AR Access Router 63 1. Introduction 65 IETF transport protocol development has been based on the 66 assumption that two communicating endpoints know more about 67 characteristics of the paths between these endpoints than any 68 single device within the network. Because IP datagrams can be 69 forwarded over a variety of paths between two endpoints, a 70 device within the network might have detailed knowledge of one 71 path, but typically does not have detailed knowledge of all 72 possible paths. 74 The scope of this work will focus on a framework for providing 75 information to the transport via triggers of connection path 76 characteristics. In particular, it is possible that a wireless 77 access device might provide information about the path in a 78 useful way because 80 (a) the wireless access device has detailed knowledge of a sub- 81 network link, and 83 (b) it can still communicate with one endpoint when a 84 problematic sub-network link stops working, or starts working, 85 or changes its characteristics in some interesting way. 87 The goal here is that changes in path characteristics, 88 especially in reachability, can be explicitly signaled 89 expeditiously, while still relying on transport 90 acknowledgements and timeouts. 92 If this goal is accepted, it may be broadened to include other 93 sub-network events, if these sub-network events are generic in 94 nature and accepted by the IETF community as a whole. 96 To further this goal this document will provide a basis of 97 understanding of the following: 99 - The nature of generic "transport triggers" 101 - Possible uses of "transport triggers" 103 - Mechanisms for signaling transport triggers to accessible 104 transport endpoints 106 - The architectural impact of this addition to the transport 107 layer 108 Although the need for this change is more obvious in a wireless 109 environment, we're also soliciting input from the rest of the 110 Internet community in these areas: 112 - Whether there are "transport triggers" applicable to many 113 sub-network types, beyond link up/link down 115 - Whether the use of "transport triggers" is worth the effort 116 of modifying existing transport protocols to make use of this 117 information 119 Why TRIGTRAN Isn't Fast Handoff 121 Transport triggers are similar to, but distinct from, similar 122 discussions on triggers in MOBILEIP and in IRTF's Routing 123 Research Group on micro-mobility. The primary difference is the 124 low latency and tight coupling required for fast handoff. It is 125 anticipated that the resulting model for defining transport 126 triggers will provide a framework for future trigger discussion 127 that are required for IP handoff protocols. 129 Why TRIGTRAN Isn't Wireless-only or TCP-only 131 Although TRIGTRAN is initially focusing on TCP connections over 132 wireless sub-network links, we note that SCTP transports often 133 have multiple wireline paths between two SCTP hosts for 134 reliability. We don't want to do anything in TRIGTRAN that 135 would prevent the use of TRIGTRAN as a notification mechanism 136 for SCTP switchover - so please keep us honest! 138 This document describes a general framework and provides for a 139 requirement list for the TRIGTRAN architecture in terms of 140 notification events and protocol considerations. In the next 141 section the authors provide a write-up on TRIGTRAN 142 justification. This content may well end up in the problem 143 space draft but the authors would like to include this 144 discussion here for purposes of the BOF that is planned at IETF 145 San Francisco. 147 2. Justification for TRIGTRAN 149 The variety of devices accessing the Internet, and the variety 150 of access links they are using, continues to increase. At least 151 some of these links exhibit characteristics that cause some 152 Internet protocols, especially TCP [RFC793], to perform poorly. 154 Among these characteristics are: 156 1. Intermittent connectivity 157 2. Access path changes ("hand-offs") 158 3. High uncorrected error rate 159 For example, TCP congestion control [RFC2581] performs well 160 over paths that lose traffic primarily because of congestion 161 and buffer exhaustion, but performs poorly when TCP connections 162 traverse links with high uncorrected error rates. Sending TCPs 163 spend an inordinate amount of time waiting for acknowledgements 164 that will not arrive, and then, although these losses are not 165 due to congestion-related buffer exhaustion, the sending TCP 166 transmits with a substantially reduced congestion window as it 167 probes the network to determine its "safe" traffic level. 169 The root cause here is that TCP sees only one (implicit) signal 170 about path conditions - packet loss - and can interpret this 171 signal in only one way. The most conservative assumption is 172 that packet loss is due to congestion, and for most of TCP's 173 history, this conservative assumption was correct and 174 sufficient. When transports traverse paths that include 175 intermittent connectivity or other non-congestion "challenges", 176 additional detection mechanisms are required. 178 TRIGTRAN ("Triggers for Transport") is a follow-up to the body 179 of work done in the IETF's Performance of Link 180 Characteristics(PILC) working group [PILC]. In PILC we were 181 able to examine the specific TCP mechanisms that are 182 problematic in environments with "challenged" links, and 183 develop Best Current Practice specifications describing what 184 can be done to mitigate these problems without introducing 185 intermediate devices into the connection. PILC established the 186 limits of "end to end" mechanisms with "challenged" links. With 187 TRIGTRAN we are looking at advisory explicit notification 188 ("hints") being initiated from an edge router to endpoint 189 transport implementations across the Internet. 191 3. Strawman Framework 193 TRIGTRAN is focusing specifically on the case of problematic 194 access links, because so many problematic links fall into this 195 category (although not all problematic links are access links), 196 and because this is the simplest useful case. More complex 197 topologies are outside the scope of TRIGTRAN, at least for now. 199 In a nutshell, the minimal TRIGTRAN architecture looks like: 201 +------+ +-----------------+ (Internet +------+ 202 | Host | | TRIGTRAN Router | goes | Host | 203 +------+ +-----------------+ here) +------+ 204 X X 205 Sub-network Event ------------------> Notifies Transport 206 Here Here 208 The critical feature here is that the host receiving a TRIGTRAN 209 trigger is across an arbitrary network topology from the 210 TRIGTRAN edge router sending the trigger. The host receiving 211 the trigger then takes some transport-level action (sending a 212 packet, retransmitting a packet, waiting for some period of 213 time to transmit a packet, etc). 215 The transports would figure out "most events" eventually, given 216 enough time (i.e., round trip times). For instance, TCP is good 217 at figuring at bandwidth changes, but not as good at detecting 218 a remote link transitioning to the "up" state after a 219 retransmission timeout. Eventually, a backed-off RTO timer will 220 fire, and the now-accessible receiver will acknowledge the next 221 (successful) retransmission, but the sender and receiver will 222 be waiting when they could be communicating. 224 TRIGTRAN can give the host receiving triggers hints that it 225 might reattempt transmission, without waiting a complete RTO 226 interval. TRIGTRAN is intended to provide network-based hints 227 that clue the transport in more quickly (where "quickly" is 228 measured in RTTs, not in milliseconds). 230 TRIGTRAN triggers are advisory in nature - they do not replace 231 transport-level mechanisms (in the case of TCP, the receiver's 232 ACK stream). Indeed, the TRIGTRAN architecture is a continuum 233 of an existing body of work based on the principle that more 234 and more often the network can clue a transport in on what is 235 going on. Previous examples of "network-based clues" include 236 ICMP Source Quench and Explicit Congestion Notification (ECN). 237 These methods are a way for the transport to obtain more clues 238 from the network but without relying exclusively on that 239 information to function properly. 241 4. TRIGTRAN Protocol Principles/Considerations 243 * Transports can request trigger coverage from any adjacent access 244 router, although only TRIGTRAN-aware access routers will provide trigger 245 coverage. The host making this request is called the "TRIGTRAN 246 Initiator". 248 * Correspondent hosts will request desired trigger notifications 249 explicitly (they will not be sent to a correspondent host without prior 250 arrangement). 252 * Trigger coverage requests and notification requests will be 253 piggybacked on existing traffic ("setting a bit", not injecting new 254 packets). The notifications themselves will be injected, of course. 256 * A TRIGTRAN-capable access router will inject trigger notifications. 257 The exact structure of the notification is TBD. 259 * Triggers are per-host-pair over a specified interface - if a TRIGTRAN 260 Initiator requests trigger coverage for any packets destined for a 261 correspondent host, and the correspondent host expresses interest in 262 receiving triggers, the TRIGTRAN-capable access router will send a 263 single notification to the correspondent host. 265 * No reliability mechanism for triggers is defined. If a single trigger 266 is lost for an event of interest to a transport, the transport will 267 respond to the event using end-to-end mechanisms. 269 * TRIGTRAN registrations can be installed in one round trip (from the 270 point of view of the TRIGTRAN Initiator). 272 * TRIGTRAN registrations install "soft state". TRIGTRAN Initiators must 273 repeat coverage requests periodically, and correspondent hosts 274 requesting trigger notifications must repeat this request periodically. 275 The periodicity for these requests is TBD, but should be on 276 the order of five minutes. The TRIGTRAN-capable access router will 277 expire these requests after three of these time periods have elapsed. 279 * TRIGTRAN should work even if TRIGTRAN-capable access routers serve 280 both hosts. Of course, each TRIGTRAN-capable access router will send 281 triggers to the "correspondent host" adjacent to the other access 282 router. 284 * TRIGTRAN is not a substitute for end-to-end mechanisms. TRIGTRAN 285 triggers must be advising the correspondent host on something that it 286 will figure out eventually without triggers. 288 * TRIGTRAN is per-transport-protocol. With two different transports 289 running over some link, if both transports have requested trigger 290 coverage, two separate triggers will be sent for a particular event. 292 * TRIGTRAN operations are not defined for an IP multicast address. 294 * Protocol notification message must contain enough information to 295 identify per-host-pair. 297 * Trigger notifications are injected when a specified event is detected 298 by the link-layer implementation on a TRIGTRAN-capable router for a 299 specified link. 301 * A correspondent node may ignore notifications even though it may have 302 requested trigger coverage for a TRIGTRAN Initiator. 304 * "Soft-state" for a per-host-pair should exist only at the adjacent 305 TRIGTRAN-capable router only. 307 * When TRIGTRAN notifications and end-to-end mechanisms are in conflict 308 the latter will take precedence over notifications. 310 * Triggers should be link-layer independent. 312 * Each TRIGTRAN notification will carry information for one event only. 313 The correspondent node should be able to determine by an appropriate 314 identifier field what event has taken place. 316 5. Trigger Events/notification 318 Presented in this section is an enumeration of the various triggers that 319 encompass the framework. Motivation and suggested responses are 320 provided for each trigger notification. This is a preliminary list of 321 notifications and their associated suggested responses. 323 These triggers were identified during our work in PILC as things 324 transports would WANT to know, but that are difficult to discover using 325 end-to-end signaling. For instance, "Connectivity Interrupted" can't be 326 signaled end-to-end, by definition. 328 Trigger: Connectivity Interrupted 330 Motivation: 332 When a link goes down TCP RTO exponential backoff occurs. 333 The sender will eventually "give up", assuming that 334 the receiving TCP (and perhaps the receiving host) will 335 not recover. 337 Suggested Response: 339 The correspondent transport may choose to perform normal RTO 340 processing for a longer period of time (in Solaris TCP, this would 341 be a longer tcp_ip_abort_interval). 343 Note that a TCP that continues to receive ACKs should ignore 344 this trigger. 346 Trigger: Connectivity Restored 348 Motivation: 350 When a link returns to working state, an other-end TCP 351 may have experienced RTO, and may be waiting to attempt 352 retransmission. Since TCP backs off exponentially (up to 353 64 seconds between retransmission attempts, in common 354 implementations), the receiver will be waiting unnecessarily. 356 Suggested Response: 358 Attempt single-packet probe immediately, if successful, 359 resume perform normal operation. 361 Note that this attempt should be made only once per 362 Connectivity Interrupted incident (clear when end-to-end ACKs 363 have been received during retransmission). 365 Trigger: Packets Discarded by subnetwork, not lost due to congestion 367 Motivation: 369 In some wireless handoff scenarios, a subnetwork may explicitly 370 discard packets at the "old" base station. In these cases, the 371 application will either Fast Retransmit/Fast Recover or RTO/Slow 372 Start (depending on whether additional ACKs are received for packets 373 delivered by the new base station). These losses will reduce the 374 congestion window, although they are not caused by congestion. 376 Suggested Response: 378 Retransmit without performing congestion avoidance. Note that this 379 attempt should be made only once per loss event (in the document 380 draft-allman-tcp-sack-13.txt, additional notifications would be 381 ignored until the "scoreboard" data structure is emptied). 383 6. Security assessment and considerations for the TRIGTRAN framework 385 TRIGTRAN mechanisms provide explicit notifications from access routers 386 to endpoint transport implementations that may be across the Internet. 388 The critical feature here is that the host receiving a TRIGTRAN trigger 389 is across an arbitrary network topology from the access router sending 390 the trigger, and the host receiving the trigger has no previous trust 391 relationship with the access router. The host receiving the trigger will 392 take some transport-level action (sending a packet, retransmitting a 393 packet, waiting for some period of time to transmit a packet, etc.). 395 The transports would "figure out an event" eventually, given enough 396 time. TRIGTRAN is intended to provide network-based hints that clue the 397 transport in more quickly (where "quickly" is measured in RTTs, not in 398 milliseconds). Since "link down" will probably be one of the triggers, 399 end-to-end mechanisms cannot be used to send explicit notifications 400 (since one of the ends isn't accessible). 402 A security assessment for TRIGTRAN amounts to evaluating what impact a 403 forged trigger can have on a host that uses the hints to deal with the 404 respective event. For example, we don't want TRIGTRAN to provide a 405 mechanism for denial of service attacks, etc. (this should be obvious, 406 but let's make it explicit). 408 TRIGTRAN triggers are advisory in nature - they do not replace 409 transport-level mechanisms (in the case of TCP, the receiver's ACK 410 stream). If a correspondent host gets a forged "Connectivity 411 Interrupted" trigger, but continues to receive ACKs from the actually- 412 reachable TRIGTRAN Initiator, the reasonable action is to ignore the 413 trigger, not the ACKs. If a correspondent host gets a forged 414 "Connectivity Restored" trigger, but does not receive ACKs from the 415 actually-unreachable receiver, the transport would take its normal 416 action for an unresponsive receiver (in the case of TCP, this would be 417 RTO, retransmission, and slow start). The correspondent host can use 418 existing transport-level mechanisms to determine the validity of the 419 trigger. Because TRIGTRAN triggers are advisory the correspondent host 420 isn't required to act as if the events are real. Thus, we don't think a 421 security association is required between the TRIGTRAN router and the 422 correspondent host receiving triggers. If one is present, fine, but it's 423 not required. 425 The alternative, requiring the host to establish trust relationships 426 with arbitrary routers in other administrative domains in order to 427 receive triggers, seems to be overkill in this situation. If TRIGTRAN 428 triggers overrode end-to-end mechanisms, a trust relationship would 429 clearly be required. 431 We note that, in the absence of trust relationships between TRIGTRAN 432 Initiators and TRIGTRAN routers, it's possible for forged packets to 433 fill up the TRIGTRAN router's "soft state" notification table. If we are 434 true to our self-imposed restriction that all triggers would be advisory 435 in nature, a denial-of-service attack would have the effect of disabling 436 TRIGTRAN, and normal end-to-end mechanisms would prevail - as they do 437 today. 439 Our self-imposed limit to access routers for our initial work may help 440 here - the access router would have some ability to "ingress-filter" 441 trigger coverage requests, as edge routers filter on IP address prefixes 442 today. 444 7. Why TRIGTRAN is Not Doomed 446 At the IETF 55 TRIGTRAN BoF, Sally Floyd presented a number of 447 questions for TRIGTRAN. One of the most relevant was "ICMP 448 Source Quench failed. P-MTU Discovery failed. Why will TRIGTRAN 449 be different?" 451 This question needs to be answered. Our crack at an answer 452 follows. 454 7.1 Why TRIGTRAN Is Not Doomed (Source Quench) 456 RFC 792 describes the Internet Control Management Protocol 457 (ICMP). ICMP includes a message type called "Source Quench" 458 (Type 4). Source Quench was intended to provide "back pressure" 459 when a gateway discards an incoming IP datagram because no 460 buffers are available. The message is sent to the Source IP 461 Address carried in the discarded IP datagram. Conceptually, a 462 host receiving an ICMP Source Quench message would slow down 463 its sending rate until it stopped receiving ICMP Source Quench 464 messages, and then gradually increase its sending rate. 466 The original specification did not provide quantitative 467 guidance on HOW MUCH to slow down. RFC 1016 proposed a formula 468 Source Quench Induced Delay ("SQuID"), but this RFC was 469 published six years after RFC 792, and defined itself as a 470 "crazy idea". A better characterization might have been 471 "embryonic", reflecting an unsophisticated awareness of 472 congestion - TCP didn't include Slow Start/Congestion Avoidance 473 until a couple of years later. 475 The original specification allowed gateways to generate an ICMP 476 Source Quench for every datagram dropped, but did not require 477 gateways to send them at all. RFC 1009 ("Requirements for 478 Internet Gateways") required gateways to include the capability 479 to send rate-limited ICMP Source Quench messages, but when it 480 was updated as RFC 1812 ("Requirements for IP Version 4 481 Routers"), this requirement was dropped in favor of deprecating 482 ICMP Source Quench ("Gateways SHOULD NOT"). The reasons given 483 for this about-face included: 485 - ICMP Source Quench affected only packets sent from the host 486 generating the "over the top" packet, so did not provide a fair 487 mechanism for hosts sharing overcommitted network paths, and 489 - ICMP Source Quench added (reverse-direction) packets to the 490 network during congestion events, and used router memory and 491 processing power to construct and send ICMP Source Quenches 492 during congestion events. 494 The overwhelming problem with ICMP Source Quench wasn't that it 495 required gateways to send a "trigger" to hosts - it had 496 problems with unfairness and inefficiency. Since the 497 specifications omitted critical details and didn't require this 498 functionality, hosts were forced to add end-to-end congestion 499 avoidance at the transport layer, anyway. 501 This experience isn't terrifically relevant to TRIGTRAN, 502 because standards-based recommendations have vacillated from 503 MAY to SHOULD NOT - hardly an overwhelming motivator to 504 deployment! 506 7.2 Why TRIGTRAN is Not Doomed (Path Maximum Transmission Unit 507 Discovery) 509 RFC 791 ("Internet Protocol") allows IP packets of up to 65,535 510 octets, but subnetworks typically don't support frames with a 511 payload this large. A host can know the Maximum Transmission 512 Unit size for its local subnetwork, but can't be sure that a 513 path across multiple subnetworks will support a larger MTU 514 without IP fragmentation. RFC 1122 ("Requirements for Internet 515 Hosts -- Communication Layers") specified that IP 516 implementations "SHOULD" use an MTU of 576 or less to 517 communicate with hosts on a different network, unless the 518 implementation "knew" that the path supported larger MTUs. 520 RFC 1063 ("IP MTU Discovery Options") and its successor RFC 521 1191 ("Path MTU Discovery") described a mechanism to gain this 522 knowledge. An IP implementation wishing to use large MTUs sent 523 a packet of the desired size into the network with the "Don't 524 Fragment" bit set. If the packet encountered a subnetwork that 525 didn't support the desired MTU size, the gateway for that link 526 discarded the packet, and reported an ICMP ICMP Destination 527 Unreachable error with a code meaning "fragmentation needed and 528 DF set", (also described as "Datagram Too Big"), and an 529 indication of the bottleneck MTU size, stored in a previously- 530 unused ICMP header field. To avoid requiring a "flag day" for 531 P-MTU discovery, hosts were required to accept "Datagram Too 532 Big" errors that didn't include the bottleneck MTU size, and to 533 either fall back to 576 bytes or search with a new, lower P-MTU 534 "guess", thus accommodating gateways that hadn't been updated. 536 As P-MTU Discovery was deployed, another "discovery" happened. 537 As described in RFC 1435 ("IESG Advice from Experience with 538 Path MTU Discovery"), "some vendors have added to their routers 539 the ability to disable ICMP messages generated by the router". 540 The effect was that of a "black hole" - the router dropped the 541 "too big" datagram, but did not send any notification to the 542 sending host that this was happening. Further deployment 543 experience led to RFC 2923 ("TCP Problems with Path MTU 544 Discovery"), pointing out that "black holing" was still 545 happening, and that routers were configured this way for a 546 variety of reasons, including a misguided attempt to shut down 547 ICMP messages crossing firewalled administrative domains. 548 Procedures for hosts encountering "black holes" were described, 549 but guessing too high on a "black-holed" path still leads to 550 delays of several seconds as the host TCP implementation uses 551 timeouts to detect failure and "falls back" to 576 bytes. 553 The Internet experience with P-MTU Discovery is more relevant 554 to TRIGTRAN if TRIGTRAN considers ICMP messages as a trigger 555 signal mechanism, although the "black holing" problem is less 556 severe because TRIGTRAN triggers are advisory in nature. End- 557 to-end mechanisms will lead to the same result after some 558 delay. 560 The history of P-MTU Discovery is useful as a reminder that 561 TRIGTRAN triggers must traverse firewalls, no matter what 562 mechanism is defined to transport them. 564 8. Summary 566 While the draft is initially focusing on wireless links, other 567 link types (i.e. modems) are of importance and will be taken into 568 account. Moving forward with this work an eye on non-wireless links 569 will also be taken into account. 571 There are many ways to skin the cat and we are interested in hearing 572 about alternatives. The draft was put together as the output from the 573 IETF TRIGTRAN BOF in Atlanta 2002. This is a preliminary writeup whose 574 purpose is to facilitate the discussion of a second BOF in San Francisco 575 IETF in March 2003. The preliminary thinking in this draft would 576 serve to create additional discussion highlighting issues and hopefully 577 asking the right questions. 579 9. Acknowledgements 581 Thanks to Ted Hardie for coming up with a good abstract and other 582 comments on the draft. Thanks to Sally Floyd for numerous 583 comments and questions raised at the IETF Atlanta BOF on TRIGTRAN 584 that structured much of the text for this draft as well as her 585 insightful review of this draft. Thanks to Mark Allman, Aaron 586 Falk, and John Wroclawski for their inputs on this draft and 587 contributions on the mailing list on this subject matter. Also, 588 thanks to those who have contributed to the IETF Atlanta BOF 589 discussion and comments on the TRIGTRAN mailing list. Special 590 thanks to Allison Mankin for her vision and leadership on dealing 591 with this problem space. 593 10. References 595 [BAR-BOF] Notes from L2 Triggers meeting (PILC mailing 596 list posting), Aaron Falk and Carl E. Williams, April 597 2002, available from 598 http://pilc.grc.nasa.gov/list/archive/1837.html. 600 Several of the following drafts describe lower-latency 601 triggers intended for Mobile IP fast handoff. TRIGTRAN 602 reuses a number of concepts from this work. 604 [CORSON] A Triggered Interface (work in progress), Scott 605 Corson, May 2002, draft-corson-triggered-00.txt 607 [WILLIAMS]Problem Statement for Link-layer Triggers work 608 (work in progress), Carl Williams, Alper E. Yegin, and 609 James Kempf, June 2002, draft-williams-l2-probstmt-00.txt 611 [YEGIN] Link-layer Triggers Protocol (work in progress), 612 Alper Yegin, June 2002, draft-yegin-l2-triggers-00.txt 614 [GURI] Layer-2 API for Paging (expired work in 615 progress), Sridhar Gurivireddy, Behcet Sarikaya, Vinod 616 Choyi, and Xiafeng Xu, October 2001, 617 draft-guri-seamoby-paging-triggers-00.txt 619 [MANYFOLKS] Supporting Optimized Handover for IP Mobility : 620 Requirements for Underlying Systems (work in progress), 621 Alper Yegin (editor), June 2002, 622 draft-manyfolks-l2-mobilereq-02.txt 624 [PILC] Performance Implications of Link Characteristics 625 IETF Working Group 626 http://www.ietf.org/html.charters/pilc-charter.html 628 [RFC896] Congestion Control in IP/TCP Internetworks, 629 IETF RFC 896, January 1984, John Nagle. 631 [RFC792] Internet Control Message Protocol, IETF RFC 792, 632 September 1981, Jon Postel. 634 [RFC1016] Something a Host Could do with Source Quench: The 635 Source Quench Introduced Delay (SQuID), IETF RFC 1016, 636 July 1987, Jon Postel. 638 [RFC1009] Requirements for Internet Gateways, 639 IETF RFC 1009, R.Braden and Jon Postel, June 1987. 641 [RFC1812] Requirements for IP version 4 Routers, 642 IETF RFC 1812, Editor: Fred Baker, 1995. 644 [RFC791] Internet Protocol, IETF RFC 791, September 1981, 645 Editor: Jon Postel. 647 [RFC1122] Requirements for Internet Hosts ? Communications 648 Layers, IETF 1122, October 1989, Editor: R. Braden. 650 [RFC1063] IP MTU Discovery Options, IETF RFC 1063, 651 July 1988, J. Mongul, C. Kent, C. Partridge, K. McCloghrie. 653 [RFC1191] PATH MTU Discovery, IETF RFC 1191, 654 November 1990, J. Mogul, S. Deering. 656 [RFC1435] IESG Advice from Experience with Path 657 MTU Discovery, March 1993, FTP Software. 659 [RFC2923] TCP Problems with PATH MTU Discovery, 660 September 2000, K. Lahey. 662 11. Contact Information 664 Spencer Dawkins 665 Cyneta Networks 666 1201 North Bowser Road Phone: 1-469-385-2484 667 Suite 100 668 Richardson, Texas 75081 669 USA Email: sdawkins@cynetanetworks.com 671 Carl E. Williams 672 MCSR Labs 673 3790 El Camino Real 674 Palo Alto, CA 94306 Phone: 1-650-279-5903 675 USA Email: carlw@mcsr-labs.org 677 Alper E. Yegin 678 DoCoMo USA Labs 679 181 Metro Drive, Suite 300 Phone: +1 408 451 4743 680 San Jose, CA 95110 Fax: +1 408 451 1090 681 USA Email: alper@docomolabs-usa.com