From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mout.gmx.net (mout.gmx.net [212.227.15.19]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by lists.bufferbloat.net (Postfix) with ESMTPS id 04EDC3B2A4 for ; Wed, 29 Apr 2020 07:21:56 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gmx.net; s=badeba3b8450; t=1588159273; bh=yw+04u2Og39q/+FG72XP1UQ4V2w5ftx7KQ+2kVixjMA=; h=X-UI-Sender-Class:Subject:From:In-Reply-To:Date:Cc:References:To; b=Uj6M/g/IR2ACjjo+zMKtqlsK3x69b+d3m6TgQv9FqZ+Ut563NLSNO/DOCs5zLJq5l 5xKPHy5NTJSGzxjiNeDd4+g+JwU5rW2C1w7R72W6Ap3R9PXTgPq9Bd5xM1dxo3hUe6 YTgulO3tNI101ApSbAdqyycErtsLp5EedzD2Di1w= X-UI-Sender-Class: 01bb95c1-4bf8-414a-932a-4f6e2808ef9c Received: from [10.11.12.16] ([134.76.241.253]) by mail.gmx.com (mrgmx004 [212.227.17.190]) with ESMTPSA (Nemesis) id 1N5VDE-1j6AD51PAo-0170zU; Wed, 29 Apr 2020 13:21:13 +0200 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.14\)) From: Sebastian Moeller In-Reply-To: Date: Wed, 29 Apr 2020 13:21:11 +0200 Cc: =?utf-8?Q?Dave_T=C3=A4ht?= , ECN-Sane , tsvwg IETF list Content-Transfer-Encoding: quoted-printable Message-Id: References: <6d925e3b-2781-0fb1-6936-7a6c006b9a21@bobbriscoe.net> <117EA22C-6C9B-47E6-9454-35C181A0A2B3@gmx.de> To: Bob Briscoe X-Mailer: Apple Mail (2.3445.104.14) X-Provags-ID: V03:K1:9G/6bqq/fL/zQx6GcP67uuwNNYOC4yBqXAB78H5VOTQ3o5x72jj 7TlqQnC482rncRMgbTnzbU7lHVwqx81IUypZMxYD3GxJNJ9cne2C0ew9MF4W6MQoW56SsSU h/gzSb8d/W/GfZyW3B0+U0gFa2kHC56+/n8R/anF5R5Wbv3enx4h87baVW/12wfn7SdpFVG CF4xkPM+/wOX8aFhTWp5g== X-Spam-Flag: NO X-UI-Out-Filterresults: notjunk:1;V03:K0:h5HZ9/3kMog=:227zTKj5Fbg2YCbjxuSSY0 esOsqapfkTn2ChVEB0DMqAEX5ixwaSndNTPn79gSO7JmbXS2mNcnf8tlqkWHwIp5NpwoJ6QYI Giwyzrb29UCE8Z8pqoDiKh8lb1hOY814+mczwTi0wLY2Tvy+f+XsdbKH0hEiKdY8x+fDR8YMR gXfHb7U3mHbHLyVp02Hn+/PVcf9tf5Z1sHIr5lSwDEM1JaibOfqgYQcQX/pXplSY01Olsc7W8 6C6BzOOWTR/9fSEGfxBtZpFlU6/bq7WMiiBDIbxhR8epPBDAG7PXebqHUC4RB64FOglAQ1ffY lm0EOlGeOpYqMX96QsdK79RWo5V6b4P5EjSTTx3UhiOcZyfwCyX+7fUoE8wCPNcmT3+xdGXc9 mL4Tr1qs4bEJOkeLYAzezftC4jtMNjXwmfsjnaWzeXw1yL+YFk0SCtkQ9IimRRH3kYeT4hS3h +p2ddxEGhwCEhik6guVy4jcGbf/gDFsIPJVwXl243pMOKrf1nCPoD2NCkpwdfBvqmZOCv0cN6 BiTyqo+5aoPu3hpRjOxft8aR3kT1oiyKho0qK4ZflXIEuBKbt/uJiendxWU+tYtAnjfo+Ys4o a3KiG4ZOa5poF64UERSu+LsAv4829iF9EBJdSCBxREphAPb32w/E3To1NV1KrWHUAOqU56558 8bvC1RYdCn3knkmhbLgmFL3thrOYlSO1RQfFPC4K3pPC91sDBW6SkkZZ9piqY1z4RFPspRVcK P8+tgL05B4FUMiYCYLHwrox6xN81RojZ82cZ9N/gdUPpvJQ78ncbxjUqm3qmoU8VxvWphAdiy wam0cWWS6QUk0HpsOswjFIAttg9KxQntCvrms2ooo+NTebKCgezBIgTrPTvrvoI2ub98uSgUc 8fixulQRoR0B1P3e3Qy7Y07n1p/HE811BRQOsT940DkF60M8DGktZu9MHbGWrUwwKL7MPcvLg vR7NRPubhPdi3uPNUv+j/v/3HIXJ9hth227jcUQ3NtmcwniACVZCJ7BO1szeDurN0BPv3VtQL CSpGENUqUEoe+Oc9+XlXQpI87TdyZb7EYdlSdQgTbiRmrzTPQQtETt0qQjOySOtIOfy3F2jwK qclfdwx9dnVfDfoV1NUS08v4KFjyRM1A7JDeMGuBPyXQJLvvG1i9DH7xzit7ldjbbiGkQ54iC v1hWhn50dd9lD2XoKvRilpq0m1YPCO0LEiKspAC2jz2GrmYpn5x8uaetlFNLh2HulODo8GbUV dtsn7wuE+Z190prKke4biqCGCtDtqq+0bgz9KCw== 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 11:21:57 -0000 Hi Bob, more below in-line. > On Apr 29, 2020, at 12:32, Bob Briscoe wrote: >=20 > Sebastian, >=20 > On 29/04/2020 10:46, Sebastian Moeller wrote: >> Hi Bob, >>=20 >>=20 >>> On Apr 29, 2020, at 11:31, Bob Briscoe wrote: >>>=20 >>> Dave, >>>=20 >>> Please don't tar everything with the same brush. Inline... >>>=20 >>> On 27/04/2020 20:26, Dave Taht wrote: >>>> just because I read this list more often than tsvwg. >>>>=20 >>>> ---------- 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 >>>>=20 >>>>=20 >>>> 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? >>>>=20 >>>> ... >>>>=20 >>>> so: A) PLEA: =46rom 10 years now, of me working on bufferbloat, = working >>>> on real end-user and wifi traffic and real networks.... >>>>=20 >>>> 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#sub= section.4.2 >>> 2019: = https://www.files.netdevconf.info/f/febbe8c6a05b4ceab641/?dl=3D1 >>> 2015: = http://bobbriscoe.net/projects/latency/dctth_preprint.pdf#subsection.7.2 >>>=20 >>> 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. >>=20 >>> 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. >=20 > [BB] Fair enough, it's true there was not saturating traffic in the = uplink. [SM] Yes, please report the outcome of such a test, as this s = not an irrelevant corner-case, but one of the conditions where L4S needs = to shine if you want it to succeed. The idea here would be obviously to = instantiate one L4S AQM instance per direction, just as the RFC's = propose L4S to be rolled-out.=20 QUESTON: I take it that you actually have tested topologies with one = DualQ instance per direction, but you never attempted to saturate bot = directions simultaneously, or did you only ever test topologies with a = single AQM instance? >=20 > 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. [SM] Pardon me? Please go and try standard SQM with either = HTB+fq_codel or just cake and revisit the idea about ACK traffic to be = an unsurmountable challenge. And for your entertainment cake actually = has a optional ACK filter...=20 What I want to say, I have tested that condition already and the = relative low-latency solution I use copes with that rather nasty traffic = pattern pretty well, from reading the L4S drafts my understanding that = L4S should also perform admirably here.=20 >=20 > 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. [SM] So you are saying that L4S is not suitable for = bi-directionally saturating traffic? I have long complained about the = lack of testing against adversarial traffic patterns in L4S, but here we = are not talking adversarial traffic, but really the bread and butter = traffic, a solution that claims to deliver low-latency, low-loss and = high throughput needs to cope with gracefully. IMHO, ACK thinning is a red herring, as the acceptable = performance of SQM (without ACK thinning) under these conditions = demonstrates.=20 >=20 > 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. [SM] All fine, but if L4S really depends on this for normal = operation, this needs to be honestly described in the L4S RFC IMHO, = especially what the expected consequences are of not fixing ACK = congestion. > However, when you're digging the foundations for others to build on - [SM] How about we let history be the judge of that? > 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). [SM] Well, if you promise the world, the onus is on you to = deliver it. If, as it seems, you just agreed, that L4S as currently = designed and implemented will not gracefully deal with bi-directionally = saturating loads... Puzzled, why you believe the releasing L4S into the = wild before that open flank is closed?=20 >=20 > 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. [SM] And then you need to test whether what you learned in the = isolated/reduced cases also holds for the interactions... > 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. [SM] I am puzzled, if you consider bi-directional saturating = traffic to be theoretically problematic for L4S, why did you not = actually go and confirm that, and then try to figure out remedies INSIDE = of the L4S framework (and with that I mean the ietf relevant portions, = if you consider TCP Prague as part of L4S, It would be nice to see an = RFC draft for that) Regards Sebastian >=20 > Regards >=20 >=20 >=20 > Bob >=20 >=20 >=20 >>=20 >> Best Regards >> Sebastian >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >=20 > --=20 > ________________________________________________________________ > Bob Briscoe http://bobbriscoe.net/