From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from server.dnsblock1.com (server.dnsblock1.com [85.13.236.178]) (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 1C56F3CB36 for ; Thu, 21 Mar 2019 02:04:37 -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=k+rcIxpLoWEqbiNLyv7tWw5TRQ4IW8kprsbZwFexNKg=; b=R3rFqljM5t8rvT2YueCF6ns2TK /os4giQ/9tAFsTFeOX7VRhyMVPn7LZHYGzAQJbNNOkO/r5PsTchswXWXlW8hxOs/VepbrpsoK6lx5 Ng+MyuRyMrEX7+tEXBU8guI1cIsuBfI7ht/SKESjHLZvM3jZ72joW2gWmU076DwZ/dPEoPgqtkodj vHKvc9H6aS1FFq9BCT1nHzE0A4IjdaULJyl8jVUtvx7/RS1L483dWy8CJi+SxS6ijBun0PFWsxjM1 oMNjgUE52wJlSJGDMonwTxYJY7RZCHp5Lg8fpumpTEMUYx4p8tC858lqsr/wIy4hsFgh5xrZJ0p6f dXXK6bkw==; Received: from 215.212.broadband18.iol.cz ([109.81.212.215]:61717 helo=[10.0.0.47]) by server.dnsblock1.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.91) (envelope-from ) id 1h6qoc-0008Qx-Uq; Thu, 21 Mar 2019 06:04:35 +0000 To: Jonathan Morton Cc: "Holland, Jake" , tsvwg IETF list , bloat References: <1E80578D-A589-4CA0-9015-B03B63042355@gmx.de> <27FA673A-2C4C-4652-943F-33FAA1CF1E83@gmx.de> <1552669283.555112988@apps.rackspace.com> <7029DA80-8B83-4775-8261-A4ADD2CF34C7@akamai.com> <1552846034.909628287@apps.rackspace.com> <5458c216-07b9-5b06-a381-326de49b53e0@bobbriscoe.net> <7e49b551-22e5-5d54-2a1c-69f53983d7e5@bobbriscoe.net> <04E62EA7-82EF-4F1B-A86D-5A23CA3B190A@gmail.com> From: Bob Briscoe Message-ID: Date: Thu, 21 Mar 2019 07:04:34 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.5.1 MIME-Version: 1.0 In-Reply-To: <04E62EA7-82EF-4F1B-A86D-5A23CA3B190A@gmail.com> 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 - server.dnsblock1.com 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: server.dnsblock1.com: authenticated_id: in@bobbriscoe.net X-Authenticated-Sender: server.dnsblock1.com: in@bobbriscoe.net Subject: Re: [Bloat] [Ecn-sane] [iccrg] Fwd: [tcpPrague] Implementation and experimentation of TCP Prague/L4S hackaton at IETF104 X-BeenThere: bloat@lists.bufferbloat.net X-Mailman-Version: 2.1.20 Precedence: list List-Id: General list for discussing Bufferbloat List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Mar 2019 06:04:37 -0000 Jonathan, On 20/03/2019 23:51, Jonathan Morton wrote: >> On 21 Mar, 2019, at 1:29 am, Bob Briscoe wrote: >> >>> But more importantly, the L4S usage couples the minimized latency use >>> case to any possibility of getting a high fidelity explicit congestion >>> signal, so the "maximize throughput" use case can't ever get it. >> Eh? There's definitely a misunderstanding or a difference in terminology between us here. The whole point of using a congestion controller like DCTCP is so that flow rate can scale indefinitely with capacity. Van Jacobson actually noted that the original TCP was unscalable in a footnote to the tech report version of the SIGCOMM paper. >> >> The high fidelity congestion signal of what we call scalable congestion controllers (like DCTCP) is inversely proportional to the window. So as window scales up, the congestion signal scales down, so that their product remains constant. That means the number of ECN marks per RTT is scale-invariant. So the control signal remains just as tight at any scale. > If you'll indulge me for a moment, I'd like to lay out a compromise scenario where a lot of L4S' stated goals are still met. > > There is no dualQ. There is an AQM at the bottleneck link, of unspecified type, which implements SCE. Assume that it produces CE marks like a conventional AQM, and also produces SCE marks like an L4S AQM produces CE. > > A sender implements DCTCP-SCE, which is essentially Paced NewReno modified to subtract half of all acked data that was SCE-marked from its cwnd. (This is equivalent to the DCTCP algorithm with g=1 and an arbitrarily small measurement window, but acting on SCE instead of CE.) Any SCE mark also kicks it out of slow-start. > > The means by which SCE information gets back to the sender is left vague for now; it's an orthogonal problem with several viable solutions. > > What is missing from this scenario, from L4S' point of view? And why have I been able to describe it so succinctly? My goal is also to tighten the EWMA parameter, g, in DCTCP to 1 (or 2). That is why we have recommended a queuing-time-based ramp AQM for the Low Latency queue, which so far works equivalently to the step with g set to its current default of 1/16. We have been doing experiments on this for some time. But it is important to assess each change one at a time. Congestion controls are tricky to get stable in all situations. So it is important to separate ideas and research from engineering of more mature approaches that are ready for more widespread experimentation on the public Internet. Our goal with L4S was to use proven algorithms, and put in place mechanism to allow those algorithms to evolve. As regards the desire to use SCE instead of the L4S approach of using a classifier, please answer all the reasons I gave for why that won't work, which I sent in response to your draft some days ago. The main one is incremental deployment: the source does not identify its packets as distinct from others, so the source needs the network to use some other identifier if it wants the network to put it in a queue with latency that is isolated from packets not using the scheme. The only way I can see to so this would be to use per-flow-queuing. I think that is an unstated assumption of SCE. In contrast, L4S works with either per-flow queuing or dualQ, so it is more appropriate for a wider spread of scenarios. Again, in that same unanswered email, I described a way L4S can use per-flow queuing, and Greg has since given pseudocode. There are other problems with doing the codepoints the SCE way round - pls see that email. There has been a general statement that the SCE way round is purer. However, that concept is in the eye of the beholder. The SCE way round does not allow the ECN field to be used as a classifier, so you don't get the benefit above about support for per-flow-queueing and dual queue. You also don't get the benefit of being able to relax resequencing in the network, because the network has no classifier to look at. For these, the SCE codepoint would need to be combined with a DSCP, and I assume you don't want to do that. The L4S way round signifies an alternative meaning of the ECN field, which is exactly what it is. The problem of having to guess which type of packet a CE used to be has been roundly discussed at the IETF in TCPM and TSVWG WGs and it has been decided it is a non-problem if it is assumed to have been ECT(1) even if it was not - as written up in draft-ietf-ecn-l4s-id. And that discussion assumed TCP with 3DupACK reordering tolerance, not the more liberal use of RACK (or a RACK-like approach in other transports). With a RACK-like approach, it becomes even less of a problem. Bob > - Jonathan Morton > -- ________________________________________________________________ Bob Briscoe http://bobbriscoe.net/