idnits 2.17.1 draft-eddy-tsvwg-saratoga-tfrc-02.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. 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 133: '... The receiver MUST echo timestamps i...' RFC 2119 keyword, line 134: '... packets. It SHOULD generate and tr...' RFC 2119 keyword, line 138: '...the receiver, it MAY choose to only se...' RFC 2119 keyword, line 142: '...aratoga receiver MUST track the time w...' RFC 2119 keyword, line 148: '...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 (October 6, 2012) is 4220 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 (==), 2 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: April 9, 2013 Surrey alumni 6 W. Ivancic 7 NASA 8 October 6, 2012 10 TFRC-based Congestion Control for Saratoga 11 draft-eddy-tsvwg-saratoga-tfrc-02 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 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 April 9, 2013. 37 Copyright Notice 39 Copyright (c) 2012 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. Code Components extracted from this document must 48 include Simplified BSD License text as described in Section 4.e of 49 the Trust Legal Provisions and are provided without warranty as 50 described in the Simplified BSD License. 52 Table of Contents 54 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 55 2. Receiver-Side Behavior . . . . . . . . . . . . . . . . . . . . 5 56 3. Sender-Side Behavior . . . . . . . . . . . . . . . . . . . . . 6 57 4. Security Considerations . . . . . . . . . . . . . . . . . . . 9 58 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 59 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 11 60 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 12 61 7.1. Normative References . . . . . . . . . . . . . . . . . . . 12 62 7.2. Informative References . . . . . . . . . . . . . . . . . . 12 63 Appendix A. Differences from Shahriar et al. . . . . . . . . . . 13 64 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 14 66 1. Introduction 68 In order to support use of the Saratoga protocol 69 [draft-wood-tsvwg-saratoga] on networks with multiple data flows, 70 multiple hops, and/or experimentally on the Internet, some form of 71 congestion control is required. Particularly, for use on the 72 Internet, rather than the private links and networks that Saratoga 73 was originally developed for, congestion control is a requirement, as 74 indicated by the UDP Guidelines [RFC5405]. 76 This document provides the specification of one type of congestion 77 control, based on TCP-Friendly Rate Control (TFRC), which is intended 78 to be fairly conservative in terms of performance. Better-performing 79 congestion-control algorithms are possible in terms of throughput, 80 but this TFRC-based algorithm has the advantages of being relatively 81 simple and based on the well-established TFRC components, rather than 82 on a newer and less well-tested mechanism. 84 Saratoga data flow occurs within uniquely identified transactions 85 between a sender and receiver. Saratoga primitively supports link- 86 local multicast to a set of receivers, but that use case is not 87 considered further in this specification and is considered out of 88 scope for this document. The congestion control mechanism specified 89 in this document operates within a single transaction between a 90 sender and a receiver. Subsequent or concurrent transactions between 91 the same nodes use distinct congestion control state. 93 TFRC has "receiver-based" and "sender-based" variations, as 94 descripted in [RFC5348]. In either case, a node with knowledge of 95 the loss-event rate and round-trip time (RTT) uses this information 96 in the TFRC throughput equation in order to compute an allowed 97 transmit rate for the sender. A sender-based variant of TFRC for use 98 with Saratoga has been described in the academic literature 99 [Shahriar11], and the mechanism described in this document is derived 100 to some extent from that previous work. 102 Saratoga allows the receiver to generate, at any time, a STATUS 103 packet containing a "Progress Indicator" cumulative acknowledgement 104 (PI cumack) and a list of "holes" in the sequence space of data bytes 105 received. The STATUS packet can also be requested to be sent by 106 setting a flag in the DATA packet header. A DATA packet can 107 optionally include a timestamp field, which is echoed in any STATUS 108 packet that it may trigger. This enables the sender to estimate the 109 Round-Trip Time (RTT), required as part of TFRC equation. The TFRC 110 adaptation for Saratoga relies on the regular reception of STATUS 111 packets at the sender, in order for the sender to use its knowledge 112 of the RTT, the packets sent within an interval, and the packets 113 received (implicit from the holes and PI cumack), to run the TFRC 114 equation to determine a reasonable sending rate. 116 Generally, Saratoga is designed to enable high-performance transfers 117 over highly asymmetric and lossy links, which may also have high 118 latencies. The rate-control, in the base specification, has been 119 permitted to be open-loop with the sender configured to saturate the 120 network capacity that it expects exclusive access to. However, in 121 order to permit sender-based TFRC congestion control for shared 122 capacity, accurate and timely feedback is necessary in order to 123 create a functioning closed-loop control system. This limits the 124 applicability of TFRC extensions to Saratoga to networks with RTTs 125 more typical of the Internet than, for instance, interplanetary 126 microwave communications links. Supporting congestion control also 127 limits the asymmetry that can be supported between the data path 128 capacity and the feedback path capacity, as more regular STATUS 129 updates are required for the congestion control loop. 131 2. Receiver-Side Behavior 133 The receiver MUST echo timestamps in non-voluntary (solicited) STATUS 134 packets. It SHOULD generate and transmit these STATUS packets 135 without unnecessary implementation delay. The sender will typically 136 request mandatory STATUS packets at least once per its estimated RTT. 137 If multiple STATUS packets within the same transaction are queued for 138 transmission within the receiver, it MAY choose to only send the most 139 recent STATUS and clear others from its queue. This may help to 140 mitigate asymmetry issues. 142 The Saratoga receiver MUST track the time when it last sent a STATUS 143 packet, and periodically send voluntary (unsolicited) STATUS packets 144 to the sender, even if no DATA packets requesting STATUS have been 145 received. This is needed to provide feedback of progress (or lack of 146 progress) when there is heavy loss in the DATA path, and the sender 147 needs to be informed of this in order to adjust its sending rate. 148 This timer for sending unsolicited STATUS packets MAY be set to the 149 minimum among the the last three measured interarrival times between 150 consecutive DATA packets bearing STATUS requests within the 151 transaction. 153 The receiver SHOULD generate voluntary STATUS packets with an updated 154 holes list when it receives an incoming DATA packets with offset 155 beyond the current cumack (i.e. not advancing the Progress 156 Indicator). This creates a hole in the STATUS packet and provides a 157 timely notification of loss to the sender. Possible exceptions to 158 this behavior would be for highly-asymmetric links, where the 159 feedback traffic needs to be minimized, or for cases where 160 significant reordering is expected and a more intelligent strategy 161 for generating STATUS packets is implemented. 163 3. Sender-Side Behavior 165 As the envisioned use of Saratoga implementations with TFRC is for 166 bulk-transfer applications that will not be "data-limited" in 167 [RFC5348] terms, tracking of data-limited periods and adjusting the 168 sending rate based on them is not required by the specification in 169 this document. 171 The "nofeedback" timer defined in [RFC5348] is reset based on the 172 reception of Saratoga STATUS packets, as these provide the feedback 173 information. 175 It is assumed that the Saratoga sender MUST implement a configurable 176 "Maximum Payload Size" (MPS), which limits the total number of bytes 177 of user data per Saratoga packet. This assumption is used to 178 simplify tracking of lost packets based on STATUS feedback that only 179 provides ranges of DATA holes, and not the detail of individual lost 180 or received packets. The MPS MAY be adjusted downwards by an 181 implementation based on PMTUD feedback, but the details for this are 182 not within scope of this document, and do not impact the TFRC 183 mechanism defined here, as long as the current MPS for a transaction 184 is known by the implementation. 186 The initial sending rate for DATA packets within a Saratoga 187 transaction from the Saratoga sender implementing TFRC is initialized 188 to: 190 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 procecess 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", 296 RFC 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-12 (work in progress) , 302 October 2012. 304 7.2. Informative References 306 [RFC5405] Eggert, L. and G. Fairhurst, "Unicast UDP Usage Guidelines 307 for Application Designers", BCP 145, RFC 5405, 308 November 2008. 310 [RFC6298] Paxson, V., Allman, M., Chu, J., and M. Sargent, 311 "Computing TCP's Retransmission Timer", RFC 6298, 312 June 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