Re: [tsvwg] L4S status: #17 Interaction w/ FQ AQMs

["Tilmans, Olivier (Nokia - BE/Antwerp)" <[e-mail]>]

Hi Sebastian,

> I just stumbled over:
> 
> • TCP Prague will always use Accurate ECN, regardless of the
> net.ipv4.tcp_ecn value. This eases up concurrent testing of different CCA
> that may or may not want to use ECN (e.g., plain non-ECN cubic).
> 
> I assume that this is only for testing and not supposed to be the default
> for an eventual up-stream submission of tcp prague?

To achieve its goal (low latency even in the high percentiles), a sender has
to finely tune its sending rate to match the bottleneck queueing limit.
- CBR-sparse-* flows have no issue doing this as they tend to under-utilize the
link (or their service is simply broken anyway).
- Capacity-seeking/greedy flows need a way to estimate this limit--that is what
motivates the needs for a 1/p response with L4S.

DCTCP can achieve this estimation with an implicit, negociation-less, estimate
as it operates in a controlled environment (both in terms of endhost configuration
as they need to cooperate, and in terms of network behaviors, as ACK losses/thinning
could massively impact peformances)

Given that Prague aims to be "DCTCP over the internet", it has to withstand
middleboxes toying with the receive window, ACK thinning in WiFi/LTE/..., pure
ACK losses, encapsulation, proxies, ... Getting this fine-grained CE estimate in
order to deliver its service--LL even in the high percentiles, has to work in all
cases. AccECN is at the moment the only (as far as I know) reliable way
to get this fine-grained feedback/congestion estimate for TCP.
QUIC has this built-in its ACK frame, so does rmcat/SCReAM.

This is similar to DCTCP forcing the use/negociation of ECN, regardless of the actual
sysctl value, as it cannot provide its service without it (in other words, becomes
plains reno).

Of course, anyone can decide to write its own TCP CCA that does not want to rely on
AccECN yet somehow benefit from the marking given by the L queue, and experiment with
it--e.g., playing with the usual latency/bandwidth tradeoff.


Best,
Olivier