From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-lf1-x12a.google.com (mail-lf1-x12a.google.com [IPv6:2a00:1450:4864:20::12a]) (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 89F3C3B29E; Sun, 3 Feb 2019 20:12:05 -0500 (EST) Received: by mail-lf1-x12a.google.com with SMTP id n23so3734210lfl.4; Sun, 03 Feb 2019 17:12:05 -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=d6V+gDKPnTO5z3DmahuudCJ2kNodJ8eskGad6UH8JbQ=; b=VqkxNORBpMJvwTYu6avOo2gBLkk9aS5B9lThFU4AqFPgi8kivoWmIpUICbsjhdGbBg AArwk3lfMl5juxrG+fcBQeEWOhQFfW6JMeap15mkadgNOjUGwnKlZdr92zqwIw2e0RPh IA/lvvilzl7jUD3f9zRUWzJoNjUajCC3Pu9YyP+tw5PdBxX0VSsJwWFJQviyLpkkUbCx aSblcCnA2yInYPGwwZgahGRNbQzc8eN4Mpt5cGU8fwyelTxjExvKbR9RsBS3Z8JclTgW M/ETnXdxDwOdjHi5sb8zItrCKjA3cKc2Nf5Ky9HKHgPJrkAatV4dNyc3aGEE4ct3IIoX JGdg== 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=d6V+gDKPnTO5z3DmahuudCJ2kNodJ8eskGad6UH8JbQ=; b=NYr2vVNfdJ+N+TMQakKtfJ1/44HMJDBFstesnuZYZULAS38OkuQvbMIltaZJ2w/wBO USgT+oI9XyKkzQLxoU9iD8ngChCNr+fs+n9dL87JxecAfithgFYsaxukJdWt2l4Z21K0 aapnIOSUDt6IHF7pop3gU64hShJbnlTpS90NGl8DvmhdvgRBLWTNQt1idtApIasP6gkA +oTiOGJm+goAH9MYmMY0za4+3zGmJgZqdX03xOjkeAZOhOo90cidPhiUGXe6vJWesJjC ekfCG77FDiO3wQjjnZ04bzew3JKREyTfhxO0fFOsRVGhJ4r5UyvA6+qR+IgPDyJ83vky Tmmg== X-Gm-Message-State: AJcUukf8arGy3h27Qy7N49gAj57NXuW321D09GAfmFbLaCRpa0xzAh/F +wVu/ZwSMLgN7gfbEOCpslw= X-Google-Smtp-Source: ALg8bN5h+juD18Q6PJVcuM4HbV9cxQwuq4Z+T3zFVEUEylGI7a40c/EuwHGK/TXZcXIa39j407LRlg== X-Received: by 2002:a19:982:: with SMTP id 124mr38278019lfj.138.1549242724316; Sun, 03 Feb 2019 17:12:04 -0800 (PST) Received: from jonathartonsmbp.lan (83-245-233-163-nat-p.elisa-mobile.fi. [83.245.233.163]) by smtp.gmail.com with ESMTPSA id o14-v6sm2471903lji.70.2019.02.03.17.12.02 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sun, 03 Feb 2019 17:12:03 -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 X-Priority: 3 (Normal) In-Reply-To: <1549233729.17269312@apps.rackspace.com> Date: Mon, 4 Feb 2019 03:12:01 +0200 Cc: Dave Taht , Cake List , cerowrt-devel Content-Transfer-Encoding: quoted-printable Message-Id: <8927B785-18EB-4AA6-A0B3-79ED499FBDE6@gmail.com> References: <1549233729.17269312@apps.rackspace.com> To: "David P. Reed" X-Mailer: Apple Mail (2.3445.9.1) Subject: Re: [Cerowrt-devel] [Cake] https://tools.ietf.org/html/draft-ietf-tsvwg-le-phb-06 is in last call X-BeenThere: cerowrt-devel@lists.bufferbloat.net X-Mailman-Version: 2.1.20 Precedence: list List-Id: Development issues regarding the cerowrt test router project List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Feb 2019 01:12:05 -0000 > On 4 Feb, 2019, at 12:42 am, David P. Reed = wrote: >=20 > This fairy story about traffic giving way to higher priority traffic = being a normal mode of operation is just that. A made up story, largely = used by folks who want to do selective pricing based on what customers = are willing to pay, not on value received. Honestly, I can believe that selective pricing was the original = motivation behind Diffserv (and the older TOS definition). I think it = probably originated from the way telegrams were handled at the time. In telegraph networks, there is a real cost to handling each message, = because traffic volume correlates directly with the number of human = operators involved. The telegraph network was therefore perpetually = congested, as the network sought to balance costs and revenue. In modern packet-switched networks, it's traffic *capacity* which bears = a *capital* cost, not so much in terms of running maintenance costs. = That's where the difference lies; in the latter case, selective pricing = leads to perverse incentives in that inducing congestion can lead to = higher revenue without higher costs, but with poorer service delivered. Hence the present fight over Net Neutrality and, perhaps, the resistance = of hardware manufacturers to properly tackling bufferbloat. After all, = if congestion doesn't lead to obvious signs of poor performance, there = is less incentive to buy newer and faster network hardware and/or = service plans. > When Mother's Day happens, you should have enough capacity to absorb = vast demand. Therefore what you do all the other days doesn't matter. = And on Mother's Day, if you have congestion, there's no way in hell that = anybody is happy. You're clearly looking at this from a core-network perspective - which = has its place. My philosophy on core and backhaul networks is that they = should be sized so that congestion is rare, and they should *also* = degrade gracefully when congestion does in fact occur. Application of = simple AQM algorithms, to keep latency low and spread the pain = more-or-less fairly, seems sufficient there. Last-mile links have different characteristics; they spend long periods = completely idle, and also significant periods completely saturated. = That's because they don't have the high degree of statistical = multiplexing that you see deeper in the network. This is, therefore, = where putting intelligence into the network has maximum advantage - = hence the all-singing, all-dancing design of Cake. Consumer ISPs tend to run their backhaul networks much fuller on average = than the core. Some are congested as much as 50% of the time; most are = reliably congested at certain times of the day or week, and performance = degrades noticeably when exceptional demand occurs (such as a sporting = event or newsworthy disaster, or simply the release of a blockbuster AAA = game). Whatever the reason, these networks are *not* prepared for = Mother's Day. Diffserv, as currently specified, does not reliably help. It is too = rarely implemented, by either consumer-grade ISPs, CPE or applications, = to gain much traction. Cake's interpretation is starting to trickle = into CPE, but it's too soon to tell whether that'll have much practical = effect. And you're right that strict priority is the wrong approach - it's too = easy to abuse. That's why Cake doesn't do strict priority, and actively = tries to avoid starving any class of traffic. In my view, there are just four classes of traffic with global meaning, = though additional classes may have local meaning: - High Throughput; what we now call Best Effort. Latency and packet = loss are relatively minor concerns for this traffic. - Low Latency; throughput and packet loss are less important than = immediacy. Attempting high throughput in this class should be = penalised, so that overall throughput is less under congested conditions = than if High Throughput were requested; this forms a natural incentive = to choose the correct class for the traffic. - High Reliability; packet loss would hurt performance more than = latency or throughput limitations. This might be suitable for simple = request-response protocols such as DNS. Long queues with fairness = metrics are appropriate here, with a similar throughput handicap as Low = Latency. - Low Priority; this traffic volunteers to "get out of the way" when = congestion occurs. It receives a relatively small guaranteed throughput = under congested conditions, but may fill otherwise-unused capacity when = the situation eases. If networks were widely designed to respect and preserve these four = classifications of traffic, which could be represented using a two-bit = codepoint rather than the present six bits, I'm certain that = applications would start to use those classes appropriately. Expanding = to three bits would allow representing locally-valid traffic classes = such as Network Control and Isochronous Audio/Video, which might = reasonably have strict priority over the global classes but which Should = Not be sent over the core network, and Should be interpreted as Low = Priority if encountered by a device not specifically configured to = understand them. - Jonathan Morton