[tsvwg] [Errata Rejected] RFC7141 (7237)

[RFC Errata System <[e-mail]>]

The following errata report has been rejected for RFC7141,
"Byte and Packet Congestion Notification".

--------------------------------------
You may review the report below and at:
https://www.rfc-editor.org/errata/eid7237

--------------------------------------
Status: Rejected
Type: Technical

Reported by: Sebastian Moeller <[e-mail]>
Date Reported: 2022-11-03
Rejected by: Martin Duke (IESG)

Section: 2

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
--------------
I am not sure the text is actually salvageable, as it appears ti be a logic disconnect at the core of the recommendations.

Notes
-----
The recommendations seem not self consistent:
A) Section 2.2.  recommends that CE marking should be made independent of packet size, so a CE-mark carries no information about packet size.

B) Section 2.3 then recommends to use the size of marked packets as direct indicators of congestion strength.

C) Section 2.3 then later clarifies that transports should interpret the size of CE-marked packets as correlate for congestion strength but are in no way required to take this interpretation into account when acting based on the congestion signal.


This has several problems:
1) A) and B) are in direct contradiction to each other. If we ask marking nodes to ignore packet size while marking, but end nodes to take it into account we basically create random congestion strength "information" by the pure chance of a specific packet of a specific size "catching" a CE mark. At which point we might as well simply draw a random number at the end-point to interpret congestion strength (except that packet sizes are not distributed randomly).

2) Asking endpoints to interpret CE_marks in this way but not act on it, is hardly actionable advice for potential implementers. If we can not recommend a specific way, we should refrain from offering recommendations at all to keep things as simple as reasonably possible.
 --VERIFIER NOTES-- 
 I would summarize the discussion on the WG list as follows:

1) while there is a tension between the two recommendations, it is logically coherent for one endpoint to do one thing and the other input to assume the opposite.

2) This is the original intent of the authors

3) Some people disagree with that design, but that is not a subject for errata.

--------------------------------------
RFC7141 (draft-ietf-tsvwg-byte-pkt-congest-12)
--------------------------------------
Title               : Byte and Packet Congestion Notification
Publication Date    : February 2014
Author(s)           : B. Briscoe, J. Manner
Category            : BEST CURRENT PRACTICE
Source              : Transport and Services Working Group
Area                : Transport
Stream              : IETF
Verifying Party     : IESG