University of Surrey alumni

SydneyNew South Wales Australia L.Wood@society.surrey.ac.uk

MTI Systems

MS 500-ASRC NASA Glenn Research Center 21000 Brookpark Road ClevelandOH 44135 USA +1-216-433-6682 wes@mti-systems.com

Syzygy Engineering LLC

WestlakeOH 44145 USA +1-440-835-8448 ivancic@syzygyengineering.com

congestion control Saratoga TCP friendly TFRC Saratoga is a data transfer protocol designed to carry potentially large volumes of data over difficult network paths, often including only a single high-rate link and only one application flow. As the requirements for use vary across deployment environments, the base Saratoga specification only assumes that an implementation will be able to clock packets out at a configurable rate, and beyond this specifies no inherent or particular congestion-control behaviour. The design of Saratoga deliberately supports the integration of congestion-control algorithms without modification to the base protocol. This document describes how congestion control can be supported in the Saratoga transfer protocol. Saratoga is intended for use in private networks, where its use is engineered as a single flow to fill a link. However, as Saratoga is implemented over UDP, it can be multiplexed, and can be run across the public Internet, in which case congestion control in accordance with the UDP Guidelines becomes necessary.

The Saratoga data transfer protocol is described in . Given that Saratoga was originally developed for scheduled peer-to-peer communications over dedicated links in private networks, where each application has the entire link for the duration of its transfer, many Saratoga implementations deliberately lack any form of congestion control and send at line rate to maximise throughput and link utilisation in their environments. Congestion control is necessary for use in the public Internet, in accordance with the UDP Guidelines . Newer Saratoga implementations may use timestamps to perform TCP-Friendly Rate Control (TFRC) or other congestion control mechanisms such as LEDBAT , if appropriate for the environment, and where simultaneous sharing of capacity with other traffic and applications is required. Sender-side TFRC for Saratoga has been shown to be possible without modifications to the Saratoga protocol specification, using existing timestamps on selective negative acknowledgement messages . The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119.

Saratoga can be implemented to perform congestion control at the sender, based on feedback from acknowledgement STATUS packets, or have the sender configured to use simple open-loop rate control to only use a fixed amount of link capacity. Congestion control is expected to be undesirable for many of Saratoga's use cases and expected environmental conditions, while simple rate control is considered useful for some use cases. Use over the public Internet requires congestion control. 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.

Sender-side TCP-friendly rate control can be implemented by mirroring timestamps in STATUS messages and using the approach outlined in . Other approaches to TCP-friendly congestion control are possible, and Saratoga and its selective negative acknowledgements may prove useful as an implementation testbed for developing and refining new congestion-control algorithms.

Supporting Explicit Congestion Notification in a UDP-based protocol such as Saratoga requires that ECN events be exposed to userspace applications using UDP via a programming interface. Once such a programming interface becomes available, providing counts of ECN events in STATUS and DATA packets will be straightforward. Until that time, specifying ECN support in more detail is not required.

Use of effective congestion control mechanisms always raises concerns about fairness and spoofing or misleading senders - issues not unique to Saratoga.

There should be no additional IANA considerations.

We thank the IETF for reminding us about the importance of congestion for standards-track protocols. Work on this document at NASA's Glenn Research Center was funded by NASA's Earth Science Technology Office (ESTO).