Re: [Ecn-sane] tsvwg preso for sce is up

[Sebastian Moeller <moeller0@gmx.de>]

Hi Dave,


> On Jul 31, 2019, at 04:03, Dave Taht <dave.taht@gmail.com> wrote:
> [...]
> Also bob is perpetually making a point about applications needing to
> briefly exceed their fair share, I'd like to make a point
> about how quickly an application can grab more share when it appears
> with shorter rtts possible on the link. Quadratic response
> times mean a lot....

	The obvious problem with Bob's rationale is that his idealized behavior immediately turn against the user, if it is "everything else" in Bob's example that the user actually would like to have priority then his lack of euqal-bandwidth enforcement will actually be harmful. 
	Personally, I believe that it is better to do, equal-share as default and let the user's override that on a if-needed-basis instead of having Bob's anything goes world (which unfortunately is the current reality), as equal share is easy to understand and to predict, and we have ample proof now that FQ (sqm-scripts in OpenWrt) for the home network is an improvement over the what-ever mode of the default internet experience. 
	In other words, Bob seemingly puts too much trust in the benevolence of all endpoints. This reminds me yet again on the discussions I had decades ago about the differences/advantages between cooperative and/over preemptive multitasking: theoretically cooperative multitasking will be superior to preemptive one but assumes both benevolent processes and effectively perfect information not only about a processe's own resource demands but also about all other running (and to be started) processes; I end this tangent by noting that preemptive multitasking more or less won this battle with only nice use of cooperative multitasking surviving. 
	I believe the same rational to be applicable for AQMs, since not all endpoints are benevolent (see the arms race of CDNs with the initial window size), we are better off to treat all of them as "hostile" and enforce a sane default policy; FQ being one of those sane policies that already proved that they are worth their salt. I wonder whether it is worth disscusing that point openly with Bob, though as it is partly a matter of taste and subjective risk-aversion.


> [...]
> Convincing an entire market to take a 3x latency hit on normal traffic
> so some other traffic can gain priority seems like an uphill climb.

	So far I fail to see L4S working for any other use-case than "high-way" to a close DC, as I simply do not believe that the required synchronization of remote senders to below-millisecond accuracy will generally work over the internet (L$S basically assumes close to zero RTT variations and the ability of OSs to actually dispatch packets with <ms accuracy). The initial paper only demonstrated that this accuracy is achievable but failed ot demonstrate how robust and reliable this can be achieved. The fact that ACK-clocking is supposed to aim as synchronisation mechanism makes we wonder what these guys were smoking. As far as I know NTP only claims several-milliseconds accuracy for its synchronisation over the internet, so I wonder what special souce the L4S team brought to the table to improve on the status quo by ~an order of magnitude?


> 
> I'd like to define terms better. "Ultra-low-latency" seems to mean sub
> 1ms latency?, which fq achieves on 90+% of flows.

	"Ultra-low-latency" is perfect marketing-speak with very little substance...


Best Regards
	Sebastian