From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wr1-x431.google.com (mail-wr1-x431.google.com [IPv6:2a00:1450:4864:20::431]) (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 5E0AA3CB36 for ; Wed, 20 Mar 2019 19:51:10 -0400 (EDT) Received: by mail-wr1-x431.google.com with SMTP id w1so4699380wrp.2 for ; Wed, 20 Mar 2019 16:51:10 -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=eIY15Jwq/kjKC17TBs5pWcD3kZV+fQgzPGiMn1TRGO4=; b=QBHcXB3zYTRqu173Gp6tNPFjufBBES5KyjcH4lNTrY71blo2szXGoHspZz/3jXpkRx Rmtw1oB3DUUq/59b6A+GY57mw/QJXGQfL7CT0FeZ18Uh2BQqVukXX7+OhWh5/PZQIPtc wxGZUtGaWE4Cintr8MoEJ3v+JxnNTtdGxKyFXfNoZhq41GL9nuVLBvXEB5zK2HEp2N+B 3VIxKt87Amtr4dq8jcQi3idtsm+3OU4GChTtY2M/5X0nSe1WrFT1AbOFeWLfF6Z4FFzI rRRjWWFVU9qc6/nvTRIj5wol2BkdTzZiID5vIL8IyOHhNqD/SG00Ipl+DAZxUMhghSyt /qzA== 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=eIY15Jwq/kjKC17TBs5pWcD3kZV+fQgzPGiMn1TRGO4=; b=JlkrADRGAtMFNVIpdDocrRRwq85PtHSMlCQsXbsFxzyTFpwBVOVn5LfA1Xg/hwDmd3 /hulwWF7SrvSXwXPVu5MYWfuD09XXiy/lrVsbotd86bvOxn+yVMjwna1tV3Uk5cREOoY UVyh2IrvAQelp1d2YvwINc32kNmC8hzkK90bYhj5lZtNRSbqOvnE9/mWBo6KZUr1r/JX hQzw7xobv5gSes8wHfieN4oJX22qXikfDoDK1pMfUpQRf92JvRfy38hcWepHZeuUiOph w8cglIo1cfC/4YScpDC3EcygpP1m9OH7m4WiD5yGRKmBjgY58JJOfRwCEtrtdg9paVSx oX9g== X-Gm-Message-State: APjAAAU3cYFwAljuLDh9GSHH9bvBleocXrYJpg4yoZPZu9MlvF8hRk27 GnODe4k1UJi9GooyxYcyX6M= X-Google-Smtp-Source: APXvYqygj5NeiBaiph5SNQzta6KBHw4D+ryW3tVvyzcWwtjAS2Kn/oM5JKQggkenUWRT53eNpGPm9Q== X-Received: by 2002:adf:cd84:: with SMTP id q4mr459254wrj.250.1553125869559; Wed, 20 Mar 2019 16:51:09 -0700 (PDT) Received: from jonathartonsmbp.lan (83-245-226-9-nat-p.elisa-mobile.fi. [83.245.226.9]) by smtp.gmail.com with ESMTPSA id c18sm2545389wmk.47.2019.03.20.16.51.08 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 20 Mar 2019 16:51:08 -0700 (PDT) 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: <7e49b551-22e5-5d54-2a1c-69f53983d7e5@bobbriscoe.net> Date: Thu, 21 Mar 2019 01:51:07 +0200 Cc: "Holland, Jake" , "David P. Reed" , Vint Cerf , tsvwg IETF list , bloat Content-Transfer-Encoding: quoted-printable Message-Id: <04E62EA7-82EF-4F1B-A86D-5A23CA3B190A@gmail.com> References: <1E80578D-A589-4CA0-9015-B03B63042355@gmx.de> <27FA673A-2C4C-4652-943F-33FAA1CF1E83@gmx.de> <1552669283.555112988@apps.rackspace.com> <7029DA80-8B83-4775-8261-A4ADD2CF34C7@akamai.com> <1552846034.909628287@apps.rackspace.com> <5458c216-07b9-5b06-a381-326de49b53e0@bobbriscoe.net> <7e49b551-22e5-5d54-2a1c-69f53983d7e5@bobbriscoe.net> To: Bob Briscoe X-Mailer: Apple Mail (2.3445.9.1) Subject: Re: [Bloat] [Ecn-sane] [iccrg] Fwd: [tcpPrague] Implementation and experimentation of TCP Prague/L4S hackaton at IETF104 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: Wed, 20 Mar 2019 23:51:10 -0000 > On 21 Mar, 2019, at 1:29 am, Bob Briscoe wrote: >=20 >> But more importantly, the L4S usage couples the minimized latency use >> case to any possibility of getting a high fidelity explicit = congestion >> signal, so the "maximize throughput" use case can't ever get it. > Eh? There's definitely a misunderstanding or a difference in = terminology between us here. The whole point of using a congestion = controller like DCTCP is so that flow rate can scale indefinitely with = capacity. Van Jacobson actually noted that the original TCP was = unscalable in a footnote to the tech report version of the SIGCOMM = paper. >=20 > The high fidelity congestion signal of what we call scalable = congestion controllers (like DCTCP) is inversely proportional to the = window. So as window scales up, the congestion signal scales down, so = that their product remains constant. That means the number of ECN marks = per RTT is scale-invariant. So the control signal remains just as tight = at any scale.=20 If you'll indulge me for a moment, I'd like to lay out a compromise = scenario where a lot of L4S' stated goals are still met. There is no dualQ. There is an AQM at the bottleneck link, of = unspecified type, which implements SCE. Assume that it produces CE = marks like a conventional AQM, and also produces SCE marks like an L4S = AQM produces CE. A sender implements DCTCP-SCE, which is essentially Paced NewReno = modified to subtract half of all acked data that was SCE-marked from its = cwnd. (This is equivalent to the DCTCP algorithm with g=3D1 and an = arbitrarily small measurement window, but acting on SCE instead of CE.) = Any SCE mark also kicks it out of slow-start. The means by which SCE information gets back to the sender is left vague = for now; it's an orthogonal problem with several viable solutions. What is missing from this scenario, from L4S' point of view? And why = have I been able to describe it so succinctly? - Jonathan Morton