From: Simon Barber <simon@superduper.net>
To: David Lang <david@lang.hm>
Cc: Jonathan Morton <chromatix99@gmail.com>,
bloat <bloat@lists.bufferbloat.net>
Subject: Re: [Bloat] lwn.net's tcp small queues vs wifi aggregation solved
Date: Mon, 25 Jun 2018 17:36:11 -0700 [thread overview]
Message-ID: <642CBFAE-A182-4D6E-968B-411159CBFD9B@superduper.net> (raw)
In-Reply-To: <alpine.DEB.2.02.1806251716290.10496@nftneq.ynat.uz>
Most hardware needs the packet finalized before it starts to contend for the medium (as far as I’m aware - let me know if you know differently). One issue is that if RTS/CTS is in use, then the packet duration needs to be known in advance (or at least mid point of the RTS transmission).
Simon
> On Jun 25, 2018, at 5:21 PM, David Lang <david@lang.hm> wrote:
>
> 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)
> _______________________________________________
> Bloat mailing list
> Bloat@lists.bufferbloat.net
> https://lists.bufferbloat.net/listinfo/bloat
next prev parent reply other threads:[~2018-06-26 0:36 UTC|newest]
Thread overview: 32+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-06-21 4:58 Dave Taht
2018-06-21 9:22 ` Toke Høiland-Jørgensen
2018-06-21 12:55 ` Eric Dumazet
2018-06-21 15:18 ` Dave Taht
2018-06-21 15:31 ` Caleb Cushing
2018-06-21 15:46 ` Stephen Hemminger
2018-06-21 17:41 ` Caleb Cushing
2018-06-21 15:50 ` Dave Taht
2018-06-21 16:29 ` David Collier-Brown
2018-06-21 16:54 ` Jonathan Morton
2018-06-21 16:43 ` Kathleen Nichols
2018-06-21 19:17 ` Dave Taht
2018-06-21 19:41 ` Sebastian Moeller
2018-06-21 19:51 ` Toke Høiland-Jørgensen
2018-06-21 19:54 ` Dave Taht
2018-06-21 20:11 ` Sebastian Moeller
2018-06-22 14:01 ` Kathleen Nichols
2018-06-22 14:12 ` Jonathan Morton
2018-06-22 14:49 ` Michael Richardson
2018-06-22 15:02 ` Jonathan Morton
2018-06-22 21:55 ` Michael Richardson
2018-06-25 10:38 ` Toke Høiland-Jørgensen
2018-06-25 23:54 ` Jim Gettys
2018-06-26 0:07 ` Jonathan Morton
2018-06-26 0:21 ` David Lang
2018-06-26 0:36 ` Simon Barber [this message]
2018-06-26 0:44 ` Jonathan Morton
2018-06-26 0:52 ` Jim Gettys
2018-06-26 0:56 ` David Lang
2018-06-26 11:16 ` Toke Høiland-Jørgensen
2018-06-26 1:27 ` Dave Taht
2018-06-26 3:30 ` Simon Barber
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: https://lists.bufferbloat.net/postorius/lists/bloat.lists.bufferbloat.net/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=642CBFAE-A182-4D6E-968B-411159CBFD9B@superduper.net \
--to=simon@superduper.net \
--cc=bloat@lists.bufferbloat.net \
--cc=chromatix99@gmail.com \
--cc=david@lang.hm \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox