RFC Errata
Found 1 record.
Status: Rejected (1)
RFC 7141, "Byte and Packet Congestion Notification", February 2014
Source of RFC: tsvwg (wit)
Errata ID: 7237
Status: Rejected
Type: Technical
Publication Format(s) : TEXT
Reported By: Sebastian Moeller
Date Reported: 2022-11-03
Rejected by: Martin Duke
Date Rejected: 2024-01-18
Section 2 says:
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.
It should say:
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.