1. As a taxpayer, I’m on the hook for the bill.
2. Politicians simply can’t resist giving unions money in exchange for votes.

I apologize to the firefighters, police officers, and teachers.  Your jobs are extremely important.  But we can’t afford your unions, and we need your help to bust them apart.  Unions are the same cancer which bankrupted America’s once-largest-company, General Motors.  Why do we let this cancer invade our state?  (Oh yeah, Jerry Brown did it – so don’t vote for him now)

Shedlock puts it well:

In the case of public unions, if politicians strike a bad deal, taxpayers foot the bill. In the case of private corporations, if management strikes a bad deal, the company goes bankrupt, shareholders take a hit, or the jobs move elsewhere, as soon as the contract is up.

If you aren’t convinced, here are some articles to read:

Here’s The Real Problem With Labor Unions

The Beholden State

Plundering California

Public-sector unions bankrupting America

Chrome turns 2 today

That’s 6 stable releases in 2 years.  Not too bad.

I can’t believe I’ve been working on this project for 4 years now.  It’s entirely too fun.

He’s right about America’s business-unfriendly policies and that Obama is making them worse.  This is important stuff – once the jobs are gone, it’s really hard to get them back. 

Regarding current economic policy, Otellini said, “I think this group does not understand what it takes to create jobs.  And I think they’re flummoxed by their experiment in Keynesian economics not working.”

Today, we view the web as two protocols:

• HTTP:  The protocol of the web
• HTTPS: The secure version of HTTP.  Cool!

But we should think of it like this:

• HTTPS: The protocol of the web
• HTTP: The insecure version of HTTPS.  Yikes!

We shouldn’t feel safe when we use https.  We should feel unsafe when we use http.

Our vantage point is backwards because we started with the notion that security is an “add on”.  In today’s hostile networking environment, nothing could be further from the truth.  Security is not a feature, but a requirement.  Offering an “insecure” version for those that want to play risky should be the optional feature.  This just becomes more true when you think of the fact that new protocols will be in use 10 years from now…

To understand the problem, you first need to fully understand how local unions have bankrupted the states.  This has hit California particularly hard over the past 30 years, but the same drama is playing out in states across the country.  For the full details, go read this article to understand how Jerry Brown enabled public service workers in California to unionize, and how ever since then, California has fallen from grace.

At this point, the Unions have tapped out the states.  In the past, they’ve always been able to squeeze a little more money out of California.  But California has been bled dry.

Recognizing that they’ve exhausted local money, the massive, cash-rich unions are turning to their only available savior:  the federal government.  Unfortunately, Obama and Pelosi are too clueless to know what is happening.

It’s sad to hear this – but it is true.  We pay our public workers too much.  The only solution is to cut pay or to cut workers.  Federal bailouts will not cure the disease.  We need to eliminate unions from our public jobs and start anew.

Marc’s blog is dead

As far back as I can see, all Marc’s posts are just advertisements for Ben’s blog.  Ben’s a smart guy, who I respect a lot, for a whole bunch of reasons.  And he probably writes better than Marc does by a mile.  But his blog is so droll!  I can never get through the first paragraph or so without falling asleep!  It’s a compilation of self-help articles for entrepreneurs.  Blech!

Marc – write!  Don’t get our hopes up with this boring Management-101 crap from Ben!  Hmm… wonder what he’ll say about my crappy blog…

The answer is simple:  users want it.

But how did we get here anyway?
If I told you that I was building a house with no locks, surely you’d ask me to install locks.  Then, if I grumpily installed a lock only on the front door, you’d tell me to go install locks on all the doors.  But this is essentially the web we have today.  When you’re using TLS, nobody can get through your front door.  But when you’re not using TLS, potential attackers can easily see exactly what you’re doing on every website you visit.  How is it that we’ve built a house without locks?

When the web was invented in the early 1990’s, there was little need for locks.  It was about sharing information, not purchasing your new TV or sending your medical information to your doctor.  And because it wasn’t a critical means of communication, would-be eavesdroppers would rather tap your phone than tap your Internet.

Netscape, recognizing the need for security on the web to facilitate e-commerce, invented SSL (the predecessor to TLS).  At that time, SSL was computationally expensive and algorithmically unproven.  Forcing everything to run over SSL then would have been impractical.  Instead, two protocols were used, https for data exchanges which were critically sensitive, and http for everything else.  It worked.

Since that time, the computational overhead of TLS has dropped by orders of magnitude, and the protocol has held up to algorithmic scrutiny.  At the same time, the web has grown massively, evolving from a system designed for sharing of ideas into a system which carries our most sensitive and personal secrets.  But despite that, the security of our communications has not changed much.  Don’t get me wrong – it’s not all bad.  The most critical information exchanged with our banks and online purchases is usually secured by using TLS, which is great.  And on some sites, email is secure too.  But the majority of web traffic is still sent insecurely, using HTTP.

Users have grown accustomed to security problems on the net which are far worse than the lack of protocol security, and the need for protection has been relatively low.  But as our lives move from physical to digital, the desire of hackers, governments, and the otherwise unscrupulous grows massively too.

So, from a user’s perspective, instead of asking the question, why does SPDY require encryption and authentication, a better question would be to ask, why not?

What Does TLS Do?
TLS, which is most commonly used by users when they go to a site using a https:// URL, offers two basic features: server authentication and data encryption.

Server authentication is a mechanism where the client can know that a site is trusted to be who the site claims to be.  For example, when you visit http://www.bankofamerica.com/, TLS uses a system of known trust points to validate that this site really is Bank of America, according to a service that your browser has chosen to trust because it complies with a detailed set of specific security practices.  Yeah, it’s complex, but the complexity is hidden from the user.

Data encryption is what prevents others from reading the data that you send over the Internet.

The Argument For Maintained Insecurity
At this point, I think I’ve heard all the arguments against TLS.  Some are valid, and some are not.  But we can overcome all of them.

Invalid Argument #1:  Certificates Are Costly And Too Hard to Deploy
Certificates are a critical element of trust for implementing server authentication within TLS.  Any site wishing to use TLS must get a certificate so that they can prove ownership of a site.  Verifying your identity is a manual, offline, and usually time consuming process.  So typically the companies offering these service charge fees to do so.

The cost of a certificate used to be really high – even over $1000.  But these days, certificates can be surprisingly cheap, sometimes less than $10 (or even for free).   At this cost, it is insignificant.

Despite the low cost, maintaining a certificate on a website is difficult. Server administrators must take precautions to protect their identity, and getting the right keys and certificates to the right servers is time consuming.

But in the end, this is not an argument for the user.  This is an argument for a website that wants to save a relatively small amount of money.  User security is more important than that.

Invalid Argument #2:  It’s Just a Youtube Video, We Don’t Need To Secure It
Some content is so public, that many people believe that it doesn’t need to be secured, and this is partially true.  For example, I really don’t care if someone sees the traffic I sent to Facebook today, because I’m posting that data publicly on the web already.  It’s obvious.

But the problem is that when we offer two modes of communication, one secure and one not secure, we punt the problem to the user:  “Do I need to send this securely?”  Even if the user did know the answer to that question, and most users don’t, what one user may consider public information may be very sensitive to another.  The only way to solve the problem for everyone is to always send data securely so that users don’t need to disambiguate.

Invalid Argument #3: Schools and Families Can’t Filter With TLS
Earlier this year, Google enabled a new feature, Encrypted Web Search.  This feature didn’t force all communications to use TLS, it simply allowed the users to choose it if they wanted to.  Unfortunately, this feature rollout was matched with cries from schools that they could no longer enforce content filtering for their students, which they are required to do by law.

Side note:  Its ironic that Google is often criticized by our governments for not being sensitive enough about privacy.  However in this case, when Google rolled out a feature to enhance privacy, that same government complained that Google is preventing censorship of our children.  But, that’s politics!

Seriously, schools have a legitimate need here.  They want to protect children from adult material, and they have bought solutions to this problem from many vendors.  But unfortunately, most of those solutions leverage the fact that the web is insecure to implement the filtering!  If we encrypt the web, these filters no longer work, and that is a problem for schools.  It should be noted as well  that these solutions already break when kids at school use SSL proxies (such as this one, or this one, or this one).  But the filters don’t have to be perfect, so these problems are overlooked.  The filtering vendors are in a constant arms race with services which attempt to circumvent the filters.

I really do sympathize with schools, and nobody wants to levy a costly solution on our already cash strapped schools.  But filtering can be solved even in the presence of encryption; it is just a little harder. Many solutions exist, and we need to move the filtering to be certificate aware.

It doesn’t make sense to sacrifice the security of the entire web so that we can continue to enable cheap filtering in schools today.

Invalid Argument #4:  Debugging The Web Is More Difficult
A natural consequence of security is that you can’t read the communications between the clients and servers easily.  For web developers, this can make it more difficult to find bugs.  Yes, it’s true.  Debugging is still possible, it is just harder.  But developer laziness is not a good reason to keep the internet insecure.

Invalid Argument #5: Political Backlash
Some governments are pretty adamant about their need to filter the net, and they aggressively  filter using complicated techniques.  If the web attempts to move to an all-encrypted protocol, these governments may decide to ban the protocol altogether.  Yeah, I guess that is true.  At some point, the citizens might want to revolt. I’m lucky I don’t live there, but that’s not a good reason why other countries can’t choose privacy.

Invalid Argument #6:  Existing Servers At Capacity Will Break
Some websites today are already running their servers at full capacity.  If we add security to the protocol, which requires even 1% more server resources, these sites could get slow.

While this is probably a true statement, it’s really not the user’s problem.  I don’t see this as a compelling reason to not improve the security of the web.

Invalid Argument #7: Features of Transparent Proxies
Because the web is insecure today, it is possible for network operators to install transparent proxies which inspect the insecure traffic and change it.  Sometimes these proxies do good things, like scan for viruses and malware.  But other times, these proxies do bad things, such as turn off compression.

From experience, we know that there are a lot of problems with transparent proxies.  And these proxies are generally considered to be an obstacle for protocol evolution on the internet.  For instance, HTTP’s pipelining is currently disabled in all browsers largely because proxies make it impossible to deploy.

Enabling security on the web does not prevent the anti-virus and anti-malware “good” proxies.  It just means they have to be explicit.  But turning on security does prevent the proxies which intentionally or inadvertently break the protocol.

Ok – so that is the list of what I consider invalid arguments.  But there are a couple of valid arguments too.

Valid Argument #1: TLS is Too Slow!
It’s true.  TLS is too slow.  This is in part because TLS is used so rarely that nobody has bothered to optimize it, and in part because it is difficult to change.  The net result is that secure communications are slower than insecure communications.  This will probably always be true, but doesn’t mean we can’t solve the problem enough to make it insignificant.

To understand the problem, we need to recognize there are 4 parts to TLS performance:
  a) The round-trip-times of the TLS authentication handshake
  b) The CPU cost of the PKI operations during the handshake
  c) The additional CPU to encrypt data being transferred
  d) The additional bandwidth due to TLS record overhead

a) The additional round-trips of TLS are real and need to be addressed.  Today, the first connection to a site requires 2 round-trips for server authentication, and subsequent connections require 1 round-trip.  Adam Langley has proposed a protocol change which reduces these to 0 round-trips (more details here).  So for the sites you visit regularly, TLS will no longer incur any extra round trips.

b) The cost of PKI operations these days is super cheap.  While these complex math computations took hundreds of milliseconds in the mid-1990’s, faster processor speeds make them take nanoseconds today. With optional hardware offloading, this is just not a problem.

c) Many people assume that bulk-data encryption is expensive.  This is not true; the most common bulk encryption used with TLS today is the RC-4 cipher.   RC-4 is extremely cheap computationally, and we’ve measured it has no additional latency costs when compared to the NULL cipher.  Other encryption algorithms can have small costs (such as AES), but they’re still quite fast and you don’t have to use them.

d) We’ve measured SSL using ~3% more bandwidth than non-SSL. That is a relatively low overhead number, but it does add a non-trivial amount of latency.  For a 320KB web page, 3% more data can add 30-80ms to the web page load time.  Fortunately, bandwidth speeds continue to rise, and because of this, we don’t see the 3% overhead as excessive.

Overall, we believe (b) and (c) are non problems.  We believe we can solve most of (a), and that (d) is an acceptable cost, mitigated by bandwidth improvements over time.

Valid Argument #2: Caching Servers Don’t Work With TLS
One of the most complicated parts of web communications today is communicating with proxy servers.  Proxies have many purposes, but one of them is to cache content closer to the client to reduce latency. For example, if two users in Australia are both communicating to the same server in London, it reduces latency for the second user if he can use a cached copy of the content that the first user already downloaded.  Unfortunately, when all traffic is private, the proxy servers don’t know what data is being sent, and so they can’t cache it for other users.  This can make the user’s bandwidth costs go up and also increase his page load times.

But the use of proxy servers over the past few years has eased as the age of the Content-Delivery-Network has grown.  Content Delivery Networks (CDNs) are a mechanism where websites can distribute content to a server which is proximal to the user regardless of whether the user has set up a proxy or not.  CDN usage today is extremely common and growing.  Almost all of the top-100 websites use CDNs to offer performance which is even better than proxy servers.  Speculatively, we could guess that in the future all content will be delivered through CDNs as more and more sites move to hosted cloud computing platforms which will have the infrastructure of a CDN.

Given the use of CDNs and the decentralized use of proxy servers, it is hard to quantify the benefit of proxy servers today.  We know that the majority of Internet users do not use caching proxies at all.  But we also know that for some users they are very useful.  And if we move to all secure communications, those users will no longer have caching proxies.  I don’t have a good answer for this problem, except to say that I don’t think it is a huge problem, and that it is mitigated by CDNs. But I confess I lack data as well.

Conclusion
Changing protocols is not something we do very often.  TCP/IP are over 30 years old, despite attempts to replace them.  As such, the opportunity to improve network security does not come up often, and is not one to be overlooked.  SPDY is a unique opportunity to improve not just HTTP, but also the fundamental underpinnings of how we communicate.

From the user’s perspective, the only argument against TLS is performance, which we believe we are actively solving.  The other arguments don’t help the users – they help server and IT administrators.  As we look to build the next generation Internet protocols, should we be looking out for the user or the administrator? SPDY wants to make sure the user is safe and in control.

It would be easier to make SPDY successful without TLS.  Biting off security in addition to performance is a huge task that almost seems counter productive.  But, lack of security is such a gaping hole in today’s Internet infrastructure, that we just don’t feel it can be overlooked.  If security does prove to be an insurmountable task, we can always fall back to the same-old-same-old insecure plan.  That is easy.  But pushing things forward?  When will we ever get that opportunity again? Maybe never.

It is sad that network traffic today is insecure.  It will be absolutely tragic if network traffic in the year 2020 is still insecure.

There are currently still 85,000-100,000 US troops in Iraq.  All other countries have already pulled out.  Just as under the Bush administration, the objective of our presence in the region is unclear.

And although his campaign promises were to reduce the US war efforts, Obama has also more than doubled US troop levels in Afghanistan in the past year.  If you think this is Bush’s war, you’re wrong.  Obama did this.

Obama’s failure to hold to his campaign promise is just one more reason why he will never again get a vote from me.

Over the past couple of years, several of us have dedicated a lot of time to Chrome’s timer system. Because we do things a little differently, this has raised some eyebrows. Here is why and what we did.

Goal
Our goal was to have fast, precise, and reliable timers. By “fast”, I mean that the timers should fire repeatedly with a low period. Ideally we wanted microsecond timers, but we eventually settled for millisecond timers. By “precise”, I mean we wanted the timer system to work without drift – you should be able to monitor timers over short or long periods of time and still have them be precise. And by “reliable”, I mean that timers should fire consistently at the right times; if you set a 3.67ms timer, it should be able to fire repeatedly at 3.67ms without significant variance.

Why?
It may be surprising to hear that we had to do any work to implement these types of timers. After all, timers are a fundamental service provided by all operating systems. Lots of browsers use simpler mechanisms and they seem to work just fine. Unfortunately, the default timers really are too slow.

Specifically, Windows timers by default will only fire with a period of ~15ms. While processor speeds have increased from 500Mhz to 3Ghz over the past 15 years, the default timer resolution has not changed.  And at 3GHz,15ms is an eternity.

This problem does affect web pages in a very real way. Internally, browsers schedule time-based tasks to run a short distance in the future, and if the clock can’t tick faster than 15ms, that means the application will sleep for at least that long. To demonstrate, Erik Kay wrote a nice visual sorting test. Due to how Javascript and HTML interact in a web page, applications such as this sorting test use timers to balance execution of the script with responsiveness of the webpage.

John Resig at Mozilla was also wrote a great test for measuring the scalability, precision, and variance of timers. He conducted his tests on the Mac, but here is a quick test on Windows.

In this chart, we’re looking at the performance of IE8, which is similar to what Chrome’s timers looked like prior to our timer work. As you can see, the timers are slow and highly variable. They can’t fire faster than ~15ms. 

A Seemingly Simple Solution
Internally, Windows applications are often architected on top of Event Loops. If you want to schedule a task to run later, you must queue up the task and wake your process later. On Windows, this means you’ll eventually land in the function WaitForMultipleObjects(), which is able to wait for UI events, file events, timer events, and custom events.  (Here is a link to Chrome’s central message loop code) By default, the internal timer for all wait-event functions in Windows is 15ms. Even if you set a 1ms timeout on these functions, it will only wake up once every 15ms (unless non-timer related events are pumped through it).

To change the default timer, applications must call timeBeginPeriod(), which is part of the multimedia timers API. This function changes the clock frequency and is close to what we want.  Its lowest granularity is still only 1ms, but that is a lot better than 15ms. Unfortunately, it also has a a couple of seriously scary side effects. The first side effect is that it is system wide. When you change this value, you’re impacting global thread scheduling among all processes, not just yours. Second, this API also effects the system’s ability to get into it’s lowest-power sleep states.

Because of these two side effects, we were reluctant to use this API within Chrome. We didn’t want to impact any process other than a Chrome process, and all of the possible impacts of the API were nebulous.  Unfortunately, there are no other APIs which could make our message loop work quickly. Although Windows does have a high-performance cycle counter API, that API is slow to execute¹, has bugs on some AMD hardware², and has no effect on the system-wide wait functions.

Justifying timeBeginPeriod
At one point during our development, we were about to give up on using the high resolution timers, because they just seemed too scary.  But then we discovered something. Using WinDbg to monitor Chrome, we discovered that every major multi-media browser plugin was already using this API. And this included Flash³, Windows Media Player, and even QuickTime.  Once we discovered this, we stopped worrying about Chrome’s use of the API.  After all – what percentage of the time is Flash open when your browser is open?  I don’t have an exact number, but it’s a lot. And since this API effects the system globally, most browsers are already running in this mode.

We decided to make this the default behavior in Chrome.  But we hit another roadblock for our timers.

Browser Throttles and Multi-Process
With the high-resolution timer in place, we were now able to set events quickly for Chrome’s internals.  Most internal delayed tasks are long timers, and didn’t need this feature, but there are a half dozen or so short timers in the code, and these did materially benefit. Nonetheless, the one which matters most, the timer stall for the browser’s setTimeout and setInterval functions did not yet benefit. This is because our WebKit code (and other browsers do this too) was intentionally preventing any timer sustaining a faster than 10ms tick.

There are probably several reasons for the 10ms timer in browsers. One was simply for convention. But another is because some websites are poorly written, and will set timers to run like crazy.  If the browser attempts to service the timers, this can spin the CPU, and who gets the bug report when the browser is spinning? The browser vendor, of course.  It doesn’t matter that the real bug is in the website, and not the web browser, so it is important for the browser to address the issue.

But the 3rd, and probably most critical reason is that most single-process browser architectures can become non-responsive if you allow websites to loop excessively with 0-millisecond delays in their JavaScript. Remember that browsers are generally written on top of Event Loops.  If the slow JavaScript interpreter is constantly scheduling a wakeup through a 0ms timer, this clogs the Event Loop which also processes mouse and keyboard events. The user is left with not just a spinning CPU, but a basically hung browser.  While I was able to reproduce this behavior in single-process browsers, Chrome turned out to be immune – and the reason was because of Chrome’s multi-process architecture. Chrome puts the website into a separate process (called a “renderer”) from the browser’s keyboard and mouse handling process.  Even if we spin the CPU in a renderer, the browser remains completely responsive, and unless the user is checking her Task Manager, she might not even notice.

So the multi-process architecture was the enabler. We wrote a simple test page to measure the fastest time through the setTimeout call and verified that a tight loop would not damage Chrome’s responsiveness.  Then, we modified WebKit to reduce the throttle from 10ms to 1ms and shipped the world’s peppiest beta browser: Chrome 1.0beta.

Real World Problems
Our biggest fear with shipping the product was that we would identify some website which was spinning the CPU and annoying users.  We did identify a couple of these, but they were with relatively obscure sites. Finally, we found one which mattered – a small newspaper known as the New York Times. The NYTimes is a well constructe site – they just ran into a little bug with a popular script called prototype.js, and this hadn’t been an issue before Chrome cranked up the clock. We filed a bug, but we had to change Chrome too. At this point, with a little experimentation we found that increasing the minimum timer from 1ms to 4ms seemed to work reasonably well on most machines. Indeed, to this day, Chrome still uses a 4ms minimum tick.

Soon, a second problem emerged as well. Engineers at Intel pointed out that Chrome was causing laptops to consume a lot more power. This was a far more serious problem and harder to fix.  We were not concerned much about the impact on desktops, because Flash, Windows Media Player, and QuickTime, were already causing this to be true.  But for laptops, this was a big problem. To mitigate, we started tapping into the Windows Power APIs, to monitor when the machine is running on battery power. So before Chrome 1.0 shipped out of beta, we modified it to turn off fast timers if it detects that the system is running on batteries. Since we implemented this fix, we haven’t heard many complaints.

Results
Overall, we’re pretty happy with the results.  First off, we can look at John Resig’s timer performance test. In contrast to the default implementation,  Chrome has very smooth, consistent, and fast timers: 

Finally, here is the result at the Visual Sorting Test mentioned above.  With a faster clock in hand, we see performance doubles. 

Future Work
We’d still like to eliminate the use of timeBeginPeriod.  It is unfortunate that it has such side effects on the system. One solution might be to create a dedicated timer thread, built atop the machine cycle counter (despite the problems with QueryPerformanceCounter), which wakens message loops based on self-calculated, sub-millisecond timers. This sounds trivial, but if we forget any operating system call which is stuck in a wait and don’t manually wake it, we’ll have janky timers. We’d also like to bring the current 4ms timer back down to 1ms. We may be able to do this if we better detect when web pages are accidentally spinning the CPU.

From the operating system side, we’d like to see sub-millisecond event waits built in by default which don’t use CPU interrupts or otherwise prevent CPU sleep states. A millisecond is a long time.

1. Although written in 2003, the data in this article is still relatively accurate: Win32 Performance Measurement Options. 
2. http://developer.amd.com/assets/TSC_Dual-Core_Utility.pdf
3. Note:  The latest versions of Flash (10) no longer use timeBeginPeriod.
NOTE: This article is my own view of events, and do not reflect the views of my employer.

This puts Apple and Microsoft in the #2 and #3 spots for largest US companies.  #1 is Exxon Mobil.  Of course, this could all re-shuffle tomorrow!

His quotes in the interview are jaw-dropping.  Not only does he admit that the spending policies threw California into massive debt, but he also admits that he, and the other legislators did this without really having tried to analyze the effects of the laws they were implementing.

Here is a nice quote,  "I had actually participated in moving legislation to reduce the retirement age for teachers and I did it with great pride and I created it in my resume as one of my great achievements… Nobody took the time to do the analysis that would have persuaded us we needed to add money to make it work”

Well, that’s good to know.

He goes on to be fairly self-critical, “I may have been one of the key architects of many of the things that have created a challenge for my successors.”

So there you have it – even Willie Brown knows that Democrats are the architects of our problems.  But Brown couldn’t do it alone – it took all of them – much like Obama is doing now – to systematically ignore logic and common sense in favor of grabbing votes by promising to spend money on programs we know we cannot afford.

Mike Belshe – mbelshe@google.com – 04/08/10

When choosing an Internet connection, it is intuitive to focus on network bandwidth – “Speeds up to 5Mbps!”  Bandwidth is important, but it isn’t the only factor in performance.  And given the way that HTTP uses short, bursty connections, it turns out that the round-trip-times dominate performance more than bandwidth does.

Of course, bandwidth speeds are very important for video, music, and other large content downloads.  These types of content, unlike web pages, are able to utilize the network because they are large, whereas web pages are comprised of many short connections.  This report is only concerned with the effect of bandwidth and RTT on the loading of web pages.

Two Factors in Web-page Downloads:  Bandwidth and Round-Trip Time

If we make an analogy between plumbing and the Internet, we can consider the bandwidth of the Internet to be like the diameter of the water pipe.  A larger pipe carries a larger volume of water, and hence you can deliver more water between two points.

At the same time, no matter how big your pipe is, if the pipe is empty, and you want to get water from one point to the other, it takes time for water to travel through the pipe.  In Internet parlance, the time it takes for water to travel from one end of the pipe to the other and back again is called the round trip time, or RTT.

While it is easy to install a bigger pipe between two points to add more bandwidth, minimizing the round trip time is difficult because physics gets in our way.  If your server is located in London, for example, and you are in San Francisco, the time it takes to send a message is gated at least by the speed of light (even light would take ~30ms to travel that distance, or 60ms for a full round-trip).  On the internet today, round trip times of 150ms to 250ms is common.  And no matter how big your pipe is, the RTT will take this long.

Test #1:  Vary the Bandwidth

The first test we ran was to see the effect on web-page download times when you change the bandwidth of the network.  In this test, we’ve chosen fixed values for packet loss (0%) and round-trip-time (60ms) so that we can isolate the variable under test, bandwidth.  In this test we’re downloading a simulation of 25 of the web’s most popular web pages.

Here are the raw results, using HTTP to download the web page:

Bandwidth

Page Load Time via HTTP

Figure 1: This graph shows the decrease in latency (page load time) as the bandwidth goes up.  As you can see, there are diminishing returns as the bandwidth gets higher.   According to the Akamai Internet Report Q2’09, the average bandwidth in the US is only 3.9Mbps.

Figure 2: Here we see the incremental percentage decrease in latency as we add more bandwidth.  An increase from 5Mbps to 10Mbps amounts to a 5% improvement in Page Load Times.

Figure 3: This graph shows the effective bandwidth of the web page download as the raw bandwidth is increased.  At 1Mbps, web pages can be downloaded at ~69% of the total bandwidth capacity.  At 10Mbps, however, web pages can only be downloaded at ~16% of the total capacity; and we’re tapering off.

Test #2:  Vary the RTT

For this test, we fix the bandwidth at 5Mbps, and vary the RTT from 0ms to 240ms.  Keep in mind that the worldwide average RTT to Google is over 100ms today.  In the US, RTTs are lower, but 60-70ms is still common.  

RTT

Page Load Time via HTTP

Figure 4:  In this graph, we see the obvious effect that Page Load Time decreases as the RTT decreases. Continued reductions in RTT always helps, even when RTT is low.

Figure 5: This graph shows the % reduction in PLT for each 20 milliseconds of reduced RTT.  Unlike improvements to bandwidth (figure 2), where benefits diminish, reducing the RTT always helps the overall PLT.  In these tests, with bandwidth fixed at 5Mbps, each 20ms yielded 7-15% reduction in PLT.

Figure 6: This chart shows the increased overall effective bandwidth as RTT is reduced.  With high RTT, bandwidth of a page load was as low as 550Kbps, which is a little more than 10% of the 5Mbps theoretical throughput.  With low RTT, web page downloads still only achieve ~54% of the total bandwidth available.  This is due to other factors of how web pages are loaded.

Conclusions

As you can see from the data above,  if users double their bandwidth without reducing their RTT significantly, the effect on Web Browsing will be a minimal improvement.  However, decreasing RTT, regardless of current bandwidth always helps make web browsing faster.  To speed up the Internet at large, we should look for more ways to bring down RTT.  What if we could reduce cross-atlantic RTTs from 150ms to 100ms?  This would have a larger effect on the speed of the internet than increasing a user’s bandwidth from 3.9Mbps to 10Mbps or even 1Gbps.