Subject: [tsvwg] ECT(1) Position with rationale

From: Luca Muscariello <[email-masked]>
Date: Sat, 9 May 2020 22:10:36 +0200

I fail to understand the way the chairs have formulated
the questions as they force everyone to choose among
L4S and SCE instead of focusing on specific issues.

Trying to find consensus on something that is not yet well
defined may end up in a vote of confidence.
If that is the case, I think that is of little help to fix
any of the pending issues.

Forced by this vote, I chose to stay on option 2 pretty much
as David Black I find myself in group 2 because “If you believe
L4S will not be safe for the internet without significant
architectural changes, you are in this group.”

The rationale of that is due to the pending issues reported
below.
There is overlap with issues reported by David Black, Jake Holland,
and others that have raised concern on safety, but some
have not been covered.

1) L4S goal is to reduce latency by using DCTCP. Therefore the queue
that accommodates DCTCP traffic is also supposed to serve
all latency sensitive traffic. However DCTCP and unresponsive
traffic do not coexist well in the same queue.
To what extent the two traffic types can share the same queue has
been ignored and should be the object of additional research.
I've mentioned this issue several times but it has
always been ignored.

2) DCTCP and TCP are conflicting and need to be separated.
L4S does that using dualQ. DualQ gives priority to DCTCP over TCP
with a variable service ratio. Any traffic that is marked
with ECT(1)  enters the priority queue.

2.1 Traffic that is unresponsive to ECN and is marked with ECT(1)
can starve the non-priority-queue
2.2 Traffic that is unresponsive to ECN and is marked with ECT(1)
can make the priority queue incapable to meet the low-latency goal.

3) Previous issues can happen because of misconfiguration, to harm
the network (DoS) or to obtain a profit to the disadvantage of other
applications.

The component that is supposed to protect the priority queue in L4S
is called queue-protection and is a flow-based black-list.
The queue protection mechanism reacts to misbehavior and by definition
inhibits the ability of L4S to guarantee its primary goal to
optimize for latency.
In addition to the above the queue protection is not mandatory.

4) L4S assumes a revolutionary deployment and not evolutionary.
By design L4S assumes that the bottleneck is a dualQ link.
To meet the optimization objectives, L4S assumes that the access
link is the only bottleneck (DOCSIS).
However this is often not the case.

4.1 In ISP networks over-subscription is not rare nowadays and L4S
puts pressure on network upgrades at the aggregation level.
An ISP that deploys dualQ in the DOCSIS segment either
deploy dualQ where congestion is possible to happen or it
upgrades the aggregation network.

4.2 On a similar level the transit network can be a bottleneck.
Not every ISP has content-peering agreements.

4.3 Enterprise networks, reachable via a VPN can easily have a bottleneck
in the enterprise WAN.
The bottleneck can easily be out of the home access.

In all the cases above, heuristics must be put in place to make
DCTCP fall back to standard ECN (RFC 3168) or worse ignore ECN.
These heuristics can create damages as DCTCP and TCP may share
the same queue. In the best case latency optimization vanishes.

For a very long time L4S may not provide any measurable advantage
in terms of latency unless the network segments above
are guaranteed to be congestion-free or unless dualQ is deployed in all
of them. I do not see the latter and the former happen
in the foreseeable future.

/Luca