Guidelines for Internet Congestion Control at Endpoints

Versions: 00 01 02 03 04 05                                             
Internet Engineering Task Force                             G. Fairhurst
Internet-Draft                                    University of Aberdeen
Intended status: Standards Track                           July 01, 2019
Expires: January 2, 2020

        Guidelines for Internet Congestion Control at Endpoints


   This document provides guidance on the design of methods to avoid
   congestion collapse and to provide congestion control.
   Recommendations and requirements on this topic are distributed across
   many documents in the RFC series.  It seeks to gather and consolidate
   these recommendations.  This is intended to provide input to the
   design of new congestion control methods in protocols, such as IETF

   The present document is for discussion and comment by the IETF.

Status of This Memo

   This Internet-Draft is submitted in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF).  Note that other groups may also distribute
   working documents as Internet-Drafts.  The list of current Internet-
   Drafts is at

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   This Internet-Draft will expire on January 2, 2020.

Copyright Notice

   Copyright (c) 2019 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents
   ( in effect on the date of
   publication of this document.  Please review these documents
   carefully, as they describe your rights and restrictions with respect

Fairhurst                Expires January 2, 2020                [Page 1]

Internet-Draft                CC Guidelines                    July 2019

   to this document.  Code Components extracted from this document must
   include Simplified BSD License text as described in Section 4.e of
   the Trust Legal Provisions and are provided without warranty as
   described in the Simplified BSD License.

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
   2.  Terminology . . . . . . . . . . . . . . . . . . . . . . . . .   3
   3.  Principles of Congestion Control  . . . . . . . . . . . . . .   3
     3.1.  A Diversity of Path Characteristics . . . . . . . . . . .   3
     3.2.  Flow Multiplexing and Congestion  . . . . . . . . . . . .   4
     3.3.  Avoiding Congestion Collapse  . . . . . . . . . . . . . .   6
   4.  Guidelines for performing Congestion Control  . . . . . . . .   6
     4.1.  Connection Initialization . . . . . . . . . . . . . . . .   6
     4.2.  Timers and Retranmission  . . . . . . . . . . . . . . . .   8
     4.3.  Using Path Capacity . . . . . . . . . . . . . . . . . . .   9
     4.4.  Responding to Potential Congestion  . . . . . . . . . . .  10
     4.5.  Using More Capacity . . . . . . . . . . . . . . . . . . .  11
     4.6.  Network Signals . . . . . . . . . . . . . . . . . . . . .  12
     4.7.  Protection of Protocol Mechanisms . . . . . . . . . . . .  13
   5.  IETF guidelines on evaluation of Congestion Control . . . . .  13
   6.  Acknowledgements  . . . . . . . . . . . . . . . . . . . . . .  13
   7.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .  13
   8.  Security Considerations . . . . . . . . . . . . . . . . . . .  14
   9.  References  . . . . . . . . . . . . . . . . . . . . . . . . .  14
     9.1.  Normative References  . . . . . . . . . . . . . . . . . .  14
     9.2.  Informative References  . . . . . . . . . . . . . . . . .  15
   Appendix A.  Revision Notes . . . . . . . . . . . . . . . . . . .  17
   Author's Address  . . . . . . . . . . . . . . . . . . . . . . . .  17

1.  Introduction

   The IETF has specified Internet transports (e.g., TCP [ID.ietf-tcpm-
   rfc793bis], UDP [RFC0768], UDP-Lite [RFC3828], SCTP [RFC4960], and
   DCCP [RFC4340]) as well as protocols layered on top of these
   transports (e.g., RTP, QUIC [I-D.ietf-quic-transport], SCTP/UDP
   [RFC6951], DCCP/UDP) and transports that work directly over the IP
   network layer.  These transports are implemented in endpoints
   (Internet hosts or routers acting as endpoints) and are designed to
   detect and react to network congestion.

   Recommendations and requirements on this topic are distributed across
   many documents in the RFC series.  This document seeks to gather and
   consolidate these recommendations.  This is intended to provide input
   to the design of new congestion control methods in protocols.

Fairhurst                Expires January 2, 2020                [Page 2]

Internet-Draft                CC Guidelines                    July 2019

2.  Terminology

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   document are to be interpreted as described in [RFC2119].

   Other terminology is directly copied the cited RFCs.

3.  Principles of Congestion Control

   This section describes principles for providing congestion control.

3.1.  A Diversity of Path Characteristics

   The path between endpoints (sometimes called "internet Hosts")
   consists of the endpoint protocol stack (implementing the transport)
   and a succession of links and network devices (routers or
   middleboxes) that provide connectivity across the network.

   Internet transports do not usually rely upon prior reservation of
   capacity along the path they use.  In the absence of such a resource
   reservation, endpoints are unable to determine a safe rate start or
   continue their transmission.  The use of an Internet path therefore
   requires a combination of end-to-end transport mechanisms to detect
   and respond to changes in the capacity available across the network
   path.  Buffering (an increase in latency) or loss (discard of a
   packet) arises when the traffic arriving at a link or network exceed
   the resources available.  A network device that does not support
   Active Queue Management (AQM) [RFC7567] typically uses a drop-tail
   policy to drop excess IP packets when its queue becomes full.
   Although losses are not always due to congestion (loss may be due to
   link corruption, receiver overrun, etc.  [RFC3819]), endpoints have
   to conservatively presume that loss is potentially due to congestion
   and reduce the sending rate of their flows to reflect the available

   A path that is not congested can still experience an increased
   latency when the path multiplexes the traffic of multiple flows, and/
   or when the level of traffic is (transiently) higher than the
   currently available capacity.  As with loss, latency can also be
   incurred for other reasons [RFC3819] (e.g.  Quality of service
   scheduling, link radio resource management/bandwdith on demand,
   transient outages, link retransmission, and connection/resource setup
   below the IP layer).

   The use of a path impacts any flows (possibly from or to other
   endpoints) that share (multiplex their data) over a common network
   device or link.

Fairhurst                Expires January 2, 2020                [Page 3]

Internet-Draft                CC Guidelines                    July 2019

   Principles include:

   o  The design of a congestion controller needs to consider the wide
      range of path characteristics presented by the variety of Internet
      paths.  Transports MUST be designed such that they operate safely
      and effectively over common paths.

   o  An endpoint cannot assume that a particular packet header is
      passed transparently by the path or a particular forwarding
      treatment applies.  The supported set of packet headers and
      forwarding can also change once a flow has commenced.

   o  A design MUST assume path characteristics can change over
      relatively short intervals of time (i.e. characteristics
      discovered do not necessarily remain valid for multiple Round Trip
      Times, RTTs).  In particular, they need to measure and adapt to
      the path(s) they use path capacity, and the estimated RTT used for

   o  A design MUST assume that the set of network devices encountered
      along a path can change with time.  This MUST be robust to
      reconfiguration of network devices, reset of devices

3.2.  Flow Multiplexing and Congestion

   It is normal to observe some perturbation in latency or loss to
   traffic when it shares a common network bottleneck with other
   traffic.  This impact needs to be considered and Internet flows ought
   to implement appropriate safeguards to avoid inappropriate impact on
   other flows that share the resources along a path.  Congestion
   control methods satisfy this requirement and therefore also avoid
   congestion collapse [@ARTICLE{author = {Bob Briscoe}, title = {Flow
   Rate Fairness: Dismantling a Religion}, journal = {ACM CCR}, year =
   {2007} }].

   Internet transports should react to avoid congestion that impacts
   other flows sharing the path, and need to be designed to avoid
   starving other flows of capacity.  This could include methods seeking
   to equally distribute resources between sharing flows, but this is
   explicitly not a requirement for design of network devices.

   The Requirements for Internet Hosts [RFC1122] formally mandates that
   endpoints perform congestion control.  "Because congestion control is
   critical to the stable operation of the Internet, applications and
   other protocols that choose to use UDP as an Internet transport must
   employ mechanisms to prevent congestion collapse and to establish
   some degree of fairness with concurrent traffic [RFC2914].  They may
   also need to implement additional mechanisms, depending on how they

Fairhurst                Expires January 2, 2020                [Page 4]

Internet-Draft                CC Guidelines                    July 2019

   use UDP" [RFC8085].  [RFC2309] also discussed the dangers of
   congestion-unresponsive flows and states that "all UDP-based
   streaming applications should incorporate effective congestion
   avoidance mechanisms."  [RFC7567] and [RFC8085] reaffirm this.

   An endpoint can become aware of congestion by various means.  A
   signal that indicates congestion on the end-to-end network path, must
   result in a congestion control reaction by the transport to reduce
   the maximum rate permitted by the sending endpoint [RFC8087]].

   The general recommendation in the UDP Guidelines [RFC8085] is
   therefore that applications SHOULD leverage existing congestion
   control techniques, such as those defined for TCP [RFC5681], TFRC
   [RFC5348], SCTP [RFC4960], and other IETF-defined transports.  This
   is because there are many trade offs and details that can have a
   serious impact on the performance of congestion control for the
   application they support and other traffic that seeks to share the
   resources along the path over which they communicate.

   Section 3.6 notes that by default, IETF specifications target
   deployment on the general Internet.  Experience has however shown
   that successful protocols developed in one specific context or for a
   particular application tend to become used in a wider range of
   contexts.  Experience has however shown that successful protocols
   developed in one specific context or for a particular application
   tend to become used in a wider range of contexts.

   Principles include:

   o  [RFC1122] mandates that endpoints perform congestion control.

   o  Transports need to avoid inducing flow starvation to other flows
      sharing resources along the path they use.

   o  "If an application or protocol chooses not to use a congestion-
      controlled transport protocol, it SHOULD control the rate at which
      it sends UDP datagrams to a destination host, in order to fulfil
      the requirements of [RFC2914]", as stated in [RFC8085].

   o  Transports that do not target Internet deployment need to be
      constrained to only operate in a controlled environment (e.g. see
      Section 3.6 of [RFC8085]) and provide appropriate mechanisms to
      prevent traffic accidentally leaving the controlled environment

Fairhurst                Expires January 2, 2020                [Page 5]

Internet-Draft                CC Guidelines                    July 2019

3.3.  Avoiding Congestion Collapse

   A significant pathology can arise when a poorly designed transport
   creates congestion.  This can result in severe service degradation or
   "Internet meltdown".  This phenomenon was first observed during the
   early growth phase of the Internet in the mid 1980s [RFC896]
   [RFC970]; it is technically called "congestion collapse" and was a
   key focus of [RFC2309].

   o  Endpoints MUST control their flows to avoid Congestion Collapse.

   o  Endpoints MUST employ exponential backoff to their traffic when
      they detect persistent congestion.

   o  Endpoints MUST treat a loss of all feedback (e.g., RTO expiry) as
      a tentative indication of congestion collapse, reacting until the
      path characteristics can again be confirmed.

   o  Network devices should provide mechanisms to avoid congestion
      collapse (e.g., priority forwarding of control information, and
      starvation detection and protection [RFC7567]).

4.  Guidelines for performing Congestion Control

   This section provides guidance for designers of a new transport
   protocol that decide to implement congestion control and its
   associated mechanisms.

4.1.  Connection Initialization

   When a connection or flow to a new destination is established, the
   endpoints have little information about the characteristics of the
   network path.  This section describes how a flow starts transmission
   over such a path.

   Flow Start:  A new flow between a local and a remote endpoint cannot
      assume that capacity is available at the start of the flow, unless
      it uses a mechanism to explicitly reserve capacity.  In the
      absence of a capacity signal, a flow MUST therefore start slowly.

      The slow-start algorithm is the accepted standard for flow startup
      [RFC5681].  TCP uses the notion of an Initial Window (IW [RFC3390]
      updated by [RFC6928]) to define the initial volume of data that
      can be sent on a path.  This is not the smallest burst, or the
      smallest window - it is considered a safe starting point for a
      network that is not suffering persistent congestion, and
      applicable until feedback about the path is received.  This

Fairhurst                Expires January 2, 2020                [Page 6]

Internet-Draft                CC Guidelines                    July 2019

      initial sending rate needs to be viewed as tentative until the
      capacity is confirmed to be available.

   Initial RTO:  When a flow sends the first packet it typically has no
      way to know the actual RTT of the path it uses.  The values used
      to initialise the Retransmission Timeout (RTO) is therefore a
      trade off that has important consequences on the overall Internet
      stability [RFC6928] [RFC8085].  In the absence of any knowledge
      about the latency of a path, the RTO MUST be conservatively set to
      no less than 1 second.  Values shorter than 1 second can be
      problematic (see the appendix of [RFC6298]).

   Initial RTO Expiry:  If the RTO timer expires while awaiting
      completion of the connection setup (in TCP, the ACK of a SYN
      segment), and the implementation is using an RTO less than 3
      seconds, the sender can resend the connection setup.  The RTO MUST
      then be re-initialized to increase it to 3 seconds when data
      transmission begins (i.e., after the three-way handshake
      completes) [RFC6298] [RFC8085].  This conservative increase is
      necessary to avoid congestion collapse when many flows retransmit
      across a shared bottleneck with restricted capacity.

   Initial Measured RTO:  Once an RTT measurement is available (e.g.,
      through reception of an acknowledgement), this value must be
      adjusted, and MUST take into account the RTT variance.  For the
      first (sample this variance cannot be determined, and a sender
      must therefore initialise the variance to RTT/2 (see equation 2.2
      of [RFC6928] and related text for UDP in section 3.1.1 of

   Current State:  A congestion controller MAY assume that recently used
      capacity between a pair of endpoint addresses is an indication of
      capacity available in the next RTT between the same endpoints (and
      react accordingly if this is not confirmed to be true).

   Cached State:  An endpoint that has recently used the same path
      between a local and remote endpoint could also have additional
      state that lets a flow take-over utilising the capacity that was
      previously consumed (e.g., in the last RTT) by another flow.  In
      TCP, this mechanism is referred to as TCP Control Block (TCB)
      sharing [RFC2140] [ID.ietf-tcpm-2140bis].  This and other
      information can be used to suggest a faster initial sending rate,
      but MUST be viewed as tentative until the capacity is confirmed to
      be available.  A sender MUST reduce its rate if the actual used
      capacity is not confirmed within the current RTT interval.

Fairhurst                Expires January 2, 2020                [Page 7]

Internet-Draft                CC Guidelines                    July 2019

4.2.  Timers and Retranmission

   This section describes mechanisms to detect and provide
   retransmission, and to protect the network in the absence of timely

   Loss Detection:  Loss detection occurs after a sender determines
      there is no delivery confirmation within an expected period of
      time.  Retransmission mechanisms MAY utilise a measure of the RTT
      of a path to detect loss before the period specified by the RTO

      Detection can also be performed using the time-ordering of
      transmission (as in TCP DupACK), or a combination of using a timer
      and ordering information to trigger retransmission of data
      [ID.ietf-tcpm-rack-05 ].

   Retransmssion:  Retransmission of lost packets or messages is a
      common reliability mechanism.  When a loss is detected, the sender
      can choose to retransmit the lost data, ignore the loss, or send
      other data.  Any transmission consumes network capacity, therefore
      retransmissions MUST NOT increase the network load in response to
      congestion loss (which worsens that congestion) [RFC8085].  Any
      method that sends additional data following loss is responsible
      for congestion control of the retransmissions (and any other
      packets sent) as well as the original traffic.

   Maintaining the RTO:  Once an endpoint is communicating with it peer
      the RTO should MUST adjusted by measuring the RTT and its variance
      (see equation 2.3 of [RFC6928]).  The RTO SHOULD be set based on
      recent observations [RFC8530].

   RTO Expiry:  Persistent lack of feedback detected by the RTO (or
      other means) must be used an indication of potential congestion.
      A failure to receive any specific response within a RTO interval
      could potentially be a result of a RTT change, change of path,
      excessive loss, or even congestion collapse.

      If there is no response within the timeout period (often called
      the RTO interval), TCP collapses the congestion window to one
      segment [RFC5681].  Other transports must similarly respond when
      they detect loss of feedback.

      RTO expiry require to exponentially increase the size of the
      timeout interval [RFC8085].  When the retransmission timer
      expires, the RTO MUST be set to RTO * 2 ("back off the timer")
      [RFC6298] [RFC8085].  A maximum value MAY be placed on the RTO.
      This maximum RTO MUST NOT be less than 60 seconds [RFC6298].

Fairhurst                Expires January 2, 2020                [Page 8]

Internet-Draft                CC Guidelines                    July 2019

4.3.  Using Path Capacity

   This section describes how a sender needs to regulate the maximum
   volume of data in flight over the interval of the current RTT, and
   how it manages transmission of the capacity that it perceives is

   Congestion Management:  The capacity available to a flow could be
      expressed as the number of bytes in flight, the sending rate or a
      limit on the number of unacknowledged segments.  In steady-state
      this congestion window reflects a safe limit to the sending rate
      that has not resulted in persistent congestion.  A sender
      performing congestion management will usually optimise performance
      for its application by avoiding excessive loss or delay.

      One common model views the path between two endpoints as a pipe,
      new packets enter the pipe at the sender, older one leaves at the
      receiver.  The rate of data that leaves the pipe indicates the
      share of the capacity utilised by a flow.  If on average (over an
      RTT the sending rate equals the sending rate, it indicates the
      capacity can safely be used in the next RTT.  If the average
      receiving rate is less than the sending rate, then the path is
      either queuing packets, the RTT/path has changed, or there is
      packet loss.

   Transient Path:  Path capacity information is transient.  A sender
      that fails to use capacity has no understanding whether that
      capacity remains available to use - or whether it has disappeared
      (e.g., to a change to a path with a smaller bottleneck, or more
      traffic has emerged that has consumed the previously available
      capacity).  For this reason, a sender that is limited by the
      volume of application data available to send MUST NOT continue to
      grow the congestion window [RFC5681].

      Standard TCP states that a TCP sender SHOULD set the congestion
      window to no more than the Restart Window (RW) before beginning
      transmission if the TCP sender has not sent data in an interval
      that exceeds the current retransmission timeout, i.e., when an
      application becomes idle [RFC5681].  Experimental specifications
      permit TCP senders to tentatively maintain a congestion window
      when application-limited, provided that they appropriately and
      rapidly collapse the window when potential congestion is detected
      [RFC7661].  This mechanism is called Congestion Window Validation

   Burst Mitigation:  Even in the absence of congestion, statistical
      multiplexing of flows can result in transient effects for flows
      sharing common resources.  A sender therefore SHOULD avoid

Fairhurst                Expires January 2, 2020                [Page 9]

Internet-Draft                CC Guidelines                    July 2019

      inducing excessive congestion to other flows (collateral damage),
      or patterns of loss that result in denying a reasonable access to
      the available capacity (sometimes called flow starvation).  While
      a congestion controller ought to limit sending at the granularity
      of the current RTT, this can be insufficient to satisfy the goals
      of preventing starvation and mitigating collateral damage.  This
      requires moderating the burst rate of the sender to avoid
      significant periods where a flow(s) consume all buffer capacity at
      the path bottleneck, which would otherwise prevent other flows
      from gaining a reasonable share.

      Endpoints SHOULD provide mechanisms to regulate the bursts of
      transmission that the application/protocol sends to the network
      (section 3.1.6. of [RFC8085]).  ACK-Clocking [RFC5681] can help
      mitigate bursts for protocols that receive continuous feedback of
      reception (such as TCP).  Sender pacing can mitigate this
      [RFC8085], (See Section 4.6 of [RFC3449], and has been recommended
      for TCP in conditions where ACK-clocking is not effective, (e.g.,
      [RFC3742], [RFC7661]).  SCTP [RFC4960] defines a maximum burst
      length (Max.Burst) with a recommended value of 4 segments to limit
      the SCTP burst size.

4.4.  Responding to Potential Congestion

   Internet flows SHOULD implement appropriate safeguards to avoid
   inappropriate impact on other flows that share the resources along a
   path.  The safety and responsiveness of new proposals need to be
   evaluated [RFC5166].  In determining an appropriate congestion
   response, designs could take into consideration the size of the
   packets that experience congestion [RFC4828].

   Congestion Response:  An endpoint MUST reduce the rate of
      transmission when it detects loss (or some other indicator of
      congestion) [RFC2914]. (i.e. a reduction needs to not depend on
      reception of a signal from the remote endpoint, considering that
      congestion indications could themselves be lost under congestion).

      TCP Reno established a method that relies on multiplicative-
      decrease to halve the sending rate while congestion is detected.
      This response to loss is considered sufficient for safe Internet
      operation, but other decrease factors have also been published in
      the RFC series [RFC8312].

   ECN Response:  A congestion control design should provide the
      necessary mechanisms to support Explicit Congestion Notification
      (ECN) [RFC3168] [RFC6679], as described in section 3.1.7. of
      [RFC8085].  This can provide help determine an appropriate

Fairhurst                Expires January 2, 2020               [Page 10]

Internet-Draft                CC Guidelines                    July 2019

      congestion window when supported by routers on the path [RFC7567]
      to enable rapid early indication of incipient congestion.

      The early detection of incipient congestion justifies a different
      reaction to that for loss [RFC8311] [RFC8087]].  Simple feedback
      of congestion experienced by ECN-marked packets [RFC3168]
      [RFC8511], relies only on an indication that congestion has been
      experienced within the last RTT.  The reaction for traffic marked
      with ECT(0) when using this simple feedback of congestion was
      modified [RFC8511].

      Further detail of the ECN marking can be obtained by providing
      more accurate receiver feedback [ID.-ietf-tcpm-accurate-ecn],
      enabling a faster reaction reducing the queuing latency
      [RFC8087]].  Current work in progress [ID.ietf-tsvwg-l4s-arch]
      defines a reaction for packets marked with ECT(1), building on the
      style of feedback provided by [ID.-ietf-tcpm-accurate-ecn].

   Protection from Path Change:  Congestion control, like loss recovery,
      requires timely feedback.  Congestion control MUST NOT solely rely
      on the presence of feedback to perform safely.  The only way to
      surely confirm that a local endpoint has successfully communicated
      with a remote endpoint is to utilise a timer Section 4.2 to detect
      a lack of response that could result from a change in the path or
      the path characteristics.  Congestion controllers that are unable
      to react one (or at most a few RTT) after a congestion indication
      should observe the guidance in 3.3 of the UDP Guidelines

   Persistent Congestion:  Endpoints MUST reduce the rate further below
      that reflected by the restart window, if the RTO continues to

      Persistent congestion can result in congestion collapse and MUST
      be aggressively avoided [RFC2914].  [RFC8085] provides guidelines
      for a sender that does not or is unable too adapt the congestion
      window.  A suitable method (e.g., TFRC) continues to reduce the
      sending rate under persistent congestion, to one packet per round-
      trip time and then exponentially backs off the time between single
      packet transmissions if congestion continues to persist [RFC2914].

4.5.  Using More Capacity

   In the absence of persistent congestion, endpoints are permitted to
   increase their congestion window and hence their sending rate,
   providing that there is (or is expected to be) additional data
   available to send across the path.

Fairhurst                Expires January 2, 2020               [Page 11]

Internet-Draft                CC Guidelines                    July 2019

   TCP Reno [RFC5681] defines an algorithm, known as the AIMD (additive-
   increase/ multiplicative-decrease) that allows a sender to
   exponentially increase the congestion window each RTT from the
   initial window to the first detected congestion event.  This is
   designed to allow new flows to rapidly acquire a suitable congestion
   window.  Where the bandwidth delay product (BDP) is large it can take
   many RTTs to find a suitable share of the path capacity, such paths
   benefit from methods that more rapidly increase the congestion window
   (e.g., TCP Cubic [RFC8312]), but need to be designed to also react
   rapidly to any detected congestion.

   Increasing Congestion Window:  A sender SHOULD stop increasing its
      congestion window as soon as it receives indication of congestion
      and MUST NOT continue to increase its rate for more than a RTT
      after a congestion indication is received.  When increasing the
      congestion window, a sender can transmit faster than the last
      known safe rate.

      Any increase above the last confirmed rate needs to be regarded as
      tentative and the sender reduce their rate below the last
      confirmed safe rate when they experience congestion.

   Congestion:  An endpoint MUST utilise a method that assures the
      sender will keep the rate below the previously confirmed safe rate
      for multiple RTTs after an observed congestion event.  In TCP this
      is performed by using linear increase from a slow start threshold
      that is re-initialised when congestion is experienced.

   Avoiding Overshoot:  Overshoot of the congestion window beyond the
      point of congestion can significantly impact other flows sharing
      resources along a path.  It is important to note that as endpoints
      experience more paths with a large BDP and a wider range of
      potential path RTT, that variability or changes in the path can
      have very significant impacts on appropriate dynamics for
      increasing the congestion window (see also burst mitigation
      Section 4.3).

4.6.  Network Signals

   An endpoint can utilise signals from the network to help determine
   how to control the traffic it sends.

   Network Signals:  The assumptions that network devices on path may
      change motivates the use of soft-state when designing protocols
      that interact with network devices (e.g., ECN).  To protect from
      changes in the path.

Fairhurst                Expires January 2, 2020               [Page 12]

Internet-Draft                CC Guidelines                    July 2019

      Transport mechanisms need to be robust to potential black-holing
      of signals, as it must also be robust to loss of packets.

      Mechanisms MUST NOT solely rely on ICMP messages or other specific
      signalling messages to perform safely when these are not received
      (section 5.2 of [RFC8085]).  This can include context-sensitive
      treatment of "soft" signals provided to the endpoint [RFC5461].

   Validation of ICMP:  ICMP messages [RFC0792] MUST to be validated
      before they are used.  Other path signals must similarly be
      validated to protect from malicious use.

4.7.  Protection of Protocol Mechanisms

   Off Path Attack:   A design MUST protect from off-path attack
      [RFC8085] where an attack on the congestion control can lead to a
      DoS vulnerability for the flow being controlled and/or other flows
      that share network resources along the path.

   OffOn Path Attack:   A protocol can be designed to protect from on-
      path attacks, but this requires more complexity and the use of
      encryption/authentication mechanisms (e.g., IPsec [RFC4301], QUIC

5.  IETF guidelines on evaluation of Congestion Control

   The IETF has provided guidance [RFC5033] for considering alternate
   congestion control algorithms.  The IRTF has described set of metrics
   and related trade-off between metrics that can be used to compare,
   contrast, and evaluate congestion control techniques [RFC5166].

6.  Acknowledgements

   Nicholas Kuhn helped develop the first draft of these guidelines.
   Tom Jones reviewed the first version of this draft.  Gorry Fairhurst
   and Tom Jones were funded at the University of Aberdeen by the
   European Space Agency.

   The views expressed are solely those of the author(s).

7.  IANA Considerations

   This memo includes no request to IANA.

   RFC Editor Note: If there are no requirements for IANA, the section
   will be removed during conversion into an RFC by the RFC Editor.

Fairhurst                Expires January 2, 2020               [Page 13]

Internet-Draft                CC Guidelines                    July 2019

8.  Security Considerations

   The security considerations for the use of transports are provided in
   the references section of the cited RFCs.  Security guidance for
   applications using UDP is provided in the UDP Usage Guidelines

   Section Section 4.6 supports current best practice to validate ICMP
   messages prior to use.  Section Section 4.7 describes general
   requirements relating to the design of safe protocols and their
   protection from on and off path attack.

9.  References

9.1.  Normative References

   [RFC1122]  Braden, R., Ed., "Requirements for Internet Hosts -
              Communication Layers", STD 3, RFC 1122,
              DOI 10.17487/RFC1122, October 1989,

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119,
              DOI 10.17487/RFC2119, March 1997,

   [RFC2914]  Floyd, S., "Congestion Control Principles", BCP 41,
              RFC 2914, DOI 10.17487/RFC2914, September 2000,

   [RFC3168]  Ramakrishnan, K., Floyd, S., and D. Black, "The Addition
              of Explicit Congestion Notification (ECN) to IP",
              RFC 3168, DOI 10.17487/RFC3168, September 2001,

   [RFC3742]  Floyd, S., "Limited Slow-Start for TCP with Large
              Congestion Windows", RFC 3742, DOI 10.17487/RFC3742, March
              2004, <>.

   [RFC5681]  Allman, M., Paxson, V., and E. Blanton, "TCP Congestion
              Control", RFC 5681, DOI 10.17487/RFC5681, September 2009,

   [RFC6298]  Paxson, V., Allman, M., Chu, J., and M. Sargent,
              "Computing TCP's Retransmission Timer", RFC 6298,
              DOI 10.17487/RFC6298, June 2011,

Fairhurst                Expires January 2, 2020               [Page 14]

Internet-Draft                CC Guidelines                    July 2019

   [RFC6928]  Chu, J., Dukkipati, N., Cheng, Y., and M. Mathis,
              "Increasing TCP's Initial Window", RFC 6928,
              DOI 10.17487/RFC6928, April 2013,

   [RFC7567]  Baker, F., Ed. and G. Fairhurst, Ed., "IETF
              Recommendations Regarding Active Queue Management",
              BCP 197, RFC 7567, DOI 10.17487/RFC7567, July 2015,

   [RFC7661]  Fairhurst, G., Sathiaseelan, A., and R. Secchi, "Updating
              TCP to Support Rate-Limited Traffic", RFC 7661,
              DOI 10.17487/RFC7661, October 2015,

   [RFC8085]  Eggert, L., Fairhurst, G., and G. Shepherd, "UDP Usage
              Guidelines", BCP 145, RFC 8085, DOI 10.17487/RFC8085,
              March 2017, <>.

9.2.  Informative References

              Iyengar, J. and M. Thomson, "QUIC: A UDP-Based Multiplexed
              and Secure Transport", draft-ietf-quic-transport-20 (work
              in progress), April 2019.

   [RFC0768]  Postel, J., "User Datagram Protocol", STD 6, RFC 768,
              DOI 10.17487/RFC0768, August 1980,

   [RFC0792]  Postel, J., "Internet Control Message Protocol", STD 5,
              RFC 792, DOI 10.17487/RFC0792, September 1981,

   [RFC2309]  Braden, B., Clark, D., Crowcroft, J., Davie, B., Deering,
              S., Estrin, D., Floyd, S., Jacobson, V., Minshall, G.,
              Partridge, C., Peterson, L., Ramakrishnan, K., Shenker,
              S., Wroclawski, J., and L. Zhang, "Recommendations on
              Queue Management and Congestion Avoidance in the
              Internet", RFC 2309, DOI 10.17487/RFC2309, April 1998,

   [RFC3449]  Balakrishnan, H., Padmanabhan, V., Fairhurst, G., and M.
              Sooriyabandara, "TCP Performance Implications of Network
              Path Asymmetry", BCP 69, RFC 3449, DOI 10.17487/RFC3449,
              December 2002, <>.

Fairhurst                Expires January 2, 2020               [Page 15]

Internet-Draft                CC Guidelines                    July 2019

   [RFC3819]  Karn, P., Ed., Bormann, C., Fairhurst, G., Grossman, D.,
              Ludwig, R., Mahdavi, J., Montenegro, G., Touch, J., and L.
              Wood, "Advice for Internet Subnetwork Designers", BCP 89,
              RFC 3819, DOI 10.17487/RFC3819, July 2004,

   [RFC3828]  Larzon, L-A., Degermark, M., Pink, S., Jonsson, L-E., Ed.,
              and G. Fairhurst, Ed., "The Lightweight User Datagram
              Protocol (UDP-Lite)", RFC 3828, DOI 10.17487/RFC3828, July
              2004, <>.

   [RFC4340]  Kohler, E., Handley, M., and S. Floyd, "Datagram
              Congestion Control Protocol (DCCP)", RFC 4340,
              DOI 10.17487/RFC4340, March 2006,

   [RFC4828]  Floyd, S. and E. Kohler, "TCP Friendly Rate Control
              (TFRC): The Small-Packet (SP) Variant", RFC 4828,
              DOI 10.17487/RFC4828, April 2007,

   [RFC4960]  Stewart, R., Ed., "Stream Control Transmission Protocol",
              RFC 4960, DOI 10.17487/RFC4960, September 2007,

   [RFC5033]  Floyd, S. and M. Allman, "Specifying New Congestion
              Control Algorithms", BCP 133, RFC 5033,
              DOI 10.17487/RFC5033, August 2007,

   [RFC6951]  Tuexen, M. and R. Stewart, "UDP Encapsulation of Stream
              Control Transmission Protocol (SCTP) Packets for End-Host
              to End-Host Communication", RFC 6951,
              DOI 10.17487/RFC6951, May 2013,

   [RFC8087]  Fairhurst, G. and M. Welzl, "The Benefits of Using
              Explicit Congestion Notification (ECN)", RFC 8087,
              DOI 10.17487/RFC8087, March 2017,

   [RFC8311]  Black, D., "Relaxing Restrictions on Explicit Congestion
              Notification (ECN) Experimentation", RFC 8311,
              DOI 10.17487/RFC8311, January 2018,

Fairhurst                Expires January 2, 2020               [Page 16]

Internet-Draft                CC Guidelines                    July 2019

   [RFC8511]  Khademi, N., Welzl, M., Armitage, G., and G. Fairhurst,
              "TCP Alternative Backoff with ECN (ABE)", RFC 8511,
              DOI 10.17487/RFC8511, December 2018,

Appendix A.  Revision Notes

   Note to RFC-Editor: please remove this entire section prior to

   Individual draft -00:

   o  Comments and corrections are welcome directly to the authors or
      via the IETF TSVWG, working group mailing list.

   o  This update is proposed for initial WG comments.

   o  If there is interest in progresisng this document, the next
      version will include more complee referencing to citred material.

Author's Address

   Godred Fairhurst
   University of Aberdeen
   School of Engineering
   Fraser Noble Building
   Aberdeen  AB24 3U


Fairhurst                Expires January 2, 2020               [Page 17]