From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-lj1-x22c.google.com (mail-lj1-x22c.google.com [IPv6:2a00:1450:4864:20::22c]) (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 A1FB33B2A4 for ; Thu, 29 Nov 2018 05:30:13 -0500 (EST) Received: by mail-lj1-x22c.google.com with SMTP id k19-v6so1236307lji.11 for ; Thu, 29 Nov 2018 02:30:13 -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=peXmRdRWFjrd7pZfLT64QyqfBrllpXjt9svvEwYh7l0=; b=mN2pPLGfOrtE/h0sz9k/Ryqeg5Ftq1P2ztU+AaA+d+iVeamU1Hnzrd+X2QIGh/mKC8 XhWglFBY+4MTQbsFWH820AD8m4vTr2LRw2zd/aOYyEfNZ1y5sRfGpBPNFJ1KnNkSOzNQ KoQs94qi2wy3toHIKFnzyuTcjhp6zm6X0ax1cdJmXPn1IUqu/63CEKogrFdZN6mWzyn3 lc7EYFiTcqyL0pmbNbL3BnLniLSOXTivf1pu0FGhpAUA86eiHu8fej7tw2+2FR3Z/9gZ aXPzsBbnaV/Kd2pA+PYhUoEDUGjpFFN3WdNbdM/dOo93lfQ8ZEaOIwm4vWqTuO/TqLew sUUg== 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=peXmRdRWFjrd7pZfLT64QyqfBrllpXjt9svvEwYh7l0=; b=Ef6Wnk5UM7O83wY8+P36lgIwBYabx+bWeaoo1G+ouzX8O7JJqjpOs2sQfk3kSgda8K 2l1g1ZQ6xhFa8knGRqMMXLs9PsGx6smo7WOZZs1vkfI0jA1d6LX1lzhePNMw8b+VvlNe R97/wWstB4f2imZ+rY2lQATPnzsYOP+bb/5uUTFXXDK4pZsg8eDdvxohkEcFLv6ppep1 PP7s8LtY/j8MTxGSDG3X639hjsscFHMVvrvALruhVZypQQLsclwL9Hu0NxGKLF1clUN/ qrgQ49fln8S2PXjqvzpmgQF1keBTQFIAedDVQvHfHcsXwZYkUjAuejR1YKw/pjFeG3Bs iLqA== X-Gm-Message-State: AA+aEWZbWArB/iX06dY3ZL/m0XIplG4QHqAcNuOzhAuEdl55BzmRXJdw UWGrHd06oFLhnC3mVl8StdE= X-Google-Smtp-Source: AFSGD/UOSp5+3jIJ3MkYnuw3b38dipXZHmlIGEY/8Vg5cVG2pEwpHdJLyZRXpTrdjKeNpAYapPNC2Q== X-Received: by 2002:a2e:1f01:: with SMTP id f1-v6mr684852ljf.129.1543487412340; Thu, 29 Nov 2018 02:30:12 -0800 (PST) Received: from jonathartonsmbp.lan (83-245-236-220-nat-p.elisa-mobile.fi. [83.245.236.220]) by smtp.gmail.com with ESMTPSA id q30sm234250lfi.94.2018.11.29.02.30.11 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 29 Nov 2018 02:30:11 -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: <7D833179-4D95-4C2F-B0AF-4FFD4D29DEE4@ifi.uio.no> Date: Thu, 29 Nov 2018 12:30:10 +0200 Cc: Mikael Abrahamsson , bloat Content-Transfer-Encoding: quoted-printable Message-Id: <963ACC89-890D-4EA6-9E5E-1E7315F07C5A@gmail.com> References: <65EAC6C1-4688-46B6-A575-A6C7F2C066C5@heistp.net> <38535869-BF61-4FC4-A0FB-96E91CC4F076@ifi.uio.no> <87va4gwe74.fsf@taht.net> <7125B446-F2C4-45B3-B48C-8720B1E35776@gmail.com> <7D833179-4D95-4C2F-B0AF-4FFD4D29DEE4@ifi.uio.no> To: Michael Welzl X-Mailer: Apple Mail (2.3445.9.1) Subject: Re: [Bloat] incremental deployment, transport and L4S (Re: when does the CoDel part of fq_codel help in the real world?) 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: Thu, 29 Nov 2018 10:30:13 -0000 >>> My alternative use of ECT(1) is more in keeping with the other = codepoints represented by those two bits, to allow ECN to provide more = fine-grained information about congestion than it presently does. The = main challenge is communicating the relevant information back to the = sender upon receipt, ideally without increasing overhead in the TCP/IP = headers. >>=20 >> You need to go into the IETF process and voice this opinion then, = because if nobody opposes in the near time then ECT(1) might go to L4S = interpretation of what is going on. They do have ECN feedback mechanisms = in their proposal, have you read it? It's a whole suite of documents, = architecture, AQM proposal, transport proposal, the entire thing. >>=20 >> On the other hand, what you want to do and what L4S tries to do might = be closely related. It doesn't sound too far off. >=20 > Indeed I think that the proposal of finer-grain feedback using 2 bits = instead of one is not adding anything to, but in fact strictly weaker = than L4S, where the granularity is in the order of the number of packets = that you sent per RTT, i.e. much higher. An important facet you may be missing here is that we don't *only* have = 2 bits to work with, but a whole sequence of packets carrying these = 2-bit codepoints. We can convey fine-grained information by setting = codepoints stochastically or in a pattern, rather than by merely = choosing one of the three available (ignoring Not-ECT). The receiver = can then observe the density of codepoints and report that to the = sender. Which is more-or-less the premise of DCTCP. However, DCTCP changes the = meaning of CE, instead of making use of ECT(1), which I think is the big = mistake that makes it undeployable. So, from the middlebox perspective, very little changes. ECN-capable = packets still carry ECT(0) or ECT(1). You still set CE on ECT packets, = or drop Non-ECT packets, to signal when a serious level of persistent = queue has developed, so that the sender needs to back off a lot. But if = a less serious congestion condition exists, you can now signal *that* by = changing some proportion of ECT(0) codepoints to ECT(1), with the = intention that senders either reduce their cwnd growth rate, halt growth = entirely, or enter a gradual decline. Those are three things that ECN = cannot currently signal. This change is invisible to existing, RFC-compliant, deployed = middleboxes and endpoints, so should be completely backwards-compatible = and incrementally deployable in the network. (The only thing it breaks = is the optional ECN integrity RFC that, according to fairly recent = measurements, literally nobody bothered implementing.) Through TCP Timestamps, both sender and receiver can know fairly = precisely when a round-trip has occurred. The receiver can use this = information to calculate the ratio of ECT(0) and ECT(1) codepoints = received in the most recent RTT. A new TCP Option could replace TCP = Timestamps and the two bytes of padding that usually go with it, = allowing reporting of this ratio without actually increasing the size of = the TCP header. Large cwnds can be accommodated at the receiver by = shifting both counters right until they both fit in a byte each; it is = the ratio between them that is significant. It is then incumbent on the sender to do something useful with that = information. A reasonable idea would be to aim for a 1:1 ratio via an = integrating control loop. Receipt of even one ECT(1) signal might be = considered grounds for exiting slow-start, while exceeding 1:2 ratio = should limit growth rate to "Reno linear" semantics (significant for = CUBIC), and exceeding 2:1 ratio should trigger a "Reno linear" = *decrease* of cwnd. Through all this, a single CE mark (reported in the = usual way via ECE and CWR) still has the usual effect of a = multiplicative decrease. That's my proposal. - Jonathan Morton