From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-ssdrsserver2.hostinginterface.eu (mail-ssdrsserver2.hostinginterface.eu [185.185.85.90]) (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 3A4853B29E for ; Mon, 27 Sep 2021 10:50:18 -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=4nYY2hGAOfktoOZBa0nee15B60hWkSfZeA5l92uSRUI=; b=tRtLxt0T1vfsFmB+uEA/YqbTI4 yHDun77GlBPxye6IKKPdo+yrUZooGlJOdJbLXm26OF7UpJWOHekDy7nUxGRuc0NGHXFMhPcTGugLp 7mS1qkqgEs/70L1zjDXikADHk82hEdzfOXMQxQiI4u2XRCnA7Mz8/KPVcY6I0Bf0aV709HipgLf5t h7GanGECkmwJII/wJKKT0mwL4HWfP3wCkP5feh3FH4+T4xjnPZwz29wIguvGoSVf8K0PDWm/seSM/ o9x2Jw7cnXS6UPXsIswREmRrfvgjd+XQWv2L6DTApuhi1iP+tO3un277KcJJ5NJEWYkeSmnf6CtoO pXxO2PiQ==; Received: from 67.153.238.178.in-addr.arpa ([178.238.153.67]:40754 helo=[192.168.1.13]) by ssdrsserver2.hostinginterface.eu with esmtpsa (TLS1.2) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.94.2) (envelope-from ) id 1mUrxT-002oS1-7u; Mon, 27 Sep 2021 15:50:17 +0100 To: Dave Taht , "Mohit P. Tahiliani" , Asad Sajjad Ahmed Cc: ECN-Sane References: From: Bob Briscoe Message-ID: Date: Mon, 27 Sep 2021 15:50:14 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.13.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-GB X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - ssdrsserver2.hostinginterface.eu 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: ssdrsserver2.hostinginterface.eu: authenticated_id: in@bobbriscoe.net X-Authenticated-Sender: ssdrsserver2.hostinginterface.eu: in@bobbriscoe.net X-Source: X-Source-Args: X-Source-Dir: Subject: Re: [Ecn-sane] paper idea: praising smaller packets 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: Mon, 27 Sep 2021 14:50:18 -0000 Dave, On 26/09/2021 21:08, Dave Taht wrote: > ... an exploration of smaller mss sizes in response to persistent congestion > > This is in response to two declarative statements in here that I've > long disagreed with, > involving NOT shrinking the mss, and not trying to do pacing... I would still avoid shrinking the MSS, 'cos you don't know if the congestion constraint is the CPU, in which case you'll make congestion worse. But we'll have to differ on that if you disagree. I don't think that paper said don't do pacing. In fact, it says "...pace the segments at less than one per round trip..." Whatever, that paper was the problem statement, with just some ideas on how we were going to solve it. after that, Asad (added to the distro) did his whole Masters thesis on this - I suggest you look at his thesis and code (pointers below). Also soon after he'd finished, changes to BBRv2 were introduced to reduce queuing delay with large numbers of flows. You might want to take a look at that too: https://datatracker.ietf.org/meeting/106/materials/slides-106-iccrg-update-on-bbrv2#page=10 > > https://www.bobbriscoe.net/projects/latency/sub-mss-w.pdf > > OTherwise, for a change, I largely agree with bob. > > "No amount of AQM twiddling can fix this. The solution has to fix TCP." > > "nearly all TCP implementations cannot operate at less than two packets per RTT" Back to Asad's Master's thesis, we found that just pacing out the packets wasn't enough. There's a very brief summary of the 4 things we found we had to do in 4 bullets in this section of our write-up for netdev: https://bobbriscoe.net/projects/latency/tcp-prague-netdev0x13.pdf#subsubsection.3.1.6 And I've highlighted a couple of unexpected things that cropped up below. Asad's full thesis:               Ahmed, A., "Extending TCP for Low Round Trip Delay",               Masters Thesis, Uni Oslo , August 2019,               . Asad's thesis presentation:     https://bobbriscoe.net/presents/1909submss/present_asadsa.pdf Code:     https://bitbucket.org/asadsa/kernel420/src/submss/ Despite significant changes to basic TCP design principles, the diffs were not that great. A number of tricky problems came up. * For instance, simple pacing when <1 ACK per RTT wasn't that simple. Whenever there were bursts from cross-traffic, the consequent burst in your own flow kept repeating in subsequent rounds. We realized this was because you never have a real ACK clock (you always set the next send time based on previous send times). So we set up the the next send time but then re-adjusted it if/when the next ACK did actually arrive. * The additive increase of one segment was the other main problem. When you have such a small window, multiplicative decrease scales fine, but an additive increase of 1 segment is a huge jump in comparison, when cwnd is a fraction of a segment. "Logarithmically scaled additive increase" was our solution to that (basically, every time you set ssthresh, alter the additive increase constant using a formula that scales logarithmically with ssthresh, so it's still roughly 1 for the current Internet scale). What became of Asad's work? Altho the code finally worked pretty well {1}, we decided not to pursue it further 'cos a minimum cwnd actually gives a trickle of throughput protection against unresponsive flows (with the downside that it increases queuing delay). That's not to say this isn't worth working on further, but there was more to do to make it bullet proof, and we were in two minds how important it was, so it worked its way down our priority list. {Note 1: From memory, there was an outstanding problem with one flow remaining dominant if you had step-ECN marking, which we worked out was due to the logarithmically scaled additive increase, but we didn't work on it further to fix it.} Bob -- ________________________________________________________________ Bob Briscoe http://bobbriscoe.net/