On Fri, 31 Jul 2015, [email protected] 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: [email protected] _______________________________________________ Cerowrt-devel mailing list [email protected] https://lists.bufferbloat.net/listinfo/cerowrt-devel
