Slashdot Mirror
Google, Microsoft Cheat On Slow-Start — Should You?
kdawson writes "Software developer and blogger Ben Strong did a little exploring to find out how Google achieves its admirably fast load times. What he discovered is that Google, and to a much greater extent Microsoft, are cheating on the 'slow-start' requirement of RFC-3390. His research indicates that discussion of this practice on the Net is at an early, and somewhat theoretical, stage. Strong concludes with this question: 'What should I do in my app (and what should you do in yours)? Join the arms race or sit on the sidelines and let Google have all the page-load glory?'"
Without cheating, I wouldn't get the first post.
RFC 3390 uses the "MUST" terminology exactly one place: when describing behavior after a packet is lost during the syn/synack. It doesn't use the phrase "MUST NOT" anywhere.
In every other respect slow-start is recommended but optional. Google is in no way breaching the standard by not using it.
Moderating "-1, Disagree" is simple censorship. Have the guts to post your opinion.
...if it wasn't for slow start. Damn you, cwnd!
So kdawson couldn't post this FUD himself? He needed Soulskill to do it for him?
When the competition starts crying you know someone is doing something right. Is it just me or has there been a lot of crying lately
did you forget to take your meds?
This is reliable. It is comaptible with the spec (otherwise it wouldn't be reliable), and it's faster.
I don't think it matters whether Google "cheats" or not. I and they both want me to get the data as quickly as possible. Strict adherence to the guidelines doesn't matter to either of us and doesn't affect anyone else.
I intentionally removed kdawson and timothy from the front page on slashdot just so I wouldn't have to see their ignorant, retarded, not a fucking clue posts ...
Did they realize that no one read their tripe anymore now they have to have someone else approve it for them?
kdawson and timothy are idiots, please give me a way to automatically not see anything that has to do with those two morons. Please.
kdawson is cheating to get around the effort I put on not seeing his crap, MS and Google on the other hand are following the RFC just fine ... if anyone involved in the posting of this story had a clue about what it said or did any sort of actual research than I wouldn't have to rant about it ...
Persistent Volume manager for Kubernetes - https://github.com/dwimsey/openshift-pvmanager
That's been known in the TCP community for decades.
I looked at this back in my RFC 896 days, when TCP was in initial development and I was working on congestion. I introduced the "congestion window" concept and put it in a TCP implementation (3COM's UNET, which predated Berkeley BSD). The question was, what should be the initial size of the congestion window? If it's small, you get "slow start"; if it's large, the sender can blast a big chunk of data at the receiver at start, up to the amount of buffering the receiver is advertising.
I decided back then to start with a big congestion window, because starting with a small one would slow down traffic even when bandwidth was available. One of the big performance issues back then was the time required to FTP a directory across a LAN, where TCP connections were being set up and torn down at a high rate. So startup time mattered. The decision to go with a smaller initial congestion window size came years later, from others. This reflected trends in router design. I wanted routers to have "fair queuing", so that sending lots of packets from one source didn't gain the sender any bandwidth over sending few packets. But routers gained speed faster than RAM costs dropped, and so faster routers couldn't have enough RAM for fair queuing. Today, your "last mile" CISCO router might have fair queuing. Some DOCSIS cable modem termination units have it. But many routers are running Random Early Drop, which is a simple but mediocre approach. (The backbone routers barely queue at all; if they can't forward something fast, they drop it. Network design tries to keep the congestion near the edges, where it can be dealt with.)
Remember, every dropped packet has to be retransmitted. (Too much of that leads to congestion collapse, a term I coined in 1984. That's what the "Nagle algorithm" is about.) In a world with packet-dropping routers, "slow start" makes sense. So that was put into TCP in the late 1980s (by which time I was out of networking.)
However, the RFC-documented slow start algorithm is rather conservative. RFC 2001 says to start at one maximum segment size. Microsoft's implementations in Win95 and later start at two maximum segment sizes. In RFC 3390, from 2002, the limit was raised to 3 or 4 maximum segment sizes. (We used to worry about delaying keystroke echo too much because big FTP packets were tying up the 9600 baud lines too long. We're past that.)
But Google is sending at least 8 segments at start, and Microsoft was observed to be sending 43. Sending 43 packets blind is definitely overdoing it.
I wonder whether they're doing this blindly, or if there's more smarts behind the scenes. If their TCP implementation kept a cache of recent final congestion window sizes by IP address, they could legitimately start off the next connection with the value from the last one. So, having discovered a path that's not dropping big bursts of packets, they could legitimately start fast. If they're just doing it the dumb way, starting fast every time, that's going to choke some part of the net under heavy load.
Slow start and congestion avoidance were designed in the time of unreliable networks. Shouldn't the TCP/IP protocol be rediscussed in the age of fiber networks?
The Third rule of network design, for a moral being, is to consider the moral, ethical, and legal consequences of any atypical changes you make to your behavior.
Why the Third rule?
Because the first rule is to figure out what on earth is going on--not just in theory, but in fact. Code for the OSI model is ugly, perhaps by necessity (it has to be very fast), but it's code that is very, very easy to get wrong. It involves a lot of interacting pieces working on different levels of abstraction with other players that you don't have code control over.
The second rule is to realize when the first rule means that you shouldn't touch the stuff. Google and Microsoft have the engineering competence to mess with it--MSFT even should be messing with it, in terms of looking for ways to improve their behavior in a community-friendly way. Because they write the code that handles a huge portion of connections, and let's face it, TCP/IP just isn't designed for lots of things: AJAX or broadband, for example.
The third rule is to consider the moral and ethical and legal consequences of changes.
Only after at least these three steps should someone make changes that involve connections that go beyond the computers they control.
-- IANAL, this isn't legal advice, and definitely isn't legal advice for you. Also, Squee!
You do realize that if servers on the Internet start ignoring Internet standards (RFCs) as a matter of usual
practice that there is a very good chance the net will, if not grind to a halt, develop instability, the probability
of unreliability, poor performance, isolated unreachable islands etc.
This is a clear case of the tragedy of the commons. Only the general adherence to RFCs and effective
shunning mechanisms have prevented the tragedy from occurring so far.
Where are we going and why are we in a handbasket?
Well, this guy discovered something but wasted time he should have been working on his web app ;)
Has anyone taken a look at whether Google, Microsoft, et al are similarly pushing on the TCP congestion backoff and recovery mechanisms?
First, implement it, and show that it works in practice.
Later, standardize the proven best practices.
Google, ur doin' it rite! :D
"Convictions are more dangerous enemies of truth than lies."
Please, I'd like to use this on our web servers too... :-P
"I love my job, but I hate talking to people like you" (Freddie Mercury)
I'm not getting the blinding fast response time shown in the article at all :(
Google looks up my country via geo-location and feeds me a localised version (tested via the curl method in the article). This takes 0.9 seconds for me. If I directly specify google.co.uk or some other variation, I get a more reasonable 0.3 seconds. But never 85ms. Is the author sitting on a really awesome connection at work? ;)
I understand the theoretical problem with breaking the spec, but since it actually took this guy a packet sniffer to detect the violation, it would seem that, in practice, most (all?) clients out there are perfectly capable of processing this non-standard response. If so, then I don't see a problem, since it really is a de facto standard - and those appear all the time. The best thing they could do then is publish a new RFC to make it part of the spec, and move on.
I suppose now would be a good time to point out that RFC 5681 is the most current specification of the standard for TCP congestion control. Would it be asking too much for people to stay current on the RFC series before they start cracking off about standards compliance?
jhw
There are other protocols such as SCTP intended to address shortcommings of TCP... Yet after all these years nobody seems to care that they even exist. If TCP were as bad as your remarks suggest I would have expected more takers on the alternatives?
You comment TCP is so broken and backwards yet I don't know and you don't mention whats wrong with it?
TCP is a head of line blocking protocol supporting only one active stream per session.
By establishing multiple connections some can still transmit data while other TCP sessions might be idle waiting for acks. It makes a noticable difference in environments with high latency links..not so much anymore for broadband users.
Today the bigger reasons for it are just shortcomings in HTTP and browser technology stacks. If you sent everything in a single stream there is an ordering dependancy that significantly effects load time. For example if you send a large image before sending a style sheet the page loading now needs to wait for the style sheet. You could use more intelligence and huersitics to prioritize but the ideal dependancies are not always easy to resolve, deterministic or knowable a priori. Sending everything at once is low hanging fruit that for the most part works.
Whats the point of even trying? You can't constrain aggregates WRT other applications, computers, access devices..etc so why pretend it makes any difference if it were possible on the TCP session level? In my view the only approach is for the session to be aware of the environment and live as cooperativly as reasonable within its constraints.
I'm concerned with the possibility of judgements slanted by each corporations narrow world views. I prefer open SDOs whos members are comprised of all stake holders take us forward.
When did RFCs official standards at which you could "cheat"?
Consider this "cheating" Google and Microsoft's comments.
Before writing a post like this, you might want to wait a few minutes for the inevitable corrections to the inevitably wrong Slashdot story comes in. A good 50% of the stories on this site are misleading, and probably 25% of those are blatant lies.
Here's a pro-tip: if it says kdawson either as the editor *or* the submitter, it's complete bullshit. I don't think he's ever gotten a story entirely right in this whole career.
Comment of the year
If you type
man ip
You will see that you can set the initial congestion window on a given route using
ip route change initcwnd NUMBER
*Where NUMBER=The maximum initial congestion window (cwnd) size in MSS of a TCP connection. I believe applications may also choose socket options although most of the time it's left to the OS. So go ahead and set it to 10 or whatever.
Cool! Amazing Toys.
Do you always talk in Perl? I'm not taking sides in what seems to be an embarrassingly petty argument, but that post was truly awful to read.
Meta will eat itself
"Ad hominem attack..."
"8 digit registered LUSER ID..."
If you're going to do all the work for me, there's no point in arguing. I'll just apologise for pricking your ego and leave it there.
Meta will eat itself
Yes, 10 has been recommend as the new initial window:
http://tools.ietf.org/html/draft-hkchu-tcpm-initcwnd-01
New things are always on the horizon
I think you meant:
ip route change default via $GW dev eth0 initcwnd 10
Where $GW is your default gateway.
New things are always on the horizon
HTTP only supports one active stream over TCP or SSL/TLS, SPDY is a proposal to allow HTTP over TCP or SSL/TLS to support multiple streams:
http://www.chromium.org/spdy/spdy-whitepaper
I'm guessing only multiple HTTP streams over SSL/TLS will be very backward compatibility with the existing internet.
Thus soon, https (thus SSL/TLS) with the SPDY extension may even be faster to load your webpage than normal HTTP.
New things are always on the horizon