idnits 2.17.1 draft-eddy-tsvwg-saratoga-tfrc-07.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- -- The document has an IETF Trust Provisions (28 Dec 2009) Section 6.c(i) Publication Limitation clause. 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 : ---------------------------------------------------------------------------- ** 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 134: '... The receiver MUST echo timestamps i...' RFC 2119 keyword, line 135: '... packets. It SHOULD generate and tr...' RFC 2119 keyword, line 139: '...the receiver, it MAY choose to only se...' RFC 2119 keyword, line 143: '...aratoga receiver MUST track the time w...' RFC 2119 keyword, line 149: '...cited STATUS packets MAY be set to the...' (9 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (April 18, 2015) is 3258 days in the past. Is this intentional? Checking references for intended status: Experimental ---------------------------------------------------------------------------- -- Obsolete informational reference (is this intentional?): RFC 5405 (Obsoleted by RFC 8085) Summary: 1 error (**), 0 flaws (~~), 1 warning (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group W. Eddy 3 Internet-Draft MTI Systems 4 Intended status: Experimental L. Wood 5 Expires: October 20, 2015 Surrey alumni 6 W. Ivancic 7 NASA 8 April 18, 2015 10 TFRC-based Congestion Control for Saratoga 11 draft-eddy-tsvwg-saratoga-tfrc-07 13 Abstract 15 This document specifies the use of TCP-Friendly Rate Control (TFRC) 16 with the Saratoga data transfer protocol. The necessary conventions 17 that a Saratoga sender and receiver implementation must follow if 18 they wish to enable the use of TFRC are described. 20 Status of This Memo 22 This Internet-Draft is submitted to IETF in full conformance with the 23 provisions of BCP 78 and BCP 79. 25 Internet-Drafts are working documents of the Internet Engineering 26 Task Force (IETF). Note that other groups may also distribute 27 working documents as Internet-Drafts. The list of current Internet- 28 Drafts is at http://datatracker.ietf.org/drafts/current/. 30 Internet-Drafts are draft documents valid for a maximum of six months 31 and may be updated, replaced, or obsoleted by other documents at any 32 time. It is inappropriate to use Internet-Drafts as reference 33 material or to cite them other than as "work in progress." 35 This Internet-Draft will expire on October 20, 2015. 37 Copyright Notice 39 Copyright (c) 2015 IETF Trust and the persons identified as the 40 document authors. All rights reserved. 42 This document is subject to BCP 78 and the IETF Trust's Legal 43 Provisions Relating to IETF Documents 44 (http://trustee.ietf.org/license-info) in effect on the date of 45 publication of this document. Please review these documents 46 carefully, as they describe your rights and restrictions with respect 47 to this document. 49 This document may not be modified, and derivative works of it may not 50 be created, except to format it for publication as an RFC or to 51 translate it into languages other than English. 53 Table of Contents 55 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 56 2. Receiver-Side Behavior . . . . . . . . . . . . . . . . . . . 3 57 3. Sender-Side Behavior . . . . . . . . . . . . . . . . . . . . 4 58 4. Security Considerations . . . . . . . . . . . . . . . . . . . 6 59 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6 60 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 7 61 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 7 62 7.1. Normative References . . . . . . . . . . . . . . . . . . 7 63 7.2. Informative References . . . . . . . . . . . . . . . . . 7 64 Appendix A. Differences from Shahriar et al. . . . . . . . . . . 7 65 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 8 67 1. Introduction 69 In order to support use of the Saratoga protocol 70 [draft-wood-tsvwg-saratoga] on networks with multiple data flows, 71 multiple hops, and/or experimentally on the Internet, some form of 72 congestion control is required. Particularly, for use on the 73 Internet, rather than the private links and networks that Saratoga 74 was originally developed for, congestion control is a requirement, as 75 indicated by the UDP Guidelines [RFC5405]. 77 This document provides the specification of one type of congestion 78 control, based on TCP-Friendly Rate Control (TFRC), which is intended 79 to be fairly conservative in terms of performance. Better-performing 80 congestion-control algorithms are possible in terms of throughput, 81 but this TFRC-based algorithm has the advantages of being relatively 82 simple and based on the well-established TFRC components, rather than 83 on a newer and less well-tested mechanism. 85 Saratoga data flow occurs within uniquely identified transactions 86 between a sender and receiver. Saratoga primitively supports link- 87 local multicast to a set of receivers, but that use case is not 88 considered further in this specification and is considered out of 89 scope for this document. The congestion control mechanism specified 90 in this document operates within a single transaction between a 91 sender and a receiver. Subsequent or concurrent transactions between 92 the same nodes use distinct congestion control state. 94 TFRC has "receiver-based" and "sender-based" variations, as 95 descripted in [RFC5348]. In either case, a node with knowledge of 96 the loss-event rate and round-trip time (RTT) uses this information 97 in the TFRC throughput equation in order to compute an allowed 98 transmit rate for the sender. A sender-based variant of TFRC for use 99 with Saratoga has been described in the academic literature 100 [Shahriar11], and the mechanism described in this document is derived 101 to some extent from that previous work. 103 Saratoga allows the receiver to generate, at any time, a STATUS 104 packet containing a "Progress Indicator" cumulative acknowledgement 105 (PI cumack) and a list of "holes" in the sequence space of data bytes 106 received. The STATUS packet can also be requested to be sent by 107 setting a flag in the DATA packet header. A DATA packet can 108 optionally include a timestamp field, which is echoed in any STATUS 109 packet that it may trigger. This enables the sender to estimate the 110 Round-Trip Time (RTT), required as part of TFRC equation. The TFRC 111 adaptation for Saratoga relies on the regular reception of STATUS 112 packets at the sender, in order for the sender to use its knowledge 113 of the RTT, the packets sent within an interval, and the packets 114 received (implicit from the holes and PI cumack), to run the TFRC 115 equation to determine a reasonable sending rate. 117 Generally, Saratoga is designed to enable high-performance transfers 118 over highly asymmetric and lossy links, which may also have high 119 latencies. The rate-control, in the base specification, has been 120 permitted to be open-loop with the sender configured to saturate the 121 network capacity that it expects exclusive access to. However, in 122 order to permit sender-based TFRC congestion control for shared 123 capacity, accurate and timely feedback is necessary in order to 124 create a functioning closed-loop control system. This limits the 125 applicability of TFRC extensions to Saratoga to networks with RTTs 126 more typical of the Internet than, for instance, interplanetary 127 microwave communications links. Supporting congestion control also 128 limits the asymmetry that can be supported between the data path 129 capacity and the feedback path capacity, as more regular STATUS 130 updates are required for the congestion control loop. 132 2. Receiver-Side Behavior 134 The receiver MUST echo timestamps in non-voluntary (solicited) STATUS 135 packets. It SHOULD generate and transmit these STATUS packets 136 without unnecessary implementation delay. The sender will typically 137 request mandatory STATUS packets at least once per its estimated RTT. 138 If multiple STATUS packets within the same transaction are queued for 139 transmission within the receiver, it MAY choose to only send the most 140 recent STATUS and clear others from its queue. This may help to 141 mitigate asymmetry issues. 143 The Saratoga receiver MUST track the time when it last sent a STATUS 144 packet, and periodically send voluntary (unsolicited) STATUS packets 145 to the sender, even if no DATA packets requesting STATUS have been 146 received. This is needed to provide feedback of progress (or lack of 147 progress) when there is heavy loss in the DATA path, and the sender 148 needs to be informed of this in order to adjust its sending rate. 149 This timer for sending unsolicited STATUS packets MAY be set to the 150 minimum among the the last three measured interarrival times between 151 consecutive DATA packets bearing STATUS requests within the 152 transaction. 154 The receiver SHOULD generate voluntary STATUS packets with an updated 155 holes list when it receives an incoming DATA packets with offset 156 beyond the current cumack (i.e. not advancing the Progress 157 Indicator). This creates a hole in the STATUS packet and provides a 158 timely notification of loss to the sender. Possible exceptions to 159 this behavior would be for highly-asymmetric links, where the 160 feedback traffic needs to be minimized, or for cases where 161 significant reordering is expected and a more intelligent strategy 162 for generating STATUS packets is implemented. 164 3. Sender-Side Behavior 166 As the envisioned use of Saratoga implementations with TFRC is for 167 bulk-transfer applications that will not be "data-limited" in 168 [RFC5348] terms, tracking of data-limited periods and adjusting the 169 sending rate based on them is not required by the specification in 170 this document. 172 The "nofeedback" timer defined in [RFC5348] is reset based on the 173 reception of Saratoga STATUS packets, as these provide the feedback 174 information. 176 It is assumed that the Saratoga sender MUST implement a configurable 177 "Maximum Payload Size" (MPS), which limits the total number of bytes 178 of user data per Saratoga packet. This assumption is used to 179 simplify tracking of lost packets based on STATUS feedback that only 180 provides ranges of DATA holes, and not the detail of individual lost 181 or received packets. The MPS MAY be adjusted downwards by an 182 implementation based on PMTUD feedback, but the details for this are 183 not within scope of this document, and do not impact the TFRC 184 mechanism defined here, as long as the current MPS for a transaction 185 is known by the implementation. 187 The initial sending rate for DATA packets within a Saratoga 188 transaction from the Saratoga sender implementing TFRC is initialized 189 to: 191 X = min(4*MPS, max(2*MPS, 4380)) 192 This is as already defined for TFRC, with the Saratoga transaction 193 MPS used as the Maximum Segment Size that TFRC is based on. During 194 the course of the transaction, this is adjusted as described in the 195 remainder of this section. 197 The Saratoga sender implementing TFRC-based congestion control 198 specified in this document MUST use timestamps on its DATA packets. 199 For each DATA packet that the Saratoga sender releases onto the 200 network, it MUST temporarily store the timestamp, offset, and packet 201 size in a packet history list. The history is accessed by looking 202 for packets sent at or before a given timestamp, and if organized 203 this way by timestamp, continuous portions of the packet history list 204 are periodically cleared during processing of STATUS packets, 205 described later in this section. 207 The sender MUST keep track of a per-transaction estimated RTT based 208 on observance of timestamp echo fields in STATUS packets. On 209 receiving a STATUS packet, an RTT sample is computed via subracting 210 the echoed timestamp from the current clock time. [RFC5348] 211 nominally includes t_delay; no t_delay is employed (or t_delay is 0) 212 as Saratoga does not have a way to convey t_delay. The collection of 213 RTT samples SHOULD be smoothed via an algorithm such as the EWMA 214 described in [RFC6298]. In this document, the use of "RTT" generally 215 refers to the smoothed RTT computed via this process rather than an 216 instantaneous RTT sample, unless clearly noted. 218 When sending DATA packets, the sender MUST periodically request 219 STATUS packets using the available DATA packet flag for this purpose. 220 The time period for making these requests is a minimum of once per 221 the current estimated RTT. 223 There is no assumption of the ordering which a Saratoga sender 224 delivers particular chunks of a file, nor to the order and algorithms 225 which it uses to respond to and repair the list of holes conveyed in 226 the STATUS packets. However, the sender must keep track of the 227 comprehensive set of holes within the transaction that have been seen 228 most recently in STATUS feedback. 230 On receiving an STATUS packet, the Saratoga sender MUST compute a 231 loss rate sample. The loss rate in packets is computed via comparing 232 the changes between the current snapshot and the prior one generated 233 when the last STATUS packet was received. Signs of positive progress 234 include: (1) advancement of the cumack field by some multiple of the 235 MPS (or less than one MPS in the case of the final packet of DATA 236 within a transaction, (2) reduction in the size of any holes. The 237 number of MPS-sized chunks, packets_rcvd, covered by signs of 238 positive progress in the current STATUS packet represents the number 239 of non-duplicate packets received during the last reporting interval 240 (assuming a prior STATUS packet was not lost). The sender uses its 241 history of sent DATA packets and the timestamp echoed in the STATUS 242 in order to determine how many DATA packets were sent within the 243 interval. It simply counts the number of packets, packets_sent, in 244 the history with timestamps prior or equal to the echoed one. At 245 this point, the packet history at or below the echoed timestamp can 246 be cleared or released. packets_ecnd is always 0, as implementing 247 support for ECN from a UDP application raises implementation 248 difficulties. The loss event rate sample for the TFRC equation, p, 249 is then computed from packets_sent, packets_rcvd, and packets_ecnd as 250 described below. This loss rate sample, along with the current RTT 251 measurement are fed into the TFRC equation to arrive at a sending 252 rate for the Saratoga sender. 254 The values needed to compute the TCP sending rate (X_Bps) from the 255 TFRC equation, using the variable names from [RFC5348] are: 257 o s := the MPS value configured for the transaction 259 o R := the current smoothed RTT 261 o p := the computed loss event rate; 1 - ((packets_rcvd - 262 packets_ecnd) / packets_sent) 264 o t_RTO := 4*R (as recommended by [RFC5348] 266 o b := 1 (as recommended by [RFC5348] 268 The TFRC procedure for computing X_recv_set, recv_limit, X_Bps, and X 269 are performed as defined in [RFC5348] per STATUS packet received, 270 along with the rest of the TFRC feedback processing. The new X value 271 is immediately applied to the Saratoga implementation's outgoing 272 packet clocking. 274 4. Security Considerations 276 The security considerations for use of TFRC in Saratoga are the same 277 as those described in [RFC5348] for TFRC itself (but do not share the 278 considerations listed there for TFRC's use in DCCP). 280 5. IANA Considerations 282 This document has no IANA considerations. 284 6. Acknowledgements 286 We thank Cisco Systems for funding the early investigations into 287 Saratoga congestion control that led to [Shahriar11], which has 288 heavily influenced this document. 290 7. References 292 7.1. Normative References 294 [RFC5348] Floyd, S., Handley, M., Padhye, J., and J. Widmer, "TCP 295 Friendly Rate Control (TFRC): Protocol Specification", RFC 296 5348, September 2008. 298 [draft-wood-tsvwg-saratoga] 299 Wood, L., Eddy, W., Smith, C., Ivancic, W., and C. 300 Jackson, "Saratoga: A Scalable Data Transfer Protocol", 301 draft-wood-tsvwg-saratoga-17 (work in progress) , April 302 2015. 304 7.2. Informative References 306 [RFC5405] Eggert, L. and G. Fairhurst, "Unicast UDP Usage Guidelines 307 for Application Designers", BCP 145, RFC 5405, November 308 2008. 310 [RFC6298] Paxson, V., Allman, M., Chu, J., and M. Sargent, 311 "Computing TCP's Retransmission Timer", RFC 6298, June 312 2011. 314 [Shahriar11] 315 Shahriar, A., Atiquzzaman, M., Ivancic, W., and L. Wood, 316 "A sender-based TFRC for Saratoga: A rate control 317 mechanism for a space-friendly transfer protocol", IEEE 318 Aerospace Conference Big Sky, Montana, March 2011. 320 Appendix A. Differences from Shahriar et al. 322 The method described in this document does not involve keeping track 323 of the "symmetry factor" that was a part of [Shahriar11]. 325 The method described in this document does not use the "dummy 326 sequences" described as part of [Shahriar11], and instead infers lost 327 packet counts from the number of bytes covered by holes above the PI 328 cumack (the Progress Indicator). This inference is possible whenever 329 the cumack is less than the highest sequence number expected (the In- 330 Response-To field) within the last loss period. 332 Authors' Addresses 334 Wesley M. Eddy 335 MTI Systems 337 Email: wes@mti-systems.com 339 Lloyd Wood 340 University of Surrey alumni 341 Sydney, New South Wales 342 Australia 344 Email: L.Wood@society.surrey.ac.uk 346 Will Ivancic 347 NASA Glenn Research Center 348 21000 Brookpark Road, MS 54-5 349 Cleveland, OH 44135 350 USA 352 Phone: +1-216-433-3494 353 Email: William.D.Ivancic@grc.nasa.gov