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

[Rich Brown]

Here's where I display my massive ignorance of how Linux networking/drivers work. This feels like a place to apply the Nagle algorithm... Maybe everyone already understands this, but, isn't this scheme something like what we're looking for? 

- Initial state: all queues (fq_codel and wifi driver) are empty.

- A packet arrives at fq_codel, it's placed in the proper queue for its flow, and the wifi driver gets tapped on the shoulder that there's something to send.

- Sometime later, the wifi driver has bid for and received an opportunity to transmit. 

- 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.

- If more packets remain in the fq_codel queue(s), the wifi driver gets tapped on the shoulder again to start another transmission. 

Good Attributes:

- The wifi driver has no "queued packets" per se - only those it pulled from fq_codel for immediate transmission.

- 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

- A singleton packet (e.g., one widely separated in time from all the other traffic) gets sent as soon as it can, without waiting in hopes "that more traffic will arrive" This leaves the wifi utilization unchanged (since the singleton packet would have to be sent anyway), but avoids the delay for that particular flow.

Downsides:

- Most likely, "It doesn't work that way". :-)

- The wifi driver would probably have to queue the single last-retrieved packet from fq_codel when it doesn't fit in the wifi frame. But this would be an immediate signal to bid for another transmit opportunity.

Rich


On Aug 7, 2015, at 4:28 AM, Mikael Abrahamsson <swmike at swm.pp.se> wrote:

> On Fri, 31 Jul 2015, dpreed at reed.com wrote:
> 
>> So ignore the hardware folks who can't think about the fact that their link is embedded in a context that the link doesn't understand at all! Don't let them convince you to queue things, especially lower priority things....  instead push congestion back to the source!!!
> 
> So while I think you have a point, I don't see how this can be achieved (at most 1 packet in the queue) on something like wifi where there are retransmits and an onloaded link can have between a few ms and all of a sudden have 50-100ms of delay, and then get back to a few ms again). If you screetch to a halt when you get this "congestion" (that isn't even caused by traffic but by RF environment), if you have packets in the buffer and feedback the sender to stop, there after the RF problem has past, buffer is emptied, but now basically all traffic has screetched to a halt.
> 
> So a compromise must be achieved somewhere, so that 300ms RTT flows get decent performance without affecting realtime flows. I don't understand how both goals of low delay/no buffering and decent high-RTT flow speed, can work without some kind of scheme where different flows are put in different queues.
> 
> -- 
> Mikael Abrahamsson    email: swmike at swm.pp.se
> _______________________________________________
> Cerowrt-devel mailing list
> Cerowrt-devel at lists.bufferbloat.net
> https://lists.bufferbloat.net/listinfo/cerowrt-devel