idnits 2.17.1 draft-rfced-exp-partridge-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Cannot find the required boilerplate sections (Copyright, IPR, etc.) in this document. Expected boilerplate is as follows today (2024-04-24) according to https://trustee.ietf.org/license-info : IETF Trust Legal Provisions of 28-dec-2009, Section 6.a: This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 2: Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 3: This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing document type: Expected "INTERNET-DRAFT" in the upper left hand corner of the first page ** Missing expiration date. The document expiration date should appear on the first and last page. ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. ** 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? ** The document seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts. ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories. ** Expected the document's filename to be given on the first page, but didn't find any == The page length should not exceed 58 lines per page, but there was 1 longer page, the longest (page 1) being 69 lines Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an Abstract section. ** 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 an Authors' Addresses Section. ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** There are 5 instances of too long lines in the document, the longest one being 3 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == Couldn't figure out when the document was first submitted -- there may comments or warnings related to the use of a disclaimer for pre-RFC5378 work that could not be issued because of this. Please check the Legal Provisions document at https://trustee.ietf.org/license-info to determine if you need the pre-RFC5378 disclaimer. -- The document date (Sep 1998) is 9353 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- -- Missing reference section? '2' on line 176 looks like a reference -- Missing reference section? '1' on line 183 looks like a reference Summary: 14 errors (**), 0 flaws (~~), 2 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 End-To-End Research Group C. Partridge 3 Request for Comments: DRAFT BBN Technologies 4 Category: Informational Sep 1998 6 ACK Spacing for High Delay-Bandwidth Paths with Insufficient Buffering 8 Status of this Memo 10 This document is an Internet-Draft. Internet-Drafts are working 11 documents of the Internet Engineering Task Force (IETF), its areas, and 12 its working groups. Note that other groups may also distribute working 13 documents as Internet-Drafts. 15 Internet-Drafts are draft documents valid for a maximum of six months 16 and may be updated, replaced, or obsoleted by other documents at any 17 time. It is inappropriate to use Internet- Drafts as reference material 18 or to cite them other than as "work in progress." 20 To view the entire list of current Internet-Drafts, please check the 21 "1id-abstracts.txt" listing contained in the Internet-Drafts Shadow 22 Directories on ftp.is.co.za (Africa), ftp.nordu.net (Northern Europe), 23 ftp.nis.garr.it (Southern Europe), munnari.oz.au (Pacific Rim), 24 ftp.ietf.org (US East Coast), or ftp.isi.edu (US West Coast). 26 An argument is made that the correct way to solve buffering shortages 27 in routers on high delay-bandwidth paths is for routers to space out 28 the TCP acks. 30 This memo presents thoughts from a discussion held at the July 1997 31 meeting of the End-To-End (E2E) Research Group. The material 32 presented is a half-baked suggestion and should not be interpreted as 33 an official recommendation of the Research Group. Comments are 34 solicited and should be addressed to the author. 36 1. Introduction 38 Suppose you want TCP implementations to be able to fill a 155 Mb/s 39 path. Further suppose that the path includes a satellite in a 40 geosynchronous orbit, so the round trip delay through the path is at 41 least 500 ms, and the delay-bandwidth product is 9.7 megabytes or 42 more. 44 If we further assume the TCP implementations support TCP Large 45 Windows and PAWS (many do), so they can manage 9.7 MB TCP window, 46 then we can be sure the TCP will eventually start sending at full 47 path rate (unless the satellite channel is very lossy). But it may 48 take a long time to get the TCP up to full speed. 50 One (of several) possible causes of the delay is a shortage of 51 buffering in routers. To understand this particular problem, 52 consider the following idealized behavior of TCP during slow start. 53 During slow start, for every segment ACKed, the sender transmits two 54 new segments. In effect, this behavior means the sender is 55 transmitting at *twice* the data rate of the segments being ACKed. 56 Keep in mind the separation between ACKs represents (in an ideal 57 world) the rate segments can flow through the bottleneck router in 58 the path. So the sender is bursting data at twice the bottleneck 59 rate, and a queue must be forming during the burst. In the simplest 60 case, the queue is entirely at the bottleneck router, and at the end 61 of the burst, the queue is storing half the data in the burst. (Why 62 half? During the burst, the sender transmitted at twice the 63 bottleneck rate. Suppose it takes one time unit to send a segment on 64 the bottlenecked link. During the burst the bottleneck will receive 65 two segments in every time unit, but only be able to transmit one 66 segment. The result is a net of one new segment queued every time 67 unit, for the life of the burst.) 69 TCP will end the slow start phase in response to the first lost 70 datagram. Assuming good quality transmission links, the first lost 71 datagram will be lost because the bottleneck queue overflowed. We 72 would like that loss to occur in the round-trip after the slow start 73 congestion window has reached the delay-bandwidth product. Now 74 consider the buffering required in the bottleneck link during the 75 next to last round trip. The sender will send an entire delay- 76 bandwidth worth of data in one-half a round-trip time (because it 77 sends at twice the channel rate). So for half the round-trip time, 78 the bottleneck router is in the mode of forwarding one segment while 79 receiving two. (For the second half of the round-trip, the router is 80 draining its queue). That means, to avoid losing any segments, the 81 router must have buffering equal to half the delay-bandwidth product, 82 or nearly 5 MB. 84 Most routers do not have anywhere near 5 MB of buffering for a single 85 link. Or, to express this problem another way, because routers do 86 not have this much buffering, the slow start stage will end 87 prematurely, when router buffering is exhausted. The consequence of 88 ending slow start prematurely is severe. At the end of slow start, 89 TCP goes into congestion avoidance, in which the window size is 90 increased much more slowly. So even though the channel is free, 91 because we did not have enough router buffering, we will transmit 92 slowly for a period of time (until the more conservative congestion 93 avoidance algorithm sends enough data to fill the channel). 95 2. What to Do? 97 So how to get around the shortage of router buffering? 99 One solution has been proposed, cascading TCPs. We would like to 100 suggest another solution, ACK spacing. Both schemes involve layer 101 violations because they require the router to examine the TCP header. 103 2.1 Cascading TCPs 105 One approach is to use cascading TCPs, in which we build a custom TCP 106 for the satellite (or bottleneck) link and insert it between the 107 sender's and receiver's TCPs, as shown below: 109 sender ---- Ground station -- satellite -- ground station -- receiver 111 +---------------+ +------------------------+ +---------------+ 112 | loop 1 | | loop 2 | | loop 3 | 113 +---------------+ +------------------------+ +---------------+ 115 This approach can work but is awkward. Among its limitations are: 116 the buffering problem remains (at points of bandwidth mismatches, 117 queues will form); the scheme violates end-to-end semantics of TCP 118 (the sender will get ACKs for data that has not and may never reach 119 the receiver); it constrains the reverse path of the TCP connection 120 to pass through points at which the multiple TCP connections are 121 spliced together (a problem if satellite links are unidirectional); 122 and it doesn't work with end-to-end encryption (i.e. if data above 123 the IP layer is encrypted). 125 2.2 ACK Spacing 127 Another approach is to find some way to spread the bursts, either by 128 having the sender spread out the segments, or having the network 129 arrange for the ACKs to arrive at the sender with a two segment 130 spacing (or larger). 132 Changing the sender is feasible, although it requires very good 133 operating system timers. But it has the disadvantage that only 134 upgraded senders get the performance improvement. 136 Finding a way for the network to space the ACKs would allow TCP 137 senders to transmit at the right rate, without modification. 138 Furthermore, it can be done by a router. The router simply has to 139 snoop the returning TCP ACKs and spread them out. (Note that if the 140 transmissions are encrypted, in many scenarios the router can still 141 figure out which segments are likely TCP ACKs and spread them out). 143 There are some difficult issues with this approach. The most notable 144 ones are: 146 1. What algorithm to use to determine the proper ACK spacing. 148 2. Related to (1), it may be necessary to known when a TCP is in 149 slow-start vs. congestion-avoidance, as the desired spacing 150 between ACKs is likely to be different in the two phases. 152 3. What to do about assymetric routes (if anything). The scheme 153 works so long as the router sees the ACKs (it does not have to see 154 the related data). However, if the ACKs do not return through the 155 ACK-spacing router, it is not possible to do ACK spacing. 157 4. How much, if at all, does ack compression between the respacing 158 point and the sender undo the effects of ack spacing? 160 5. How much per-flow (soft) state is required in the ACK spacing 161 router? 163 Despite these challenges the approach has appeal. Changing software 164 in a few routers (particularly those at likely bottleneck links) on 165 high delay-bandwidth paths could give a performance boost to lots of 166 TCP connections. 168 Security Issues 170 ACK spacing introduces no new security issues. ACK spacing does not 171 change the contents of any datagram. It simply delays some 172 datagrams in transit, just as a queue might. TCP and other higher 173 layer protocols are already required to work correctly with queueing 174 delays, and indeed, work correctly when encountering far more serious 175 transmission errors such as damage, loss, duplication and reordering 176 [2]. 178 Credit and Disclaimer 180 The particular idea of ACK spacing was developed by during the 181 meeting by Mark Handley and Van Jacobson in response to an issue 182 raised by the author, and was inspired, in part by ideas to enhance 183 wireless routers to improve TCP performance [1]. 185 Intellectual Property Issues 187 The author has learned from the IETF that parties may be attempting 188 to patent schemes similar to this one. Readers are advised to check 189 with the IETF to learn of any intellectual property rights issues. 191 References 193 1. H. Balakrishnan, V.N. Padmanabhan, S. Seshan and R.H. Katz, "A 194 Comparison of Mechanisms for Improving TCP Performance over Wireless 195 Links", Proc. ACM SIGCOMM '96, pp. 256-269. 196 2. J. Postel, ed. Transmission Control Protocol RFC-793, Internet 197 Requests for Comments, No. 793, September 1981, p. 4.