Subject: [tsvwg] Position on ECT(1)

From: Luca Muscariello <[email-masked]>
Date: Sun, 26 Apr 2020 17:56:16 +0200

Tsvwg list members,

This constitutes my personal opinion but it has matured by following
the discussion in this list and with internal discussion at Cisco.
It is not an official position at Cisco but my genuine personal
technical opinion.

Any contribution that can help reduce buffer occupancy in the Internet is
highly valuable as it can potentially allow to build equipment with less
memory, simpler to design and build in software and hardware. It can reduce
applications' latency but it has to come w/o penalizing existing
applications
and services that need predictable performance.
The effort coming from both teams L4S and SCE is highly valuable. So
many thanks to both teams as they have made an incredible amount of work.

I believe that ECT(1) should be a network output.

I agree with all comments written by Jake but I wanted to add
a few more comments.

- Congestion control is a closed loop adaptation and having additional
adaptations to detect the parameterization of a specific congestion control
mechanism, used at the end-point, looks not safe. Having one closed-loop on
top of
another is difficult to model, analyze and tune to obtain predictable
performance. Adding perturbation analysis to some of the experiments
presented
by the L4S and SCE team would probably reveal different kinds of
instabilities
that in practice may be difficult to troubleshoot, if things go wrong.
They are already difficult when it comes to congestion control. Adding
complexity seems a bad idea.

- ECT(1) as a network output is deterministic, it is simpler to analyze.
This  looks like a clear advantage, as congestion signals based on 3DUPACK,
low frequency ECN and high frequency ECN coexist.
It is not uncommon that the same network path may be congested in the last
mile in the morning, in the middle-mile in the afternoon and in the
transit at night (all combinations are possible).

- It is unclear to me that standard ECN management has to retire, whatever
is the output of these experiments. IMO the output of these experiments
should not retire standard ECN.

- Real-Time collaboration services such as on-line meetings generate
a mix of traffic. Some flows react to losses differently compared to TCP.
Audio/video/content sharing makes use of FEC rather than ARQ and FEC makes
traffic increase with losses.
I don't see any of these applications using ECN and they may share a low
rate
link with TCP (common). Having an adaptation mechanism on top of TCP to
guess the correct parametrization, may affect negatively the quality of an
on-line meeting. These kind of interactions have not been considered so far
in the experiments but it is clear that having deterministic behaviours
is safer.

- using ECT(1) as network output makes each component loosely coupled
to the others. In general, this is a good property for distributed systems.
Different AQMs can use different ECN signals, designed and parameterized
by different people. Different kinds of controllers can coexist, be
designed and optimized for different use cases (thinking a lot about
wireless).
For instance, I think that dualQ and TCP Prague work in progress suffer
from
the two parts being highly coupled, by using ECT(1) as network input. This
also
complexifies the work from the access viewpoint (e.g. DOCSIS) which has
a strong requirement on the end-point behaviour.

- DSCP looks like the most natural way to classify traffic, including
for dualQ. I believe that most of the low latency services targeted
in this whole discussion may need to have an edge compute appliance
on premise or in the ISP network. DSCP becomes a valuable solution
in such a case.

Luca