Re: [tsvwg] [Errata Rejected] RFC7141 (7237)

[Sebastian Moeller <[e-mail]>]

Hi Martin,


> On 19. Jan 2024, at 00:17, RFC Errata System <[e-mail]> wrote:
> 
> 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.

	[SM] Only if you assume that the best response to congestion can be achieved without getting ass veridical an estimate of the true congestion situation. IMHO such an assumption needs strong data to support it, as it essentially is a recommendation to make up a signal where there is none.


> 2) This is the original intent of the authors

	[SM] I understand that intention, but that still does not fix the logical fallacy for me.

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

	[SM] It is a set of as it appears untested/unimplemented recommendations, not a 'design'.

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