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

[Gorry Fairhurst <[e-mail]>]

On 04/11/2022 10:43, Sebastian Moeller wrote:
> Hi Gorry,
>
> See [SM] below.
>
> On 4 November 2022 11:20:56 CET, Gorry Fairhurst <[e-mail]> wrote:
>> Commenting as an individual on the Errata filing:
>>
>> On 04/11/2022 09:40, RFC Errata System wrote:
>>> The following errata report has been submitted for RFC7141,
>>> "Byte and Packet Congestion Notification".
>>>
>>> --------------------------------------
>>> You may review the report below and at:
>>> https://www.rfc-editor.org/errata/eid7237
>>>
>>> --------------------------------------
>>> Type: Technical
>>> Reported by: Sebastian Moeller <[e-mail]>
>>>
>>> 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.
>> I did not understood that it needed to. This RFC I think was intended to be independent of the transport.  I see the transport sender as responsible for determining the packetisation of the transport segments, and the (S)ACKs can often identify segments, hence the sender can determine the segments that have been acknoweldged or times when ECN marking was seen.
> [SM] This assumes that relevant segment size does not change along the path. Which generally is not true. Just think fragmentation, if the sender sends a packet that gets fragmented along the path and only a single fragment gets CE marked the sender will see this as the whole packet being marked. Or from the other side of the issue, if say a Linux router uses GRO/GSO and queues a larger meta packet and CE marks that, receiver and sender at best see a sequence of CE marked packets. So the recommendation would need to be changed to calculate the consecutive sequence of CE marked octets and take these as correlate for congestion strength. So no, the sender really has no reliable knowledge about the size of the data unit the marking node marked.
>
I suggest IETF transports treat all IP fragments as one unit of 
retransmission/congestion at the transport layer.

GSO/GRO and variants would/could change the fragmentation, that is true 
and need to be considered.

>>> 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.
>> This doesn't appear to be textual errata, it seems more like the request is for more clarification or motivating an alternative?
> [SM] What alternatives to changing incorrect text do exist? I do not think changing the status to historic is a realistic option in spite of the text recommending the impossible.
>
Put simply:

An Erratum would normally specify either:

     a direct change of text to fix a mistake in production, but a 
change of the spec from the original intended method;

     or specify something to inform a future revision.

An update in a new RFC is needed to change the method, or a process 
request to mark an RFC as historic.

Gorry

>>> Instructions:
>>> -------------
>>> This erratum is currently posted as "Reported". If necessary, please
>>> use "Reply All" to discuss whether it should be verified or
>>> rejected. When a decision is reached, the verifying party
>>> can log in to change the status and edit the report, if necessary.
>>>
>>> --------------------------------------
>>> 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 Area Working Group
>>> Area                : Transport
>>> Stream              : IETF
>>> Verifying Party     : IESG
>>