From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mout.gmx.net (mout.gmx.net [212.227.17.22]) (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 A1E513B29E; Sat, 30 Nov 2019 10:42:33 -0500 (EST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gmx.net; s=badeba3b8450; t=1575128551; bh=pjFKmbxtSYtGxxqRuEETei/xEwEyn1G0zgcuKflsuC4=; h=X-UI-Sender-Class:Subject:From:In-Reply-To:Date:Cc:References:To; b=BSc8kV/jZfhggGaSJIjSicm5kPTwIdq82hqXnOFM7QhJhBwasXLQ+NiYowVD4dz0P PoL4MmBELrPLCXSDPqhJyCLF7gdumFC98npUcmP7snSvk8EeXkigR1CdndYOBMk9Hg 8KdZFL1fMO9ouOgCxATuTJs1Pb77Jxdodbh/0NDs= X-UI-Sender-Class: 01bb95c1-4bf8-414a-932a-4f6e2808ef9c Received: from hms-beagle2.lan ([77.1.8.229]) by mail.gmx.com (mrgmx105 [212.227.17.168]) with ESMTPSA (Nemesis) id 1Ml6qC-1hwGPz2tem-00lSD2; Sat, 30 Nov 2019 16:42:31 +0100 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) From: Sebastian Moeller In-Reply-To: <385CF47C-17AD-4A62-9924-068E1485FFD5@gmail.com> Date: Sat, 30 Nov 2019 16:42:30 +0100 Cc: "alex.burr@ealdwulf.org.uk" , ECN-Sane , bloat Content-Transfer-Encoding: quoted-printable Message-Id: <63DE3099-443D-4ADB-84ED-B1A25AB6D80C@gmx.de> References: <63E9C0E4-C913-4B2F-8AFC-64E12489BC65@gmail.com> <297503679.4519449.1575069001960@mail.yahoo.com> <54C976BC-DEC7-4710-9CFF-0243559D9002@gmail.com> <156EA284-C01D-4FAA-89F4-DB448795F7FC@gmx.de> <385CF47C-17AD-4A62-9924-068E1485FFD5@gmail.com> To: Jonathan Morton X-Mailer: Apple Mail (2.3445.104.11) X-Provags-ID: V03:K1:fqCAW7HbWV0O8TJSuYA3SJD+LoXIkBl6cCZj8AtnyiQykSL1ODx VrPoASolKqFkX3eK61eHcPTT87jtVEIrGdkc1bf53k2lDRp98anSZ2xHnIUYJVHbg7Rka13 8ZUNmwcg4n9BzCiv6qAZGsNQwjv6yI7fckMeL0YkOB2qKrqZ+hca3fYz43OkFemYBryq7NW YUpYvglwURcBS8lP0yn1A== X-Spam-Flag: NO X-UI-Out-Filterresults: notjunk:1;V03:K0:UYZcVshUQ1w=:6PGpzAsOrA40y+ZkybypOl 5oZobkmsnzLwwc5fsHewszMaP29hJhlAdBpLz28CzGokD736kLPvYtmyrqr378fjnxSAnhsoq 5NBl7LbIShw/zBNMh2lAVCoWqrkzMKmPO/WlfCyn0kky7ZftMyQ6syLncGjth08gvreaQcnV2 a4cTHIH1v/92aGdz43TtcgEjVicQ8+rHT8ahrOlYcIu8kITC76CoN4n7e47O9f528CuvDOXnX NwVr/AkZ3mf3zfI2vKEXgG2ugg1IkBmDUEyG4Zw8FlXSRRPOXqXMSC/oKacwS8UiqfGHlmDfp +5S+48QNKuzyonBRfkZ70SxpawVthk0tLRqHkFqnJNYVOcPbHpetY7wJrhiKBqhnrBvJ+sLIo 7AiOV51HUf+TkHG/4gNnYvJZ9D9Ob4I+QU19JBW1obdds4HBSicgUGHZbmdcnTeIklgxo4AVv shu/rqm9falV1tlOJy/s/9N6QHicx+/84hN6IKmM4S8vqCD7TJNA0NS/vRmR/k+2eAQQ0PLyC 6ClmrGEcAQ4cMi8/3ZL7Fotf72F9jxVpWO2/RgCJ017FPRqabowIuKypG4KlXSvkKbY3LEthY UHLEGxzIAtXhDJNR4DaHZqzQ+PiEB7yqnpGspvKZRnGHXihb5GwZgYQ+1NBgpVB5nKzTiXP4B xrv5nnz1d9qKFHTrttCQ5cKOKeeK4rSRNjeQTQ8+XKevX/cfYROnqw/OHrmr9IBqbE0LEcoVT TYfIIOc6ksGi6b9675nupvK0lCIRLx70YvrqWl9g3p0rLC56Cq6c44PKVuZMdyTx8UdEsLmxg CBVBCZ5hCotjzk+MHr6Et4Ti+eYO5DUX4o/x4HkPKjt60k7CaBS7vs+9cV91GUwK2TsQePbrr VTSp0ZWztaCf0stNTtDQGa64Ze6nhxThzTmJG/ArmipUHR5FKr37pBOiWYaY5IaSFRJSA0leB 3pFaAljNhoJd1iSRJh1A+ZhUsW3HZ7DblJLzwyDbWK6Uq7CxmO6x1eT0snnXEy0TeFuk3Gf6H iDQg+k7MtQqK0j+5zDTeExJiryMXuPI/ph1bdQ3/RneL1qVlgQg6i0fTxOqC3vRw6GUFu0QbK 6dXpOQjRai66OeG2/3WOxNQJ54uC2ns7R3nDt4qhgjC1v1CfaKKQB5SsqltVL+ijpoLw9vAg1 VuC2U1nBrVBv1AJfOQnnVkz+2kAt+L54GxpqwpoMFo6i14EoOLQTZ0D88sI2CddpVt7hy0Plk A//UXycW8vmCmdNsTsrHPLvbEcxkeoUhX26CodVamglfHO502aIxbKgzCUZs= Subject: Re: [Ecn-sane] [Bloat] sce materials from ietf 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: Sat, 30 Nov 2019 15:42:34 -0000 Hi Jonathan, thanks, more below. > On Nov 30, 2019, at 15:32, Jonathan Morton = wrote: >=20 >>> 2: Accurate ECN Feedback. >>>=20 >>> We use a spare bit in the header of TCP acks to feed back SCE marks, = and the existing ECE/CWR mechanism from RFC-3168 unchanged for CE marks. = The SCE feedback is "accurate" but not "reliable", because it can = tolerate large errors (as much as 100% relative) without departing the = control loop. The scheme is very simple and straightforward to implement = at the receiver, and interpret at the sender. >>>=20 >>> L4S uses AccECN to give CE mark feedback that is both "accurate" and = "reliable". It is a somewhat complex specification which takes over = three TCP header bits, including the two used for RFC-3168 feedback. >>=20 >> Question: How feasible would it be for any SCE aware transport = protocol to evaluate AccECN? This might make sense if not viewed from a = technical but from a ietf politics perspective? >> I personally believe, that if the ECN feedback woukd e really = important it should be packeged into TCP data as the payload has some = delivery guarantees, while ACKs are effectively best effort (tangent: = and this is why I consider ACK filtering/compression as abominations = which should be counted against any guarantee the contract with the = traffic-carrier entails, not that this helps end customers). >=20 > It would be *possible* to use AccECN for SCE feedback, but only = because the distinction between ECT(0) and ECT(1) is fed back in a TCP = option. SCE also has no use for the "accurate" CE feedback for which = the ECE/CWR bits are replaced; if that three-bit field lay somewhere = else, it could conceivably have been used for SCE feedback instead. I guess a "proper" solution would be to get a decently sized = counter and just accumulate the SCE marks the receiver side saw, similar = to the acknowledgment counter, to gain reasonable robustness against = lost/filtered ACK packets. I naively would just try to get access to the = 16 bit URG field ;) (ducks and runs....) >=20 > There are unfortunate problems with introducing new TCP options, in = that some overzealous firewalls block traffic which uses them. This = would be a deployment hazard for SCE, which merely using a spare header = flag avoids. So instead we are still planning to use the spare bit - = which happens to be one that AccECN also uses, but AccECN negotiates in = such a way that SCE can safely use it even with an AccECN capable = partner. Fair enough, I was mainly concerned about politics here. >=20 >>> 4: TCP-friendly response to RFC-3168 CE marking. >>>=20 >>> SCE does this by design, retaining the existing feedback mechanism = for CE marks and implementing an RFC-8511 (ABE) compliant response in = each of the TCP algorithms presented so far. We can do this easily = because CE and SCE information from the network is unambiguous. >>>=20 >>> L4S presently does not do this, largely because CE marks from = RFC-3168 AQMs are not easily distinguished vice CE marks from an L4S = AQM. They seem to be working on some sort of solution, but it has not = yet been demonstrated to work, and their paper describing it leaves a = lot of open questions (including tuning constants). That we saw no = demonstration of it at IETF-106 (indeed they even skipped over their = planned talk on it in a side session dedicated to L4S) suggests to me = that they found flaws that were difficult to overcome at short notice, = and possibly even managed to look bad next to our demonstration of = jitter tolerance at the Hackathon. >>=20 >> I fear that they will come up with something that in reality = will a) by opt-out, that is they will assume L4S-style feedback until = reluctantly convinced that the bottleneck marker is rfc3160-compliant = and hence will b) trigger too late c) trigger to rarely to be actually = helpful in reality, but might show a good enough effort to push L4S past = issue #16. >=20 > I'm sure they will, and we will of course point out these shortcomings = as they occur, so as to count them against issue #16. =20 That might be bad position to be in though (if one party only = gives negative feed-back no matter how justified it will generate a = residual feeling of lack of good faith cooperation), I would have = preferred if the requirements would have bee discussed before. > Conversely, if they do manage to make it fail-safe, it is highly = likely that their scheme will give false positives on real Internet = paths and fail to switch into L4S mode, impairing their performance in = other ways. Yes, so far they always err on the advantage of L4S, and justify = this with "but, latency" and if one buys the latency justification = cautiously default to rfc3168 becomes obviously sub-optimal, and so far = none of the chairs put down the "first, do no harm" hammer (and I doubt = they will).=20 >=20 >>> 5: Reduced RTT dependence >>>=20 >>> This is a mathematically interesting requirement which, at present, = neither L4S nor SCE meets. >>>=20 >>> Fundamentally, any two flows following the same congestion-signal = response which makes average cwnd dependent solely on marking = probability, and which share the same bottleneck queue and AQM and = therefore experience the same marking probability, will converge to the = same average cwnd and their relative throughputs will therefore be = inversely proportional to their RTTs. This adequately describes both = the pure AIMD response of Reno, and the so-called 1/p response of DCTCP = (which TCP Prague apes slavishly). >>>=20 >>> The steady-state cwnd formula for CUBIC, however, is a function of = both p(CE) and RTT, such that its throughput should be proportional to = the reciprocal quartic root of RTT, rather than linearly reciprocal. = This assumes that CUBIC is not in its Reno compatibility regime, of = course. So CUBIC is the standard to beat, or at least match, for this = requirement. >>=20 >> "Funny" story, looking at figure 6 of H=C3=B8iland-J=C3=B8rgensen = T, Hurtig P, Brunstrom A (2015) The Good, the Bad and the WiFi: Modern = AQMs in a residential setting. Computer Networks 89:90=E2=80=93106. = shows clearly that a) single queue Pie (the AQM L4S inflicts upon at = least the standard compliant traffic) causes worse RTT dependence than = pfifo_fast and that fq_codel actually does (mostly) better, so by = avoiding FQ like the devil, the L4S team shoots their own foot.=20 >=20 > Right, and we can easily explain why this happens. A dumb FIFO adds a = more-or-less constant delay to both competing flows, effectively = reducing their RTT ratio towards unity. Even at the short effective = queue lengths proposed by L4S, the example they give in the Prague = Requirements is of a 100ms versus 1ms baseline path, lengthened to 101ms = versus 2ms by a 1ms queue. This reduces a 100:1 ratio to 50.5:1. Well, that is my point, the default is no AQM and just a fifo, = so "Reduced RTT dependence" is an euphemism as the chosen solution = actually makes the RTT dependence in reality worse in the first place ;) >=20 > The FQ example is, however, of the network enforcing fairness, rather = than informing the endpoints of the corrections they need to make to = resolve unfairness. Yes, and the figure shows, even with fq fairness is still = sub-optimal, but short of measuring and keeping an individual = interval/target pair for each flow not that much that can be done (a = shorter control loop simply will be better equipped to sweep up = bandwidth freed when longer RTT flows scaled bandwidth down, no?) > We really like FQ, of course, but it's not feasible to deploy it = everywhere, But realistically, all we are talking about, not withstanding = L4S' grand design and ambitions, about is the shapers at the = ISP/end-customer boundary, and there we have no proof that fq is not = feasible? > so we have to ensure reasonable competition between flows sharing a = single queue. We've already started testing one such idea=E2=80=A6 That, if it works, certainly will make the "fq is too costly" = crowd easier to convince. So the best of luck! Best Regards Sebastian >=20 > - Jonathan Morton