Google short term SPDY roadmap

[Mike Belshe]

Hi,

I wanted to announce more specifically what Google's plans are with SPDY.

There are two active projects underway.  First, there is the SPDY Protocol Work, and second there is the first SPDY Experiment.

Protocol Work
The protocol work that we are doing is completely in the open and we invite others to use that work in any way they wish.  We find data most valuable and greatly appreciate those willing  to invest engineering time and diligence to proving what works and does not.  We expect this will be an ongoing effort for some time.  We hope to formally work with standards bodies soon to determine a good course of action for incorporating the concepts of SPDY into something official.  Some of the people that are far more experienced at this than we are have been politely contributing on this list (thanks Mark, Roy, Bill, and others!).

As already announced, a client implementation of SPDY is already available to anyone from the chromium code base.  We will also be releasing an open-source server (probably not a usable one for production purposes, but for experimentation and demonstration purposes) in the near future.

There are many features in the protocol which we'd like to explore:
   - Core:  multiplexing, prioritization, compression
   - Server Push and Server Hints
   - Other?

We need help on this and appreciate the fantastic feedback and help already offered.  We hope this will grow in the coming months.

SPDY Experiment #1
In parallel with the protocol design and development, we are also actively working on getting an end-to-end implementation of the protocol running between Chromium and Google Services.  We do this because we don't believe we could ever accurately quantify the benefits of a new protocol solely with lab work.  So we are planning to deploy this protocol as part of an experimental framework in our live products.  Although it will be an experiment, it will be subject to the same stability and performance criteria that any Google product must meet.

We do not expect this to be the last experiment by any means; we plan to implement, measure, and test, and then iterate.  We will iterate until we are satisfied that we have the right protocol, and one that stands on its own with standards bodies as well.

The features in Experiment #1 include only the "core" of SPDY (mentioned above), as published in the SPDY spec, running over SSL.  We will measure the performance of SPDY and publish the results when we can.  This will likely take a couple of months.

Let me know if you have any questions.

Mike

[Bram Cohen]

Which Google web services will be given experimental support for SPDY?

Will the experimental not-yet-standardized SPDY support be put into
the regular public release of Chrome, or will it be in a beta or
special experimental build?

[Roberto Peon]

I believe the plan is to have it in the 'dev-channel' build, and enabled by command-line flag or the like.

It will not be enabled for all Google properties, nor at all Google locations.

This will be an extremely limited scope test for the next few months. Hopefully during that time we'll be able to convince people to hack support for SPDY into traffic-server, squid, or apache, and we can widen the scope of the test--  it would be very interesting to see how well the protocol worked on other sites. I suspect (given lab results) that many other sites may see a larger latency benefit moving to SPDY that would Google.

BTW, We're planning on landing the server code tomorrow. It still doesn't compile in the Chromium tree, but it is a lot closer to doing so. Much of the delay w.r.t. open-sourcing it has been cleaning it up to not rely on non-public Google libraries.

-=R

[Bram Cohen]

On Nov 23, 3:42 pm, Roberto Peon <fe...@google.com> wrote:
>
> This will be an extremely limited scope test for the next few months.
> Hopefully during that time we'll be able to convince people to hack support
> for SPDY into traffic-server, squid, or apache, and we can widen the scope
> of the test--  it would be very interesting to see how well the protocol
> worked on other sites. I suspect (given lab results) that many other sites
> may see a larger latency benefit moving to SPDY that would Google.

It might not be such a hot idea to convince projects you don't
directly control to implement SPDY before it's really finalized,
because as soon as that happens you have a serious legacy
compatibility problem.

You're probably right about other sites getting more benefit than
Google though, since Google properties are already highly optimized to
have very little graphics and few separate requests. Much more
sloppily designed and un-optimized sites are likely to get lots more
benefit. Maybe Orkut would be a good test bed :-)

[Robert]

Google Maps would be nice - it has a lot of parallel requests, XHR &
Flash (Streetview) - a small "stress test" ;-)

BTW: It would be nice, if the protocol spec gets a history (maybe
versioning) to track changes.

@Mark - is your nbhttp able to issue SPDY client requests? Maybe we
can use it to programmatically issue SPDY requests to test server
implementations?

Robert