idnits 2.17.1 draft-ietf-tcplw-sack-02.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-25) 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 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 == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 4 longer pages, the longest (page 7) being 61 lines 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 separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** There are 3 instances of too long lines in the document, the longest one being 1 character in excess of 72. ** There are 16 instances of lines with control characters in the document. ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 119: '... has opened. It MUST NOT be sent on n...' RFC 2119 keyword, line 213: '...he data receiver MAY elect to generate...' RFC 2119 keyword, line 215: '...circumstance, it SHOULD generate them ...' RFC 2119 keyword, line 217: '...r a given connection, it MUST NOT send...' RFC 2119 keyword, line 220: '...ll, SACK options SHOULD be included in...' (15 more instances...) 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 (26 April 1996) is 10226 days in the past. Is this intentional? 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: 'VJ88' is mentioned on line 87, but not defined == Missing Reference: 'RFC1323' is mentioned on line 253, but not defined ** Obsolete undefined reference: RFC 1323 (Obsoleted by RFC 7323) ** Downref: Normative reference to an Experimental RFC: RFC 1045 (ref. 'Cheriton88') ** Downref: Normative reference to an Experimental RFC: RFC 998 (ref. 'Clark87') -- Possible downref: Non-RFC (?) normative reference: ref. 'Fall95' -- Possible downref: Non-RFC (?) normative reference: ref. 'Floyd96' -- Possible downref: Non-RFC (?) normative reference: ref. 'Huitema81' -- Possible downref: Non-RFC (?) normative reference: ref. 'Jacobson88' ** Obsolete normative reference: RFC 1323 (ref. 'Jacobson92') (Obsoleted by RFC 7323) -- Possible downref: Non-RFC (?) normative reference: ref. 'Keshav94' -- Possible downref: Non-RFC (?) normative reference: ref. 'Mathis95' -- Possible downref: Non-RFC (?) normative reference: ref. 'Partridge87' ** Obsolete normative reference: RFC 793 (ref. 'Postel81') (Obsoleted by RFC 9293) -- Possible downref: Non-RFC (?) normative reference: ref. 'Stevens94' -- Possible downref: Non-RFC (?) normative reference: ref. 'Strayer92' ** Downref: Normative reference to an Experimental RFC: RFC 908 (ref. 'Velten84') Summary: 18 errors (**), 0 flaws (~~), 5 warnings (==), 10 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Internet Engineering Task Force TCPLW WG 2 INTERNET-DRAFT Mathis/Mahdavi/Floyd/Romanow 3 Draft-ietf-tcplw-sack-02.txt PSC/LBL/Sun 4 26 April 1996 5 Expires: 29/7/96 7 TCP Selective Acknowledgment Options 9 STATUS OF THIS MEMO 11 This document is an Internet-Draft. Internet-Drafts are working 12 documents of the Internet Engineering Task Force (IETF), its areas, 13 and its working groups. Note that other groups may also distribute 14 working documents as Internet-Drafts. 16 Internet-Drafts are draft documents valid for a maximum of six 17 months and may be updated, replaced, or obsoleted by other 18 documents at any time. It is inappropriate to use Internet- 19 Drafts as reference material or to cite them other than as ``work in 20 progress.'' 22 To learn the current status of any Internet-Draft, please check 23 the ``1id-abstracts.txt'' listing contained in the Internet- 24 Drafts Shadow Directories on ftp.is.co.za (Africa), 25 nic.nordu.net (Europe), munnari.oz.au (Pacific Rim), 26 ds.internic.net (US East Coast), or ftp.isi.edu (US West Coast). 28 ABSTRACT 30 TCP may experience poor performance when multiple packets are lost 31 from one window of data. With the limited information available 32 from cumulative acknowledgments, a TCP sender can only learn 33 about a single lost packet per round trip time. An aggressive 34 sender could choose to retransmit packets early, but such 35 retransmitted segments may have already been successfully 36 received. 38 A Selective Acknowledgment (SACK) mechanism, combined with a 39 selective repeat retransmission policy, can help to overcome these 40 limitations. The receiving TCP sends back SACK packets to the 41 sender informing the sender of data that has been received. The 42 sender can then retransmit only the missing data segments. 44 This draft proposes an implementation of SACK and discusses its 45 performance and related issues. 47 ACKNOWLEDGMENTS 49 Much of the text in this document is taken directly from RFC1072 50 ``TCP Extensions for Long-Delay Paths'' by Bob Braden and Van 51 Jacobson. The authors would like to thank Kevin Fall (LBNL), 52 Christian Huitema (INRIA), Van Jacobson (LBNL), Greg Miller 53 (MITRE), Greg Minshall (Ipsilon), Lixia Zhang (XEROX PARC and 54 UCLA), Dave Borman (BSDI), Allison Mankin (ISI) and others for 55 their review and constructive comments. 57 1. INTRODUCTION 59 Multiple packet losses from a window of data can have a 60 catastrophic effect on TCP throughput. TCP [Postel81] uses a 61 cumulative acknowledgment scheme in which received segments that 62 are not at the left edge of the receive window are not 63 acknowledged. This forces the sender to either wait a roundtrip 64 time to find out about each lost packet, or to unnecessarily 65 retransmit segments which have been correctly received [Fall95]. 66 With the cumulative acknowledgment scheme, multiple dropped 67 segments generally cause TCP to lose its ACK-based clock, reducing 68 overall throughput. 70 Selective Acknowledgment (SACK) is a strategy which corrects this 71 behavior in the face of multiple dropped segments. With selective 72 acknowledgments, the data receiver can inform the sender about all 73 segments that have arrived successfully, so the sender need 74 retransmit only the segments that have actually been lost. 76 Several transport protocols, including NETBLT [Clark87], XTP 77 [Strayer92], RDP [Velten84], NADIR [Huitema81], 78 and VMTP [Cheriton88] have used selective 79 acknowledgment. There is some empirical evidence in favor of 80 selective acknowledgments -- simple experiments with RDP have shown 81 that disabling the selective acknowledgment facility greatly 82 increases the number of retransmitted segments over a lossy, 83 high-delay Internet path [Partridge87]. A recent simulation study 84 by Kevin Fall and Sally Floyd [Fall95], demonstrates the strength of 85 TCP with SACK over the non-SACK Tahoe and Reno TCP implementations. 87 RFC1072 [VJ88] describes one possible implementation of SACK 88 options for TCP. Unfortunately, it has never been deployed in the 89 Internet, as there was disagreement about how SACK options should 90 be used in conjunction with the TCP window shift option (initially 91 described RFC1072 and revised in [Jacobson92]). 93 We propose slight modifications to the SACK options as proposed in 94 RFC1072. Specifically, sending a selective acknowledgment for the 95 most recently received data reduces the need for long SACK options 96 [Keshav94, Mathis95]. In addition, the SACK option now carries full 97 32 bit sequence numbers. These two modifications represent the only 98 changes to the proposal in RFC1072. They make SACK easier to 99 implement and address concerns about robustness. 101 The selective acknowledgment extension uses two TCP options. The 102 first is an enabling option, "SACK-permitted", which may be sent in 103 a SYN segment to indicate that the SACK option can be used once the 104 connection is established. The other is the SACK option itself, 105 which may be sent over an established connection once permission 106 has been given by SACK-permitted. 108 The SACK option is to be included in a segment sent from a TCP that 109 is receiving data to the TCP that is sending that data; we will 110 refer to these TCP's as the data receiver and the data sender, 111 respectively. We will consider a particular simplex data flow; any 112 data flowing in the reverse direction over the same connection can 113 be treated independently. 115 2. SACK-PERMITTED OPTION 117 This two-byte option may be sent in a SYN by a TCP that has been 118 extended to receive (and presumably process) the SACK option once 119 the connection has opened. It MUST NOT be sent on non-SYN segments. 121 TCP Sack-Permitted Option: 123 Kind: 4 125 +---------+---------+ 126 | Kind=4 | Length=2| 127 +---------+---------+ 129 3. SACK OPTION FORMAT 131 The SACK option is to be used to convey extended acknowledgment 132 information from the receiver to the sender over an established 133 TCP connection. 135 TCP SACK Option: 137 Kind: 5 139 Length: Variable 141 +--------+--------+ 142 | Kind=5 | Length | 143 +--------+--------+--------+--------+ 144 | Left Edge of 1st Block | 145 +--------+--------+--------+--------+ 146 | Right Edge of 1st Block | 147 +--------+--------+--------+--------+ 148 | | 149 / . . . / 150 | | 151 +--------+--------+--------+--------+ 152 | Left Edge of nth Block | 153 +--------+--------+--------+--------+ 154 | Right Edge of nth Block | 155 +--------+--------+--------+--------+ 156 The SACK option is to be sent by a data receiver to inform the 157 data sender of non-contiguous blocks of data that have been 158 received and queued. The data receiver awaits the receipt of data 159 (perhaps by means of retransmissions) to fill the gaps in sequence 160 space between received blocks. When missing segments are 161 received, the data receiver acknowledges the data normally by 162 advancing the left window edge in the Acknowledgment Number field 163 of the TCP header. The SACK option does not change the meaning of 164 the Acknowledgment Number field. 166 The SACK option provides additional information which the data 167 transmitter can use to optimize retransmissions. The TCP data 168 receiver includes the SACK option in an acknowledgment segment 169 whenever it has data that is queued and unacknowledged. 170 The SACK option may be sent only when the TCP has received the 171 SACK-permitted option in the SYN segment for that connection. 173 This option contains a list of some of the blocks of contiguous 174 sequence space occupied by data that has been received and queued 175 within the window. 177 Each contiguous block of data queued at the data receiver is 178 defined in the SACK option by two 32-bit unsigned integers in 179 network byte order: 181 * Left Edge of Block 183 This is the first sequence number of this block. 185 * Right Edge of Block 187 This is the sequence number immediately following the last 188 sequence number of this block. 190 Each block represents received bytes of data that are contiguous and 191 isolated; that is, the bytes just below the block, (Left Edge of 192 Block - 1), and just above the block, (Right Edge of Block), have 193 not been received. 195 A SACK option that specifies n blocks will have a length of 196 8*n+2 bytes, so the 40 bytes available for TCP options can 197 specify a maximum of 4 blocks. It is expected that SACK will 198 often be used in conjunction with the Timestamp option used for 199 RTTM [Jacobson92], which takes an additional 10 bytes (plus two 200 bytes of padding); thus a maximum of 3 SACK blocks will be 201 allowed in this case. 203 The SACK option is advisory, in that, while it notifies the data 204 sender that the data receiver has received the indicated segments, 205 the data receiver is permitted to later discard data which have been 206 reported in a SACK option. A discussion appears below in Section 8 207 of the consequences of advisory SACK, in particular that the data 208 receiver may renege, or drop already SACKed data. 210 4. GENERATING SACK OPTIONS: DATA RECEIVER BEHAVIOR 212 If the data receiver has received a SACK-Permitted option on the 213 SYN for this connection, the data receiver MAY elect to generate 214 SACK options as described below. If the data receiver generates 215 SACK options under any circumstance, it SHOULD generate them under 216 all permitted circumstances. If the data receiver has not received 217 a SACK-Permitted option for a given connection, it MUST NOT send 218 SACK options on that connection. 220 If sent at all, SACK options SHOULD be included in all ACKs which 221 do not ACK the highest sequence number in the data receiver's queue. 222 In this situation the network has lost or mis-ordered data, such 223 that the receiver holds non-contiguous data in its queue. RFC 224 1122, Section 4.2.2.21, discusses the reasons for the receiver to 225 send ACKs in response to additional segments received in this 226 state. The receiver SHOULD send an ACK for every valid segment 227 that arrives containing new data, and each of these "duplicate" 228 ACKs SHOULD bear a SACK option. 230 If the data receiver chooses to send a SACK option, the following 231 rules apply: 233 * The first SACK block (i.e., the one immediately following the 234 kind and length fields in the option) MUST specify the 235 contiguous block of data containing the segment which triggered 236 this ACK, unless that segment advanced the Acknowledgment Number 237 field in the header. This assures that the ACK with the SACK 238 option reflects the most recent change in the data receiver's 239 buffer queue. 241 * The data receiver SHOULD include as many distinct SACK blocks 242 as possible in the SACK option. Note that the maximum 243 available option space may not be sufficient to report all 244 blocks present in the receiver's queue. 246 * The SACK option SHOULD be filled out by repeating the most 247 recently reported SACK blocks (based on first SACK blocks in 248 previous SACK options) that are not subsets of a SACK block 249 already included in the SACK option being constructed. This 250 assures that in normal operation, any segment remaining part 251 of a non-contiguous block of data held by the data receiver is 252 reported in at least three successive SACK options, even for 253 large-window TCP implementations [RFC1323]). After the first 254 SACK block, the following SACK blocks in the SACK option may be 255 listed in arbitrary order. 257 It is very important that the SACK option always reports 258 the block containing the most recently received segment, because 259 this provides the sender with the most up-to-date information 260 about the state of the network and the data receiver's queue. 262 5. INTERPRETING THE SACK OPTION AND RETRANSMISSION STRATEGY: 263 DATA SENDER BEHAVIOR 265 When receiving an ACK containing a SACK option, the data sender 266 SHOULD record the selective acknowledgment for future reference. 267 The data sender is assumed to have a retransmission queue 268 that contains the segments that have been transmitted but not yet 269 acknowledged, in sequence-number order. If the data sender 270 performs re-packetization before retransmission, the block 271 boundaries in a SACK option that it receives may not fall on 272 boundaries of segments in the retransmission queue; however, this 273 does not pose a serious difficulty for the sender. 275 One possible implementation of the sender's behavior is as follows. 276 Let us suppose that for each segment in the retransmission queue 277 there is a (new) flag bit "SACKed", to be used to indicate that 278 this particular segment has been reported in a SACK option. 280 When an acknowledgment segment arrives containing a SACK option, 281 the data sender will turn on the SACKed bits for segments that 282 have been selectively acknowledged. More specifically, for each 283 block in the SACK option, the data sender will turn on the 284 SACKed flags for all segments in the retransmission queue that are 285 wholly contained within that block. This requires straightforward 286 sequence number comparisons. 288 After the SACKed bit is turned on (as the result of processing a 289 received SACK option), the data sender will skip that segment during 290 any later retransmission. Any segment that has the SACKed bit turned 291 off and is less than the highest SACKed segment is available for 292 retransmission. 294 After a retransmit timeout the data sender SHOULD turn off all of 295 the SACKed bits, since the timeout might indicate that the data 296 receiver has reneged. The data sender MUST retransmit the segment 297 at the left edge of the window after a retransmit timeout, whether or 298 not the SACKed bit is on for that segment. A segment will not be 299 dequeued and its buffer freed until the left window edge is 300 advanced over it. 302 5.1 Congestion Control Issues 304 This document does not attempt to specify in detail the congestion 305 control algorithms for implementations of TCP with SACK. However, 306 the congestion control algorithms present in the de facto standard 307 TCP implementations MUST be preserved [Stevens94]. In particular, 308 to preserve robustness in the presence of packets reordered by the 309 network, recovery is not triggered by a single ACK reporting 310 out-of-order packets at the receiver. Further, during recovery the 311 data sender limits the number of segments sent in response to each 312 ACK. Existing implementations limit the data sender to sending one 313 segment during Reno-style fast recovery, or to two segments during 314 slow-start [Jacobson88]. Other aspects of congestion control, such 315 as reducing the congestion window in response to congestion, must 316 similarly be preserved. 318 The use of time-outs as a fall-back mechanism for detecting dropped 319 packets is unchanged by the SACK option. Because the data receiver 320 is allowed to discard SACKed data, when a retransmit timeout 321 occurs the data sender MUST ignore prior SACK information in 322 determining which data to retransmit. 324 Future research into congestion control algorithms may take 325 advantage of the additional information provided by SACK. One such 326 area for future research concerns modifications to TCP for a 327 wireless or satellite environment where packet loss is not 328 necessarily an indication of congestion. 330 6. EFFICIENCY AND WORST CASE BEHAVIOR 332 If the return path carrying ACKs and SACK options were lossless, 333 one block per SACK option packet would always be sufficient. Every 334 segment arriving while the data receiver holds discontinuous data 335 would cause the data receiver to send an ACK with a SACK option 336 containing the one altered block in the receiver's queue. The data 337 sender is thus able to construct a precise replica of the 338 receiver's queue by taking the union of all the first SACK blocks. 340 Since the return path is not lossless, the SACK option is 341 defined to include more than one SACK block in a single packet. 342 The redundant blocks in the SACK option packet increase the 343 robustness of SACK delivery in the presence of lost ACKs. For a 344 receiver that is also using the time stamp option [Jacobson92], the 345 SACK option has room to include three SACK blocks. Thus each SACK 346 block will generally be repeated at least three times, if necessary, 347 once in each of three successive ACK packets. However, if all 348 of the ACK packets reporting a particular SACK block are dropped, 349 then the sender might assume that the data in that SACK block has 350 not been received, and unnecessarily retransmit those segments. 352 The deployment of other TCP options may reduce the number of 353 available SACK blocks to 2 or even to 1. This will reduce the 354 redundancy of SACK delivery in the presence of lost ACKs. Even so, 355 the exposure of TCP SACK in regard to the unnecessary retransmission 356 of packets is strictly less than the exposure of current 357 implementations of TCP. The worst-case conditions necessary 358 for the sender to needlessly retransmit data is discussed in more 359 detail in a separate document [Floyd96]. 361 Older TCP implementations which do not have the SACK option will not 362 be unfairly disadvantaged when competing against SACK-capable TCPs. 363 This issue is discussed in more detail in [Floyd96]. 365 7. SACK OPTION EXAMPLES 367 The following examples attempt to demonstrate the proper behavior of 368 SACK generation by the data receiver. 370 Assume the left window edge is 5000 and that the data transmitter 371 sends a burst of 8 segments, each containing 500 data bytes. 373 Case 1: The first 4 segments are received but the last 4 are 374 dropped. 376 The data receiver will return a normal TCP ACK segment 377 acknowledging sequence number 7000, with no SACK option. 379 Case 2: The first segment is dropped but the remaining 7 are 380 received. 382 Upon receiving each of the last seven packets, the data 383 receiver will return a TCP ACK segment that acknowledges 384 sequence number 5000 and contains a SACK option specifying 385 one block of queued data: 387 Triggering ACK Left Edge Right Edge 388 Segment 390 5000 (lost) 391 5500 5000 5500 6000 392 6000 5000 5500 6500 393 6500 5000 5500 7000 394 7000 5000 5500 7500 395 7500 5000 5500 8000 396 8000 5000 5500 8500 397 8500 5000 5500 9000 399 Case 3: The 2nd, 4th, 6th, and 8th (last) segments are 400 dropped. 402 The data receiver ACKs the first packet normally. The 403 third, fifth, and seventh packets trigger SACK options as 404 follows: 406 Triggering ACK First Block 2nd Block 3rd Block 407 Segment Left Right Left Right Left Right 408 Edge Edge Edge Edge Edge Edge 410 5000 5500 411 5500 (lost) 412 6000 5500 6000 6500 413 6500 (lost) 414 7000 5500 7000 7500 6000 6500 415 7500 (lost) 416 8000 5500 8000 8500 7000 7500 6000 6500 417 8500 (lost) 419 Suppose at this point, the 4th packet is received out of 420 order. (This could either be because the data was badly 421 misordered in the network, or because the 2nd packet was 422 retransmitted and lost, and then the 4th packet was 423 retransmitted). At this point the data receiver has only two 424 SACK blocks to report. The data receiver replies with the 425 following Selective Acknowledgment: 427 Triggering ACK First Block 2nd Block 3rd Block 428 Segment Left Right Left Right Left Right 429 Edge Edge Edge Edge Edge Edge 431 6500 5500 6000 7500 8000 8500 433 Suppose at this point, the 2nd segment is received. The 434 data receiver then replies with the following Selective 435 Acknowledgment: 437 Triggering ACK First Block 2nd Block 3rd Block 438 Segment Left Right Left Right Left Right 439 Edge Edge Edge Edge Edge Edge 441 5500 7500 8000 8500 443 8. DATA RECEIVER RENEGING 445 Note that the data receiver is permitted to discard data in its 446 queue that has not been acknowledged to the data sender, even if 447 the data has already been reported in a SACK option. Such 448 discarding of SACKed packets is discouraged, but may be used if the 449 receiver runs out of buffer space. 451 The data receiver MAY elect not to keep data which it has reported 452 in a SACK option. In this case, the receiver SACK generation is 453 additionally qualified: 455 * The first SACK block MUST reflect the newest segment. Even 456 if the newest segment is going to be discarded and the receiver 457 has already discarded adjacent segments, the first SACK block 458 MUST report, at a minimum, the left and right edges of the 459 newest segment. 461 * Except for the newest segment, all SACK blocks MUST NOT 462 report any old data which is no longer actually held by the 463 receiver. 465 Since the data receiver may later discard data reported in a SACK 466 option, the sender MUST NOT discard data before it is acknowledged 467 by the Acknowledgment Number field in the TCP header. 469 9. SECURITY CONSIDERATIONS 471 This document neither strengthens nor weakens TCP's current 472 security properties. 474 10. REFERENCES 476 [Cheriton88] Cheriton, D., "VMTP: Versatile Message Transaction 477 Protocol", RFC 1045, Stanford University, February 1988. 479 [Clark87] Clark, D., Lambert, M., and L. Zhang, "NETBLT: A Bulk 480 Data Transfer Protocol", RFC 998, MIT, March 1987. 482 [Fall95] Fall, K. and Floyd, S., "Comparisons of Tahoe, Reno, 483 and Sack TCP", ftp://ftp.ee.lbl.gov/papers/sacks.ps.Z, December 1995. 485 [Floyd96] Floyd, S., "Issues of TCP with SACK", 486 ftp://ftp.ee.lbl.gov/papers/issues_sa.ps.Z, January 1996. 488 [Huitema81] Huitema, C., and Valet, I., An Experiment on High 489 Speed File Transfer using Satellite Links, 7th Data Communication 490 Symposium, Mexico, October 1981. 492 [Jacobson88] Jacobson, V., "Congestion Avoidance and Control", 493 Proceedings of SIGCOMM '88, Stanford, CA., August 1988. 495 [Jacobson88}, V. and Braden, R., TCP Extensions for Long-Delay 496 Paths, RFC 1072, October 1988. 498 [Jacobson92] Jacobson, V., Braden, R., and Borman, D., TCP 499 Extensions for High Performance, RFC 1323, May 1992. 501 [Keshav94] Keshav, presentation to the Internet End-to-End 502 Research Group, November 1994. 504 [Mathis95] Mathis, M., and Mahdavi, J., TCP Forward 505 Acknowledgment Option, presentation to the Internet End-to-End 506 Research Group, June 1995. 508 [Partridge87] Partridge, C., "Private Communication", February 509 1987. 511 [Postel81] Postel, J., "Transmission Control Protocol - DARPA 512 Internet Program Protocol Specification", RFC 793, DARPA, 513 September 1981. 515 [Stevens94] Stevens, W., TCP/IP Illustrated, Volume 1: The 516 Protocols, Addison-Wesley, 1994. 518 [Strayer92] Strayer, T., Dempsey, B., and Weaver, A., XTP -- the 519 xpress transfer protocol. Addison-Wesley Publishing Company, 520 1992. 522 [Velten84] Velten, D., Hinden, R., and J. Sax, "Reliable Data 523 Protocol", RFC 908, BBN, July 1984. 525 11. AUTHORS' ADDRESSES 527 Matt Mathis and Jamshid Mahdavi 528 Pittsburgh Supercomputing Center 529 4400 Fifth Ave 530 Pittsburgh, PA 15213 531 mathis@psc.edu 532 mahdavi@psc.edu 534 Sally Floyd 535 Lawrence Berkeley National Laboratory 536 One Cyclotron Road 537 Berkeley, CA 94720 538 floyd@ee.lbl.gov 540 Allyn Romanow 541 Sun Microsystems, Inc. 542 2550 Garcia Ave., MPK17-202 543 Mountain View, CA 94043 544 allyn@eng.sun.com