idnits 2.17.1 draft-scharf-tcpm-flow-control-quick-start-00.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 18. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 565. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 576. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 583. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 589. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust Copyright Line does not match the current year -- 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 (July 7, 2008) is 5764 days in the past. Is this intentional? Checking references for intended status: Experimental ---------------------------------------------------------------------------- ** Obsolete normative reference: RFC 793 (Obsoleted by RFC 9293) ** Obsolete normative reference: RFC 1323 (Obsoleted by RFC 7323) ** Obsolete normative reference: RFC 2581 (Obsoleted by RFC 5681) Summary: 4 errors (**), 0 flaws (~~), 1 warning (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group M. Scharf 3 Internet-Draft University of Stuttgart 4 Intended status: Experimental S. Floyd 5 Expires: January 8, 2009 ICIR 6 P. Sarolahti 7 Nokia Research Center 8 July 7, 2008 10 TCP Flow Control for Fast Startup Schemes 11 draft-scharf-tcpm-flow-control-quick-start-00.txt 13 Status of this Memo 15 By submitting this Internet-Draft, each author represents that any 16 applicable patent or other IPR claims of which he or she is aware 17 have been or will be disclosed, and any of which he or she becomes 18 aware will be disclosed, in accordance with Section 6 of BCP 79. 20 Internet-Drafts are working documents of the Internet Engineering 21 Task Force (IETF), its areas, and its working groups. Note that 22 other groups may also distribute working documents as Internet- 23 Drafts. 25 Internet-Drafts are draft documents valid for a maximum of six months 26 and may be updated, replaced, or obsoleted by other documents at any 27 time. It is inappropriate to use Internet-Drafts as reference 28 material or to cite them other than as "work in progress." 30 The list of current Internet-Drafts can be accessed at 31 http://www.ietf.org/ietf/1id-abstracts.txt. 33 The list of Internet-Draft Shadow Directories can be accessed at 34 http://www.ietf.org/shadow.html. 36 This Internet-Draft will expire on January 8, 2009. 38 Abstract 40 This document describes extensions for the flow control of the 41 Transmission Control Protocol (TCP) that avoid interactions with fast 42 startup congestion control mechanisms, in particular the Quick-Start 43 TCP extension. Quick-Start is an optional TCP extension that allows 44 to start data transfers with a large congestion window, using 45 feedback of the routers along the path. This can avoid the time 46 consuming Slow-Start, provided that the TCP flow control is not a 47 limiting factor. 49 There are two potential interactions between the TCP flow control and 50 congestion control schemes without the standard Slow-Start: First, 51 receivers might not allocate a sufficiently large buffer space after 52 connection setup, or they may advertise a receive window implicitly 53 assuming the Slow-Start behavior on the sender side. This document 54 therefore provides guidelines for buffer allocation in hosts 55 supporting the Quick-Start extension. Second, the TCP receive window 56 scaling mechanism can prevent fast startups immediately after the 57 initial three-way handshake connection setup. This document 58 describes a simple solution to overcome this problem. 60 Table of Contents 62 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 63 2. Requirements Notation . . . . . . . . . . . . . . . . . . . . 4 64 3. Receive Buffer Dimensioning . . . . . . . . . . . . . . . . . 4 65 3.1. Background . . . . . . . . . . . . . . . . . . . . . . . . 4 66 3.2. Recommendations for Buffer Dimensioning with 67 Quick-Start . . . . . . . . . . . . . . . . . . . . . . . 4 68 4. Receive Window Scaling Issues . . . . . . . . . . . . . . . . 5 69 4.1. Background . . . . . . . . . . . . . . . . . . . . . . . . 5 70 4.2. Interaction Problem . . . . . . . . . . . . . . . . . . . 6 71 4.3. Proposed Solution . . . . . . . . . . . . . . . . . . . . 6 72 4.4. Deployment Considerations . . . . . . . . . . . . . . . . 8 73 5. Security Considerations . . . . . . . . . . . . . . . . . . . 9 74 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 75 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 9 76 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 10 77 8.1. Normative References . . . . . . . . . . . . . . . . . . . 10 78 8.2. Informative References . . . . . . . . . . . . . . . . . . 10 79 Appendix A. Applicability to Other Proposals . . . . . . . . . . 11 80 Appendix B. Alternative Solutions . . . . . . . . . . . . . . . . 11 81 Appendix C. Document Revision History . . . . . . . . . . . . . . 12 82 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 12 83 Intellectual Property and Copyright Statements . . . . . . . . . . 13 85 1. Introduction 87 The Transmission Control Protocol (TCP) [RFC0793] realizes both flow 88 control and congestion control. The TCP flow control is a receiver- 89 driven mechanism that informs the sender about the available receive 90 buffer space and limits the maximum amount of outstanding data. In 91 general, flow control and congestion control are independent 92 mechanisms, and the allocation of receive buffer space is up to the 93 receiving network stack only. But if the TCP connection spans a path 94 with a large bandwidth-delay product (BDP), both congestion and 95 receive window should have large values in order to achieve good TCP 96 performance (see [RFC2488],[RFC3481]). This results in some overlap 97 of flow control and congestion control. 99 A fast startup scheme, which speeds up data transfers by not using 100 the standard Slow-Start mechanism [RFC2581], can suffer from further 101 interactions between the TCP flow control and congestion control. 102 While not being appropriate for the global Internet, such a fast 103 startup congestion control could be deployed for instance in 104 controlled environments. The experimental Quick-Start TCP extension 105 [RFC4782] is currently the only specified TCP extension that realizes 106 a fast startup. This is why this document only considers Quick- 107 Start. However, as discussed in Appendix A, interactions between the 108 TCP flow control and congestion control mechanisms could also arise 109 if a fast startup was realized by other means. 111 With Quick-Start, TCP hosts can request permission from the routers 112 along a network path to send at a higher rate than allowed by the 113 default TCP congestion control, in particular during connection setup 114 or after longer idle periods. The explicit router feedback avoids 115 the time-consuming capacity probing by the TCP Slow-Start and can 116 significantly improve transfer times over paths with a high 117 bandwidth-delay product [SAF07]. 119 The usage of a fast startup significantly changes the TCP behavior 120 during connection setup, since a sender can use large congestion 121 windows immediately after connection setup. Concerning the flow 122 control, these large windows raise two questions: First, what 123 receiver buffer allocation strategies should be used? And second, 124 how to appropriately signal large windows? This document addresses 125 these issues and shows that fast startup schemes require special 126 mechanisms in both cases. The document thereby supplements the 127 Quick-Start TCP specification [RFC4782], where flow control issues 128 have not been addressed in detail. 130 The rest of this document is structured as follows: First, the 131 question of receive buffer allocation in combination with Quick-Start 132 is addressed and dimensioning guidelines are provided. And second, a 133 usage of the receive window scaling mechanism [RFC1323] is specified, 134 which is required to fully benefit from Quick-Start when the Quick- 135 Start request is used in the initial segment. 137 2. Requirements Notation 139 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 140 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 141 document are to be interpreted as described in [RFC2119]. 143 3. Receive Buffer Dimensioning 145 3.1. Background 147 According to [RFC2581], a TCP sender can transmit up to the minimum 148 of the congestion window and the receive window (also called 149 receiver's advertised window). Several factors can have an impact on 150 the value of the receive window: On the one hand, hosts with a 151 potentially high number of TCP connections need to optimize their 152 buffer and memory usage to be able to serve a maximum possible number 153 of TCP connections. On the other hand, a receiver that wants to use 154 the available bandwidth should advertise a receive window that is big 155 enough to allow an efficient utilization of the connection path. 156 Finding a fixed receive buffer size that is optimal between these two 157 goals is difficult. 159 This is why many modern TCP implementations use an intelligent 160 dynamic buffer management. There are different auto-tuning 161 techniques and heuristics [Dun06] designed to prevent the receive 162 window from limiting the data rate at the sender. An implementation 163 using receive window auto-tuning is described for instance in [SB05]. 164 A common characteristic of most of these buffer allocation strategies 165 is that they initially advertise a rather small receive window. The 166 more data arrives, the more buffer is advertised to the corresponding 167 connection. This behavior is reasonable if the sender uses the 168 standard Slow-Start algorithm and thus starts with a small congestion 169 window anyway. However, when a fast startup shall be used, the 170 receiver must be ready to buffer a large amount of data immediately 171 after the connection setup. 173 3.2. Recommendations for Buffer Dimensioning with Quick-Start 175 A network stack that supports the Quick-Start TCP extension should 176 apply the following guidelines for receive buffer allocation, in 177 addition to the normal buffer management principles: 179 When a host receives and approves a Quick-Start request, it SHOULD 180 announce a receive window that is large enough so that a potential 181 Quick-Start data transfer can start with a high sending window. If 182 buffer size auto-tuning is used, it SHOULD be ensured that a 183 sufficiently high initial receive window is announced. The handling 184 of buffer space upon arrival of a Quick-Start request SHOULD be 185 configurable by the corresponding application. 187 The TCP host could estimate the required buffer space as the product 188 of the approved Quick-Start rate and the round-trip time, and 189 advertise a receive window based on this required buffer space. This 190 receive window should allow the other TCP host to fully use the 191 approved Quick-Start Request. If the TCP host doesn't know the 192 round-trip time, the TCP host could use an estimate of the round-trip 193 time in calculating the required buffer space. For instance, the 194 buffer dimension could be done for a configurable "worst-case" RTT 195 such as 500 ms. Alternately, the TCP host could base the advertised 196 receive window on the available buffer space, without calculating the 197 buffer space required for the other TCP host to fully use the 198 approved Quick-Start Request. 200 4. Receive Window Scaling Issues 202 4.1. Background 204 The TCP header specified in [RFC0793] uses a 16 bit field to report 205 the receive window size to the sender. This effectively limits the 206 sending window to 64 KB. To circumvent this limitation, the "Window 207 Scale" TCP extension [RFC1323] defines an implicit scale factor, 208 which is used to multiply the window size value found in a TCP header 209 to obtain a 32 bit window size. If enabled, the scale factor is 210 announced during connection setup by the "Window Scale" TCP option in 211 and segments. 213 In general, using receive window scaling is highly beneficial for TCP 214 connections over path with a large bandwidth-delay product 215 [RFC2488],[RFC3481]. Otherwise, the path capacity cannot fully be 216 utilized by TCP. Quick-Start TCP can significantly speed up data 217 transfers over such paths [RFC4782],[SAF07]. As a consequence, a 218 host supporting Quick-Start should enable receive window scaling 219 according to [RFC1323]. If Quick-Start is used in the initial three- 220 way handshake, the minimum required scaling factor may be obtained 221 from the required receive buffer space, which can be approximated as 222 described in the previous section. 224 4.2. Interaction Problem 226 A problem arises when the Quick-Start mechanism is used within the 227 three-way handshake, and the Quick-Start request is added to the 228 initial segment: In this scenario, if the Quick-Start request 229 is approved by the routers along the path, the receiver echoes back 230 the Quick-Start response in the segment. This process is 231 illustrated in [RFC4782]. Upon reception of the with the 232 Quick-Start response, the sender can set the congestion window to the 233 determined value so that it can immediately start to send with the 234 approved data rate. 236 However, [RFC1323] defines that the "Window field in a SYN (i.e., a 237 or ) segment itself is never scaled." This means that 238 the maximum receive window that can be signaled to the sender in the 239 is 64 KB. As a consequence, the TCP flow control will 240 prevent the TCP sender from having more than 64 KB of outstanding 241 data, even if the receiver has much more free buffer, and the Quick- 242 Start feedback allows a much larger congestion window. 244 This effect essentially limits the maximum amount of data sent by 245 Quick-Start to 64 KB, when the sender sends the Quick-Start request 246 in the initial segment. Also, the congestion window after 247 quiting the Quick-Start rate pacing phase is at most 64 KB, as the 248 congestion window is set to the amount of data that has actually been 249 sent during the rate pacing phase. This is an undesirable 250 restriction for the Quick-Start mechanism, even if 64 KB is still 251 much more than the initial congestion window in Slow-Start that is 252 allowed by [RFC3390]. 254 This issue only occurs when Quick-Start is used in the three-way TCP 255 connection setup procedure, and only in the direction of the 256 connection originator to the acceptor. Still, this case is one of 257 the planned usage scenarios for the Quick-Start TCP extension. 259 4.3. Proposed Solution 261 The limitation imposed by the window scaling could be addressed in 262 different ways. This document proposes the following solution: If 263 necessary, the TCP host SHOULD send a scaled receive window in a 264 separate packet following the packet. 266 This means that when a host receives a segment with a Quick- 267 Start option, it processes the option as described in [RFC4782]. 268 Provided that the host has Quick-Start support enabled, the Quick- 269 Start response is echoed back in the segment. As 270 explained, this segment cannot announce receive windows larger than 271 64 KB. If the receiver allocates a buffer space larger than 64 KB, 272 an additional empty segment (without flag) SHOULD be sent after 273 the segment, in order to announce the true receive window. 274 The resulting message flow is depicted in Figure 1. 276 Sender Routers (approving QS request) Receiver 277 ------ ------- -------- 278 | | 279 | ------------------------------------------------>| 280 | QS request | 281 | TCP , unscaled receive window | 282 | window scaling and other options | 283 | | 284 | <------------------------------------------------| 285 | QS response | 286 | TCP , unscaled receive window | 287 | window scaling and other options | 288 | | 289 | <------------------------------------------------| 290 | Additional acknowledgment | 291 | TCP , scaled receive window | 292 | | 293 | ------------------------------------------------>| 294 | QS report | 295 | TCP | 296 | | 297 | ================================================>| 298 | ================================================>| 299 | Rate paced data transfer | 300 | | 301 | <------------------------------------------------| 302 | First new acknowledgment | 303 V V 305 Figure 1: Message sequence chart of the proposed mechanism 307 After having received this additional acknowledgment, the sender is 308 aware of the true available receive buffer. Provided that the Quick- 309 Start request is approved on the path and that the receive window is 310 sufficiently large, this allows the sender to send more than 64 KB 311 during the Quick-Start rate pacing phase. 313 We note that there is some degree of freedom as to when to send the 314 additional acknowledgment. The straightforward solution is to send 315 it immediately after the segment. But this is not 316 required: It is sufficient if the sender receives this segment before 317 reaching the limit of the unscaled receive window. As a consequence, 318 receivers could also delay the sending of this segment for some small 319 amount of time. 321 4.4. Deployment Considerations 323 The method proposed in this document is compliant with the TCP 324 specifications: Sending empty segments to increase the receive window 325 is implicitly allowed by [RFC0793], and in [RFC2581] it is clearly 326 stated that sending an acknowledgment is allowed to update the 327 receive window. For standard-compliant TCP stacks, implementing the 328 method thus should require changes in the receiver TCP implementation 329 only. 331 However, sending an empty acknowledgment shortly after a 332 segment is an atypical TCP communication event. The and 333 the additional segment could get reordered in the network. In this 334 case, the sending host will typically ignore the additional segment, 335 as it is still awaiting the . Furthermore, middleboxes such 336 as stateful firewalls might drop the additional acknowledgment. Even 337 worse, this segment might also be dropped because a middlebox 338 receives it earlier than the segment from the sender. At this 339 point in time, from the viewpoint of the middlebox, the bi- 340 directional end-to-end TCP connection is not yet established. If the 341 additional segment gets dropped, the sender only knows the unscaled 342 receive window until the next new acknowledgment arrives, which may 343 limit the benefit of Quick-Start. Delaying the additional 344 acknowledgment for a short period of time could help to avoid such 345 problems. Further investigation is needed to analyze whether such a 346 delay is required. 348 A possible alternative to the message flow in Figure 1 would be to 349 piggyback the Quick-Start response on the additional acknowledgment 350 segment instead of the . However, this approach has several 351 drawbacks and is therefore not recommended: First, the Quick-Start 352 response would be received later, which could cause additional 353 delays. Second, the is immediately acknowledged by the 354 segment. The Quick-Start rate report can thus be piggybacked 355 on this . In contrast, if the Quick-Start response is included 356 in the additional acknowledgment, the Quick-Start report has to be 357 piggybacked to a data segment, i. e., it depends on the availability 358 of application data whether and when the Quick-Start report is sent. 360 The additional segment mandated by this document results in a network 361 overhead of one segment. In many potential usage scenarios this 362 overhead will be small compared to the network load caused by the 363 acknowledgments of a starting high-speed Quick-Start data transfer. 365 Instead of sending one additional acknowledgment, a host could also 366 send a small number of copies in order to improve robustness. This 367 could help to reduce the risk of reordering with the 368 segment. However, given the additional overhead, it is recommended 369 to send only one acknowledgment unless there are indications that the 370 path suffers from frequent packet reordering. 372 5. Security Considerations 374 Quick-Start TCP imposes a number of security challenges. Known 375 security threats as well as counter-measures are discussed in the 376 section "Security Considerations" of [RFC4782]. Since this document 377 describes extensions to Quick-Start TCP, the security issues and 378 solutions identified in [RFC4782] apply here, too. 380 If a host reserves large amounts of buffer space during the three-way 381 handshake, this could increase the vulnerability to "syn flooding" 382 attacks: An attacker sending many Quick-Start requests could try to 383 allocate much buffer space at a host, which is then not available any 384 more for other TCP connections. If most involved routers support 385 Quick-Start, this type of attack is difficult to realize, since the 386 routers may reject many requests before they reach a host. However, 387 an attack could be possible if some routers on the path do not 388 support Quick-Start. A simple countermeasure would be to set an 389 upper limit on the total amount of buffer space granted to 390 connections with Quick-Start, and possibly to deny requests if they 391 arrive at a host with too high a frequency. The main impact of this 392 abuse is that Quick-Start may be rendered useless for other 393 connections. This can result in some performance degradation, 394 because the default Slow-Start must be used instead. In general, it 395 is an inherent weak point of Quick-Start that one can send much more 396 requests than required, which temporarily can block resources for 397 other earnest Quick-Start requests [RFC4782]. 399 It is an allowed behavior for a TCP connection endpoint to send an 400 additional acknowledgment segment in order to update the receive 401 window. The usage of the proposed mechanism causes some limited 402 network overhead, but it does not result in additional security 403 threats. 405 6. IANA Considerations 407 This document has no actions for IANA. 409 7. Acknowledgments 411 Special thanks to Haiko Strotbek, Martin Koehn, Simon Hauger, 412 Christian Mueller, and Gorry Fairhurst for suggestions and comments. 414 8. References 416 8.1. Normative References 418 [RFC0793] Postel, J., "Transmission Control Protocol", STD 7, 419 RFC 793, September 1981. 421 [RFC1323] Jacobson, V., Braden, B., and D. Borman, "TCP Extensions 422 for High Performance", RFC 1323, May 1992. 424 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 425 Requirement Levels", BCP 14, RFC 2119, March 1997. 427 [RFC2581] Allman, M., Paxson, V., and W. Stevens, "TCP Congestion 428 Control", RFC 2581, April 1999. 430 [RFC3390] Allman, M., Floyd, S., and C. Partridge, "Increasing TCP's 431 Initial Window", RFC 3390, October 2002. 433 [RFC4782] Floyd, S., Allman, M., Jain, A., and P. Sarolahti, "Quick- 434 Start for TCP and IP", RFC 4782, January 2007. 436 8.2. Informative References 438 [Dun06] Dunigan, T., "TCP auto-tuning zoo", available 439 at http://www.csm.ornl.gov/~dunigan/net100/auto.html, 440 February 2006. 442 [FPK07] Falk, A., Pryadkin, Y., and D. Katabi, "Specification for 443 the Explicit Control Protocol (XCP)", Internet Draft, work 444 in progress, June 2007. 446 [LAJ+07] Liu, D., Allman, M., Jin, S., and L. Wang, "Congestion 447 Control Without a Startup Phase", Proc. PFLDnet2007, 448 February 2007. 450 [RFC2488] Allman, M., Glover, D., and L. Sanchez, "Enhancing TCP 451 Over Satellite Channels using Standard Mechanisms", 452 BCP 28, RFC 2488, January 1999. 454 [RFC3481] Inamura, H., Montenegro, G., Ludwig, R., Gurtov, A., and 455 F. Khafizov, "TCP over Second (2.5G) and Third (3G) 456 Generation Wireless Networks", BCP 71, RFC 3481, 457 February 2003. 459 [SAF07] Sarolahti, P., Allman, M., and S. Floyd, "Determining an 460 Appropriate Sending Rate Over an Underutilized Network 461 Path", Computer Networks, vol. 51, no. 7, 2007. 463 [SB05] Smith, M. and S. Bishop, "Flow Control in the Linux 464 Network Stack", available 465 at http://www.cl.cam.ac.uk/~pes20/Netsem/linuxnet.pdf, 466 February 2005. 468 Appendix A. Applicability to Other Proposals 470 Besides Quick-Start, there are some other fast startup proposals 471 under discussion. A common characteristic is that they can be more 472 aggressive than the standard TCP Slow-Start. A comprehensive survey 473 of this related work can be found in [RFC4782]. For instance, the 474 Explicit Control Protocol (XCP) [FPK07] proposes a new congestion 475 control based on explicit router feedback. Furthermore, there are 476 discussions in the research community whether a host could start to 477 send with a large congestion window, combined with a rate pacing 478 mechanism and a conservative reaction in case of congestion [LAJ+07]. 479 Basically, the effects discussed in this document are inherent to all 480 fast startup schemes and not specific to Quick-Start. 482 Dynamic receive buffer dimensioning is a non-trivial task for all 483 fast startup schemes. The amount of information that a receiver can 484 gain during a connection setup procedure differs from proposal to 485 proposal. However, the basic guideline to advertise a larger inital 486 receive window applies to all proposals similar to Quick-Start. 488 If the TCP header semantics apply, the interaction with receive 489 window scaling mechanism could also be a problem for other 490 approaches. In this case, the workaround of sending an additional 491 acknowledgment can be helpful, too. 493 Appendix B. Alternative Solutions 495 The limitation imposed by the window scaling could be addressed in 496 several ways. This document proposes to send an additional 497 acknowledgment to announce the true receive window, if needed. This 498 method is compliant with the current TCP standards. 500 Alternatively, one could circumvent [RFC1323] in several ways. For 501 instance, one could use a scaled receive window in and 502 segments, if they include Quick-Start options. The usage 503 of a scaled window could also be indicated by some other means (e. 504 g., a new TCP option). Finally, the advertised window could 505 selectively be ignored by a sender that receives a Quick-Start 506 response. Still, such alternative solutions would require changes in 507 the TCP header semantics and might cause interworking problems with 508 currently deployed TCP implementations. 510 Appendix C. Document Revision History 512 This document was originally entitled by "Avoiding Interactions of 513 Quick-Start TCP and Flow Control". Changes from earlier versions of 514 the document include: 515 o draft-scharf-tcpm-flow-control-quick-start-00.txt: Changed title 516 and more precise statements on the applicability beyond Quick- 517 Start 518 o draft-scharf-tsvwg-quick-start-flow-control-01.txt: Improved 519 description of deployment implications 520 o draft-scharf-tsvwg-quick-start-flow-control-00.txt: Initial 521 version 523 Authors' Addresses 525 Michael Scharf 526 University of Stuttgart 527 Pfaffenwaldring 47 528 D-70569 Stuttgart 529 Germany 531 Phone: +49 711 685 69006 532 Email: michael.scharf@ikr.uni-stuttgart.de 533 URI: http://www.ikr.uni-stuttgart.de/en/~scharf 535 Sally Floyd 536 ICIR (ICSI Center for Internet Research) 538 Phone: +1 (510) 666-2989 539 Email: floyd@icir.org 540 URI: http://www.icir.org/floyd/ 542 Pasi Sarolahti 543 Nokia Research Center 544 P.O. Box 407 545 FI-00045 NOKIA GROUP 546 Finland 548 Phone: +358 50 4876607 549 Email: pasi.sarolahti@iki.fi 551 Full Copyright Statement 553 Copyright (C) The IETF Trust (2008). 555 This document is subject to the rights, licenses and restrictions 556 contained in BCP 78, and except as set forth therein, the authors 557 retain all their rights. 559 This document and the information contained herein are provided on an 560 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 561 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 562 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 563 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 564 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 565 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 567 Intellectual Property 569 The IETF takes no position regarding the validity or scope of any 570 Intellectual Property Rights or other rights that might be claimed to 571 pertain to the implementation or use of the technology described in 572 this document or the extent to which any license under such rights 573 might or might not be available; nor does it represent that it has 574 made any independent effort to identify any such rights. Information 575 on the procedures with respect to rights in RFC documents can be 576 found in BCP 78 and BCP 79. 578 Copies of IPR disclosures made to the IETF Secretariat and any 579 assurances of licenses to be made available, or the result of an 580 attempt made to obtain a general license or permission for the use of 581 such proprietary rights by implementers or users of this 582 specification can be obtained from the IETF on-line IPR repository at 583 http://www.ietf.org/ipr. 585 The IETF invites any interested party to bring to its attention any 586 copyrights, patents or patent applications, or other proprietary 587 rights that may cover technology that may be required to implement 588 this standard. Please address the information to the IETF at 589 ietf-ipr@ietf.org.