From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from bifrost.lang.hm (lang.hm [66.167.227.134]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by lists.bufferbloat.net (Postfix) with ESMTPS id 2E66A3B29E for ; Mon, 25 Jun 2018 20:21:40 -0400 (EDT) Received: from asgard.lang.hm (asgard.lang.hm [10.0.0.100]) by bifrost.lang.hm (8.13.4/8.13.4/Debian-3) with ESMTP id w5Q0LYFs009985; Mon, 25 Jun 2018 17:21:34 -0700 Date: Mon, 25 Jun 2018 17:21:34 -0700 (PDT) From: David Lang X-X-Sender: dlang@asgard.lang.hm To: Jonathan Morton cc: Jim Gettys , bloat In-Reply-To: <68C3BBE1-96DA-41F7-9878-582074C4E769@gmail.com> Message-ID: 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> User-Agent: Alpine 2.02 (DEB 1266 2009-07-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed 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 00:21:40 -0000 On Tue, 26 Jun 2018, Jonathan Morton wrote: >> We only care about conserving txops when they are scarce, not when they are abundant. >> >> This principle is why a window system as crazy as X11 is competitive: it naturally becomes more efficient in the face of load (more and more requests batch up and are handled at maximum efficiency, so the system is at maximum efficiency at full load. >> >> Or am I missing something here? > > The problem is that currently every data aggregate received (one TXOP each > from the AP) results in two TXOPs just to acknowledge them, the first one > containing only a single ack. This is clearly wasteful, given the airtime > overhead per TXOP relative to the raw data rate of modern wifi. Relying > solely on backpressure would require that the channel was sufficiently busy to > prevent the second TXOP from occurring until the following data aggregate is > received, and that just seems too delicate to me. If there are no other stations competing for airtime, why does it matter that we use two txops? [1] If there are no other stations that you are competing with for airtime, go ahead and use it. If there are other stations that you are competing with for airtime, you are unlikely to get the txop immediately, so as long as you can keep updating the rf packet to send until the txop actially happens, the later data will get folded in. There will be a few times when you do get the txop immediately, and so you do end up 'wasting' a txop, but the vast majority of the time you will be able to combine the packets. Now, the trick is figureing out how long we can wait to finalize the rf packet David Lang [1] ignoring the hidden transmitter problem for the moment)