From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from uplift.swm.pp.se (swm.pp.se [212.247.200.143]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by lists.bufferbloat.net (Postfix) with ESMTPS id 5A80F3B2A4 for ; Thu, 30 Nov 2017 14:59:05 -0500 (EST) Received: by uplift.swm.pp.se (Postfix, from userid 501) id 8BE97B4; Thu, 30 Nov 2017 20:59:03 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=swm.pp.se; s=mail; t=1512071943; bh=KIm6Zd4ToftUA4q5OMxy54aogymo6mFf68dpCPM2W9E=; h=Date:From:To:cc:Subject:In-Reply-To:References:From; b=QJJaviKNlzy0ULX9iqq+AjUf6NWR5HER/NMQBA5eLy46R4gvgg6a8K2TsDJlY2ofv VRI9Snc/53F5zo2FbS5rauW22mncoOJakFocndeba+rioE1FPPQlutbWYnx+GTCyTn 8icQlLdciqMHNiOtIc9GrGrvgyfP9ICRXrOos41U= Received: from localhost (localhost [127.0.0.1]) by uplift.swm.pp.se (Postfix) with ESMTP id 88D769F; Thu, 30 Nov 2017 20:59:03 +0100 (CET) Date: Thu, 30 Nov 2017 20:59:03 +0100 (CET) From: Mikael Abrahamsson To: Jonathan Morton cc: bloat In-Reply-To: Message-ID: References: <87shd18c51.fsf@toke.dk> <874lpe8y2f.fsf@toke.dk> <57A2696A-F95C-4EEC-95B7-45EC4C2ADA55@pnsol.com> User-Agent: Alpine 2.20 (DEB 67 2015-01-07) Organization: People's Front Against WWW MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Subject: Re: [Bloat] Bufferbloat in high resolution + non-stationarity 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: Thu, 30 Nov 2017 19:59:05 -0000 On Thu, 30 Nov 2017, Jonathan Morton wrote: > I submit that to provide *deployable* QoS schemes, you must either solve > the classification problem elegantly (which is a Hard Problem), or else > show that your scheme works adequately in the absence of classification. > I'm taking the latter approach with Cake, even though it *also* supports > Diffserv awareness to enhance its performance where classification is > straightforward. In IETF INT-AREA, there is now discussion about allocating a new diffserv codepoint for "less-than-best-effort" traffic. I have been advocate for this for quite a while, and I actually believe that this is incrementally deployable and has a chance to actually get ISP buy-in. The idea is to use TOS 0, but use the last 3 diffserv bits to indicate that this is less-than-BE. Non-implementing networks will treat this as BE, implementing networks can use some kind of DRR scheme to give this traffic less bandwidth in case of congestion, or just drop it earlier when there is queue buildup. I think this is the only chance we have to get internet-wide coordination for a diffserv codepoint that people will do anything with, and the recommendation should be to only act on this at the customer access line (the one connecting the ISP to the residential gateway) or perhaps within the customer network. The hope is that ISPs will not mangle/bleach this codepoint, because it actually indicates traffic should get lower priority, not higher. I am in complete agreement with you that any scheme that relies on Internet-wide QoS scheme based on diffserv/TOS is a no-go. No ISP will listen to this and act on it, as it's a DoS vector. -- Mikael Abrahamsson email: swmike@swm.pp.se