From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wm0-x22c.google.com (mail-wm0-x22c.google.com [IPv6:2a00:1450:400c:c09::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 8709F3B2A4 for ; Thu, 29 Mar 2018 05:07:41 -0400 (EDT) Received: by mail-wm0-x22c.google.com with SMTP id x82so10161169wmg.1 for ; Thu, 29 Mar 2018 02:07:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-transfer-encoding; bh=itjz1xsT+b8GUoF2yePSuBZs32WTuvjTy3+bG6kJkuQ=; b=hS3+t0T6PyaONEgFo52HyMxQx5DbJCuS8RmvI8onq7IpWGXTvhV6IuxOw4J+9at+Wo ag/dvj/D+akFfJ9Axd9iBorHRlxLJIMtZjSf6V8zfzCkPfJdJKfuWKsV6Pl8cJYjY/Tk arbgoSv74aitTnqcRWdFyjFGIRjhazsyfedzYvU2Q2asGPo4v5f4MpjtFcZPMdfKUBz9 CbQ2GGvGnGiMbhe0ZnPALKhtLBwXilpJoFlMncqz9P9EebmEV1NekvVoMVqyJoNcdbsO 8sjGRqUi+6xQWPXuf50UO2w9IDokCOd39CNcnQ+82cJhg77JdY/kZdXA7hGRvH/MOTOt QZHg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding; bh=itjz1xsT+b8GUoF2yePSuBZs32WTuvjTy3+bG6kJkuQ=; b=duZHMrQ41XWXIIEJgpEWrWHhY5iKH99wqZzmvSPCAHJ7TvfaGgKvUPXAwmPl+B0ITy 9l6Rj79WG++1vO195KchVkSeoxKVvU1n+wPmKWqGx5iT788p5+o3/r9esE6FvTuDfju0 XQ/1bNwBIxK4zSQAiEsXoONfLdhgvi9cc5i7omxp9OQ2aF0UTOQjCJrTnti5L1E0uMow F2j2fYflRDwvj8EOG4HuhWtCFAUI8VWLWr2cmTiL2wTVdf0aXVly21BUUoFRpTlI+uZ6 GH2ZOwwyHB4oWwsY9wfpfD8fpVxWOEhw62yvhoPx1gYnj5tzRGxlRV5OvzxtINu5PqT+ S0mQ== X-Gm-Message-State: AElRT7HuweQcfBdWCganHlVo27+qKJAbMVUubIZilt3e3Ls3++PNwBDF X+ZFz8Gw1nopeglqLW0sfPMS+A== X-Google-Smtp-Source: AIpwx48siae0o8OinBhbU/rBmq38E7TuQTNGb2W5tVcwR/mmXC3d+W9dGweTGW2sm0ketCclhR/c1w== X-Received: by 10.28.23.21 with SMTP id 21mr5243778wmx.49.1522314460065; Thu, 29 Mar 2018 02:07:40 -0700 (PDT) Received: from [192.168.0.3] (184.77.159.143.dyn.plus.net. [143.159.77.184]) by smtp.gmail.com with ESMTPSA id d18sm3899614wre.5.2018.03.29.02.07.39 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 29 Mar 2018 02:07:39 -0700 (PDT) To: cake@lists.bufferbloat.net References: <87k1twgpsy.fsf@toke.dk> <0FDFC78B-95A4-4A4E-8498-6C4AC9610BD0@gmail.com> From: Andy Furniss Message-ID: Date: Thu, 29 Mar 2018 10:07:38 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:54.0) Gecko/20100101 Firefox/54.0 SeaMonkey/2.51a2 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [Cake] bufferbloat still misunderstood & ignored X-BeenThere: cake@lists.bufferbloat.net X-Mailman-Version: 2.1.20 Precedence: list List-Id: Cake - FQ_codel the next generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Mar 2018 09:07:41 -0000 Ironically, in the UK my cheap ISP, Plusnet used to do QOS for free. The ASA (Advertising standards authority) decreed that ISPs that mark traffic can't claim "totally unlimited" in ads - so they turned it off. You can now pay more to opt into something similar. It could be of course that there is more to it - eg. excuse to save on kit for marking, or the ASA considered that internal "discrimination" was going on - but IME over years with them I never saw evidence of that. Anyway for a single line I think Plusnet and opt in/pay more would be cheaper than AA (who IIRC, historically at least, don't classify/mark but just do something simple like prio smaller packets - though I haven't checked what they do now). Dave Taht wrote: > I so wish that the network nuetrality debate included discussions such as these. > > On Wed, Mar 28, 2018 at 5:53 PM, Jonathan Morton wrote: >>> On 29 Mar, 2018, at 3:26 am, Dave Taht wrote: >>> >>> A finicky bit would be who to penalize when the underlying medium >>> (shared cable) is oversubscribed. >> >> Two obvious reasonable solutions: share equally per subscriber, or share proportionately to provisioned bandwidth per subscriber. Either should be fairly straightforward to implement in an integrated qdisc, and either would penalise the (instantaneously) heaviest users before affecting normal or light users. >> >> Equal sharing has the interesting side-effect that subscribers on lower tiers don't notice backhaul congestion at all until higher tiers have been forced down to their level. This potentially gives ISPs an incentive to avoid such extreme congestion (by upgrading backhaul to match demand), since rational customers won't pay for bandwidth they can't use. It also ensures that all subscribers retain a reasonable, basic level of service during abnormal congestion events. >> >> Conversely, proportional sharing might give a perverse incentive, since paying more gives a larger share of the pie, no matter how cramped it is. Artificial scarcity could then be used to aid up-selling in an anti-consumer manner, similar to what's been seen with Netflix. It would be naive to assume that ISPs won't do this, given the opportunity, so it would be better to build only the more consumer-friendly option into the software. >> >> Theoretically, a middle ground could be to assign a sharing weight separately from the provisioned bandwidth. This would permit, for example, subscribers provisioned at 100:1 bandwidths to receive 4:1 service under congested conditions. However, this would be under ISPs' control and fully documented, and would therefore be a little too tempting to abuse. >> >> - Jonathan Morton >> > > >