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

[Bob Briscoe <ietf@bobbriscoe.net>]

Sebastian,

On 29/04/2020 10:46, Sebastian Moeller wrote:
> Hi Bob,
>
>
>> On Apr 29, 2020, at 11:31, Bob Briscoe <ietf@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@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@ietf.org>
>>> Cc: bloat <bloat@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.

[BB] Fair enough, it's true there was not saturating traffic in the uplink.

Until we introduce ACK congestion control (host) or RFC3449-compliant 
ACK thinning (network), such tests would just prove the need for better 
ACK congestion control or good ACK thinning, and not properly test the 
thing we're both trying to test.

IOW, if you want to test a solution to problem A, there's no point using 
a scenario that deliberately shows up problem B, for which a solution 
isn't included in the test environment.

As is made clear in the informative part of the ECN++ draft ( 
https://tools.ietf.org/html/draft-ietf-tcpm-generalized-ecn-05#section-4.4.1 
), AccECN feedback provides an easy basis to integrate ACK congestion 
control with data congestion control. However, when you're digging the 
foundations for others to build on - you can't do all the building work 
as well - you have to rely on other people to take up that mantle (hence 
the pointers I gave to the other work on sender control of ACK thinning, 
that are now snipped from this thread).

This is something else I meant to say to Dave. When testing distributed 
systems, you have to test each change one at a time, to discover which 
changes are good and which are bad. That's why there is a role for tests 
with simple traffic mixes, even tho they're not realistic. Yes, it's 
also necessary to show a system works as a whole in a realistic setting 
(hence the tests I pointed to with real applications), but for testing 
purposes, changing multiple things at once gives little insight into 
potential problems or actual problems.

Regards



Bob



>
> Best Regards
> 	Sebastian
>
>
>
>
>
>
>

-- 
________________________________________________________________
Bob Briscoe                               http://bobbriscoe.net/