Re: [tsvwg] Question about proper node behavior -ECN

[Jonathan Morton <[e-mail]>]

> On 18 May, 2023, at 10:32 pm, Greg White <g.white=[e-mail]> wrote:
> 
> RFC3168 also includes a statement which allows manipulation of the ECN field:  
> “When the router's buffer
>    is not yet full and the router is prepared to drop a packet to inform
>    end nodes of incipient congestion, the router should first check to
>    see if the ECT codepoint is set in that packet's IP header.  If so,
>    then instead of dropping the packet, the router MAY instead set the
>    CE codepoint in the IP header.”
>  
> And, it includes a section 18 which talks about possible changes of the ECN field in the network, and specifically 18.1.4 “Falsely Indicating ECN-Capability” which describes the transition of Not-ECT to ECT0 or ECT1 (and by extension CE) as being “incorrect”.
>  
> RFC9331 section 5.1 discusses L4S network node behavior and includes the statement: “An L4S AQM treatment follows similar codepoint transition rules to those in [RFC3168].” But, I haven’t found those rules stated very explicitly in RFC3168.

My general interpretation of these rules is as follows:

Not-ECT MUST NOT be changed to any other value by a node (per RFC-3168).  This would falsely indicate an ECN-Capable Transport to other nodes, which might then choose not to drop the packet in response to congestion, since they believe they can indicate congestion by other means.

ECT(0) and ECT(1) MAY be changed to CE in order to indicate congestion without packet loss (per RFC-3168).  These values MAY also be changed to Not-ECT when circumstances dictate, eg. under certain abnormal conditions at the decapsulation end of a tunnel, but ideally this should never occur in well-behaved scenarios.

There is no established rule stating whether ECT(0) may be changed to ECT(1) by a node or vice versa.  An obsolete RFC did rely on this *not* occurring in the network, but this RFC was never deployed in the wild.  There remains the possibility of using these transitions to indicate fine-grained congestion information, so ideally nodes not participating in such experiments should avoid them.

CE MUST NOT be changed to another value, since that would erase congestion information (per RFC-3168):

> When a CE packet (i.e., a packet that has the CE codepoint set) is
>    received by a router, the CE codepoint is left unchanged…

If it is necessary (due to the aforementioned abnormal conditions) to change it to Not-ECT, then the entire packet MUST instead be dropped, as a Not-ECT packet would have been instead of receiving the CE mark.  See also the discussion on reassembling fragmented packets in RFC-3168.

I hope that is intuitive enough to follow.

 - Jonathan Morton