Slashdot Mirror

← Back to Stories (view on slashdot.org)

Google, Microsoft Cheat On Slow-Start — Should You?

Posted by Soulskill on from the reply-hazy-ask-again dept.

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

9 of 123 comments (clear)

  1. Misread the RFC by Spazmania · · Score: 5, Informative

    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.
    1. Re:Misread the RFC by H0p313ss · · Score: 4, Informative

      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.

      --
      XML is a known as a key material required to create SMD: Software of Mass Destruction
    2. Re:Misread the RFC by Anonymous Coward · · Score: 3, Informative

      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.

    3. Re:Misread the RFC by Anonymous Coward · · Score: 3, Informative

      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.

    4. Re:Misread the RFC by Anonymous Coward · · Score: 3, Informative

      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.

    5. Re:Misread the RFC by fluffy99 · · Score: 5, Informative

      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

  2. Re:I do. by Jello+B. · · Score: 3, Informative

    not even close, sorry

  3. Re:This is well known to a small community by egoots · · Score: 5, Informative

    Are you a wizard?

    No, he's John Nagle.

  4. Re:I do. by Tubal-Cain · · Score: 3, Informative

    Not even the first one this week.