User: Password:
|
|
Subscribe / Log in / New account

Network transmit queue limits

Network transmit queue limits

Posted Aug 15, 2011 11:43 UTC (Mon) by jch (guest, #51929)
Parent article: Network transmit queue limits

> So it is not surprising that we have seen various latency-reducing changes from Google, including the increase in the initial congestion window

This doesn't decrease latency -- it increases throughput for short-lived connections ("mice"). Quite the opposite, in underprovisioned networks with a lot of mice it could increase latency dramatically.

--jch


(Log in to post comments)

Network transmit queue limits

Posted Aug 15, 2011 13:45 UTC (Mon) by corbet (editor, #1) [Link]

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.

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 (guest, #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.


Copyright © 2017, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds