From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-lf1-x132.google.com (mail-lf1-x132.google.com [IPv6:2a00:1450:4864:20::132]) (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 282E93B29E; Sat, 30 Nov 2019 09:32:56 -0500 (EST) Received: by mail-lf1-x132.google.com with SMTP id a17so24594587lfi.13; Sat, 30 Nov 2019 06:32:56 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=ta/kzhiUYjgtWWcs4r488L73CeXu9oSdq+gPdtPb1Jw=; b=Jyw9wVbt2vUv77FD/pwsIqBYF+xFKYZmfGV8ttFLC6GUo0ahnb53rTpHdzuvuevfjs 9w/2AWO+aLv03OMzkQ6AKMhxVaSaR/C2Ii8TojTh5wndJ1wafodEjn0nEwHUhFpihkv8 dorf7dZpzgOAf0Zxvk/ceEMvhOfarupHHUTqRsBzmpL5yHky4FUHx8gT3mECrWmln04u pls/pxKv8T4faXvfG/kokfEHqprOyWqFC5EdFd6KURwPry7ptS+yBZuCLB5G6N4u4vQS qlGkRokRplohf+d8upiBZqauHG9Ohj8qrKR8nzatJmDEWjpGpZz1rfcUGe033m3VKlVN KI+A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=ta/kzhiUYjgtWWcs4r488L73CeXu9oSdq+gPdtPb1Jw=; b=mxqjlH0aJ4B9q5aviTSOung0Ry6v9WY1U9tId7V2FC9eHAJm0/0i2Ls79CfKCU9zhG KtmxECKIjC7k9HUYBxbJR0ol1eOHjv1hxh8PyUvFb3uzGzlUAt87dgyVEQDC95RePqpj MIXYjsbg1I5fwP4rO0v1ahYvF3h3rntWgikyZBRQAXPsHHeelok3K0HAh22ZQuXmf3CH qbLcyeLaePTLDOfDkqb0k/9UJAK+Zf/zAoqRRo0hMPnqhrW9rfc64TwXacP35FhRDtoI 9ai4VHUVgNdVQ5gZGWR3bBlEQlaOINfsd/aZmXIIo5JSMyjsJ+7/ldsnTueSjhGVtmAH MCrA== X-Gm-Message-State: APjAAAVtwNOvtz+ODq/NdBh4tnj184ALbjC324eUshmV3RlK6k1VJDiF AGdZysxwG6AAs0oStCF0eGk= X-Google-Smtp-Source: APXvYqydVHAwStArJGmTP0tnYGm0jKdhr8csg0d8N+mzf2YrSI9SpzPknxNvGW3IduKTY6r1NKEh+Q== X-Received: by 2002:a19:4208:: with SMTP id p8mr3882064lfa.160.1575124374910; Sat, 30 Nov 2019 06:32:54 -0800 (PST) Received: from jonathartonsmbp.lan (83-245-229-102-nat-p.elisa-mobile.fi. [83.245.229.102]) by smtp.gmail.com with ESMTPSA id a24sm2533864ljp.97.2019.11.30.06.32.53 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sat, 30 Nov 2019 06:32:54 -0800 (PST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) From: Jonathan Morton In-Reply-To: <156EA284-C01D-4FAA-89F4-DB448795F7FC@gmx.de> Date: Sat, 30 Nov 2019 16:32:52 +0200 Cc: "alex.burr@ealdwulf.org.uk" , ECN-Sane , bloat Content-Transfer-Encoding: quoted-printable Message-Id: <385CF47C-17AD-4A62-9924-068E1485FFD5@gmail.com> 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> To: Sebastian Moeller X-Mailer: Apple Mail (2.3445.9.1) 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 14:32:56 -0000 >> 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). 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. 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. >> 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. 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. 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. >> 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 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. 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. We really like FQ, of course, but it's not feasible = to deploy it everywhere, so we have to ensure reasonable competition = between flows sharing a single queue. We've already started testing one = such idea=E2=80=A6 - Jonathan Morton=