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 ADC443B2A4; Sat, 30 Nov 2019 02:27:34 -0500 (EST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gmx.net; s=badeba3b8450; t=1575098852; bh=NafYPVz1Z/Ug+zO+es/wkzp6XltWUiD1Uh3qQP80NVE=; h=X-UI-Sender-Class:Subject:From:In-Reply-To:Date:Cc:References:To; b=UWSrTgVnfon+MZxOdG8XhvkFG3c/CmO5wQ8SphQjqd6YhHF2A9LvAq9YPkTOvAhRJ MyFMkh97ukH7fVHz2w+dPSB58cENxjWMwSHeebhaKsbW9y3DuK8B+TdOy1RTwl9gVB cn3Cn+TBomy7Ozpri3WzNYR60U2SXb1iXlH2tPkQ= X-UI-Sender-Class: 01bb95c1-4bf8-414a-932a-4f6e2808ef9c Received: from hms-beagle2.lan ([95.112.252.202]) by mail.gmx.com (mrgmx005 [212.227.17.190]) with ESMTPSA (Nemesis) id 1MAwXr-1iUeZ32JSb-00BNaq; Sat, 30 Nov 2019 08:27:32 +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: <54C976BC-DEC7-4710-9CFF-0243559D9002@gmail.com> Date: Sat, 30 Nov 2019 08:27:31 +0100 Cc: "alex.burr@ealdwulf.org.uk" , ECN-Sane , bloat Content-Transfer-Encoding: quoted-printable Message-Id: <156EA284-C01D-4FAA-89F4-DB448795F7FC@gmx.de> References: <63E9C0E4-C913-4B2F-8AFC-64E12489BC65@gmail.com> <297503679.4519449.1575069001960@mail.yahoo.com> <54C976BC-DEC7-4710-9CFF-0243559D9002@gmail.com> To: Jonathan Morton X-Mailer: Apple Mail (2.3445.104.11) X-Provags-ID: V03:K1:pnexOQaRfG7yJZhNG6NTGX3fkrxSaeOCd9lT921j0dV8qPydXZB oglQnca8pkOkABiueSH/kGAg/fhITTa24qfqIYB1KSsps/S7sOhPBAKHt8cVDUxK/kG+8WC ZPzm+I5GY0FvdEpQDc0Q8ysK4C7ZrJ3FSidbpM7XClwfMpDeaKn0o6HGqVc9UP0uZZzHQds /e5/Km6veFiTIoMqd8FsA== X-Spam-Flag: NO X-UI-Out-Filterresults: notjunk:1;V03:K0:0EGx9yV5cBs=:Pfte9y4kJc7BMIqkzwYqOe SOXg3brJQ8aFgwuMvHHz3t+xQ6ToUt9OJcU/QqB5LjG0bMxHiElEn6ASTXzCS4xSl0jFbvuqw BAP2k6zdIaPkALFYDQH6+0qYUZKqBgh7Lk4QjdzZ/upvu/4X4zFt2P5kOEmGnBLuQ/RGGs/V9 Jd4KyZRziWla6gH1xg7LGtEi9DDo8KcARuM7AuhW+zObE0BrsDC8LROS0VlDH3kvCN0nmK8FZ 0EG8iaeCZ8iX5wPqSc14G5QRZRI2qE5jn9goqdyy4GFEbHUW0DXbYMOs15tCjGw1t8xk6+RaJ /95MTN+Eb8gBvO20Cl4lVQiA5rI4vGFM4vFhFTWLnKjWswejtwIjSHz8HN6XAXiPPLF4w3xar KYylLk2ztJTnUN6bWblMhc71VQpCLd/G8iN6X0kvDePgNvstaz40QvpgFnClqBX8UEMyZxDeT chQ88WiDgjwzqsWt/UYIl9r7p5y6vK2Q4XbzDm6FtNTLlGfDu1cCgRXYLQ8eSI0ch3GobVc38 ivZpPWe/I6W5mbikcZzI/+7H8PEI0W2i7PG5nj7RrnERsXIJrZsNVC2pPIoxMRdqwovDS6/0i mE3jTHmqU0fu63saQ/feGrGoWaHneXykYuHAS1/Vyh0tZJyPtr1/swCVhWqmFkcmm8cXgDlBK nLVNqYssvW1uLhmz85QxJKxFnt3dshs6YrLIWYl5vIoBPowfbhxQdLpFMWDt3BzES2SsT3ihe TWTlQMdpTha9S297g5VfXDTjsAknWMQ4QquMhRp9Hp6XR53oY+RWlriDR6+W79gUEzgiMwe1j X1YQbdvzO0wPJdocPivsHetIb0RbUAyVuUBWmki1FGs/6DpgxBpUfSDzINduacPY+92C8R3Zw Seu0VDzdA4hbva1zWQTpNW5tQKegy22Hkafpwtb47+q+xbtBq0nmDrYdxAQMypKPpsYPWpMed mKaNBw6zqFcTLllf55nOj946QR93QltsQISko9nLV3uGBEmuwrxObFqlNkyy1y0hP1oa2PhYr 7ieBd7vREES7MNjfqhCZ2rmAq2Vfi7yLHMov1AP80ZqYClWbR4jOsvuILsTVSQEo+eizrgKko wNOQ35TUF+QcobIWzm5rDqZ2PosAwBHihdOhecK2O9z31GLj2skrdbEld85WjgHz3aSW5zr9Z l0H/y7o6i15yyglU+K4hPdRyM80nKDOnp+jAxpJ+4YMkVeed0FQFsN5PNk/k1N/uVdqij3p46 XSh6mPuJHlQaywZpvPCyBgbfKvti01P3sjrREBtON55WOFT7i4P0E+tJMUIo= 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 07:27:35 -0000 Hi Jonathan, > On Nov 30, 2019, at 02:39, Jonathan Morton = wrote: >=20 >> I don't see what you gain by going after the Prague requirements. = They're internal requirements for a TCP that would fulfill the L4S goals = if classified into the L4S side of a DualQ AQM: 'Packet Identification' = means that the L4S AQM can identify L4S supporting flows. This seems = like a distraction from your main pitch to me. It would seem better to = compare against the actual goals of L4S (AFAICT, low latency at the 99th = percentile, in the presence of Reno-compatible flows, with some fairness = requirement which I increasingly don't understand). >=20 > We're certainly not treating the Prague Requirements as our only = goals. We just looked over them and realised we do sufficiently well on = them already to compare favourably against L4S. They are failing on = their own merits. Like it or not, we are somewhat in competition with = them in IETF space, so this sort of comparison should help to bolster = our standing. >=20 > A brief summary of the Prague Requirements: >=20 >=20 > 1: Packet Identifier. >=20 > We ID ourselves as RFC-3168 compliant using ECT(0), because we are. >=20 > L4S has to identify itself more specifically to the network, because = it is *not* RFC-3168 compliant. It additionally relies on AQMs in the = network understanding this distinction, which at present none do. We = would much prefer that they use a DSCP for this purpose, but at present = they use ECT(1). >=20 >=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. 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 >=20 > 3: TCP-friendly response to packet loss. >=20 > Both SCE and L4S do this without difficulty. >=20 >=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. 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 wib) 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 > This point has always been the main difference between L4S and SCE. > ll=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. "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 Best Regards Sebastian >=20 > As I mentioned, I have an idea for how to do this. I've seen no = evidence that the L4S team have any equivalent ideas; again, they're = failing their own requirements. >=20 >=20 > 6: Scale down to fractional effective cwnd. >=20 > We technically achieve this with our preferred choice of pacing = parameters, reducing send rate to 80% of a segment per RTT at the = min-cwnd of 2 segments. We could easily do better with different pacing = ratios. >=20 > L4S have apparently implemented a packet size adjustment. We haven't = tried it out yet, but we'll take their word for it for the moment. = There's no inherent technical reason why we couldn't do the same. >=20 >=20 > 7: Reordering tolerance on time basis (ie. RACK). >=20 > Both SCE and L4S inherit this capability from the Linux TCP stack, so = it's not a problem. FreeBSD also has a RACK compliant TCP stack which = is being stabilised. >=20 >=20 > Other criteria which we are actively considering are listed in, for = example, RFC-5033. That makes a fun read if you're a masochist; I = wonder about Pete sometimes. :-) >=20 > - Jonathan Morton >=20 > _______________________________________________ > Ecn-sane mailing list > Ecn-sane@lists.bufferbloat.net > https://lists.bufferbloat.net/listinfo/ecn-sane