Re: [tsvwg] Another tunnel/VPN scenario (was RE: Reasons for WGLC/RFC asap)

[Jonathan Morton <[e-mail]>]

> On 3 Dec, 2020, at 2:19 pm, Bob Briscoe <[e-mail]> wrote:
> 
> Encrypted tunnels not revealing the component flows in the payload is a correct property of layering, which has been a principle that guides protocol design since long before the Internet protocols adopted it. I would ask you to imagine standing up (virtually) in an IETF plenary (or any networking forum) and blame layering (and/or layered encryption) for FQ not being able to isolate component flows. You would be flamed to a crisp.

I did not make any such argument about layering, so I will treat this as the strawman it is, by ignoring it.

> The root cause of the problem can be objectively determined. FQ doesn't correctly schedule flows within encrypted tunnels, whether L4S is present or not. Therefore L4S cannot be the root cause of this problem.

This is where you are incorrect.  If FQ cannot distinguish between the flows encapsulated within a tunnel, its behaviour merely reverts to that of a single queue, by design.  This also means that FQ-AQMs effectively revert to single-queue AQMs in that case.  Existing traffic is perfectly happy with that arrangement, and it is generally an improvement over single queues *without* AQM, which is presently the status quo over much of the Internet.

RFC-3168 and RFC-8511 lay out certain congestion control behaviours which permit ECN and loss signalling of congestion to coexist, and that arrangement works quite well at present.  Transports obeying these requirements (and those of TCP friendliness without ECN) coexist without starving each other out of the network.  Even though they do not always share the link with perfect fairness (or even RTT-fairness), it is within some reasonable factor.

Specifically, RFC-3168 expects AQMs to signal by loss on Not-ECT packets at the same rate as they signal by CE marks on ECT packets, to treat ECT(0) and ECT(1) as equivalent, and for congestion control to respond in the same way to CE marks as to packet loss.  RFC-8511 relaxes RFC-3168 slightly, and specifies a minimum response to single CE marks (per RTT) of a 15% reduction of cwnd (for window based transports) or send rate (for rate based transports), ie. a Multiplicative Decrease event.

The introduction of L4S traffic upsets this situation, by violating the above-mentioned provisions of these two RFCs.  L4S transports cause substantially more harm to other transports, when they happen to share an AQM queue, than existing transports do.  Redefining the semantics of the CE mark is the single element that, if removed, makes all the coexistence problems on existing networks go away.

Frankly, the sooner the WG understands and accepts that basic fact, the sooner we can move to a viable solution - one which does not redefine CE from the semantics established by RFC-3168 and RFC-8511, and hence does not place burdens on networks which have no interest in the L4S experiment.

 - Jonathan Morton