I just finished reading post in The Register about Google enhancing TCP performance in 12%
by altering 10 lines of code in TCP implementation.
I was a good boy, and even read the the academic paper Google sent for publication.
The paper is not bad. Interesting and very readable, even for the non-TCP expert audience.
This is rare for such an esoteric matter.
Moreover, it looks like the experimental work behind the paper is solid.
12% improvement is a lot. Doing this in 10 lines of code is probably a world record..
But -
Well, all they talk about is a configuration change!!
in geekish one liner i can sum it up in "let's change initcwd from 3/4 to 10"
That's a change of a configuration setting!
The area of fiddling with TCP parameter is far from being an unknown terrain.
Countless papers, thesis papers, Ph.D. dissertations and IETF documents were written about similar ideas.
Google recommendations is also almost as trivial and simplistic as can be.
Now, what do we make of this:
1. I think Google are right. Having 10 segments (assuming MTU of 1500, of course) makes much more sense than 4 or 3.
2. Not having changed the TCP default initcwnd since 2002 sounds like the major stake holders of the networking protocols design/implementation
bodies (IETF, Linux, Microsoft) don't have a mechanism of periodically review and update the internal settings of the protocol stack.
That's silly. These are easy bucks! The installedOSes put there are continuously updated and replaced.
How many machines have not been patched/upgraded/replaced/installed since 2006?
my guess <5% (even <1%).
Had the IETF and similar bodies been periodically review the params, then Vista/7/2008/2008R2/Linux 2.6.18+ already would have that inside.
3. Apparently Google have major interest in making the Internet fast. SPDY is a big step in this direction.
Chrome OS, as a big middleware between Chrome and the underlying Linux serves, to big extent, this purpose.
Wide adoption of tuning of TCP parameters (Google even submitted a memo to the IETF calling to change this parameter)
goes in the same direction.
4. So far - we're all good. not a single bad word about Google. Then, what with the ridiculous boasting about magically touching the antique protocol to a renaissance ?
Pkhh. it's beyond me. Either ignorant journalists, arrogant spokesmen for Google, too many mediator such that things have lost in translation, I don't know.
Google go to the press with very presumptuous claims, that are ultimately just important, yet simple if not trivial recommendation about internal TCP stack parameter settings.
by altering 10 lines of code in TCP implementation.
I was a good boy, and even read the the academic paper Google sent for publication.
The paper is not bad. Interesting and very readable, even for the non-TCP expert audience.
This is rare for such an esoteric matter.
Moreover, it looks like the experimental work behind the paper is solid.
12% improvement is a lot. Doing this in 10 lines of code is probably a world record..
But -
Well, all they talk about is a configuration change!!
in geekish one liner i can sum it up in "let's change initcwd from 3/4 to 10"
That's a change of a configuration setting!
The area of fiddling with TCP parameter is far from being an unknown terrain.
Countless papers, thesis papers, Ph.D. dissertations and IETF documents were written about similar ideas.
Google recommendations is also almost as trivial and simplistic as can be.
Now, what do we make of this:
1. I think Google are right. Having 10 segments (assuming MTU of 1500, of course) makes much more sense than 4 or 3.
2. Not having changed the TCP default initcwnd since 2002 sounds like the major stake holders of the networking protocols design/implementation
bodies (IETF, Linux, Microsoft) don't have a mechanism of periodically review and update the internal settings of the protocol stack.
That's silly. These are easy bucks! The installedOSes put there are continuously updated and replaced.
How many machines have not been patched/upgraded/replaced/installed since 2006?
my guess <5% (even <1%).
Had the IETF and similar bodies been periodically review the params, then Vista/7/2008/2008R2/Linux 2.6.18+ already would have that inside.
3. Apparently Google have major interest in making the Internet fast. SPDY is a big step in this direction.
Chrome OS, as a big middleware between Chrome and the underlying Linux serves, to big extent, this purpose.
Wide adoption of tuning of TCP parameters (Google even submitted a memo to the IETF calling to change this parameter)
goes in the same direction.
4. So far - we're all good. not a single bad word about Google. Then, what with the ridiculous boasting about magically touching the antique protocol to a renaissance ?
Pkhh. it's beyond me. Either ignorant journalists, arrogant spokesmen for Google, too many mediator such that things have lost in translation, I don't know.
Google go to the press with very presumptuous claims, that are ultimately just important, yet simple if not trivial recommendation about internal TCP stack parameter settings.
