Re: [tsvwg] RFC 4301 on ECN codepoints (was RE: L4S vs SCE (Evolvability))

[Jonathan Morton <[e-mail]>]

> On 2 Jan, 2020, at 12:13 pm, Ingemar Johansson S <ingemar.s.johansson=[e-mail]> wrote:
> 
> I read in https://tools.ietf.org/html/rfc4301#section-5.1.2.1  the following
> 
>      (6) If the ECN field in the inner header is set to ECT(0) or
>          ECT(1), where ECT is ECN-Capable Transport (ECT), and if the
>          ECN field in the outer header is set to Congestion Experienced
>          (CE), then set the ECN field in the inner header to CE;
>          otherwise, make no change to the ECN field in the inner
>          header.  (The IPv4 checksum changes when the ECN changes.)
> 
> So, if we have an SCE flow that is tunneled:
> 1) At the tunnel ingress, the ECN bits are copied to the outer header.
> 2) Somewhere along the tunneled path an SCE compatible AQM remarks from ECT 
> '10' to SCE '01'.
> 3) At tunnel egress, given rule #6 above, I understand that the inner header 
> will still be ECT '10'.
> 
> In order words, the SCE congestion marks along the tunneled interface become 
> ignored and the queue will grow until packets are either CE marked, or 
> dropped.
> 
> Is this a correct interpretation ?

Yes.  It would be as if the SCE-aware AQM on the tunnel path was merely RFC-3168 compliant, if the tunnel exit node correctly implements the above language.

 - Jonathan Morton