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 52DC53B29E for ; Fri, 30 Nov 2018 01:01:30 -0500 (EST) Received: by uplift.swm.pp.se (Postfix, from userid 501) id 58CE6B1; Fri, 30 Nov 2018 07:01:29 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=swm.pp.se; s=mail; t=1543557689; bh=UQOcq7YJv9eky7ynDqafAamaTUoX67uOag7GrEtkWiU=; h=Date:From:To:cc:Subject:In-Reply-To:References:From; b=gbfCbQ9rgLqpCMquuegJH5CeSp2REcNCDRENNqjKljrWQbrHAkiRosVk9VpUQPM9c nhrvWWBNQW3Z5BAFWF/6pXmQyphze7GjPzrym336uY7MX+b9n0c1Mstv0tLtdMDLAv L0ZSddBuWxTl940UQIcqQmBQMxC0YDDNWY2TpJSY= Received: from localhost (localhost [127.0.0.1]) by uplift.swm.pp.se (Postfix) with ESMTP id 56983B0; Fri, 30 Nov 2018 07:01:29 +0100 (CET) Date: Fri, 30 Nov 2018 07:01:29 +0100 (CET) From: Mikael Abrahamsson To: Jonathan Morton cc: bloat In-Reply-To: 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> <7D833179-4D95-4C2F-B0AF-4FFD4D29DEE4@ifi.uio.no> <6025E3FF-E413-43F5-B9EB-4FC000846BE4@ifi.uio.no> <01A9062C-52DB-4FE8-A866-2796B2ADF88C@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: Fri, 30 Nov 2018 06:01:30 -0000 On Fri, 30 Nov 2018, Jonathan Morton wrote: > Ah, so you're thinking in terms of link-layers which perform local > retransmission, like wifi. So the optimisation is to not delay packets > "behind" a corrupted packet while the latter is retransmitted. Yes. > It's possible for a TCP to interpret a reordered packet as missing, > triggering an end-to-end retransmission which is then discovered to be > unnecessary. At the application level, TCP also performs the same HoL > blocking in response to missing data. So it's easy to see why links try > to preserve ordering, even to this extent, but I suspect they typically > do so on a per-station basis rather than per-flow. It's a "truth-everybody-knows" in networking that "NEVER RE-ORDER PACKETS WITHIN 5-TUPLE FLOW!!!!! THERE BE DRAGONS THERE!". I'd also say I see enough transport people who says that this should be true generally, if nothing else because of legacy. > Personally I think the problem of reordering packets is overblown, and > that TCPs can cope with occasional missing or reordered packets without > serious consequences to performance. So if you add "reordering > tolerant" to the list of stuff that Diffserv can indicate, you might > just end up with all traffic being marked that way. Is that really > worthwhile? Question isn't so much about TCP, it's the other things I am worried about. TCP handles re-ordering kind of gracefully, other protocols might not. > Oddly enough, wifi is now one of the places where FQ is potentially > easiest to find, with Toke's work reaching the Linux kernel and so many > wifi routers being Linux based. Again, even if they're using Linux they will/might have packet accelerators that just grab the flow and the kernel never sees it again. No FQ_CODEL for that. > An acknowledged problem is overly persistent retries by the ARQ > mechanism, such that the time horizon for the link-layer retransmission > often exceeds that of the end-to-end RTO, both for TCP and > request-response protocols like DNS. I say, retransmit at the link layer > once or twice, then give up and let the end-hosts sort it out. I agree, but I also think that it would help some link-layers if the re-ordering requirement could be relaxed. However, before that can be communicated a lot of study needs to be done to check if this is actually true. I've had incidents in my 20 year networking career where it's not and applications misbehaved when they were re-ordered. -- Mikael Abrahamsson email: swmike@swm.pp.se