[Ecn-sane] [tsvwg] Fwd: my backlogged comments on the ECT(1) interim call

[Sebastian Moeller]

Hi Bob,


> On Apr 29, 2020, at 11:31, Bob Briscoe <ietf at bobbriscoe.net> wrote:
> 
> Dave,
> 
> Please don't tar everything with the same brush. Inline...
> 
> On 27/04/2020 20:26, Dave Taht wrote:
>> just because I read this list more often than tsvwg.
>> 
>> ---------- Forwarded message ---------
>> From: Dave Taht <dave.taht at gmail.com>
>> Date: Mon, Apr 27, 2020 at 12:24 PM
>> Subject: my backlogged comments on the ECT(1) interim call
>> To: tsvwg IETF list <tsvwg at ietf.org>
>> Cc: bloat <bloat at lists.bufferbloat.net>
>> 
>> 
>> It looks like the majority of what I say below is not related to the
>> fate of the "bit". The push to take the bit was
>> strong with this one, and me... can't we deploy more of what we
>> already got in places where it matters?
>> 
>> ...
>> 
>> so: A) PLEA: From 10 years now, of me working on bufferbloat, working
>> on real end-user and wifi traffic and real networks....
>> 
>> I would like folk here to stop benchmarking two flows that run for a long time
>> and in one direction only... and thus exclusively in tcp congestion
>> avoidance mode.
> 
> [BB] All the results that the L4S team has ever published include short flow mixes either with or without long flows.
>     2020: http://folk.uio.no/asadsa/ecn-fbk/results_v2.2/full_heatmap_rrr/
>     2019: http://bobbriscoe.net/projects/latency/dctth_journal_draft20190726.pdf#subsection.4.2
>     2019: https://www.files.netdevconf.info/f/febbe8c6a05b4ceab641/?dl=1
>     2015: http://bobbriscoe.net/projects/latency/dctth_preprint.pdf#subsection.7.2
> 
> I think this implies you have never actually looked at our data, which would be highly concerning if true.

	[SM] Bob, please take the time to read what Dave is asking for here, it is rather specific, and as far as I can tell has never been tested in all the years.

> 
> Regarding asymmetric links, as you will see in the 2015 and 2019 papers, our original tests were conducted over Al-Lu's broadband testbed with real ADSL lines, real home routers, etc. When we switched to a Linux testbed, we checked we were getting identical results to the testbed that used real broadband kit, but I admit we omitted to emulate the asymmetric upstream. As I said, we can add asymmetric tests back again, and we should.

	[SM] You tested an asymmetric link, with no AQM on the uplink and also no saturating traffic on the uplink, this is not the test Dave has been championing for years a fully saturating load by 4 or more capacity-seeking flows per direction. 
	As far as I can tell in all of the testing you did, you never got around to test this  for end-user rather important condition: the whole family/group is using the internet access link to its max. It is exactly that condition where latencies typically go through the roof and people resort to crude behavioral solutions (do not game while someone vide-conferences, and the like).
	The pure fact that you never tested this really IMHO demonstrates that magnitude of testing is no good proxy for quality of testing, especially since Dave repeatedly asked for bi-directionally saturating loads to be tested.

Best Regards
	Sebastian