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 9941F3B2A4 for ; Thu, 29 Nov 2018 05:53:31 -0500 (EST) Received: by uplift.swm.pp.se (Postfix, from userid 501) id 41E5CB1; Thu, 29 Nov 2018 11:53:30 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=swm.pp.se; s=mail; t=1543488810; bh=SvJa/AzMw7M9M5L/8AAi7EDdL3U8TU/Nm3Myw5qCVMI=; h=Date:From:To:cc:Subject:In-Reply-To:References:From; b=X+Nj1Un5Ml3pHESzEqBLgD2piZWuFjqj+yyt8gJqE2TeIgqTd8N8ejSorBei4ibMp g8IK2VRwQXP0o1qUcDjzsXeBxKISbnQyZExRBwD4RLkCyYvClvvBDY0sfR5IGM6fMF VGz0iB+2Uhhyo3QDIFHIguNW83yMQm9sJujcYjKU= Received: from localhost (localhost [127.0.0.1]) by uplift.swm.pp.se (Postfix) with ESMTP id 3F8EEB0; Thu, 29 Nov 2018 11:53:30 +0100 (CET) Date: Thu, 29 Nov 2018 11:53:30 +0100 (CET) From: Mikael Abrahamsson To: Sebastian Moeller cc: Jonathan Morton , bloat In-Reply-To: <2BDFF247-AF0E-452C-B1EA-2B143C6DD8F3@gmx.de> Message-ID: References: <65EAC6C1-4688-46B6-A575-A6C7F2C066C5@heistp.net> <38535869-BF61-4FC4-A0FB-96E91CC4F076@ifi.uio.no> <87va4gwe74.fsf@taht.net> <7125B446-F2C4-45B3-B48C-8720B1E35776@gmail.com> <2BDFF247-AF0E-452C-B1EA-2B143C6DD8F3@gmx.de> 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] incremental deployment, transport and L4S (Re: when does the CoDel part of fq_codel help in the real world?) 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, 29 Nov 2018 10:53:31 -0000 On Thu, 29 Nov 2018, Sebastian Moeller wrote: > As far as I can tell intel is pushing atom/x86 cores into its > docsis SoCs (puma5/6/7) as well as into the high-end dsl SoCs (formerly > lantiq, > https://www.intel.com/content/www/us/en/smart-home/anywan-grx750-home-gateway-brief.html?wapkw=grx750), > I am quite confident that those also pack enough punch for CPU based > routing at Gbps-rates. In docsis modems these are already rolled-out, I > do not know of any DSL modem/router that uses the GRX750 "10 Gbit/s packet processor". Game over, again. > Call me naive, but the solution to the impasse at getting a common > definition of diffserv agreed upon is replacing all TCP CC algorithms? > This is replacing changing all endpoints (and network nodes) to honor > diffserve with changing all endpoints to use a different TCP CC. At > least I would call that ambitious.... (unless L4S offers noticeable > advantages for all participating without being terribly unfair to the > non-participating legacy TCP users*). L4S proposes a separate queue for the L4S compatible traffic, and some kind of fair split between L4S and non-L4S traffic. I guess it's kind of along the lines of my earlier proposals about having some kind of fair split with 3 queues for PHB LE, BE and the rest. It makes it deployable in current HW without the worst kind of DDoS downsides imaginable. The Internet is all about making things incrementally deployable. It's very frustrating, but that's the way it is. Whatever we want to propose needs to work so-so with what's already out there and it's ok if it takes a while before it makes everything better. I'd like diffserv to work better, but it would take a lot of work in the operator community to bring it out to where it needs to be. It's not hopeless though, and I think https://tools.ietf.org/html/draft-ietf-tsvwg-le-phb-06 is one step in the right direction. Just the fact that we might have two queues instead of one in the simplest implementations might help. The first step is to get ISPs to not bleach diffserv but at least allow 000xxx. -- Mikael Abrahamsson email: swmike@swm.pp.se