idnits 2.17.1 draft-wood-tsvwg-saratoga-congestion-control-04.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 (October 20, 2013) is 3835 days in the past. Is this intentional? Checking references for intended status: Experimental ---------------------------------------------------------------------------- == Unused Reference: 'RFC0768' is defined on line 162, 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: April 23, 2014 MTI Systems 6 W. Ivancic 7 NASA 8 October 20, 2013 10 Congestion control for the Saratoga protocol 11 draft-wood-tsvwg-saratoga-congestion-control-04 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 April 23, 2014. 49 Copyright Notice 51 Copyright (c) 2013 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 . . . . . . . . . . . . 4 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 80 The Saratoga data transfer protocol is described in 81 [draft-wood-tsvwg-saratoga]. Given that Saratoga was originally 82 developed for scheduled peer-to-peer communications over dedicated 83 links in private networks, where each application has the entire link 84 for the duration of its transfer, many Saratoga implementations 85 deliberately lack any form of congestion control and send at line 86 rate to maximise throughput and link utilisation in their 87 environments. Congestion control is necessary for use in the public 88 Internet, in accordance with the UDP Guidelines [RFC5405]. Newer 89 Saratoga implementations may use timestamps to perform TCP-Friendly 90 Rate Control (TFRC) [RFC5348] or other congestion control mechanisms 91 such as LEDBAT [RFC6817], if appropriate for the environment, and 92 where simultaneous sharing of capacity with other traffic and 93 applications is required. Sender-side TFRC for Saratoga has been 94 shown to be possible without modifications to the Saratoga protocol 95 specification, using existing timestamps on selective negative 96 acknowledgement messages [draft-eddy-tsvwg-saratoga-tfrc]. 98 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 99 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 100 document are to be interpreted as described in RFC 2119. [RFC2119] 102 2. Approaches to congestion control 104 Saratoga can be implemented to perform congestion control at the 105 sender, based on feedback from acknowledgement STATUS packets, or 106 have the sender configured to use simple open-loop rate control to 107 only use a fixed amount of link capacity. Congestion control is 108 expected to be undesirable for many of Saratoga's use cases and 109 expected environmental conditions, while simple rate control is 110 considered useful for some use cases. Use over the public Internet 111 requires congestion control. 113 Congestion control MUST be supported and used if Saratoga is being 114 used across paths that go over the public Internet, and SHOULD be 115 supported in environments where links in the path are shared by 116 traffic flows. Congestion control MAY NOT be supported across 117 private, single-flow links engineered for performance: Saratoga's 118 primary use case. 120 2.1. TCP-friendly rate control 122 Sender-side TCP-friendly rate control can be implemented by mirroring 123 timestamps in STATUS messages and using the approach outlined in 124 [draft-eddy-tsvwg-saratoga-tfrc]. 126 Other approaches to TCP-friendly congestion control are possible, and 127 Saratoga and its selective negative acknowledgements may prove useful 128 as an implementation testbed for developing and refining new 129 congestion-control algorithms. 131 2.2. Explicit Congestion Notification 133 Supporting Explicit Congestion Notification in a UDP-based protocol 134 such as Saratoga requires that ECN events be exposed to userspace 135 applications using UDP via a programming interface. Once such a 136 programming interface becomes available, providing counts of ECN 137 events in STATUS and DATA packets will be straightforward. Until 138 that time, specifying ECN support in more detail is not required. 140 3. Security Considerations 142 Use of effective congestion control mechanisms always raises concerns 143 about fairness and spoofing or misleading senders - issues not unique 144 to Saratoga. 146 4. IANA Considerations 148 There should be no additional IANA considerations. 150 5. Acknowledgements 152 We thank the IETF for reminding us about the importance of congestion 153 for standards-track protocols. 155 Work on this document at NASA's Glenn Research Center was funded by 156 NASA's Earth Science Technology Office (ESTO). 158 6. References 160 6.1. Normative References 162 [RFC0768] Postel, J., "User Datagram Protocol", STD 6, RFC 768, 163 August 1980. 165 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 166 Requirement Levels", BCP 14, RFC 2119, March 1997. 168 6.2. Informative References 170 [RFC5348] Floyd, S., Handley, M., Padhye, J., and J. Widmer, "TCP 171 Friendly Rate Control (TFRC): Protocol Specification", RFC 172 5348, September 2008. 174 [RFC5405] Eggert, L. and G. Fairhurst, "Unicast UDP Usage Guidelines 175 for Application Designers", BCP 145, RFC 5405, November 176 2008. 178 [RFC6817] Shalunov, S., Hazel, G., Iyengar, J., and M. Kuehlewind, 179 "Low Extra Delay Background Transport (LEDBAT)", RFC 6817, 180 December 2012. 182 [draft-eddy-tsvwg-saratoga-tfrc] 183 Eddy, W., Wood, L., and W. Ivancic, "TFRC-based congestion 184 control for Saratoga", draft-eddy-tsvwg-saratoga-tfrc-04 185 (work in progress) , October 2013. 187 [draft-wood-tsvwg-saratoga] 188 Wood, L., Eddy, W., Smith, C., Ivancic, W., and C. 189 Jackson, "Saratoga: A Scalable Data Transfer Protocol", 190 draft-wood-tsvwg-saratoga-14 (work in progress) , October 191 2013. 193 Authors' Addresses 195 Lloyd Wood 196 University of Surrey alumni 197 Sydney, New South Wales 198 Australia 200 Email: L.Wood@society.surrey.ac.uk 202 Wesley M. Eddy 203 MTI Systems 204 MS 500-ASRC 205 NASA Glenn Research Center 206 21000 Brookpark Road 207 Cleveland, OH 44135 208 USA 210 Phone: +1-216-433-6682 211 Email: wes@mti-systems.com 212 Will Ivancic 213 NASA Glenn Research Center 214 21000 Brookpark Road, MS 54-5 215 Cleveland, OH 44135 216 USA 218 Phone: +1-216-433-3494 219 Email: William.D.Ivancic@grc.nasa.gov