idnits 2.17.1 draft-wood-tsvwg-saratoga-congestion-control-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 : ---------------------------------------------------------------------------- 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 6, 2012) is 4219 days in the past. Is this intentional? Checking references for intended status: Experimental ---------------------------------------------------------------------------- == Unused Reference: 'RFC0768' is defined on line 164, 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 (==), 3 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 9, 2013 MTI Systems 6 W. Ivancic 7 NASA 8 October 6, 2012 10 Congestion control for the Saratoga protocol 11 draft-wood-tsvwg-saratoga-congestion-control-02 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. This document may not be modified, 36 and derivative works of it may not be created, except to format it 37 for publication as an RFC and to translate it into languages other 38 than English. 40 Internet-Drafts are working documents of the Internet Engineering 41 Task Force (IETF). Note that other groups may also distribute 42 working documents as Internet-Drafts. The list of current Internet- 43 Drafts is at http://datatracker.ietf.org/drafts/current/. 45 Internet-Drafts are draft documents valid for a maximum of six months 46 and may be updated, replaced, or obsoleted by other documents at any 47 time. It is inappropriate to use Internet-Drafts as reference 48 material or to cite them other than as "work in progress." 49 This Internet-Draft will expire on April 9, 2013. 51 Copyright Notice 53 Copyright (c) 2012 IETF Trust and the persons identified as the 54 document authors. All rights reserved. 56 This document is subject to BCP 78 and the IETF Trust's Legal 57 Provisions Relating to IETF Documents 58 (http://trustee.ietf.org/license-info) in effect on the date of 59 publication of this document. Please review these documents 60 carefully, as they describe your rights and restrictions with respect 61 to this document. Code Components extracted from this document must 62 include Simplified BSD License text as described in Section 4.e of 63 the Trust Legal Provisions and are provided without warranty as 64 described in the Simplified BSD License. 66 Table of Contents 68 1. Background and Introduction . . . . . . . . . . . . . . . . . . 4 69 2. Approaches to congestion control . . . . . . . . . . . . . . . 4 70 2.1. TCP-friendly rate control . . . . . . . . . . . . . . . . . 4 71 2.2. Explicit Congestion Notification . . . . . . . . . . . . . 5 72 3. Security Considerations . . . . . . . . . . . . . . . . . . . . 5 73 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 5 74 5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 5 75 6. References . . . . . . . . . . . . . . . . . . . . . . . . . . 5 76 6.1. Normative References . . . . . . . . . . . . . . . . . . . 5 77 6.2. Informative References . . . . . . . . . . . . . . . . . . 6 78 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 6 80 1. Background and Introduction 82 The Saratoga data transfer protocol is described in 83 [draft-wood-tsvwg-saratoga]. Given that Saratoga was originally 84 developed for scheduled peer-to-peer communications over dedicated 85 links in private networks, where each application has the entire link 86 for the duration of its transfer, many Saratoga implementations 87 deliberately lack any form of congestion control and send at line 88 rate to maximise throughput and link utilisation in their 89 environments. Congestion control is necessary for use in the public 90 Internet, in accordance with the UDP Guidelines [RFC5405]. Newer 91 Saratoga implementations may use timestamps to perform TCP-Friendly 92 Rate Control (TFRC) [RFC5348] or other congestion control mechanisms 93 such as LEDBAT [I-D.ietf-ledbat-congestion], if appropriate for the 94 environment, and where simultaneous sharing of capacity with other 95 traffic and applications is required. Sender-side TFRC for Saratoga 96 has been shown to be possible without modifications to the Saratoga 97 protocol specification, using existing timestamps on selective 98 negative acknowledgement messages [draft-eddy-tsvwg-saratoga-tfrc]. 100 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 101 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 102 document are to be interpreted as described in RFC 2119. [RFC2119] 104 2. Approaches to congestion control 106 Saratoga can be implemented to perform congestion control at the 107 sender, based on feedback from acknowledgement STATUS packets, or 108 have the sender configured to use simple open-loop rate control to 109 only use a fixed amount of link capacity. Congestion control is 110 expected to be undesirable for many of Saratoga's use cases and 111 expected environmental conditions, while simple rate control is 112 considered useful for some use cases. Use over the public Internet 113 requires congestion control. 115 Congestion control MUST be supported and used if Saratoga is being 116 used across paths that go over the public Internet, and SHOULD be 117 supported in environments where links in the path are shared by 118 traffic flows. Congestion control MAY NOT be supported across 119 private, single-flow links engineered for performance: Saratoga's 120 primary use case. 122 2.1. TCP-friendly rate control 124 Sender-side TCP-friendly rate control can be implemented by mirroring 125 timestamps in STATUS messages and using the approach outlined in 126 [draft-eddy-tsvwg-saratoga-tfrc]. 128 Other approaches to TCP-friendly congestion control are possible, and 129 Saratoga and its selective negative acknowledgements may prove useful 130 as an implementation testbed for developing and refining new 131 congestion-control algorithms. 133 2.2. Explicit Congestion Notification 135 Supporting Explicit Congestion Notification in a UDP-based protocol 136 such as Saratoga requires that ECN events be exposed to userspace 137 applications using UDP via a programming interface. Once such a 138 programming interface becomes available, providing counts of ECN 139 events in STATUS and DATA packets will be straightforward. Until 140 that time, specifying ECN support in more detail is not required. 142 3. Security Considerations 144 Use of effective congestion control mechanisms always raises concerns 145 about fairness and spoofing or misleading senders - issues not unique 146 to Saratoga. 148 4. IANA Considerations 150 There should be no additional IANA considerations. 152 5. Acknowledgements 154 We thank the IETF for reminding us about the importance of congestion 155 for standards-track protocols. 157 Work on this document at NASA's Glenn Research Center was funded by 158 NASA's Earth Science Technology Office (ESTO). 160 6. References 162 6.1. Normative References 164 [RFC0768] Postel, J., "User Datagram Protocol", STD 6, RFC 768, 165 August 1980. 167 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 168 Requirement Levels", BCP 14, RFC 2119, March 1997. 170 6.2. Informative References 172 [I-D.ietf-ledbat-congestion] 173 Shalunov, S., Hazel, G., Iyengar, J., and M. Kuehlewind, 174 "Low Extra Delay Background Transport (LEDBAT)", 175 draft-ietf-ledbat-congestion-10 (work in progress), 176 September 2012. 178 [RFC5348] Floyd, S., Handley, M., Padhye, J., and J. Widmer, "TCP 179 Friendly Rate Control (TFRC): Protocol Specification", 180 RFC 5348, September 2008. 182 [RFC5405] Eggert, L. and G. Fairhurst, "Unicast UDP Usage Guidelines 183 for Application Designers", BCP 145, RFC 5405, 184 November 2008. 186 [draft-eddy-tsvwg-saratoga-tfrc] 187 Eddy, W., Wood, L., and W. Ivancic, "TFRC-based congestion 188 control for Saratoga", draft-eddy-tsvwg-saratoga-tfrc-02 189 (work in progress) , October 2012. 191 [draft-wood-tsvwg-saratoga] 192 Wood, L., Eddy, W., Smith, C., Ivancic, W., and C. 193 Jackson, "Saratoga: A Scalable Data Transfer Protocol", 194 draft-wood-tsvwg-saratoga-12 (work in progress) , 195 October 2012. 197 Authors' Addresses 199 Lloyd Wood 200 University of Surrey alumni 201 Sydney, New South Wales 202 Australia 204 Email: L.Wood@society.surrey.ac.uk 205 Wesley M. Eddy 206 MTI Systems 207 MS 500-ASRC 208 NASA Glenn Research Center 209 21000 Brookpark Road 210 Cleveland, OH 44135 211 USA 213 Phone: +1-216-433-6682 214 Email: wes@mti-systems.com 216 Will Ivancic 217 NASA Glenn Research Center 218 21000 Brookpark Road, MS 54-5 219 Cleveland, OH 44135 220 USA 222 Phone: +1-216-433-3494 223 Email: William.D.Ivancic@grc.nasa.gov