[Docs] [txt|pdf|xml|html] [Tracker] [Email] [Diff1] [Diff2] [Nits]

Versions: 00 01 02 03 04

Internet Engineering Task Force                             G. Fairhurst
Internet-Draft                                    University of Aberdeen
Intended status: Standards Track                           July 05, 2019
Expires: January 6, 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 https://datatracker.ietf.org/drafts/current/.

   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 6, 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
   (https://trustee.ietf.org/license-info) 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 6, 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  . . . . . . . . . . . . . .   5
   4.  Guidelines for Performing Congestion Control  . . . . . . . .   6
     4.1.  Connection Initialization . . . . . . . . . . . . . . . .   6
     4.2.  Using Path Capacity . . . . . . . . . . . . . . . . . . .   7
     4.3.  Timers and Retransmission . . . . . . . . . . . . . . . .   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 . . . . . . . . . . . . . . . . . . . . .  14
   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 6, 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].

   The path between endpoints (sometimes called "Internet Hosts")
   consists of the endpoint protocol stack at the sender and receiver
   (which implements the transport service), and a succession of links
   and network devices (routers or middleboxes) that provide
   connectivity across the network.  The set of network devices forming
   the path is not usually fixed, and it should generally be assumed
   that this set can change over arbitrary lengths of time.

   Other terminology is directly copied from the cited RFCs.

3.  Principles of Congestion Control

   This section summarises the principles for providing congestion
   control, and provides the background for section Section 4.

3.1.  A Diversity of Path Characteristics

   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 at which
   to 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
   exceeds 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]), endpoint congestion control has to conservatively
   assume that any loss is potentially due to congestion and then reduce
   the sending rate of their flows to reflect the available capacity.

   The use of a path to send packets impacts any flows (possibly from or
   to other endpoints) that share the capacity (i.e., multiplex packets)
   using a common network device or link.  Even when a path is not
   congested, flows can still experience an increased latency when the
   path multiplexes traffic belonging to multiple flows.  As with loss,
   latency can also be incurred for other reasons [RFC3819] (Quality of
   Service link scheduling, link radio resource management/bandwidth on

Fairhurst                Expires January 6, 2020                [Page 3]

Internet-Draft                CC Guidelines                    July 2019

   demand, transient outages, link retransmission, and connection/
   resource setup below the IP layer, etc).

   Principles include:

   o  The design is REQUIRED be robust to a change in the set of devices
      on the network path.  A reconfiguration, reset or other event
      could interrupt the path or trigger a change in the set of network
      devices forming the path.

   o  Transports are REQUIRED to operate safely over the wide range of
      path characteristics presented by Internet paths.

   o  The 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, a sender SHOULD measure and adapt to the
      characteristics of the path(s) they use.

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 avoid
   congestion collapse [@ARTICLE{author = {Bob Briscoe}, title = {Flow
   Rate Fairness: Dismantling a Religion}, journal = {ACM CCR}, year =
   {2007} }].

   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]].
   Internet transports should react to avoid congestion that impacts
   other flows sharing a 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 a network device.

   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 6, 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.

   The general recommendation in the UDP Guidelines [RFC8085] is 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.

   Experience has shown that successful protocols developed in a
   specific context or for a particular application tend to also become
   used in a wider range of contexts.  Therefore, IETF specifications by
   default target deployment on the general Internet, or need to be
   defined for use only within a controlled environment.

   Principles include:

   o  [RFC1122] mandates that endpoints perform congestion control.

   o  Transports MUST avoid inducing flow starvation to other flows that
      share 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

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.

Fairhurst                Expires January 6, 2020                [Page 5]

Internet-Draft                CC Guidelines                    July 2019

   o  A sender SHOULD measure and adapt the protocol timers to the
      measured the path RTT.

   o  When a endpoint detects persitent congestion, it MUST employ
      exponential backoff to the maximum rate (congestion window).

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

   o  Network devices can provide mechanisms to mitigate the impact of
      congestion collapse by transport flows (e.g., priority forwarding
      of control information, and starvation detection) to mitigate the
      impact of non-conformant and malicious flows [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 two endpoints 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
      initial sending rate needs to be viewed as tentative until the
      capacity is confirmed to be available.

   Initial RTO Interval:  When a flow sends the first packet it
      typically has no way to know the actual RTT of the path it uses.
      The initial value used to the Retransmission Timeout (RTO) is
      therefore a trade off that has important consequences on the

Fairhurst                Expires January 6, 2020                [Page 6]

Internet-Draft                CC Guidelines                    July 2019

      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 local endpoint 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 local
      endpoint 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 [RFC8085]).

   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:  A congestion controller that recently used a path
      could use additional state that lets a flow take-over the capacity
      that was previously consumed by another flow (e.g., in the last
      RTT).  In TCP, this mechanism is referred to as TCP Control Block
      (CB) 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 this capacity is
      not confirmed within the current RTO interval.

4.2.  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 RT, 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

Fairhurst                Expires January 6, 2020                [Page 7]

Internet-Draft                CC Guidelines                    July 2019

      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 sending endpoint, older ones
      leave at the receiving endpoint, and are usually acknowledged to
      the sender.  The rate that data leaves the pipe indicates the
      share of the capacity that has been utilised by the flow.  If, on
      average (over an RT), the sending rate equals the receiving rate,
      this indicates that this capacity can be safely used again in the
      next RT.  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 (R) 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
      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

Fairhurst                Expires January 6, 2020                [Page 8]

Internet-Draft                CC Guidelines                    July 2019

      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.3.  Timers and Retransmission

   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.  Loss detection can be performed observing the time-ordering
      of the reception of ACKs (as in TCP DupACK) or can utilise a timer
      to detect loss before the expiry of the RTO [RFC8085] [ID.ietf-
      tcpm-rack] or a combination of using a timer and ordering
      information to trigger retransmission of data.

   Retransmission:  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.

   Measuring the RTT:  Once an endpoint has started communicating with
      its peer, the RTT MUST adjusted by measuring the actual path RTT
      and its variance (see equation 2.3 of [RFC6928]).

   Maintaining the RTO:  The RTO SHOULD be set based on recent RTT
      observations [RFC8530].

   RTO Expiry:  Persistent lack of feedback detected by the RTO timer
      (or other means) MUST be treated an indication of potential
      congestion.  A failure to receive any specific response within a

Fairhurst                Expires January 6, 2020                [Page 9]

Internet-Draft                CC Guidelines                    July 2019

      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 RTO interval, TCP collapses the congestion
      window to one segment [RFC5681].  Other transports must similarly
      respond when they detect loss of feedback.

      An endpoint needs to exponentially backoff the RTO interval
      [RFC8085] each time the RTO expires.  That is the RTO interval
      MUST be set to the RTO * 2[RFC6298] [RFC8085].

   Maximum RTO:  A maximum value MAY be placed on the RTO interval.  The
      maximum limit to the RTO interval MUST NOT be less than 60 seconds

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].  Prompt reaction should follow a signal
      from the remote endpoint indicating congestion (or inference of
      that, e.g., through detecting packet loss).

      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
      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 the reaction to packet loss [RFC8311] [RFC8087]].
      Simple feedback of received Congestion Experienced (CE) marks
      [RFC3168], relies only on an indication that congestion has been
      experienced within the last RT, appropriate for using ECT(0).  The
      reaction to reception of this indication was modified in TCP ABE

Fairhurst                Expires January 6, 2020               [Page 10]

Internet-Draft                CC Guidelines                    July 2019

      [RFC8511].  Further detail about the received CE-marking can be
      obtained by using more accurate receiver feedback [ID.-ietf-tcpm-
      accurate-ecn].  This more detailed feedback provides an
      opportunity for a finer-granularity of congestion response.

      Current work-in-progress [ID.ietf-tsvwg-l4s-arch] defines a
      reaction for packets marked with ECT(1), building on the style of
      detailed feedback provided by [ID.-ietf-tcpm-accurate-ecn] and a
      modified marking system [ID.ietf-tsvwg-aqm-dualq-coupled].

   Robustness to Path Change:  The detection of congestion and the
      resulting reduction MUST NOT solely depend upon reception of a
      signal from the remote endpoint, because congestion indications
      could themselves be lost under persistent congestion.

      The only way to surely confirm that a sending endpoint has
      successfully communicated with a remote endpoint is to utilise a
      timer (see (Section 4.3)) to detect a lack of response that could
      result from a change in the path or the path characteristics
      (usually called the RTO).  Congestion controllers that are unable
      to react after one (or at most a few) RTTs after receiving a
      congestion indication should observe the guidance in section 3.3
      of the UDP Guidelines [RFC8085].

   Persistent Congestion:  Persistent congestion can result in
      congestion collapse.  This MUST be aggressively avoided [RFC2914].
      Endpoints that experience persistent congestion and have already
      exponentially reduced their congestion window to the restart
      window (e.g., 1 packet), MUST further reduce the rate if the RTO
      timer continues to expire.  For example, TCP-Friendly Rate Control
      (TFRC) [RFC5348] continues to reduce its sending rate under
      persistent congestion to one packet per RT, and then exponentially
      backs off the time between single packet transmissions if the
      congestion continues to persist [RFC2914].

      [RFC8085] provides guidelines for a sender that does not, or is
      unable to, adapt the congestion window.

4.5.  Using More Capacity

   In the absence of persistent congestion, an endpoint is permitted to
   increase its congestion window and hence the sending rate.  This
   increase should only occur when there is additional data available to
   send across the path (i.e., the sender will utilise the additional
   capacity in the next RT).

   TCP Reno [RFC5681] defines an algorithm, known as the AIMD (additive-
   increase/ multiplicative-decrease) that allows a sender to

Fairhurst                Expires January 6, 2020               [Page 11]

Internet-Draft                CC Guidelines                    July 2019

   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 determine a suitable share of the path capacity.
   Such high BDP paths benefit from methods that more rapidly increase
   the congestion window, but in compensation these need to be designed
   to also react rapidly to any detected congestion (e.g., TCP Cubic

   Increasing Congestion Window:  A sender MUST NOT continue to increase
      its rate for more than an RTT after a congestion indication is
      received.  It SHOULD stop increasing its congestion window as soon
      as it receives indication of congestion to avoid excessive

      While the sender is 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
      congestion is experienced (a congestion event).

   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 a 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 RT, 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.2).

4.6.  Network Signals

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

   Network Signals:  Mechanisms MUST NOT solely rely on messages or
      other specific signalling messages to perform safely (See section
      5.2 of [RFC8085] describing use of ICMP messages).  The path
      characteristics can change at any time.  Transport mechanisms need
      to be robust to potential black-holing of any signals (i.e., it
      needs to be robust to loss or modification of packets).

Fairhurst                Expires January 6, 2020               [Page 12]

Internet-Draft                CC Guidelines                    July 2019

      A mechanism that utilises signals originating in the network (e.g.
      RSVP, NSIS, Quick-Start, ECN), must assume that the set of network
      devices on the path can change.  This motivates the use of soft-
      state when designing protocols that interact with signals
      originating from network devices (e.g., ECN).  This can include
      context-sensitive treatment of "soft" signals provided to the
      endpoint [RFC5461].

4.7.  Protection of Protocol Mechanisms

   An endpoint needs to provide protection from attacks on the traffic
   it generates, or atatcks that increase the capacity it consumes
   (impacting other traffic that shared a bottleneck).

   Off Path Attack:   A design MUST protect from off-path attack to the
      protocol [RFC8085].  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.

   Validation of Signals:  Network signalling and control messages
      (e.g., ICMP [RFC0792]) MUST to be validated before they are used
      to protect from malicious use.  This MUST at least include
      protection from off-path attack [RFC8085].

   On 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 a set of
   metrics and related trade-off between metrics that can be used to
   compare, contrast, and evaluate congestion control techniques

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.  Ana Custura helped review the text.

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

Fairhurst                Expires January 6, 2020               [Page 13]

Internet-Draft                CC Guidelines                    July 2019

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.

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, <https://www.rfc-editor.org/info/rfc3742>.

Fairhurst                Expires January 6, 2020               [Page 14]

Internet-Draft                CC Guidelines                    July 2019

   [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,

   [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, <https://www.rfc-editor.org/info/rfc8085>.

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,

Fairhurst                Expires January 6, 2020               [Page 15]

Internet-Draft                CC Guidelines                    July 2019

   [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, <https://www.rfc-editor.org/info/rfc3449>.

   [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, <https://www.rfc-editor.org/info/rfc3828>.

   [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,

Fairhurst                Expires January 6, 2020               [Page 16]

Internet-Draft                CC Guidelines                    July 2019

   [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,

   [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.

   Individual draft -01:


   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

   Email: gorry@erg.abdn.ac.uk

Fairhurst                Expires January 6, 2020               [Page 17]

Html markup produced by rfcmarkup 1.129d, available from https://tools.ietf.org/tools/rfcmarkup/