From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail.taht.net (mail.taht.net [176.58.107.8]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by lists.bufferbloat.net (Postfix) with ESMTPS id 3E9D13B29E; Mon, 4 Feb 2019 01:58:53 -0500 (EST) Received: from dancer.taht.net (unknown [IPv6:2603:3024:1536:86f0:eea8:6bff:fefe:9a2]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mail.taht.net (Postfix) with ESMTPSA id A6E9821455; Mon, 4 Feb 2019 06:58:51 +0000 (UTC) From: Dave Taht To: Mikael Abrahamsson Cc: "David P. Reed" , Cake List , cerowrt-devel References: <1549233729.17269312@apps.rackspace.com> Date: Sun, 03 Feb 2019 22:58:10 -0800 In-Reply-To: (Mikael Abrahamsson's message of "Mon, 4 Feb 2019 07:02:28 +0100 (CET)") Message-ID: <87k1ig6nwd.fsf@taht.net> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.5 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain 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 06:58:53 -0000 Mikael Abrahamsson writes: > On Sun, 3 Feb 2019, David P. Reed wrote: > >> 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. (that's a >> business story, > > The point of PHB LE is so that the customer access shaper can > background the customer LE traffic. It's not intended to be used by > ISPs on their core links, it's intended for use on the customer access > port. > > If the customer buys 10 megabit/s Internet access then it's beneficial > for the customer if the software update download doesn't affect the > netflix stream and the kids' gameplay. Thus why we're trying to > differentiate between BE and LE. FQ or CAKE can solve the gameplay, > but it can't make the netflix stream get 90% of the rest of the > capacity and give 5% to the software download. LE marking the software > download traffic can do that. Well, (I just checked, let me know if you want the captures) comcast still re-marks all codepoints it does not recognize, to become CS1, including this one. So the smartest thing a comcast customer can do is wash it out on entrance to their domain. The second problem with LE in this direction is that you AND your software download provider have to trust your ISP to not A) remark this traffic B) maltreat it by introducing starvation tactics. In the US, at least, there is no trust of the ISP to be had and it is best to not mark your traffic at all. I don't think trust can ever be obtained, here, at least. Within and exiting your home domain, you might have some hope, but even then I might lean to washing out your markings pending the death of NN. (I have no idea how comcast's remarking policy escaped NN litigation in the first place) The best that I think can be hoped for is that your netflix stream gets 50% and your download 50% in this two host example. Which is what cake does, without markings, and why the wash option exists in cake. Certainly I'd like to see multi-stream downloads for non-critical things like steam die a horrible death, and I'd like uploads to places like dropbox to not kill your network.