From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from uplift.swm.pp.se (ipv6.swm.pp.se [IPv6:2a00:801::f]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by lists.bufferbloat.net (Postfix) with ESMTPS id 50F6F3B2A4 for ; Thu, 29 Nov 2018 02:28:19 -0500 (EST) Received: by uplift.swm.pp.se (Postfix, from userid 501) id CF301B1; Thu, 29 Nov 2018 08:28:17 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=swm.pp.se; s=mail; t=1543476497; bh=U7EwVu061YiO7tLW2/SrFz57e+z6QeGL1rNwpDpQgqw=; h=Date:From:To:cc:Subject:In-Reply-To:References:From; b=2Y+FvWkVYDo9okMCs8/qeVoxgLcE1X5UkyoZ4m69KeQvgRN9zKniCSDgrRJaY3mnu qe/u+772uxMpiH2MsAN/JrLxfB5N/R1AyS8U/7z/5w9qZstiwytRlcV1VCu1Wa6qgq oB0zxa6FyH0bmokhM1KJRBltOAhDlTt8rDACdKGg= Received: from localhost (localhost [127.0.0.1]) by uplift.swm.pp.se (Postfix) with ESMTP id CA357B0; Thu, 29 Nov 2018 08:28:17 +0100 (CET) Date: Thu, 29 Nov 2018 08:28:17 +0100 (CET) From: Mikael Abrahamsson To: Dave Taht cc: bloat In-Reply-To: <87va4gwe74.fsf@taht.net> Message-ID: References: <65EAC6C1-4688-46B6-A575-A6C7F2C066C5@heistp.net> <38535869-BF61-4FC4-A0FB-96E91CC4F076@ifi.uio.no> <87va4gwe74.fsf@taht.net> 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: [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:28:19 -0000 On Wed, 28 Nov 2018, Dave Taht wrote: > see ecn-sane. Please try to write a position paper as to where and why > ecn is good and bad. > > if one day we could merely establish a talmud of commentary > around this religion it would help. >From my viewpoint it seems to be all about incremental deployment. We have 30 years of "crud" that things need to work with, and the worst-case needs to be a disaster for anything that wants to deploy. This is one thing about L4S, ETC(1) is the last "codepoint" in the header not used, that can statelessly identify something. If anyone sees a better way to use it compared to "let's put it in a separate queue and CE-mark it agressively at very low queue depths and also do not care about re-ordering so a ARQ L2 can re-order all it wants", then they need to speak up, soon. I actually think the "let's not care about re-ordering" would be a brilliant thing, it'd help quite a lot of packet network types become less costly and more efficient, while at the same time not doing blocking of subsequent packets just because some earlier packet needed to be retransmitted. Brilliant for QUIC for instance, that already handles this (at least per-stream). -- Mikael Abrahamsson email: swmike@swm.pp.se