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

[Ingemar Johansson S <[e-mail]>]

Hi

Thanks Gorry, Greg and Jonathan for the prompt response. 

I believe that it pretty much explains that Not-ECT should not be changed to any of the other ECN code points in a network.

ECT(0) to ECT(1) is an open question as I see it but I guess that it is safe to state that network nodes that are to comply to RFC9331 should not implement such behavior ?

/Ingemar

> -----Original Message-----
> From: tsvwg <[e-mail]> On Behalf Of Jonathan Morton
> Sent: Friday, 19 May 2023 00:35
> To: Greg White <g.white=[e-mail]>
> Cc: Gorry Fairhurst <[e-mail]>; Ingemar Johansson S
> <ingemar.s.johansson=[e-mail]>; [e-mail]
> Subject: Re: [tsvwg] Question about proper node behavior -ECN
> 
> > 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