Re: [tsvwg] feedback and thoughts L4S / SCE

[Sebastian Moeller <[e-mail]>]

Hi Greg,



> On Nov 20, 2020, at 20:38, Greg White <[e-mail]> wrote:
> 
> Hi Mikael,
>  
> On your point about L4S in non-ECN FIFOs, I agree that these will dominate in the Internet for quite some time. But, I don’t believe there has been any evidence of lack of safety for L4S-compatible CCs in those bottlenecks.

	[SM] Correct, that is not s much a case for not being safe but rather for TCP Prague not delivering on its promises:

http://sce.dnsmgr.net/_archive/l4s-2020-11-17T164559-s1-rtt-update/l4s-s1-rttfair/l4s-s1-rttfair-ns-cubic-vs-prague-pfifo_1000_-50Mbit-160ms-10ms_tcp_delivery_with_rtt.svg

http://sce.dnsmgr.net/_archive/l4s-2020-11-17T164559-s1-rtt-update/l4s-s1-rttfair/l4s-s1-rttfair-ns-prague-vs-cubic-pfifo_1000_-50Mbit-160ms-10ms_tcp_delivery_with_rtt.svg

Cubic wiping out (but not "completely starving") TCP Prague in a FIFO with one flw @160ms RTT the other at 10ms. So TCP Prague in a non-ECN fifo gets ~1:4 of the available bandwidth. Let's not talk about latency, since without an L4S AQM TCP Prague is not a low latency transport protocol, to be generous.

That is less of a safety concern and more of a can L4S actually deiver on its promises issue.

Mind you Koen's proposed solution is to make TCP Prague automatically switch to a CUBIIC like CC response once RTTs are >= 80 ms, a clear sign of defeat if any. L4S is a short fast-lane, not more (and not less) in spite of being marketed as the "future" of the internet...






>  It is, in fact, a requirement in the ECN-L4S-ID draft that CCs respond to loss in a Reno-safe way.
> https://tools.ietf.org/html/draft-ietf-tsvwg-ecn-l4s-id-12#section-4.3

	[SM] Sure and in the FIFO TCP Prague at least does no harm to CUBIC, but the ask by Lars was show do no harm AND deliver on its promises. For a change, with FiFO is not L4S being to aggressive.


>  
> What has been argued is that the current TCP Prague prototype CC responds to loss *exactly* like Reno, and so is outcompeted by Cubic in these bottlenecks (see the pfifo results in https://github.com/heistp/l4s-tests#network-bias ).

	[SM] Basing TCP Prague on DCTCP was a conscious choice of team L4S, with data indicating than basing on Linux' defsau;t TCP might have been a better approach, but it is what it is.


>  
> If you attended Bob & Koen’s talk in ICCRG (https://datatracker.ietf.org/meeting/109/materials/slides-109-iccrg-prague-congestion-control-00), you saw that they mention (slide 9) “faster than additive increase” as an aspect that is not currently included in the Prague CC.  They also mention (slide 15) “Integration with BBR/Cubic instead of Reno” as a possible area for others to contribute. 

	[SM] So also "not tested" at all. Or put differently, not clear if actually achievable,  like RTT-independence.... (which generically is no achievable from a connections end-points)

Best Regards
	Sebastian

>  
> -Greg
>  
>  
>  
> From: tsvwg <[e-mail]> on behalf of Mikael Abrahamsson <swmike=[e-mail]>
> Organization: People's Front Against WWW
> Date: Friday, November 20, 2020 at 6:34 AM
> To: "[e-mail]" <[e-mail]>
> Subject: [tsvwg] feedback and thoughts L4S / SCE
>  
> Hi,
>  
> I'm trying to catch up on the work has been done, but I thought I'd give 
> some thoughts / feedback on what I see:
>  
> https://github.com/heistp/l4s-tests
>  
> "L4S transports experience intra-flow latency spikes at RFC3168 
> bottlenecks, particularly with the widely deployed fq_codel"
>  
> FQ_CODEL isn't widely deployed. Yes, it's enabled in the linux kernel but 
> very seldom at the bw chokepoint of the connection. I do not agree with 
> the above statement at all. Thus any benchmarking vs FQ_ anything is 
> invalid. What's mostly used today are typically simple FIFOs, sometimes 
> diffserv enabled with multiple FIFOs.
>  
> This means the tunnel argument against any FQ or non-FQ AQM is invalid. I 
> also doubt we'll see widely deployed FQ going forward because of the cost 
> of doing this in hw (and most devices are hw accelerated).
>  
> "Deployments of fq_codel
> The fq_codel qdisc has been in the Linux kernel since version 3.6 (late 
> 2012) and is now in widespread use in commercial routers (e.g. Ubiquiti 
> EdgeMAX and UniFi products)"
>  
> This is misleading. Yes, EdgeMAX supports FQ_CODEL if you turn off 
> hw_acceleration, bringing down the performance to 10% or less of what the 
> hw acceleration yields. I do not agree that it's in "widespread" use.
>  
> I'd gladly take data to prove me wrong, that FQ_CODEL is in widespread use 
> at Internet bw chokepoints. I'd be surprised if it was enabled on more 
> than 1% of residential connections.
>  
> On to L4S.
>  
> Now, taking above statement and looking at what L4S is doing, for 1-2 
> decades going forward L4S enabled transport will often encounter FIFOs, 
> mostly without ECN capability at all. They need to be proven safe in this 
> operational reality. From what I can see, this is still not the case?
>  
> Going forward:
>  
> In order to progress to a solution, we need to have participants agree on 
> what the world looks like right now, what's doable in the next few years, 
> and what's required to handle existing/near term reality. SCE proponents 
> have to stop arguing that we'll have FQ_ anything near term, or that this 
> is in wide use. It's not. L4S proponents need to prove that their 
> proposals are safe in a world of FIFOs, and accept that this is going to 
> be a reality for years to come. AQMs aren't deployed in a hurry, we're 
> talking many years to deploy on the wider Internet.
>  
> We're spending the last bit in the IP header and we'd better get it right. 
> In order to do that, I'd like to see realism and pragmatism in the 
> reasoning.
>  
> -- 
> Mikael Abrahamsson    email: [e-mail]