From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from cl3.bcs-hosting.net (cl3.bcs-hosting.net [3.11.37.202]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by lists.bufferbloat.net (Postfix) with ESMTPS id 5501A3B29E for ; Wed, 29 Apr 2020 06:32:45 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=bobbriscoe.net; s=default; h=Content-Transfer-Encoding:Content-Type: In-Reply-To:MIME-Version:Date:Message-ID:From:References:Cc:To:Subject:Sender :Reply-To:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Id:List-Help: List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=nsT23XM9c3JkiB/ZmtoIkbAKkKatZ3mMsZ06nseP/Y4=; b=AOyhrsgsdYGQP68RNppSA1YtcE 3Tp5TXkPXRbuJNd+sPTiVL7gBvtqPC3CmuFV3mbK3xUX0JVonioP5e0hCUoDkXm+JiA3adpslXvs7 LpvT3jXfA/ar0Yv3zgBVGfV4wn9p2oUQDmzk29dvVRDpFN5eZEx4MgP2u/Wry+llK9k5WIax+rJOs cmDwcfafYK8KMxOhCOciD1UdTeHyLhTzUQtRrLYLA3meKortrebKebgsE5vzK0oa1Gwz/CN03eovJ yVuyi2ioY3Z5I7yvySfihn2HBkGot3YnAQJekIU1hJJMo7vDsKBHFgs/w81YuczEdEwspdlSuz1yN t72/Qypw==; Received: from [31.185.128.97] (port=33258 helo=[192.168.0.6]) by cl3.bcs-hosting.net with esmtpsa (TLS1.2) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.93) (envelope-from ) id 1jTk1E-003MLg-F3; Wed, 29 Apr 2020 11:32:44 +0100 To: Sebastian Moeller Cc: =?UTF-8?Q?Dave_T=c3=a4ht?= , ECN-Sane , tsvwg IETF list References: <6d925e3b-2781-0fb1-6936-7a6c006b9a21@bobbriscoe.net> <117EA22C-6C9B-47E6-9454-35C181A0A2B3@gmx.de> From: Bob Briscoe Message-ID: Date: Wed, 29 Apr 2020 11:32:43 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.6.1 MIME-Version: 1.0 In-Reply-To: <117EA22C-6C9B-47E6-9454-35C181A0A2B3@gmx.de> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Content-Language: en-GB X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - cl3.bcs-hosting.net X-AntiAbuse: Original Domain - lists.bufferbloat.net X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - bobbriscoe.net X-Get-Message-Sender-Via: cl3.bcs-hosting.net: authenticated_id: in@bobbriscoe.net X-Authenticated-Sender: cl3.bcs-hosting.net: in@bobbriscoe.net X-Source: X-Source-Args: X-Source-Dir: Subject: Re: [Ecn-sane] [tsvwg] Fwd: my backlogged comments on the ECT(1) interim call X-BeenThere: ecn-sane@lists.bufferbloat.net X-Mailman-Version: 2.1.20 Precedence: list List-Id: Discussion of explicit congestion notification's impact on the Internet List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Apr 2020 10:32:45 -0000 Sebastian, On 29/04/2020 10:46, Sebastian Moeller wrote: > Hi Bob, > > >> On Apr 29, 2020, at 11:31, Bob Briscoe 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 >>> Date: Mon, Apr 27, 2020 at 12:24 PM >>> Subject: my backlogged comments on the ECT(1) interim call >>> To: tsvwg IETF list >>> Cc: bloat >>> >>> >>> 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/