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?'"

Comments

Misread the RFC

[Spazmania]

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.

Re:Misread the RFC

[H0p313ss]

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.

I just logged in to say exactly the same thing. Not implementing an optional variant is not cheating. Nothing to see, move along.

Re:Misread the RFC

[Anonymous Coward]

RFC 3390 defines the upper bound for the initial window to be min (4*MSS, max (2*MSS, 4380 bytes)), so it doesn't need to use "MUST NOT" to forbid larger initial window sizes.

Re:Misread the RFC

[Anonymous Coward]

From the RFC.
      This document obsoletes [RFC2414] and updates [RFC2581] and specifies
      an increase in the permitted upper bound for TCP's initial window
      from one or two segment(s) to between two and four segments.

So it was officially increased in 2002.
Maybe back then an initial window 2 - 4 segments seemed reasonable.
Maybe the official standard is due for an update.
For some reason I am not indignant about this news.

Re:Misread the RFC

[Anonymous Coward]

Indeed the modification is optional. It explicitly says so in the RFC. However, without the modification an even smaller initial window is set by the previous definition, which comes with all the MUSTs and MUST NOTs you can throw at an implementer.

Re:Misread the RFC

[Anonymous Coward]

Yes, that means you're free to use the (smaller) limit from the older RFC or the new (larger) one from RFC3390. The authors expect most implementations to use the new one, which would allow Google to send 3 packets without waiting for ACKs. Google sends up to 9.

Re:Misread the RFC

[Anonymous Coward]

Do you always have other people do your homework?

From RFC3390 (that's the one we're discussing):
"This document obsoletes [RFC2414] and updates [RFC2581] and specifies
  an increase in the permitted upper bound for TCP's initial window
  from one or two segment(s) to between two and four segments."

I'd start with the one which RFC3390 updates.

Re:Misread the RFC

[fluffy99]

Not sure why you got modded informative since the original poster and your "me-too" are both wrong . RFC 3390 is an extension to RFC2581. RFC 3390 says you MAY use an IW of up to 4 segments. If you don't use this option, you fall under RFC2581 which says the IW MUST be less than or equal to 2 segments.

http://www.rfc-editor.org/rfc/rfc3390.txt
http://www.rfc-editor.org/rfc/rfc2581.txt

Re:Misread the RFC

[fluffy99]

Learn how to use Google man!

http://www.rfc-editor.org/rfc/rfc3390.txt [rfc-editor.org]
http://www.rfc-editor.org/rfc/rfc2581.txt [rfc-editor.org]

Re:Misread the RFC

[James Youngman]

Indeed, Google already published a paper describing their approach:
https://www.google.com/url?sa=t&source=web&cd=1&ved=0CA8QFjAA&url=http%3A%2F%2Fcode.google.com%2Fspeed%2Farticles%2Ftcp_initcwnd_paper.pdf&ei=xUciTKhpmOiUB_HL8bAP&usg=AFQjCNET-zahhIxtRlXe28xn_8QSXXLx6A&sig2=0mlyaOW1btaj7hUjlL1Opw

Re:I do.

[Jello B.]

not even close, sorry

Re:No Cheating is the Third Rule

[pthisis]

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.

TCP/IP predates the OSI model and conflicts with it in some areas; discussion of the complexities of code targeting OSI isn't directly applicable to TCP/IP implementations, though many similarities exist.

Indeed, the fact that TCP/IP has fewer layers is often cited as one reason that it succeeded (coding an implementation of TCP/IP therefore being less complex than coding a fully abstracted 7-layer OSI implementation).

Re:This is well known to a small community

[egoots]

Are you a wizard?

No, he's John Nagle.

RFC 5681

[j h woodyatt]

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?

Re:I do.

[Tubal-Cain]

Not even the first one this week.