[Cerowrt-devel] [Make-wifi-fast] [tsvwg] Comments on draft-szigeti-tsvwg-ieee-802-11e

[David Lang]

On Fri, 7 Aug 2015, Jonathan Morton wrote:

>> On 7 Aug, 2015, at 15:22, Rich Brown <richb.hanover at gmail.com> wrote:
>> 
>> - At that time, the wifi driver requests packets from fq_codel until a) the 
>> the fq_codel queues are empty, or b) the wifi frame is full. In either case, 
>> the wifi driver sends what it has.
>
> There’s one big flaw with this: if packets are available for multiple 
> destinations, fq_codel will generally give you a variety pack of packets for 
> each of them.  But a wifi TXOP is for a single destination, so only some of 
> the packets would be eligible for the same aggregate frame.
>
> So what’s needed is a way for the wifi driver to tell the queue that it wants 
> packets for the *same* destination as it’s transmitting to.

how about when the queue hands packets to the wifi driver, it hands all packets 
to that same destination, no matter where they are in the queue (up to a max 
size, and the queue may adjust that max size within a range for fairness)

>> - Once the transmit opportunity has come around, it's a matter of 
>> microseconds (I assume) to pull in a wifi frame's worth of packets from 
>> fq_codel
>
> This is hard to guarantee in software in a general-purpose OS.

you really want to have the pckets assembled and ready to go rather than trying 
to pull them at that point.

But what happens right now is that the queue hands packets to the wifi driver, 
then the wifi driver has it's own queues that it uses to gather the packets for 
each destination.

If we can find a way to make it reasonable to short-circuit the wifi driver 
queues by making it efficient to work from the main network queues, we can work 
to eliminate the second layer of queues.



so thinking about the requierments from the driver point of view

It needs to be able to pull a chunk of data to transmit (multple packets), it 
isn't going to know very much ahead of time what speed it's going to use to talk 
to this destination, and this is going to drastically affect how long it takes 
to transmit the bits. so when it grabs data from the queue, it needs to feed 
back to the queue the transmit time for those bits, and the queue uses that 
instead of the count of bits to determine fairness.

The queue will be deciding fairness based on whois behind in their 'fair share' 
of transmit time. So the wifi driver isn't going to know when it asks for the 
net chunk of data to transmit, who it will be going to. So it will need to get 
the destination, see the speed to use to that destination, pass the speed to 
a calculation for how much data to send, then grab that much data (rounded to a 
packet boundry)



Is this sort of logic useful anywhere other than in wifi?

Wifi is the only place I know of where the transmit bit rate is going to vary 
depending on the next hop address.

I know that the inter-packet gap defined for ethernet can amount to a large 
percentage of bandwidth at high speeds. Can multiple packets to the same 
destination be combined with a smaller gap between packets? (the gap timing was 
based on the speed-of-light time needed for the entire shared bus to quiece back 
in the 10mb half-duplex hub days). If so, then there's value in bundling packets 
to the same destination together.


If this sort of logic is not useful anywhere other than in wifi, maby the right 
answer is to have a way of short-circuiting the main OS queues and have a wifi 
specific queue that can directly look at the per-client speeds/etc when deciding 
who goes next and how much to dispatch?

David Lang