On Wed, 3 Jul 2013, Dave Taht wrote:
Suggestions as to things to test and code to test them welcomed. In
I'm wondering a bit what the shallow buffering depth means to higher-RTT connections. When I advocate bufferbloat solutions I usually get thrown in my face that shallow buffering means around-the-world TCP-connections will behave worse than with a lot of buffers (traditional truth being that you need to be able to buffer RTT*2).
It would be very interesting to see what an added 100ms (<http://stackoverflow.com/questions/614795/simulate-delayed-and-dropped-packets-on-linux>) and some packet loss/PDV would result in. If it still works well, at least it would mean that people concerned about this could go back to rest.
Also, would be interesting to see is Googles proposed QUIC interacts well with the bufferbloat solutions. I imagine it will since it in itself measures RTT and FQ_CODEL is all about controlling delay, so I imagine QUIC will see a quite constant view of the world through FQ_CODEL.
-- Mikael Abrahamsson email: [email protected] _______________________________________________ Cerowrt-devel mailing list [email protected] https://lists.bufferbloat.net/listinfo/cerowrt-devel
