For a long time, my voicemail wasn’t set up. People got mad at me.

So I setup my voicemail, and now it has a greeting. But I don’t listen to messages. People get mad at me again.

The trouble with voicemail is its just too inefficient. I have to dial-in, wait for it to connect, listen to the rambling, and then act on it. The whole process is quite maddening – 20-30 seconds each! I know that at this very moment I have voicemails from my sister and brother, and I even have spare time. But the mere thought of the painful process makes me not do it. I’d rather write a whole blog post about how I hate listening to voicemail.

Hmm… I wonder how many messages I’ve got queued up?

Microsoft published their SPDY proposal today to the IETF. They call it “HTTP + Mobility”. Here are some quick comments on their proposal.

a) It’s SPDY!
The Microsoft proposal is SPDY at its core. They’ve fully retained the major elements of SPDY, including multiplexing, prioritization, and compression, and they’ve even lifted the exact syntax of most of the framing layer – maintaining SYN_STREAM, SYN_RESET, SYN_REPLY, HEADERS, etc.

It’s a huge relief for me to see Microsoft propose SPDY with a few minor tweaks.

b) WebSockets Syntax
When SPDY started a couple of years ago, WebSockets didn’t exist. Microsoft is proposing taking existing SPDY, and changing the syntax to be more like WebSockets. This won’t have any feature impact on the protocol, but does make the protocol overall more like other web technologies.

Personally, I don’t think syntax matters much, and I also see value in symmetry across web protocols. I do think the WebSocket syntax is more complicated than SPDY today, but its not that big of a deal. Overall, this part of the Microsoft proposal may make sense. I’m happy that Microsoft has presented it.

c) Removal of Flow Control
The Microsoft proposal is quick to dismiss SPDY’s per-stream flow control as though it is already handled at the TCP layer. However, this is incorrect. TCP handles flow control for the TCP stream. Because SPDY introduces multiple concurrent flows, a new layer of flow control is necessary. Imagine you were sending 10 streams to a server, and one of those streams stalled out (for whatever reason). Without flow control, you either have to terminate all the streams, buffer unbounded amounts of memory, or stall all the streams. None of these are good outcomes, and TCP’s flow control is not the same as SPDY’s flow control.

This may be an example of where SPDY’s implementation experience trumps any amount of protocol theory. For those who remember, earlier drafts of SPDY didn’t have flow control. We were aware of it long ago, but until we fully implemented SPDY, we didn’t know how badly it was needed nor how to do it in a performant and simple manner. I can’t emphasize enough with protocols how important it is to actually implement your proposals. If you don’t implement them, you don’t really know if it works.

d) Optional Compression
HTTP is full of “optional” features. Experience shows that if we make features optional, we lose them altogether due to implementations that don’t implement them, bugs in implementations, and bugs in the design. Examples of optional features in existing HTTP/1.1 include: pipelining, chunked uploads, absolute URIs, and there are many more.

Microsoft did not include any benchmarks for their proposal, so I don’t really know how well it performs. What I do know, however, is that the header compression which Microsoft is advocating be optional was absolutely critical to mobile performance for SPDY. If the Microsoft proposal were truly optimized for mobile, I suspect it would be taking more aggressive steps toward compression rather than pulling it out.

Lastly, I’m puzzled as to why anyone would propose removing the header compression. We could argue about which compression algorithm is best, but it has been pretty non-controversial that we need to start compressing headers with HTTP. (See also: SPDY spec, Mozilla example, UofDelaware research)

e) Removal of SETTINGS frames
SPDY has the promise of “infinite flows” – that a client can make as many requests as it wants. But this is a jedi mind trick. Servers, for a variety of reasons, still want to limit a client to a reasonable number of flows. And different servers have very different ideas about what “reasonable” is. The SETTINGS frame is how servers communicate to the client that they want to do this.

I’m guessing this is an oversight in the Microsoft proposal.

f) Making Server Push Optional
Microsoft proposes to make server push optional. There is a fair discussion to be had about removing Server Push for a number of reasons, but to make it optional seems like the worst of all worlds. Server Push is not trivial, and is definitely one of the most radical portions of the protocol. To make it optional without removing it leaves implementors with the burden of all the complexity with potentially none of the benefits.

The authors offer opinions as to the merits of Server Push, but offer no evidence or data to back up those claims.

h) Removal of IP Pooling
The Microsoft writeup eliminates connection pooling, but it is unclear why. Connection pooling is an important element of SPDY both for performance and for efficiency on the network. I’m not sure why Microsoft would recommend removing this, especially without benchmarks, data, or implementation details. The benchmarks clearly show it has measurable benefit, and without this feature, mobile performance for the Microsoft proposal will surely be slower than for SPDY proper.

Conclusion
I’m happy with the writeup from Microsoft. I view their proposal as agreement that the core of SPDY in acceptable for HTTP/2.0, which should help move the standardization effort along more quickly. They’ve also raised a couple of very reasonable questions. It’s clear that Microsoft hasn’t done much testing or experimentation with their proposal yet. I’m certain that with data, we’ll come to resolution on all fronts quite quickly.

I filed my second objection to the Honda Civic Hybrid Settlement this year, and they were nice enough to send me a CD of all the other letters that were submitted to the court.

Scorecard

• There were 3 letters in favor of the settlement
• There were 45 letters opposing the settlement

The Supporting Letters Were From

• The lawyers, Jonathan Cuneo and Nicholas Chimicles (who also filed for fee reimbursement of $2.332M and $2.995M, respectively).
• The mediator of the original settlement, Howard Wiener.
• Rust Consulting, paid for by American Honda Motor.

Summary

• The lawyers who are getting paid millions love it.
• Not a single member of the settlement class wrote in favor of the settlement.
• Honda just wants to pay this ransom and move on.

I’m under no illusion that my letter will have any effect.

It is a measurable fact that Cuneo and Chimicles are poor negotiators. Although damages are in the thousands of dollars per individual, they could only negotiate a $100 settlement for us. This is in spite of the fact that another member of the class, Heather Peters, was able to successfully negotiate $9,867 for herself – nearly 100 times more than Cuneo and Chimicles.

Sadly, Cuneo and Chimicles will not be fired for their lackluster performance. Instead, for this one case, they will each be paid a multi-million dollar sum greater than the average American will earn in his entire lifetime (median salary * 45 years).

Recent SPDY news comes from some big brands: Twitter, Mozilla, Amazon, Apache, Google.

• Mar, 2012
  Twitter now supports SPDY
   
• Feb, 2012
  A draft of the SPDY specification is submitted to the http-bis working group for consideration toward the HTTP/2.0 effort.
   
• Feb, 2012
  Firefox 11 now supports SPDY
   
• Jan, 2012
  Google publishes SPDY Tech Talk, Announces that SPDY with SSL is now faster than HTTP without SSL for Google sites.
   
• Dec, 2011
  Apache mod-spdy enters beta
   
• Nov, 2011
  Amazon launches Kindle Silk browser with SPDY support
   

Looking forward to seeing what comes next!

Mobile Apps use HTTP. But they usually don’t use it to transfer HyperText – rather they are using it to transfer JSON, XML, or other data formats. Just like their web counterparts, secure transmission is desirable.

But, if you ever trace a fresh SSL connection, you know that its a nasty process:

• DNS
• TCP handshake
• SSL handshake
• Server sends certificate
• DNS to CA
• TCP to CA
• OCSP to CA
• Finish SSL handshake
• Finally do what you wanted to do….

SSL is designed so that you can pick up some random certificate and check it dynamically. This is a good thing for the web, where the user coasts from site to site, happily discovering new content which needs new validation.

But this process is pretty costly, especially on mobile networks. For my own service, I just did a quick trace over 3G:

• DNS (1334ms)
• TCP handshake (240ms)
• SSL handshake (376ms)
• Follow certificate chain (1011ms) — server should have bundled this.
• DNS to CA (300ms)
• TCP to CA (407ms)
• OCSP to CA #1 (598ms) — StartSSL CA uses connection close on each!
• TCP to CA #2 (317ms)
• OCSP to CA #2 (444ms)
• Finish SSL handshake (1270ms)

With the web, this verification process makes some sense – you ask the CA to be your trust point and verify that he trusts the certificate provided.

But why do this with a mobile app? Your mobile app has a lot of trust with it – they downloaded it from you, its signed by Apple, and if the code has been compromised, well, heck, your app isn’t really running anyway.

What we really want for mobile apps is to bake the server’s certificate into the app. If the server’s certificate needs to change, you can auto-update your app. In the example above, doing so would have shaved about 3000ms off application startup time.

The downside of this is that if your certificate changes, your app won’t verify. Then what to do? Simple – force an auto update.

There is another advantage to this approach. If you can verify your own certs, you don’t need a CA provided certificate anyway. These silly 1-2 year expirations are no longer necessary. Sign your own cert, and verify it yourself. Since our CAs have been getting hacked left and right in 2011, this is probably even more secure.

PS: SSL is hard. In this one trace, I can spot at *least* 3 low-hanging-fruit optimizations. I haven’t mentioned them, because they are pervasive everywhere on the net. There are errors here at every level – the client is missing opportunities, the server is missing opportunities, and the CA is missing opportunities! It’s no wonder that SSL is slow. The chance that your combination of client + server + CA will have some dumb performance bug is ~99%.

I haven’t read about this anywhere, but in Jan 2012, Chrome 16 was the World’s Most Popular Browser. A minor stat, but a testament to modern update policies. You won’t read about this in any press release, but this is the #1 reason why Chrome’s security is better than any other browser.

I had a frustrating day. I’m writing some simple ajax/xhr tests, and I can’t get the browser to issue my requests:

Origin http://localhost is not allowed by Access-Control-Allow-Origin

Searching on Google, it’s clear that lots of other people are having the same problem, but nobody has an answer – the browser nazis are being overzealous, protecting us from localhost – really?

Fortunately, chrome has a workaround. Use this commandline:

chrome.exe –disable-web-security

And you can get your job done.

Just spent 3 days waiting for turnaround on a contract where the other party’s counsel did nothing but twiddle the bits on the confidentiality clause. What a waste of time, productivity, and legal bills.

Don’t get me wrong – the other lawyer is not the only one at fault here. My lawyer is equally to blame.

What the hell? Why is it that my lawyer, and the other lawyer both thought they needed to reinvent a confidentiality clause? Can’t we just create one, have it ratified by the courts and live with it? Why do two lawyers get to rack up wages at $300/hr to modify 2 sentences that they’ve modified a thousand times before?

Lawyers who don’t work on fixing this problem are the problem. They all need to get together, settle this, and stop raping America.

Heather Peters has become semi-famous this week because of her small-claims suit against Honda. Honda reached a class-action settlement because the gas mileage of the Civic is simply not up to par. This matches my own experience. Aside from the first few months owning the car where I was both actively hypermiling and also driving exclusively highway miles, the gas mileage in my car has been disappointing. My hybrid gets ~38mpg right now, a far cry worse than the claimed 50mpg that I should be getting.

The class action lawsuit was a joke. The lawyers walked away with millions, while the consumers were compensated with $100 and a video. And each Civic Hybrid consumer has thousands of dollars in damages. Worse, the settlement bars anyone who even complained about the settlement from receiving the settlement. I complained, of course, and my punishment is that I didn’t get the $100.

Since there seems to be renewed interest in this whole affair, here is the full text of the letter I submitted to the court regarding the class action suit back in December 2009.

UNITED STATES DISTRICT COURT
CENTRAL DISTRICT OF CALIFORNIA
EASTERN DISTRICT – RIVERSIDE

JOHN TRUE, et al.,
Plaintiffs, Case No.: 5:07-cv-00287-VAP-OP

v.

AMERICAN HONDA MOTOR CO., INC

Defendants.

OBJECTIONS TO CLASS ACTION SETTLEMENT

I am a member of the settlement class for Case No. 5:07-cv-00287-VAP-OP (True vs. Honda Motor Company Inc.). This letter officially declares my objection to the settlement on the grounds that this settlement is not in the best interest of the members of the settlement class.

Background
This lawsuit was brought against American Honda Motors (AMH) because the fuel efficiency of their cars does not match the advertised claims. Evidence has been presented that the cars were advertised to achieve 50MPG while only actually achieving 32MPG for many drivers. Drivers of these cars often purchase them specifically because of the alleged low cost of operation. When the gas mileage fails to achieve advertised claims, the consumer is left to pay the difference. I believe the difference is an accurate representation of the damages caused by AMH.

The Honda Civic warranties apply to various parts of the car for 50,000 to 150,000 miles, and consumers are sold the car with the expectation that 100,000 miles is reasonable
. Gasoline in California has averaged ~$3.20 per gallon over the last 3 years
. Using these figures, if the car only achieved 32MPG instead of 50MPG, the per-consumer damages are ~$3,600.

Objections
I have 4 objections to this settlement.

Objection #1: Failure to correct damages for the settlement class
Given the magnitude of damages to consumers, the settlement offer simply is not in the best interest of the settlement class. The settlement reimburses the members of the class for less than 2% of the damages incurred.

In the settlement, members are given 3 options:
a) Sell your hybrid, and get a $1000 coupon on another Honda (not a hybrid).
b) Give your hybrid to a family member, get a $500 coupon on another Honda (not a hybrid).
c) Get a $100 check.
All 3 options include a video for how to get better gas mileage.

Even if the settlement member wanted a new car (which many do not), the $1,000 rebate still would still be less than one-third of the damages incurred due to unexpectedly low cost-of-operation.

But worse, for most consumers, the $100 settlement is so small that it does not offset the damages at all. At the same time, this settlement greatly reduces the consumer’s claims against Honda, and may even void the consumers current warranty. Why would any consumer sell this privilege for a mere $100? (see the second objection #2).

Objection #2: Overreaching settlement releases
As part of this settlement, all members of the settlement class release all claims against AMH regarding anything related to the fuel economy of the vehicle. Specifically, the settlement covers anything

“involving, based on, relating to, arising out of or in any way connected with, directly or indirectly, the advertising of the fuel economy or m.p.g. of the HCH…”

With regard to existing warranties, it states

“Nothing in this Agreement shall be interpreted to modify or diminish the manufacturer’s limited warranty with respect to a Class Vehicle; provided, however, that any such claim of breach of any warranty or any extended warranty based on the advertising or representations made by AHM with respect to fuel economy, mileage or m.p.g are in fact released.”

This clause is completely overreaching! For instance, Honda warrants the batteries in the vehicle for 50-150K miles. When I was sold the vehicle, the salesperson told me that the batteries would not need replacement for 150K miles. However, as the batteries get old (much like the batteries in your cellphone), they hold their charge for diminishing amounts of time. The car will still operate just fine even with diminished battery life, but the MPG rating will drop significantly! I fear that if I accept this settlement, and then I go to Honda to get help with replacement of my previously-under-warranty batteries, I will no longer have a claim. Honda will be able to say that my car is working fine, and that the battery problem related to MPG was Released as part of this settlement.

As such, this contract specifically DOES alter my warranty, despite claims to the contrary.

Objection #3: The retaliatory nature of the settlement against its members.
As part of this settlement, any member of the settlement class that objects to the settlement is specifically barred from collecting any benefits if the settlement is accepted by the court. This clause is clearly not in the best interest of the settlement class, and is actually retaliatory in nature.

It is clear to me that the damages I have personally incurred due to AMH’s wrongful advertising are far in excess of the $100 settlement. Purchasing a new Honda has no appeal to me. I do not want to purchase a new car from Honda at any time in the future, and even if I did, I would like to get a hybrid. As such, options (a) and (b) simply do not make any sense.

But the negotiators of this settlement have defined only 3 options, and I am required to either accept them or be ignored from any settlement result. This clearly only serves the interest of the legal staff and does not serve the interest of the plaintiffs.

Objection #4: Negotiation of excessive attorney compensation at the expense of the settlement members
I recognize that the attorneys have worked hard on this case for the last year. While they are pushing for a quick settlement which will enable them to receive a hefty payout of nearly 3 million dollars, they have failed to negotiate a settlement which actually addresses the original problem in the claim. If they believe that settlement members would benefit by accepting a plan which voids their warranty and only recoups 2% of the damages, then the attorney fees should also be diminished – I propose they should be set to 2% of the requested fees, or $92,187.

My Status in the Settlement Class
The following responses are the required responses as per the proposed settlement in progress.

(i) Name address and phone number
Michael Belshe
[DETAILS OMITTED FROM BLOG]

(iii) Grounds for objection
Stated above.
(iv) Proof
Stated above.
(v) No persons will be called to testify
(vi) I do intend to appear at the Final Approval Hearing, schedule permitting.
(vii) I have appeared in no other cases as a settlement objector or counsel in the past 5 years.

Recommendations
I have 5 recommendations for the settlement:
(a) The negotiators should compute a reasonable figure for damages to each consumer. (I computed $3,600).
(b) The negotiators should negotiate a settlement for at least 50% of those damages.
(c) Objecting to a proposal must not cause members to be excluded from a settlement.
(d) The settlement must re-address the warranty voiding effects mentioned above.
(e) The attorney fees should be in-line with what settlement members receive in the settlement. If the settlement members recoup 50% of their damages, then the attorneys should only collect 50% of their $2.95M fee as well.

Respectfully,

Michael A Belshe

If you’re a SPDY server implementor, you’ve likely already read about the impact of CWND. Fortunately, the TCP implementors now largely agree that we can now safely increase CWND, and the standard will likely change soon. The default linux kernel implementation already has.

But, there is a second cwnd-related kernel flag which is not often mentioned. It’s important in all cases, but particularly important if you’re trying to establish long-lived connections. It’s not just important to SPDY – it’s important for HTTP keepalives or pipelines too. And many of the large web service providers are already tuning it:

> sysctl -a | grep tcp_slow_start_after_idle
net.ipv4.tcp_slow_start_after_idle = 1

At casual glance, you probably think “this sounds good, after a minute or so, it will go back into slow start mode”. That is fine, right?

Not quite. “Idle” in this case doesn’t mean a ‘minute or so’. In fact, it doesn’t even mean a second. This flag comes from RFC2861’s recommendation, which states that cwnd be cut in half with each RTT of idleness. That means that a persistently held open connection soon degrades back to the performance of an un-warmed connection very quickly.

So why does this matter? If you’re attempting to use a long-lived SPDY connection and think that the initial CWND won’t affect you because you’re only opening one connection anyway, you’re wrong. The slow-start-after-idle will still get you.

While there has been a tremendous amount of investigation and discussion about the initial cwnd value, I’m not aware of any recent debate about the slow-start-after-idle. I know that many websites are already disabling this flag to make HTTP keepalive connections perform more reasonably. Sadly, I can’t find any research which actually measured the effects of this behavior in the real world, so I can’t fall back on any real data. Given how aggressive TCP already is at backing off should network congestion change, I see no reason to enable this flag. Further, if you’re helping the net by dropping from N connections to 1, there is no reason you should be further penalized for your good deeds! Turn this one off.

I’m generally a pretty free-market kind of guy. But, when it comes to CEO pay, there is no doubt in my mind that America is screwed up and that the free market is failing us. This isn’t the biggest of our problems, but it raises unnecessary doubt about “corporate greed” and about the livelihood of the American Dream.

If you don’t believe me, check out some of the compensation paid to CEOs of companies that are losing massive amounts of money:

• Aubrey McClendon, Chesapeake Energy, paid $18.6M while the company lost $5.8B.
• Carol Bartz, Yahoo, paid $39.0M in the same year she’s fired.
• Timothy Armour, Janus Capital, paid $11.4M while the company lost $757.1M.
• Rupert Murdoch, News Corp, paid $18.0M while the company lost $3.4B.
• Robert Stevens, Lockheed Martin, paid $21.7M while the company lost $3.0B.
• Daniel Hesse, Sprint, paid $10.3M while the company lost $2.4B.
• Gregory Brown/Sanjay Jha, Motorola, paid $11.7M while the company lost $111M.
• Ronald Hovsepian, Novell, paid $5.2M while the company lost $214.6M.
• William Klesse, Valero, paid $11.3M while the company lost $353M.
• Klaus Kleinfeld, Alcoa, paid $14.3M while the company lost $985M.
• Ahmad Chatila, MEMC Electronic Materials, paid $16.7M while the company lost -$68.3M.
• The list goes on and on…

Still not convinced? Why do CEOs get golden parachutes? Why did Leo Apotheker get paid $25M after getting fired 11mos into the job? Do you get one? It makes no sense to ever have a guaranteed payout even if you screw up.

Mark Cuban once again puts this in perspective by demonstrating that the risk-reward for CEOs is out of whack.

Fortunately, it is easy to fix.

The free market should remain free. If a company wants to pay a CEO $50M in advance, they are free to do so. But the Board of Directors, whose sole responsibility is to the shareholders best interests, needs to be able to prove that such a plan is good for the shareholders. If not, the Directors need to be held personally liable.

I’d like to see the SEC adopt new rules about executive pay – including any form of guaranteed pay, pay for non-performance, pay while the company is losing money, or pay for early termination. These rules should outline a very strict and narrow definition for when such compensation would be “good for shareholders”. Common sense should win out here, and the right answer is “almost never”. We all know that if an employee isn’t working out you should fire them with impunity. CEO’s are no exception.

As for the CEOs that are already beneficiaries of guaranteed payouts – if they have any character at all, they should forfeit these benefits and ask their Board of Directors to rework their compensation to something in line with what the rest of the company gets.

This post is definitely for protocol geeks.

SPDY has been up and running in the “basic case” at Google for some time now. But I never wrote publicly about some wicked cool possibilities for SPDY in the future. (Much to my surprise, it may be that someone is doing them today already!)

To start this discussion, lets consider how the web basically works today. In this scenario, we’ve got a browser with 3 tabs open:

As you can see, these pages use a tremendous number concurrent connections. This pattern has been measured both with Firefox and also with Chrome. Many mobile browsers today cap the connections at lower levels due to hardware constraints, but their desktop counterparts generally don’t because the only way to get true parallelism with HTTP is to open lots of connections. The HTTPArchive adds more good data into the mix, showing that an average web page today will use data from 12 different domains.

Each of these connections needs a separate handshake to the server. Each of these connections occupies a slot in your ISP’s NAT table. Each of these connections needs to warm up the TCP SlowStart algorithm independently (Slow Start is how TCP learns how much data your Internet connection can handle). Eventually, the connections feed out onto the internet and on to the sites you’re visiting. Its impressive this system works very well at all, for it is certainly not a very inefficient use of TCP. Jim Gettys, one of the authors of HTTP has observed these inefficiencies and written about the effects of HTTP’s connection management with ‘bufferbloat’.

SPDY of Today

One first step to reduce connection load is to migrate sites to SPDY. SPDY resides side by side with HTTP, so not everyone needs to move to SPDY at the same time. But for those pages that do move to SPDY, they’ll have reduced page load times and transmitted with always-on security. On top of that, these pages are much gentler on the the network too. Suddenly those 30-75 connections per page evaporate into only 7 or 8 connections per page (a little less than one per domain). For large site operators, this can have a radical effect on overall network behavior. Note that early next year, when Firefox joins Chrome implementing SPDY, more than 50% of users will be able to access your site using SPDY.

SPDY of the Future

Despite its coolness, there is an aspect of SPDY that doesn’t get much press yet (because nobody is doing it). Kudos for Amazon’s Kindle Fire for inspiring me to write about it. I spent a fair amount of time running network traces of the Kindle Fire, and I honestly don’t know quite what they’re doing yet. I hope to learn more about it soon. But based on what I’ve seen so far, it’s clear to me that they’re taking SPDY far beyond where Chrome or Firefox can.

The big drawback of the previous picture of SPDY is that it requires sites to individually switch to SPDY. This is advantageous from a migration point of view, but it means it will take a long time to roll out everywhere. But, if you’re willing to use a SPDY gateway for all of your traffic, a new door opens. Could mobile operators and carriers do this today? You bet!

Check out the next picture of a SPDY browser with a SPDY gateway. Because SPDY can multiplex many connections, the browser can now put literally EVERY request onto a single SPDY connection. Now, any time the browser needs to fetch a request, it can send the request right away, without needing to do a DNS lookup, or a TCP handshake, or even an SSL handshake. On top of that, every request is secure, not just those that go to SSL sites.

Wow! This is really incredible. They’ve just taken that massive ugly problem of ~200 connections to the device and turned it into 1! If your socks aren’t rolling up and down right now, I’m really not sure what would ever get you excited. To me, this is really exciting stuff.

Some of you might correctly observe that we still end up with a lot of connections out the other end (past the SPDY gateway). But keep in mind that the bottleneck of the network today is the “last mile” – the last mile to your house. Network bandwidth and latencies are orders of magnitude faster on the general Internet than they are during that last mile to your house. Enabling SPDY on that link is the most important of them all. And the potential network efficiency gains here are huge for the mobile operators and ISPs. Because latencies are better on the open internet, it should still yield reduced traffic on the other side – but this is purely theoretical. I haven’t seen any measure of it yet. Maybe Amazon knows

More Future SPDY

Finally, as an exercise to the reader, I’ll leave it to you to imagine the possibilities of SPDY in light of multiplexing many sites, each with their own end-to-end encryption. In the diagram above, SSL is still end-to-end, so that starting a SSL conversation still requires a few round trips. But maybe we can do even better….

The F5 folks wrote a little about SPDY a few weeks ago. It’s a nice write up. But I want to challenge one particular point of it which I commonly hear:

“The most obvious impact to any infrastructure between a SPDY-enabled client and server is that it drives intermediate processing back to layer 4, to TCP”

This isn’t actually true. SPDY is not what makes load balancing or hierarchical caching difficult. SSL is what makes these hard. But even blaming SSL is a bit unfair – any protocol which introduces encryption to avoid 3rd party tampering of the data stream is going to have this problem.

In other words, it’s not deploying SPDY that is hard, it’s securing the web that is hard.

To the contrary, SPDY actually makes deployment of secure content easier. One of the common complaints against using SSL is that of performance – both in terms of client latency and also server scalability. When SSL is combined with SPDY, the performance objection is substantially lessened.

Now, don’t get me wrong, I am sympathetic to the difficulty of securing the web, and we need a lot more tools, debugging, and effort to make it simpler and cheaper for everyone. This will be especially difficult for infrastructure solutions which leverage the fact that HTTP is unsecured to do L7 packet analysis. But that doesn’t change the fact that we live in an electronic world full of bad guys. Whenever we ultimately decide to protect the web, it’s going to be hard. SPDY doesn’t create this problem at all.

Patrick McManus of Mozilla did a great presentation on SPDY. He’s excited about how much more efficient SPDY is than HTTP when layered over TCP. Firefox has now independently verified basically all of the claims that we made abut SPDY with Chrome.

Can’t wait for Firefox 11.

For the record, the standardization process for SPDY is coming.

We’ve got roads blocked off with Police Mobile Command units….

We’ve got cops loitering on every street corner….

We’ve got every police officer in SF on a motorbike….

And snipers on the rooftops….

What could it be?

Obama’s back in town!