idnits 2.17.1 draft-wood-tsvwg-saratoga-congestion-control-05.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 : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The exact meaning of the all-uppercase expression 'MAY NOT' is not defined in RFC 2119. If it is intended as a requirements expression, it should be rewritten using one of the combinations defined in RFC 2119; otherwise it should not be all-uppercase. == The expression 'MAY NOT', while looking like RFC 2119 requirements text, is not defined in RFC 2119, and should not be used. Consider using 'MUST NOT' instead (if that is what you mean). Found 'MAY NOT' in this paragraph: Congestion control MUST be supported and used if Saratoga is being used across paths that go over the public Internet, and SHOULD be supported in environments where links in the path are shared by traffic flows. Congestion control MAY NOT be supported across private, single-flow links engineered for performance: Saratoga's primary use case. -- The document date (April 19, 2014) is 3632 days in the past. Is this intentional? Checking references for intended status: Experimental ---------------------------------------------------------------------------- == Unused Reference: 'RFC0768' is defined on line 163, but no explicit reference was found in the text -- Obsolete informational reference (is this intentional?): RFC 5405 (Obsoleted by RFC 8085) Summary: 0 errors (**), 0 flaws (~~), 3 warnings (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group L. Wood 3 Internet-Draft Surrey alumni 4 Intended status: Experimental W. Eddy 5 Expires: October 21, 2014 MTI Systems 6 W. Ivancic 7 NASA 8 April 19, 2014 10 Congestion control for the Saratoga protocol 11 draft-wood-tsvwg-saratoga-congestion-control-05 13 Abstract 15 Saratoga is a data transfer protocol designed to carry potentially 16 large volumes of data over difficult network paths, often including 17 only a single high-rate link and only one application flow. As the 18 requirements for use vary across deployment environments, the base 19 Saratoga specification only assumes that an implementation will be 20 able to clock packets out at a configurable rate, and beyond this 21 specifies no inherent or particular congestion-control behaviour. 22 The design of Saratoga deliberately supports the integration of 23 congestion-control algorithms without modification to the base 24 protocol. This document describes how congestion control can be 25 supported in the Saratoga transfer protocol. Saratoga is intended 26 for use in private networks, where its use is engineered as a single 27 flow to fill a link. However, as Saratoga is implemented over UDP, 28 it can be multiplexed, and can be run across the public Internet, in 29 which case congestion control in accordance with the UDP Guidelines 30 becomes necessary. 32 Status of This Memo 34 This Internet-Draft is submitted to IETF in full conformance with the 35 provisions of BCP 78 and BCP 79. 37 Internet-Drafts are working documents of the Internet Engineering 38 Task Force (IETF). Note that other groups may also distribute 39 working documents as Internet-Drafts. The list of current Internet- 40 Drafts is at http://datatracker.ietf.org/drafts/current/. 42 Internet-Drafts are draft documents valid for a maximum of six months 43 and may be updated, replaced, or obsoleted by other documents at any 44 time. It is inappropriate to use Internet-Drafts as reference 45 material or to cite them other than as "work in progress." 47 This Internet-Draft will expire on October 21, 2014. 49 Copyright Notice 51 Copyright (c) 2014 IETF Trust and the persons identified as the 52 document authors. All rights reserved. 54 This document is subject to BCP 78 and the IETF Trust's Legal 55 Provisions Relating to IETF Documents 56 (http://trustee.ietf.org/license-info) in effect on the date of 57 publication of this document. Please review these documents 58 carefully, as they describe your rights and restrictions with respect 59 to this document. 61 This document may not be modified, and derivative works of it may not 62 be created, except to format it for publication as an RFC or to 63 translate it into languages other than English. 65 Table of Contents 67 1. Background and Introduction . . . . . . . . . . . . . . . . . 2 68 2. Approaches to congestion control . . . . . . . . . . . . . . 3 69 2.1. TCP-friendly rate control . . . . . . . . . . . . . . . . 3 70 2.2. Explicit Congestion Notification . . . . . . . . . . . . 3 71 3. Security Considerations . . . . . . . . . . . . . . . . . . . 4 72 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 4 73 5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 4 74 6. References . . . . . . . . . . . . . . . . . . . . . . . . . 4 75 6.1. Normative References . . . . . . . . . . . . . . . . . . 4 76 6.2. Informative References . . . . . . . . . . . . . . . . . 4 77 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 5 79 1. Background and Introduction 81 The Saratoga data transfer protocol is described in 82 [draft-wood-tsvwg-saratoga]. Given that Saratoga was originally 83 developed for scheduled peer-to-peer communications over dedicated 84 links in private networks, where each application has the entire link 85 for the duration of its transfer, many Saratoga implementations 86 deliberately lack any form of congestion control and send at line 87 rate to maximise throughput and link utilisation in their 88 environments. Congestion control is necessary for use in the public 89 Internet, in accordance with the UDP Guidelines [RFC5405]. Newer 90 Saratoga implementations may use timestamps to perform TCP-Friendly 91 Rate Control (TFRC) [RFC5348] or other congestion control mechanisms 92 such as LEDBAT [RFC6817], if appropriate for the environment, and 93 where simultaneous sharing of capacity with other traffic and 94 applications is required. Sender-side TFRC for Saratoga has been 95 shown to be possible without modifications to the Saratoga protocol 96 specification, using existing timestamps on selective negative 97 acknowledgement messages [draft-eddy-tsvwg-saratoga-tfrc]. 99 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 100 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 101 document are to be interpreted as described in RFC 2119. [RFC2119] 103 2. Approaches to congestion control 105 Saratoga can be implemented to perform congestion control at the 106 sender, based on feedback from acknowledgement STATUS packets, or 107 have the sender configured to use simple open-loop rate control to 108 only use a fixed amount of link capacity. Congestion control is 109 expected to be undesirable for many of Saratoga's use cases and 110 expected environmental conditions, while simple rate control is 111 considered useful for some use cases. Use over the public Internet 112 requires congestion control. 114 Congestion control MUST be supported and used if Saratoga is being 115 used across paths that go over the public Internet, and SHOULD be 116 supported in environments where links in the path are shared by 117 traffic flows. Congestion control MAY NOT be supported across 118 private, single-flow links engineered for performance: Saratoga's 119 primary use case. 121 2.1. TCP-friendly rate control 123 Sender-side TCP-friendly rate control can be implemented by mirroring 124 timestamps in STATUS messages and using the approach outlined in 125 [draft-eddy-tsvwg-saratoga-tfrc]. 127 Other approaches to TCP-friendly congestion control are possible, and 128 Saratoga and its selective negative acknowledgements may prove useful 129 as an implementation testbed for developing and refining new 130 congestion-control algorithms. 132 2.2. Explicit Congestion Notification 134 Supporting Explicit Congestion Notification in a UDP-based protocol 135 such as Saratoga requires that ECN events be exposed to userspace 136 applications using UDP via a programming interface. Once such a 137 programming interface becomes available, providing counts of ECN 138 events in STATUS and DATA packets will be straightforward. Until 139 that time, specifying ECN support in more detail is not required. 141 3. Security Considerations 143 Use of effective congestion control mechanisms always raises concerns 144 about fairness and spoofing or misleading senders - issues not unique 145 to Saratoga. 147 4. IANA Considerations 149 There should be no additional IANA considerations. 151 5. Acknowledgements 153 We thank the IETF for reminding us about the importance of congestion 154 for standards-track protocols. 156 Work on this document at NASA's Glenn Research Center was funded by 157 NASA's Earth Science Technology Office (ESTO). 159 6. References 161 6.1. Normative References 163 [RFC0768] Postel, J., "User Datagram Protocol", STD 6, RFC 768, 164 August 1980. 166 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 167 Requirement Levels", BCP 14, RFC 2119, March 1997. 169 6.2. Informative References 171 [RFC5348] Floyd, S., Handley, M., Padhye, J., and J. Widmer, "TCP 172 Friendly Rate Control (TFRC): Protocol Specification", RFC 173 5348, September 2008. 175 [RFC5405] Eggert, L. and G. Fairhurst, "Unicast UDP Usage Guidelines 176 for Application Designers", BCP 145, RFC 5405, November 177 2008. 179 [RFC6817] Shalunov, S., Hazel, G., Iyengar, J., and M. Kuehlewind, 180 "Low Extra Delay Background Transport (LEDBAT)", RFC 6817, 181 December 2012. 183 [draft-eddy-tsvwg-saratoga-tfrc] 184 Eddy, W., Wood, L., and W. Ivancic, "TFRC-based congestion 185 control for Saratoga", draft-eddy-tsvwg-saratoga-tfrc-05 186 (work in progress) , April 2014. 188 [draft-wood-tsvwg-saratoga] 189 Wood, L., Eddy, W., Smith, C., Ivancic, W., and C. 190 Jackson, "Saratoga: A Scalable Data Transfer Protocol", 191 draft-wood-tsvwg-saratoga-15 (work in progress) , April 192 2014. 194 Authors' Addresses 196 Lloyd Wood 197 University of Surrey alumni 198 Sydney, New South Wales 199 Australia 201 Email: L.Wood@society.surrey.ac.uk 203 Wesley M. Eddy 204 MTI Systems 205 MS 500-ASRC 206 NASA Glenn Research Center 207 21000 Brookpark Road 208 Cleveland, OH 44135 209 USA 211 Phone: +1-216-433-6682 212 Email: wes@mti-systems.com 214 Will Ivancic 215 NASA Glenn Research Center 216 21000 Brookpark Road, MS 54-5 217 Cleveland, OH 44135 218 USA 220 Phone: +1-216-433-3494 221 Email: William.D.Ivancic@grc.nasa.gov