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 664673B29E; Mon, 11 Mar 2019 05:07:24 -0400 (EDT) Received: by uplift.swm.pp.se (Postfix, from userid 501) id 62438B3; Mon, 11 Mar 2019 10:07:23 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=swm.pp.se; s=mail; t=1552295243; bh=6lvndJyHzhZ5N5AOKGQNe+ltUOR2+XPhqn9JThyLJP8=; h=Date:From:To:cc:Subject:In-Reply-To:References:From; b=pAzu6MR9U0Ut4oXIIXpY3meqJCN9IxGRXyvVputUgQ4BMHTVGplJtlvUf0TkK0GAK wp5EK7pjd06M2sZvZO1Gc/DQb2KoVViFjsXWgoLg0Fp6On6WNUNy3vw7erR7OppztZ IhM8c4pLZF31WNIm8RRumVP3wR9MgYKPs6PUgbeA= Received: from localhost (localhost [127.0.0.1]) by uplift.swm.pp.se (Postfix) with ESMTP id 5D1ADB0; Mon, 11 Mar 2019 10:07:23 +0100 (CET) Date: Mon, 11 Mar 2019 10:07:23 +0100 (CET) From: Mikael Abrahamsson To: Jonathan Morton cc: Richard Scheffenegger , "ecn-sane@lists.bufferbloat.net" , bloat , "codel@lists.bufferbloat.net" , Cake List In-Reply-To: Message-ID: References: <550C0248-1704-49DA-ABDC-49A91E0AC6F3@akamai.com> <1EE25778-8571-4506-A334-38C544470ACE@gmail.com> User-Agent: Alpine 2.20 (DEB 67 2015-01-07) Organization: People's Front Against WWW MIME-Version: 1.0 Content-Type: multipart/mixed; BOUNDARY="-137064504-1281224049-1552295243=:3161" Subject: Re: [Ecn-sane] [Bloat] The "Some Congestion Experienced" ECN codepoint - a new internet draft - X-BeenThere: ecn-sane@lists.bufferbloat.net X-Mailman-Version: 2.1.20 Precedence: list List-Id: Discussion of explicit congestion notification's impact on the Internet List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Mar 2019 09:07:24 -0000 This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. ---137064504-1281224049-1552295243=:3161 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8BIT On Mon, 11 Mar 2019, Jonathan Morton wrote: > Seriously? I had to dig in the specs to find any mention of that, and… > it's all about better supporting bonded links. Which can already be It doesn't stop there. Right now DOCSIS, 3GPP networks, Wifi etc all do ordering guarantees, so they will hold up any delivery of packets until it can assure that none of them are delivered out of order. Allowing these transports to re-order the packets mean they can do a better job than they do today. You do not want to ask them to drop their packets either because the drop rate is potentially way higher than most transports would feel comfortable with. > done by implementing RACK at the sender, and all you propose is that > when L4S is in use, the extra buffering at the link layer is dropped. I did? > This is absolutely useless for ordinary Internet users, who are unlikely > to have consecutive packets sufficiently closely traversing such a link > for this reordering to exceed the 3-dupack threshold in any case - so > you might as well delete that reordering buffer anyway, and let the > endpoints handle it. You don't need L4S for that. That's not my experience with wifi and how it behaves at the edge. > endpoints (eg. using AccECN) to discover whether setting ECT(1) at the > sender is legal. SCE does not require such negotiation (ie. a transport > could implement it entirely at the receiver, manipulating the send rate > via the already-standardised receive window), so should be easier to > specify and deploy successfully. Well, I am not convinced blowing the last codepoint on SCE has enough merit. ---137064504-1281224049-1552295243=:3161--