On Thu, Jul 12, 2012 at 9:46 AM, Eric Dumazet <[email protected]> wrote: > On Thu, 2012-07-12 at 09:33 -0400, John Heffner wrote: >> One general question: why a per-connection limit? I haven't been >> following the bufferbloat conversation closely so I may have missed >> some of the conversation. But it seems that multiple connections will >> still cause longer queue times. > > We already have a per-device limit, in qdisc. > > If you want to monitor several tcp sessions, I urge you use a controller > for that. Like codel or fq_codel. > > Experiments show that limiting to two TSO packets in qdisc per tcp flow > is enough to stop insane qdisc queueing, without impact on throughput > for people wanting fast tcp sessions. > > Thats not solving the more general problem of having 1000 competing > flows.
Right, AQM (and probably some modifications to the congestion control) is the more general solution. I guess I'm just trying to justify in my mind that the case of a small number of local connections is worth handling in this special way. It seems like a generally reasonable thing, but it's definitely not a general solution to minimizing latency. One thing worth noting: on a system routing traffic, local connections may be at a disadvantage relative to connections being forwarded, sharing the same interface queue, if that queue is the bottleneck. Architecturally, the inconsistency between a local queue and a queue one hop away bothers me a bit, but it's something I can learn to live with if it really does improve a common case significantly. ;-) Thanks, -John _______________________________________________ Codel mailing list [email protected] https://lists.bufferbloat.net/listinfo/codel
