From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail.toke.dk (mail.toke.dk [52.28.52.200]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by lists.bufferbloat.net (Postfix) with ESMTPS id 627EE3BA8E for ; Tue, 26 Jun 2018 07:16:52 -0400 (EDT) From: Toke =?utf-8?Q?H=C3=B8iland-J=C3=B8rgensen?= DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=toke.dk; s=20161023; t=1530011810; bh=dWLKTWugUkDJhL/JKehKLKnBSZ22TMCapxUeWM9ksGY=; h=From:To:Cc:Subject:In-Reply-To:References:Date:From; b=VcKHZGxN0H6CKtse6nVTSqP/8NQYeJLqZxjr3rCopBfadBVSCXnfbpvg58ymocHRT YaJhYE/WTyZIIipJmlSzycffQ2AC95jyP42UDBCpQzCw4jA6KN7VggWOmpLGSZvEnY kjcQW7SHpZg9bjhqC4b0t0ku6XjqpRIpR7n4uOqA0fxybKfUBifF+Azx5ABHEM0015 xyuQpxPOMG01NtWHR41qv55jeGaj5ExSQK3LS8URU79XxZRufSteCq3YHdCWCHUrT0 jnJl2pp9RtAiuA588UE+dI1dSKWeAseA3ZTOhglqGVprkzopk/YTShFl99Up9HJD5z parzAbA7ouTqw== To: David Lang , Jonathan Morton Cc: bloat In-Reply-To: References: <8736xgsdcp.fsf@toke.dk> <838b212e-7a8c-6139-1306-9e60bfda926b@gmail.com> <8f80b36b-ef81-eadc-6218-350132f4d56a@pollere.com> <9dbb8dc8-bec6-8252-c063-ff0ba5fd7c1a@pollere.com> <25305.1529678986@localhost> <47EC21F5-94D2-4982-B0BE-FA1FA30E7C88@gmail.com> <18224.1529704505@localhost> <87muvjnobj.fsf@toke.dk> <68C3BBE1-96DA-41F7-9878-582074C4E769@gmail.com> <642CBFAE-A182-4D6E-968B-411159CBFD9B@superduper.net> <422BFE8C-1AAC-4A55-AF1F-448B3B5C0E28@gmail.com> Date: Tue, 26 Jun 2018 13:16:54 +0200 X-Clacks-Overhead: GNU Terry Pratchett Message-ID: <87in65n6ft.fsf@toke.dk> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Subject: Re: [Bloat] lwn.net's tcp small queues vs wifi aggregation solved 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: Tue, 26 Jun 2018 11:16:52 -0000 David Lang writes: > On Tue, 26 Jun 2018, Jonathan Morton wrote: > >>> On 26 Jun, 2018, at 3:36 am, Simon Barber wrote: >>> >>> Most hardware needs the packet finalized before it starts to contend fo= r the=20 >>> medium (as far as I=E2=80=99m aware - let me know if you know different= ly). One issue=20 >>> is that if RTS/CTS is in use, then the packet duration needs to be know= n in=20 >>> advance (or at least mid point of the RTS transmission). >> >> This is a valid argument. I think we could successfully argue for a del= ay of=20 >> 1ms, if there isn't already enough data in the queue to fill an aggregat= e,=20 >> after the oldest packet arrives until a request is issued. > > why does the length of the txop need to be known at the time that it's > requested? Because that's how the hardware is designed. There are really two discussions here: (1) what could we do with a clean-slate(ish) design, and (2) what can we retrofit into existing drivers such as the ath9k. I think that the answer to (1) is probably 'quite a lot', but unfortunately the answer to (2) is 'not that much'. We could probably do a little bit better in ath9k, but for anything newer all bets are off, as this functionality has moved into firmware. Now, if there was a hardware vendor that was paying attention and could do the right thing throughout the stack, that would be awesome of course. But for Linux at least, sadly it seems that most hardware vendors can barely figure out how to get *any* driver upstream... :/ Also, from a conceptual point of view, I really think ACK timing issues are best solved at the TCP stack level. Which Eric is already working on (SACK compression is already in 4.18, with normal ACK compression to follow). -Toke