From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-lf1-x130.google.com (mail-lf1-x130.google.com [IPv6:2a00:1450:4864:20::130]) (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 5E0DB3B29E; Mon, 11 Mar 2019 04:59:39 -0400 (EDT) Received: by mail-lf1-x130.google.com with SMTP id u68so2785395lff.7; Mon, 11 Mar 2019 01:59:39 -0700 (PDT) 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=GbRWLVFOUOABLtGK1WfXkKbE7w+k+7SdwtQFnF5j1e0=; b=b6tpzk8AnxD5gAux+G+ItTIrhAJBcC+B1Vw0A69miG9/cl1AGV4GBqQHQ1JtuAU91z XK8lv8H1tCv9ibM09dhuAbZP/z5R7lTIwH6qNTDnU6MpObDW1LB2VJaOvR/n0lVjhw2A I+UhUI/EP7XCE/gDAXwzqbvl0bhlXw/hg4f4GdkdQkPqtXM/UKMEWxNou5Nz3nCd0ddn s0xpG4iT41jO/31NDYfNQURBZ9aN5JqA9ODQ9WkStzLatRyxA10FskcJFXnYbygLW2OK aN/ouXfxpGpsYICOo6LhNorGtpy2ymY8HyVOM6OwI9GEZ2eLCyHYf4rg/bNUFd8mSC6/ /utA== 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=GbRWLVFOUOABLtGK1WfXkKbE7w+k+7SdwtQFnF5j1e0=; b=D6ihqbuhx/U8asEX/elWb56y6pdamtSxUWla1wOmSgG7Ga1xyL4kzLm1HtyGyd3d2H tikL1n/qQF4a77r6XD87GrWLFfMnqWS61BVlYDHdTnAfa3DvyGQw79GQWF2FD2XI7y/b hT28hcvsnZjxs9kwLXZdrGWOBdXTfJFXZVjl9QrvMhPB4+kqz20X3rW4r6CwzfbYrwiH opOtvaEgZJzBR2XtX7+GB++2gqXx/j2TeDsUEH6bzMD8HAjVTM1Dfv0m2PBSchkaat/U VTNqJ0ZP8DoZ4hZOUXrtrxgUAgBAe9yF2EcSm5IFrE7HNN0UoMxfG3RW7vzJ0sbaD6Fb KBnQ== X-Gm-Message-State: APjAAAWfDBtyQtAPgXnhRoxI/+p3a6RDo7EMTzd3jMv0jgaXHHFK8Urd 8ZhkThVE7cUwaQRX+d58oGg= X-Google-Smtp-Source: APXvYqwf+4Kv7dBiaWiY6TC8zK6ONVVyyVios6ORO8QwptTqNxh9FxjifT05pkR6vvMd1ZaX+kNUig== X-Received: by 2002:ac2:5325:: with SMTP id f5mr4788663lfh.77.1552294777953; Mon, 11 Mar 2019 01:59:37 -0700 (PDT) Received: from jonathartonsmbp.lan (83-245-235-245-nat-p.elisa-mobile.fi. [83.245.235.245]) by smtp.gmail.com with ESMTPSA id b16sm854511ljb.64.2019.03.11.01.59.36 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 11 Mar 2019 01:59:37 -0700 (PDT) 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: Date: Mon, 11 Mar 2019 10:59:35 +0200 Cc: Mikael Abrahamsson , "ecn-sane@lists.bufferbloat.net" , bloat , "codel@lists.bufferbloat.net" , Cake List Content-Transfer-Encoding: quoted-printable Message-Id: References: <550C0248-1704-49DA-ABDC-49A91E0AC6F3@akamai.com> <1EE25778-8571-4506-A334-38C544470ACE@gmail.com> To: Richard Scheffenegger X-Mailer: Apple Mail (2.3445.9.1) Subject: Re: [Codel] [Bloat] The "Some Congestion Experienced" ECN codepoint - a new internet draft - X-BeenThere: codel@lists.bufferbloat.net X-Mailman-Version: 2.1.20 Precedence: list List-Id: CoDel AQM discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Mar 2019 08:59:39 -0000 > On 11 Mar, 2019, at 9:08 am, Mikael Abrahamsson = wrote: >=20 > =E2=80=A6also meant the packet was allowed to be re-ordered. I thought = this was a big and nice thing=E2=80=A6 Seriously? I had to dig in the specs to find any mention of that, = and=E2=80=A6 it's all about better supporting bonded links. Which can = already be done by implementing RACK at the sender, and all you propose = is that when L4S is in use, the extra buffering at the link layer is = dropped. This is absolutely useless for ordinary Internet users, who = are unlikely to have consecutive packets sufficiently closely traversing = such a link for this reordering to exceed the 3-dupack threshold in any = case - so you might as well delete that reordering buffer anyway, and = let the endpoints handle it. You don't need L4S for that. At bottom L4S is also a very simple scheme: when ECT(1) is used, a = higher CE marking rate is expected of middleboxes, and a less aggressive = backoff in response to CE is expected of endpoints. This is, = incidentally, incompatible with Codel-like AQMs on the one hand and = existing TCPs on the other hand, and so requires negotiation between the = endpoints (eg. using AccECN) to discover whether setting ECT(1) at the = sender is legal. SCE does not require such negotiation (ie. a transport = could implement it entirely at the receiver, manipulating the send rate = via the already-standardised receive window), so should be easier to = specify and deploy successfully. > On 11 Mar, 2019, at 9:35 am, Richard Scheffenegger = wrote: >=20 > I can remember reading quite a few papers where a similar scheme for = ect(1) was adopted - often with additional changes on both ends to make = use of this signal. Including schemes that encoded complex information = in the stream of ect0/ect1... >=20 > Where can one find simulations of the interaction between legacy and = l4s flows when using this? If by "between legacy and l4s" you mean "between existing SCE-ignorant = and new SCE-aware" - because SCE is not L4S=E2=80=A6 We haven't yet drilled down to that level of detail, but we plan to do = so in the very near future. SCE itself is just a means of communicating = network state from AQMs to receivers, hence the brevity and simplicity = of the I-D. The encoding is not complex, just a ratio of ECT to SCE markings which = is ignored by existing receivers and not produced by existing = middleboxes, *and* continued use of CE as presently standardised. This = naturally ensures backwards compatibility and incremental deployability. = The stable ratio of ECT to SCE is defined as 1:1, allowing more = flexibility in signalling how much unused link capacity remains than = DCTCP's "2 CEs per RTT" stability condition permits, and potentially = simplifying implementations. The question of whether SCE-aware transports will compete fairly with = SCE-ignorant transports, given a single-queue AQM implementing SCE, is = an interesting and important one. Intuitively, one can see that the = SCE-ignorant transport will drive the AQM into the CE-marking regime, = which may cause both flows to drop back, but there will be periods when = the SCE-aware flow has inhibited growth while the SCE-ignorant flow has = not, and so the SCE-aware flow might have overall lower throughput. On the other hand, a Codel-like AQM (as opposed to a RED-like AQM) has a = higher probability of signalling CE to a flow that sends more packets, = which may naturally compensate for this. And on the gripping hand, an = SCE-aware flow operating alone should have (slightly) higher goodput = than an SCE-ignorant flow operating alone, which illustrates the case = for flow-isolating AQMs. Two SCE-aware transports might interact strangely on a single-queue AQM, = depending on how their response to SCE is implemented. Eliminating the = present sawtooth behaviour entirely is a desirable goal, but AIMD is = what allows flows competing in a single queue to converge on fair = throughput. This will require careful attention when specifying = transport behaviour. One exciting possibility is finally solving the slow-start problem, by = beginning SCE signalling (at a low rate which still permits window = growth) when the link is half-full rather than when queuing begins. = That would cause the exponential growth phase of typical TCPs to exit = one RTT later, when the link is just fully utilised, instead of = massively overshooting and being cut back to nothing as presently = occurs. There is a range of flow lengths which could see a concrete = performance benefit from that. That requires that the AQM is able to determine when the link reaches = 50% utilisation, which is not always true (Cake and hardware AQMs could = do it, being aware of the link capacity) - but SCE does not mandate this = behaviour, it's just a good idea. I'm not aware of any possibility for = L4S to achieve the same result; however much it redefines the meaning of = CE, it won't be asserted until the link is full. SCE-aware AQMs and TCPs are not difficult to describe and should not be = very difficult to implement. Though not described explicitly in the SCE = I-D, I'm working on descriptions of how to do so, which should become = additional I-Ds. We should then be able to write working code and run = simulations in ns-3, and maybe also in Linux. - Jonathan Morton