No, no it's not. This has nothing to do with network neutrality; it's a purely server-side change/fix. Not only that, they're benefiting users without requiring anyone else to change while they wait for standards bodies to catch up. This is a similar scenario to HTML5 video, and distinctly more clear-cut than e.g. '802.11n draft' wireless routers in my opinion.
Net neutrality is not the only way to privilege your flows on the Internet: There's nothing to stop me from writing a crude application-layer protocol atop UDP that implements reliability but not congestion control. (You maybe had to implement something like this for your networking class in school; otherwise you could start with a protocol like DCCP.) If I were to use that to send data as fast as I could to some remote computer, I could be sending more data than the smallest-capacity link could handle. Other TCP/IP connections sharing that link would detect data loss and thus reduce the amount of data they put in transit, but my protocol wouldn't have to. I can monopolize that link.
So assuming your physical layer is tin cans and string, what he's arguing is that if you have a link with a capacity of 12 segments, then data from Google will use 10 of them and a client will never expand its outstanding data beyond 2 segments. If both used vanilla TCP/IP, they should share the link evenly.
Of course, speed is a critical factor for Google. Android by default uses TCP Westwood+.
It's been six years since I tinkered with TCP/IP and really focused on networking, so someone please correct me if I'm wrong >_<
He's not showing any evidence that Google wouldn't back off to a smaller window in the face of packet loss; he's just saying their initial window is 9 segments. Once one of those 10 segments in your tin-can router falls out of its receive buffer, Google will be down to 9 and the other guys get up to 3, and packet loss will random-walk toward fairness.
Right? I've never tinkered with this stuff, so please correct me if I'm wrong.
Microsoft on the other hand should really use slow-start.
I think it's difficult to argue that the profile of the underlying network hasn't changed since the last time an RFC was standardized on this issue. The problem is revving the magic numbers in the standards periodically to reflect changes in topology.
While you can say that Google should stick to the standard, unlike other net neutrality issues this isn't a change available only to a few large companies. Anyone with control of their stack can make this configuration.
The issue in net neutrality is to ensure that changes which are economically feasible for only a small group of companies are not enacted so that they cannot form a defacto monopoly.
The question, then, is whether this change is significant enough to increase internet congestion (and therefore packet loss for others). This is a subject of heated debate at the moment.
I agree with you, but whenever I see something like this the back of my mind always chimes in with "famous last words".
Edit:
I wished, google already sent the patch in May for this:
http://www.amailbox.org/mailarchive/linux-netdev/2010/5/26/6...
Nice!
Unless you are serving static content only (in which case you are hardly creating an "app"), the milliseconds you might save with TCP-level optimizations are peanuts in comparison to the multiple seconds your database and computations will be requiring.
If your database and computations are requiring multiple seconds on a normal web page, you have serious user experience problems. When you're under 140ms, it feels like the response is happening at the same time as the request (Dabrowski and Munson weren't able to reproduce the old 50- or 100-millisecond rule of thumb in what sounds to me like a poorly-controlled experiment; http://books.google.com/books?id=aU0MR-MA-BMC&pg=PA292&#...). Increasing Google search page render time from 400ms to 900ms dropped traffic by 20%, according to Marissa Mayer (http://glinden.blogspot.com/2006/11/marissa-mayer-at-web-20....). Traditional OLTP systems tried to keep response times under one second; beyond a second, people start to get frustrated and wonder if something is broken.
So, for a normal application, the milliseconds you might save by optimizing your database and computations are peanuts in comparison to the second or more that TCP-level optimizations could save you.
It sounds rather poorly-controlled to me too.
They mention that they didn't account for the time from mouse-down to mouse-release. Seriously? Here is a program that can measure that difference: http://www.daimi.au.dk/~sandmann/click.py. It uses GTK+ so you'll probably need Linux to run it. For me, the delay seems to be around 30 ms. They also don't mention the framerate of the screen or whether they controlled for that. On a 60Hz monitor there is a delay of 17ms between frames.
Both 17 and 30 ms are huge numbers if you are measuring intervals on the order of 100ms.
Then there is the question of what you consciously perceive vs. what you subconsciously perceive. It would surprise me if you couldn't measure a difference even in cases where the subjects didn't notice anything themselves.
Finally, we can definitely reject the idea that latencies below 100 ms never matter: there is an obvious difference between a 10 fps animation and a 60 fps one.
This is almost always the case when I think "this website is slow", though. When HN is slow, it's not because of some added network latency, but because something is making HN take 3 seconds to serve up my "threads" page, or 2 seconds to successfully post my comment. Same with "reddit is slow", or "this Wordpress blog is taking forever to load" or "Twitter spins the 'working' icon for 2 seconds when I click on that 'retweets' thing in the sidebar before returning anything". Those things are really common in my experience, and those rather than network round-trip times are by far the biggest and most annoying slowdowns, at least in my browsing.
net.inet.tcp.local_slowstart_flightsize: 4 net.inet.tcp.slowstart_flightsize: 1
Also useful: http://spatula.net/blog/2007/04/freebsd-network-performance-...
According to my own observations, the first 30Ko of my pages seem to be transfered faster then the next 30ko. It is not until much more is sent that the average throughput eventually get up to what it was during the first 30ko.
This is definitely weird.
Note: I am using Ubuntu on EC2 hosted VMs.
As a result, for as much as I can, I try to keep the size of my content below 30ko, using multiple concurrent HTTP requests.
I believe this is related to "slow-start" being pessimistic.
Unfortunately, "slow-start" is not configurable on Linux and I don't feel confident enough to go with some kernel level patch...
Any clue?
http://ec2-downloads.s3.amazonaws.com/user_specified_kernels...
This topic was covered really well by Amazon's John Rauser at Velocity Conf: http://velocityconf.com/velocity2010/public/schedule/detail/...
To address the points in the conclusion:
1. Fast is good. Fast is also profit.
2. The net-neutrality argument here is totally bogus, anyone that knows how can up their slow-start window today if they choose to. There doesn't really have anything to do with traffic shaping.
3. Google have been using their usual data driven approach to support their proposal for IETF. We need a lot more of that. It's great. The only way we can really find out how the Internet in general will react to changes like this is to test them in some real world environment.
4. I agree, slow-start is a good algorithm with a very valid purpose. The real problem here is that the magic numbers powering it aren't being kept inline with changes to connectivity technology and increases in consumer/commercial bandwidth.
While it's not that big a deal if your users are local to you, if they're on a different continent each extra roundtrip can easily add 100ms.
I used to do TCP/IP tuning for low latency trading applications (sometimes you need to use a third party data protocol so can't just use UDP), this sort of stuff used to bite us all the time.
If latency is important it is worth sitting down with tcpdump and seeing how your website loads (i.e how many packets, how many acks, etc.) as often there are ways of tweaking connection setting (either via socket options or kernel settings) that can result in higher performance.
(Try using tcp_slow_start_after_idle if you're using a recent linux kernel; this won't give you a bigger initial window, but it means once your window size has grown it won't get reset straight away if you have a gap between data sends)
I tried repeating the experiment. I'm in Sweden, so, annoyingly, a request to google.com redirects to google.se. If I send my request directly to google.se, I get 9k response in 130ms and the initial window looks like 4 to me, i.e. I can't see anything unexpected happening.
I then tried repeating on Amazon EC2. I can't see anything unexpected there either, but the RTT from EC2 to google is only about 3ms, which means I can't assume that the ACKS don't get there.
(The original article author looks at how long the initial 3-way handshake takes and then assumes that all packets take that long, or, probably, half as long, i.e. he assumes that ACKS sent up to one RTT before a packet from google can't have arrived at google in time to affect that packet)
Can anyone else reproduce the experiment?
Other ideas: repeat from Sweden, but send a cookie so that I really get google.com. Repeat from EC2, but make sure I never send any ACKs after the three-way handshake. I'm not curious enough to do the latter, it's a fair bit of work.
http://www.yottaa.com/url/4be004065df8ca5a730001fb/reachabil...
Isn't part of that just the network latency? Based on the timestamps for the SYN and SYN-ACK it looks like a RTT of about 16ms.
EDIT: Nevermind.
Request was sent by the client at 00.017437
Request ACK was received by the client at 00.037139
RTT of about 20ms, so the request was received by the server around 00.027
First packet of the response was received by the client at 00.067151
67-27=40. Assuming a latency of 10ms it took 30ms to generate the request.
http://osdir.com/ml/mozilla.devel.netlib/2003-01/msg00018.ht...
http://sites.google.com/a/chromium.org/dev/spdy/An_Argument_...
ip route change default via x.x.x.x dev eth0 initcwnd 6
but please test thoroughly if trying this.
