2 ms·

network latency rather than bandwidth had a greater affect on the speed of browsing This has been well-known for a while. I present to you the TCP throughput e

by shaddi 16y ago

network latency rather than bandwidth had a greater affect on the speed of browsing This has been well-known for a while. I present to you the TCP throughput equation: http://www.apps.ietf.org/rfc/rfc3448.html#sec-3.1 http://www.apps.ietf.org/rfc/rfc3448.html#sec-3.1 The fundamental reason for this result is that the rate that TCP's congestion control algorithm increases the congestion window is tied to round trip time. Congestion window determines how many packets can be "in the air" at any given time, and starts from 1-3 packets in modern OS's. Moreover, packet loss dramatically reduces TCP performance, and this can happen whenever traffic traverses a congested router along its path: once the router queue is full, packets get dropped, and your congestion window is cut in half and grows slowly afterwards. It might be surprising to some, but the effect of queueing delays can often dominate the effects of propagation delays due to the physical distance that a packet has to traverse. I know this type of measurement study has been done numerous times; I'm blanking on more recent ones but I know for instance the Rocketfuel project [1] from 2002 did perform large-scale Internet measurements that included link latencies from various vantage points on the network. [1] http://www.cs.washington.edu/research/networking/rocketfuel/ http://www.cs.washington.edu/research/networking/rocketfuel/

sh1mmer 16y ago
John Rauser did an awesome session on Slow Start at Velocity this year. Steve did an awesome write up (http://www.stevesouders.com/blog/2010/07/13/velocity-tcp-and-the-lower-bound-of-web-performance/ http://www.stevesouders.com/blog/2010/07/13/velocity-tcp-and...) Google have a really good (in my opinion) initiative to aggressively open up the initial window. Their suggestion is to move from from 4 initial packets to 10. Really though I think there needs to be some process to assess the right size of the "magic numbers" in TCP periodically without having to redraft/rewrite whole RFCs.
- shaddi 16y ago
  I mean, in reality TCP congestion control just isn't designed for today's Internet. We live in a world of huge bandwidth-delay products and short connections, the opposite of what was the case when Van Jacobsen proposed it almost 30 years ago (to be fair, it's pretty damn impressive that his basic idea has prevented congestion collapse from recurring despite decades' worth of network evolution). Google's position on window size definitely makes sense in that regard but the very existence of "magic numbers" would suggest that there's room for some fundamental improvement. I think there are some really great ideas in the RCP project [1], which basically uses some information provided by routers to allow all flows to achieve their maximum steady-state fair-share allocation within one RTT. Even if it doesn't see the light of day on the broader Internet, I think it has excellent potential for datacenter networks. That's article you linked is a really great summary of this issue; thanks for sharing that with me. [1] http://yuba.stanford.edu/rcp/ http://yuba.stanford.edu/rcp/

by shaddi 16y ago

sh1mmer 16y ago

John Rauser did an awesome session on Slow Start at Velocity this year. Steve did an awesome write up (http://www.stevesouders.com/blog/2010/07/13/velocity-tcp-and-the-lower-bound-of-web-performance/ http://www.stevesouders.com/blog/2010/07/13/velocity-tcp-and...) Google have a really good (in my opinion) initiative to aggressively open up the initial window. Their suggestion is to move from from 4 initial packets to 10. Really though I think there needs to be some process to assess the right size of the "magic numbers" in TCP periodically without having to redraft/rewrite whole RFCs.

shaddi 16y ago
I mean, in reality TCP congestion control just isn't designed for today's Internet. We live in a world of huge bandwidth-delay products and short connections, the opposite of what was the case when Van Jacobsen proposed it almost 30 years ago (to be fair, it's pretty damn impressive that his basic idea has prevented congestion collapse from recurring despite decades' worth of network evolution). Google's position on window size definitely makes sense in that regard but the very existence of "magic numbers" would suggest that there's room for some fundamental improvement. I think there are some really great ideas in the RCP project [1], which basically uses some information provided by routers to allow all flows to achieve their maximum steady-state fair-share allocation within one RTT. Even if it doesn't see the light of day on the broader Internet, I think it has excellent potential for datacenter networks. That's article you linked is a really great summary of this issue; thanks for sharing that with me. [1] http://yuba.stanford.edu/rcp/ http://yuba.stanford.edu/rcp/