| |||||||||||||
Network transmit queue limitsNetwork transmit queue limitsPosted Aug 15, 2011 13:45 UTC (Mon) by corbet (editor, #1)In reply to: Network transmit queue limits by jch Parent article: Network transmit queue limits You're talking about the congestion window change? That's very much about latency. It lets pages load more quickly without the need to open lots of independent connections; the associated documentation is very clear on the motivation.
(Log in to post comments)
Network transmit queue limits Posted Aug 16, 2011 21:45 UTC (Tue) by jch (guest, #51929) [Link]
It does cause more packets to be queued, which increases queue length and hence network-layer latency. OTOH, it does cause packets to be sent more faster, which I guess can be described as reducing application-layer latency (the time needed to load a page).
That's just the kind of tricky trade-off that the bufferbloat project is struggling with.
--jch
Network transmit queue limits Posted Aug 17, 2011 16:02 UTC (Wed) by butlerm (subscriber, #13312) [Link]
I wouldn't worry too much about an initial congestion window of ten packets. On a five mbps bottleneck link with 1500 byte packets that is only about 2.4 ms of queuing delay. The queuing delay due to ack compression as the congestion window increases is probably going to be considerably higher than that.
There seems to me to be only two good ways to solve the queuing latency problem, beyond simply reducing queuing limits on bottleneck routers and interfaces to reasonable sizes. One is the widespread deployment of packet pacing, which is difficult to do well without hardware support, and which has other challenges. The other is fair (flow specific) queuing at every bottleneck router or interface. The latter seems much more practical to me.
|
|||||||||||||