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

[Mikael Abrahamsson]

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