From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-lf1-x135.google.com (mail-lf1-x135.google.com [IPv6:2a00:1450:4864:20::135]) (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 C44A43B2A4; Fri, 29 Nov 2019 20:39:47 -0500 (EST) Received: by mail-lf1-x135.google.com with SMTP id f16so23844175lfm.3; Fri, 29 Nov 2019 17:39:47 -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=OgtCaooIPzSQkVfHZY4le5dOVUSH6IeN0ep4LbQRY24=; b=d5iwSv8YQOwKe6pg4QR327VeWRvVnvz+sxg0GhuvJmeihLm95ZIVtP0TnHQt+rKFSi W7grRY7/44Hcs0HP3m2fWUhCmvqTkRWRIwEAz5Bb8ltPN/qai6cevpczTjSzCvYUtfYT m6sEGB7qOud9Q1zMcmJ++vQIzxFGGRfmlfyGmHxj/T1/qCwUgefC0kDt4JUjovoVN0zh v4PEjb8RJY8m4O0OuO4SUntD54Sd4+UhUWh+HRV5zzwwTpK7DpTYkKSb2nmGn6HLUJMc CmFV0301GHiYMVwzmQIvl7iQS9mNzOwKoqaqtU3i4+wOagePNUIDKaSFWnrbyF8mLHbK Iw0Q== 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=OgtCaooIPzSQkVfHZY4le5dOVUSH6IeN0ep4LbQRY24=; b=Al/bQcIZcMMftT7uTFhAnqKN2Bvv12XaxQ9uAsC5+kpgwwUyJa4AtDyNwtVUxak49B JQ33y80hmR4yG5hCKXo25vc1UU9WlDItu28nPQNMUfeIV8iRPFEAX5OYeCh1OV6WawIl gmmv6VePjZlxa8ATFeaPVeDRrXTMFI+iO2ZERPgdrsX85I5ltaulBSD1fu/hGHanjq23 PAtuc/sGbooudEKcm0F2guzPBSwuWz8YKYrkg2Hj04j5DwWP0VqXM7jpTmgvJ/hVGCZB 4yYCiDgk453KKNUtx1ewKEo6HrjJC2+Mfx0+IaaHEYXMFYK/spk007AS5OaGWcLS+Xzd L3lQ== X-Gm-Message-State: APjAAAWhSfgZMQm5E8tX/8cBKfefLgBgMIDXav5p6ymIoB+6q69aWg4c byD4AXV4VmPZGWEA2oK1I2E= X-Google-Smtp-Source: APXvYqyUbbDGUQYDivuSJma1qgy8+7UtmAWYqtVOA2qpbF3/I+50Z9+vInWHG4Cu5br2/YYhRjqsBw== X-Received: by 2002:a19:cc08:: with SMTP id c8mr36787675lfg.124.1575077986630; Fri, 29 Nov 2019 17:39:46 -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 144sm11038765lfi.67.2019.11.29.17.39.44 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 29 Nov 2019 17:39:45 -0800 (PST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) From: Jonathan Morton In-Reply-To: <297503679.4519449.1575069001960@mail.yahoo.com> Date: Sat, 30 Nov 2019 03:39:42 +0200 Cc: Dave Taht , ECN-Sane , bloat Content-Transfer-Encoding: quoted-printable Message-Id: <54C976BC-DEC7-4710-9CFF-0243559D9002@gmail.com> References: <63E9C0E4-C913-4B2F-8AFC-64E12489BC65@gmail.com> <297503679.4519449.1575069001960@mail.yahoo.com> To: "alex.burr@ealdwulf.org.uk" X-Mailer: Apple Mail (2.3445.9.1) Subject: Re: [Bloat] sce materials from ietf 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: Sat, 30 Nov 2019 01:39:48 -0000 > 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). 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. A brief summary of the Prague Requirements: 1: Packet Identifier. We ID ourselves as RFC-3168 compliant using ECT(0), because we are. 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). 2: Accurate ECN Feedback. 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. 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. 3: TCP-friendly response to packet loss. Both SCE and L4S do this without difficulty. 4: TCP-friendly response to RFC-3168 CE marking. 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. 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. This point has always been the main difference between L4S and SCE. 5: Reduced RTT dependence This is a mathematically interesting requirement which, at present, = neither L4S nor SCE meets. 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). 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. 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. 6: Scale down to fractional effective cwnd. 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. 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. 7: Reordering tolerance on time basis (ie. RACK). 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. 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. :-) - Jonathan Morton