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 5348E3B2A4 for ; Thu, 29 Nov 2018 02:46:36 -0500 (EST) Received: by uplift.swm.pp.se (Postfix, from userid 501) id 0355FB1; Thu, 29 Nov 2018 08:46:35 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=swm.pp.se; s=mail; t=1543477595; bh=zOPc8O8dgQopYDe00WDuH+5k2WjX/HFMnCv4GRhDApU=; h=Date:From:To:cc:Subject:In-Reply-To:References:From; b=a+yZLI8nrtOgh9Fnsr+qln+7utAgtx1gJyTZkuO989tQ9+YZFKSD0YY2wuzQUNPZX Afp2DxegBPlx/c5/u+FEHS5VaA8lEMAzVh8kc2Wos7Xpzv++o5XIulM306hHYjhble Ig/u6k1ZZJVgVjzaqzHQURNQdhh+GgJYOrupXYeU= Received: from localhost (localhost [127.0.0.1]) by uplift.swm.pp.se (Postfix) with ESMTP id F3974B0; Thu, 29 Nov 2018 08:46:34 +0100 (CET) Date: Thu, 29 Nov 2018 08:46:34 +0100 (CET) From: Mikael Abrahamsson To: Jonathan Morton cc: Dave Taht , bloat In-Reply-To: <7125B446-F2C4-45B3-B48C-8720B1E35776@gmail.com> 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> 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 07:46:36 -0000 On Thu, 29 Nov 2018, Jonathan Morton wrote: > You are essentially proposing using ECT(1) to take over an intended function of Diffserv. Well, I am not proposing anything. I am giving people a heads-up that the L4S authors are proposing this. But yes, you're right. Diffserv has shown itself to be really hard to incrementally deploy across the Internet, so it's generally bleached mid-path. > In my view, that is the wrong approach. Better to improve Diffserv to > the point where it becomes useful in practice. I agree, but unfortunately nobody has made me king of the Internet yet so I can't just decree it into existance. > Cake has taken steps in that direction, by implementing some reasonable > interpretation of some Diffserv codepoints. Great. I don't know if I've asked this but is CAKE easily implementable in hardware? From what I can tell it's still only Marvell that is trying to put high performance enough CPUs into HGWs to do forwarding in CPU (which can do CAKE), all others still rely on packet accelerators to achieve the desired speeds. > My alternative use of ECT(1) is more in keeping with the other > codepoints represented by those two bits, to allow ECN to provide more > fine-grained information about congestion than it presently does. The > main challenge is communicating the relevant information back to the > sender upon receipt, ideally without increasing overhead in the TCP/IP > headers. You need to go into the IETF process and voice this opinion then, because if nobody opposes in the near time then ECT(1) might go to L4S interpretation of what is going on. They do have ECN feedback mechanisms in their proposal, have you read it? It's a whole suite of documents, architecture, AQM proposal, transport proposal, the entire thing. On the other hand, what you want to do and what L4S tries to do might be closely related. It doesn't sound too far off. Also, Bob Briscoe works for Cable Labs now, so he will now have silicon behind him. This silicon might go into other things, not just DOCSIS equipment, so if you have use-cases that L4S doesn't do but might do with minor modification, it might be better to join him than to fight him. -- Mikael Abrahamsson email: swmike@swm.pp.se