[tsvwg] L4S re-ordering considered harmful? (VPN edition)

[Sebastian Moeller <[e-mail]>]

Dear All,

we had a few discussions in the past about L4S' dual queue design and the consequences of packets of a single flow being accidentally steered into the wrong queue.
So far we mostly discussed the consequence of steering all packets marked CE into the LL-queue (and https://datatracker.ietf.org/doc/html/draft-ietf-tsvwg-ecn-l4s-id-14#appendix-B.1 Risk of reordering Classic CE packets: only discusses this point); there the argument is, that this condition should be rare and should also be relative benign, as an occasional packet to early should not trigger the 3 DupACK mechanism. While I would liked to see hard data confirming the two hypothesis, let's accept that argument for the time being.

BUT, there is a traffic class that is actually sensitive to packets arriving out-of-order and too early: VPNs. Most VPNs try to secure against replay attacks by maintaining a replay window and only accept packets that fall within that window. Now, as far as I can see, most replay window algorithms use a bounded window and use the highest received sequence number to set the "head" of the window and hence will trigger replay attack mitigation, if the too-early-packets move the replay window forward such that "in-order-packets" from the shorter queue fall behind the replay window.

Wireguard is an example of a modern VPN affected by this issue, since it supports ECN and propagates ECN bits between inner and outer headers on en- and decapsulation. 

I can see two conditions that trigger this:
a) the arguably relatively rare case of an already CE-marked packet hitting an L4S AQM (but we have no real number on the likelihood of that happening)
b) the arguably more and more common situation (if L4S actually succeeds in the field) of an ECT(1) sub-flow zipping past ECT(0)/NotECT sub-flows (all within the same tunnel outer flow)

I note that neither single-queue rfc3168 or FQ AQMs (rfc3168 or not) are affected by that issue since they do not cause similar re-ordering.


QUESTIONS @ALL:

1)  Are we all happy with that and do we consider this to be acceptable collateral damage?

2) If yes, should the L4S OPs draft contain text to recommend end-points how to cope with that new situation? 
	If yes, how? Available options are IMHO to eschew the use of ECN on tunnels, or to recommend increased replay window sizes, but with a Gigabit link and L4S classic target of around 20ms, we would need to recommend a repay window of:
>= ((1000^3 [b/s]) / (1538 [B/packet] * 8 [b/B])) * (20[ms]/1000[ms]) = 1625.48764629 [packets]
or with a power of two algorithm 2048, which is quite a bit larger than the old default of 64...
	But what if the L4s AQM is located on a back-bone link with considerably higher bandwidth, like 10 Gbps or even 100 Gbps? IMHO a replay window of 1625 * 100 = 162500 seems a bit excessive


Also the following text in https://datatracker.ietf.org/doc/html/draft-ietf-tsvwg-ecn-l4s-id-14#appendix-A.1.7

"  Should work in tunnels:  Unlike Diffserv, ECN is defined to always
      work across tunnels.  This scheme works within a tunnel that
      propagates the ECN field in any of the variant ways it has been
      defined, from the year 2001 [RFC3168] onwards.  However, it is
      likely that some tunnels still do not implement ECN propagation at
      all."

Seems like it could need additions to reflect the just described new issue.



Best Regards
	Sebastian