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

[Sebastian Moeller <[e-mail]>]

Hi Oliver,

more below.

> On Nov 11, 2019, at 01:18, Tilmans, Olivier (Nokia - BE/Antwerp) <[e-mail]> wrote:
> 
> 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).

	[SM] Sorry, that does not compute to me, if at all it points at a bug in dctcp that would merit fixing. In essence dctcp aims a specific niche where this can be toerated, but since yi aim for replacing all current CCs, you need to play by the rules. TCP Prague with ECN disabled should behave like Reno, it should IMHO accept that a systems admin sets policy and needs to respect the tools used for that purpose. 


> 
> 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.

	[SM] I first want to be convinced by data that this whole idea actually works under real-world conditions (for short RTTs your data indicates that dualQ/TCP Prague actually does not manage to decouple bandwidth and latency), and for that purpose being able to disable the ECN/AccECN part of TCP Prague while keeping the rest seems like much better suited for A/B testing than silently ignoring the syscontrol. This, as I repeat myself too often in the L4S related threads, is not rocket science.

Best Regards
	Sebastian

> 
> 
> Best,
> Olivier