From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-lf1-x131.google.com (mail-lf1-x131.google.com [IPv6:2a00:1450:4864:20::131]) (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 905693BA8E; Fri, 15 Mar 2019 21:26:39 -0400 (EDT) Received: by mail-lf1-x131.google.com with SMTP id a6so5756369lfl.5; Fri, 15 Mar 2019 18:26: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=Dt5G/efk7O5RSjy8/pYQ2fFXVpO9guogElmb22FGjFI=; b=h2M7DBOLaTPb3NqJaOmzl2AuO6sHVxMEkSKMs62kHzJa15tIXoiDJA+GAbMM6qIbBK I4f2gpqgOuW9qhMnB82W00dYS2oUUqtiS6598dZhq8CXnav2OBrdXRzLkmubBtbkrOKH SzeRAdfPC7r/DdcKqqcJoKj+42LTCOzAO6amjjqajDVZb1uqYEWY30dZ8TKQZRgYHy3K dgqN581zWQE4qtO7d3msWgzaKtLfZYra/nXXHmwvv61bEFzGR1JmbEWoGWoch14zEmXQ Wv+nuzwCfWZBElMmN7Kule8W89UUkMlNwAoCULThWa4SewMCC/ecR8wuqYrO/HZbZzvn FKMw== 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=Dt5G/efk7O5RSjy8/pYQ2fFXVpO9guogElmb22FGjFI=; b=RDvIeHkNNnaR1wPzESo/kvWaHdMSYLtCK3DVl5Hj4nljTlOcMcg9JRCZvPtN0Hwojm UK/+bo0147hJ87VdIi441ihMEm+NRaajJmBVdBwrwkJIPk12dAp0angzLLr3HzvLQhz7 4msogPejbyr7JLLO99KUAM7cVbFbpqcSnnROfPxENY2oIL8Nr2Jj6YdxO++E5B99wnwd bmCB+wJ7bASaC27Ext1zekPe/nA9Rq3ZltTWI2TrvapDItjcYWA8qoDFBqO5Sy6nvhfO WW6dLYd7qPUgDHWEsoDIa4ZyD3q1ZYWveXYVR9wbK65tkApTfva1wmQvi1Xa93c1CH9j FHTw== X-Gm-Message-State: APjAAAUaizLtqzEPw7GZxmJ0fww7xywoMvSs4Gr31sYT3+HeEbAUd3V6 OibeAZ5totpGGKBcp2oj7mc= X-Google-Smtp-Source: APXvYqxTpLNv4SYQqAjSKpixnlpv2QK6KuCgmEkF54DIHiMz+lfjpU9jRA2IbI+3P9Gzfa9OL9zNWA== X-Received: by 2002:a19:9e0d:: with SMTP id h13mr3589693lfe.51.1552699598531; Fri, 15 Mar 2019 18:26:38 -0700 (PDT) Received: from jonathartonsmbp.lan (83-245-235-46-nat-p.elisa-mobile.fi. [83.245.235.46]) by smtp.gmail.com with ESMTPSA id e12sm773666ljj.27.2019.03.15.18.26.37 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 15 Mar 2019 18:26:37 -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 X-Priority: 3 (Normal) In-Reply-To: <1552693438.976714769@apps.rackspace.com> Date: Sat, 16 Mar 2019 03:26:34 +0200 Cc: Mikael Abrahamsson , ecn-sane@lists.bufferbloat.net, bloat Content-Transfer-Encoding: quoted-printable Message-Id: <0803793B-1505-4D8C-AD65-D4138BCEB6E3@gmail.com> References: <1E80578D-A589-4CA0-9015-B03B63042355@gmx.de> <27FA673A-2C4C-4652-943F-33FAA1CF1E83@gmx.de> <1552669283.555112988@apps.rackspace.com> <7412ADED-D1F3-4C15-9703-0977E087013B@gmail.com> <1552679055.131328669@apps.rackspace.com> <6A1F5DC5-F4D8-4C40-B4F6-1F03368F8219@gmail.com> <1552693438.976714769@apps.rackspace.com> To: "David P. Reed" 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: Sat, 16 Mar 2019 01:26:39 -0000 > On 16 Mar, 2019, at 1:43 am, David P. Reed = wrote: >=20 > Now the other thing that is crucial is that the optimal state almost = all of the time of every link in the network is that a utilization far = from max capacity. The reason for this is the fact that the Internet = (like almost all networks) is bursty and fractal. That can be said about some types of links but not others. Last-mile links in particular are often saturated by their users' = individual traffic for minutes or even hours at a time, especially the = slower link technologies such as ADSL and 4G. The user wants their = hundred-gigabyte game update installed as soon as possible, even if they = only have 10Mbps to suck it through, and they still want to use their = connection for other things while they wait. And this is not = unreasonable; I do it regularly. At peak times, ISP backhaul capacity can often be enough of a bottleneck = for users to notice the congestion and induced latency; it is far from = the case that all ISPs worldwide massively over-provision their networks = to avoid routine congestion, even in modern technologically advanced = nations. There are remote islands where hundreds or thousands of users = must share a single satellite or microwave uplink. Cell towers are also = a shared medium with decidedly finite capacity. Only core networks, and the backhaul networks of certain particularly = conscientious ISPs, can typically be described as congestion-free. And = that is why we discuss AQM and ECN in such detail in the first place; = without congestion, they wouldn't be required. The extent to which traffic classification is needed on particular types = of link can be debated. It could fairly be argued that we've done = remarkably well without the benefit of a functioning Diffserv ecosystem, = so there is no particular urgency to create one. At the same time, it's = worth discussing *why* Diffserv fails to do its intended job, and how a = better system *could* be designed, because that may reveal lessons for = the future. I will say this: there are times, even with the benefit of everything = Cake does for me, when I would prefer that BitTorrent traffic would = automatically defer to other stuff (as it was supposedly designed to). = Several game updaters, including Wargaming.net's, use BitTorrent under = the skin - opening and using several hundred flows in parallel, and = thereby swamping any other traffic going to the same host. It would be = very straightforward for them to mark all that traffic as Minimum Cost, = while their games themselves use Minimum Latency for battle traffic. Minimum Cost is a natural choice for any transport using LEDBAT, or with = similarly altruistic philosophy. Minimum Latency is a natural choice for any application requiring = realtime response - games, VoIP, remote shells. Minimum Loss is a natural choice for applications involved in network = control, where dropped packets could have a much greater than normal = impact on overall network performance. Maximum Throughput is a natural choice for general-purpose applications = not fitting any of the above. Pricing is not required. Making the wrong choice will simply make your = application perform badly on a loaded network, as the bottleneck link = optimises for the thing you told it to optimise for, rather than for = what you actually want. That's all that's really needed. - Jonathan Morton