Re: [tsvwg] [Technical Errata Reported] RFC7141 (7237)

[Jonathan Morton <[e-mail]>]

> On 1 Oct, 2023, at 9:43 pm, Sebastian Moeller <[e-mail]> wrote:
> 
> Neither RFC 7141 nor draft-ietf-tsvwg-ecn-encap-guidelines make "the Internet work better". Others might disagree but should be prepared to explain "how".

As it stands, the text you quoted in RFC-7141 - though it is listed as a BCP - does not reflect actual Current Practice, and I would consider that the root of the problem.  Perhaps we can improve the situation by suggesting a modification to the text so that it *does* reflect Best Current Practice.  I think that would be in the spirit of an Erratum, or at least the starting point for a more productive discussion.

> Original Text
> -------------
> 2.2.  Recommendation on Encoding Congestion Notification
> 
>   When encoding congestion notification (e.g., by drop, ECN, or PCN),
>   the probability that network equipment drops or marks a particular
>   packet to notify congestion SHOULD NOT depend on the size of the
>   packet in question.
> [...]
> 2.3.  Recommendation on Responding to Congestion
> 
>   When a transport detects that a packet has been lost or congestion
>   marked, it SHOULD consider the strength of the congestion indication
>   as proportionate to the size in octets (bytes) of the missing or
>   marked packet.
> 
>   In other words, when a packet indicates congestion (by being lost or
>   marked), it can be considered conceptually as if there is a
>   congestion indication on every octet of the packet, not just one
>   indication per packet.
> 
>   To be clear, the above recommendation solely describes how a
>   transport should interpret the meaning of a congestion indication, as
>   a long term goal.  It makes no recommendation on whether a transport
>   should act differently based on this interpretation.  It merely aids
>   interoperability between transports, if they choose to make their
>   actions depend on the strength of congestion indications.
> 
> Corrected Text
> --------------

2.2.  Recommendation on Encoding Congestion Notification

  When encoding congestion notification (e.g., by drop, ECN, or PCN),
  the rate at which network equipment drops or marks packets to notify
  congestion SHOULD be approximately consistent over time, regardless
  of variations in the size of packets.

  The probability that a given traffic flow receives a congestion
  notification in any given time interval SHOULD NOT depend on the
  packet sizes it consists of, but SHOULD depend on its relative
  utilisation of the channel.  This can be achieved stochastically.

[...]

2.3.  Recommendation on Responding to Congestion

  When a transport detects that a packet has been lost or congestion
  marked, it MAY consider the strength of the congestion indication
  as proportionate to the size in octets (bytes) of the missing or
  marked packet.

  In other words, when a packet indicates congestion (by being lost or
  marked), it can be considered conceptually as if there is a
  congestion indication on every octet of the packet, not just one
  indication per packet.  Conversely, a transport can consider a
  rapid sequence of congestion notifications to be a single event of
  congestion.

  To be clear, the above recommendation solely describes how a
  transport should interpret the meaning of a congestion indication, as
  a long term goal.  It makes no recommendation on whether a transport
  should act differently based on this interpretation.  It merely aids
  interoperability between transports, if they choose to make their
  actions depend on the strength of congestion indications.

> Notes
> -----

Current Practice includes the Controlled Delay (Codel) AQM [RFC8289], which marks packets on a time-schedule basis and thus naturally adapts to the more rapid passage through a channel of smaller packets, or indeed to same-sized packets passing through a faster channel.  Codel has been shown to achieve similar congestion-control performance to probability-based AQMs with fewer congestion indications, and there is some theoretical justification for time-domain marking schedules being a good match to current congestion control schemes.  In any case, Codel is one of the most widely deployed AQMs in today's Internet, usually in concert with a fair-queuing mechanism.

With that said, probability-based AQMs which either do or do not compensate for this effect (such compensation effectively introducing a dependence on packet size) are also in Current Practice.  Packet size compensation, whose behaviour is closer (but not identical) to time-domain marking, is considered a more modern practice.

Current Practice also includes the widely deployed Standards Track congestion control algorithms NewReno and CUBIC as applied to TCP, and ECN [RFC3168], which all treat any sequence of congestion indications (losses or CE marks) during a single round-trip as being a single congestion event warranting a single congestion-control response (a multiplicative decrease of the congestion window).

Indeed RFC-3168 specifies a mechanism for reflecting CE marks back to the sender which is incapable of conveying the existence of more than CE mark per round-trip, since the ECE flag is latched on until it is acknowledged by a CWR flag set by the sender.  In the absence of SACK, TCP is also incapable of detecting more than one packet loss event per round-trip, and not all TCP implementations (particularly those for resource-constrained devices) implement SACK.

As such, the original text does not accurately reflect Current Practice and therefore cannot be said to reflect Best Current Practice.  The corrected text attempts to better reflect the state of the art.

 - Jonathan Morton