Google SPDY/3 implementations are coming

[William Chan (陈智昌)]

In the interest of giving implementers enough time to update their implementations, I'm announcing the _rough_ (and always subject to change) schedule which we at Google will follow for the SPDY/2 to SPDY/3 update.

Chrome 19 will support both SPDY/2 and SPDY/3. Note that Chrome 19 is currently in dev channel. It is as yet undecided whether and how often SPDY/3 will be preferred over SPDY/2 when a server advertises support for both via NPN, because we are trying to make sure not to regress performance with SPDY flow control. Obviously at some point when we are happy with it, SPDY/3 will always be preferred over SPDY/2. Hopefully this can happen in the Chrome 19 release cycle, but might happen in a later release. Once it is stable, we will most likely retain support SPDY/2 for a release or two (this is still TBD), but we want to encourage servers to switch over to SPDY/3 support, so at some point we will drop support for SPDY/2.

Google servers will advertise support for both SPDY/2 and SPDY/3 sometime in March. Clients can begin testing against Google's SPDY/3 implementation at that point. It's likely that we will support SPDY/2 longer on Google servers than on Chrome (not all clients will auto-update, such as Android phones using a Android browser version that speaks SPDY/2), but we again will kill off SPDY/2 support at some point, so please transition to SPDY/3 implementations soon. We've spoken to Patrick McManus on the Firefox front and he will likely begin work on SPDY/3 as soon as there's Google server support so he can test his implementation. So we hope that Firefox will switch over to SPDY/3 in not too long, which should, combined with Chrome, account for the vast majority of SPDY use on the client side.

And of course, we will be updating http://code.google.com/p/spdy-compliance-tests/ to support SPDY/3 in the near future to help verify our SPDY/3 implementations.

Basically, the important thing to take away is that Google Chrome and servers will begin deploying SPDY/3 implementations in March and hoping to ditch SPDY/2 support as soon as we feel it is "reasonable" (which is very much TBD). And we want to encourage other implementors to switch over soon, and thus are declaring our intent to drop SPDY/2 support at some point in the future, so don't dawdle too long :)

Cheers.

[patrick mcmanus]

On 2/23/2012 12:17 PM, William Chan (陈智昌) wrote:
> Basically, the important thing to take away is that Google Chrome and
> servers will begin deploying SPDY/3 implementations in March and
> hoping to ditch SPDY/2 support as soon as we feel it is "reasonable"
> (which is very much TBD). And we want to encourage other implementors
> to switch over soon,

I support this general approach while we work on standardization. No
flag days, but rather finite (and flexible) transition periods.

Once we reach a (hopefully) ietf proposed standard RFC level, then it is
suitable to talk about long term backwards compatibility. But until
then, let's iterate as quickly as we need to[*] and make sure deprecated
versions get the heck off the Internet. It certainly helps that HTTP/1
is pragmatically a fallback for implementations that fall way behind.

-Patrick

[*] a plea for discipline while we iterate: don't make official releases
of interim draft edits.. we should all have a single fixed value of what
v3 is and that should be unambiguous and once we have that discussion
should be focused around evolving v4.

[Gautam Dewan]

William: the flip_server code in the Chromium source was very useful as a reference in implementing a SPDY translator. Will you update that to spdy/3 as well ?

Regards,
Gautam.

[William Chan (陈智昌)]

Yes.

[Simon B.]

On Feb 24, 2:45 am, patrick mcmanus <pmcma...@mozilla.com> wrote:
> [*] a plea for discipline while we iterate: don't make official releases
> of interim draft edits.. we should all have a single fixed value of what
> v3 is and that should be unambiguous and once we have that discussion
> should be focused around evolving v4.

How about reserving odd version numbers to signify mean "in
development"?
That way only spdy/even numbers} would be "allowed" to appear on
public sites and any test-deployments/half-baked spdy implementations
(imagine stray publicly deployed flip_server's) would be easy to spot
on the open internets.
(This idea could be implemented now, or otherwise I suggest waiting
one more version to keep the tradition with odd numbers as development
versions.)

[Mike Belshe]

Hi, Will -

Any chance you can give an update on the Google server and Chrome status?

Thanks,

Mike

[William Chan (陈智昌)]

It's supported in Chromium trunk (and will be released with Chrome 19, but not on by default, since we will be rolling out gradually via field trials so as to catch performance regressions due to flow control). I cannot comment in detail on the rollout server-side, but I believe it is already partially deployed.

[Sam Young]

Will,

Do you have any data or findings yet from enabling flow control? I'm interested to know how it performs. In which situations have you found it most useful?

Sam

[William Chan (陈智昌)]

It's pretty important for proxies. We're gradually rolling it out *right now*. We've updated our performance dashboards with stuff to catch regressions, so hopefully I'll be able to report data soon. When we have stuff to report, we'll do so here. The only stuff I have to say currently is that we have definitely encountered some correctness bugs in our implementations :P

[Antonio Vicente]

On Mon, Apr 2, 2012 at 12:54 PM, Sam Young <sa...@amazon.com> wrote:
> Will,
> Do you have any data or findings yet from enabling flow control? I'm
> interested to know how it performs. In which situations have you found it
> most useful?

The main use of per-stream flow control is to protect proxies from
having to infinitely buffer POST data if data on the stream is coming
at a rate that is higher than what it can process while still
preventing head of line blocking from happening on the reader side
SPDY connections.

Flow control should have no effect on small requests and responses,
but could severely limit throughput on high bandwidth delay product
links. We will likely include recommendations once we have more data
from our experiments.

[Patrick McManus]

On Tue, 2012-04-03 at 13:38 -0400, Antonio Vicente wrote:
> On Mon, Apr 2, 2012 at 12:54 PM, Sam Young <sa...@amazon.com> wrote:
> > Will,
> > Do you have any data or findings yet from enabling flow control? I'm
> > interested to know how it performs. In which situations have you found it
> > most useful?
>
> The main use of per-stream flow control is to protect proxies from

That's a good use case, but browser's consuming responses care too.
Especially when coordinating things like active tabs vs stalled/jerky
plugins that might be flowing over the same spdy session. The same
buffering conundrum exists that you describe with the proxy and the
right thing to do is to let the content source feel the back pressure
without screwing up the other streams.

so +1 flow control :)

[Markus Johansson]

Hi Will,

I want to test SPDY/3 without SSL and try start chrome using:

--use-spdy=no-ssl --enable-spdy3 --enable-spdy-flow-control

but I haven't yet managed to make chrome speak SPDY/3, only SPDY/2

I'm using 20.0.1115.1.dev-m

Is there a way to foce SPDY/3 ?

Markus

[Roberto Peon]

The server to which you're connecting must support SPDY/3 and say so in the NPN string.

If that doesn't happen, then chrome won't speak it either.

-=R

[William Chan (陈智昌)]

This confusion probably came up since the *rough* timeline I outlined in the original announcement slipped. We'll be announcing a new timeline shortly.

[Markus Johansson]

I'm not using SSL / NPN. I'm using the --use-spdy=no-ssl option.

SPDY/3 can not be enabled without NPN ?

Markus

[Colin Marc]

Hi William - I see that chrome 19 was just released to stable. What is the status of preferring SPDY/3 over SPDY/2?

[William Chan (陈智昌)]

Thanks for asking! It's probably not going to happen in Chrome 20, but we're still discussing it. We've run into interesting situations where SPDY/3 is actually *faster* than SPDY/2 and also some other edge cases and implementation issues. We plan on discussing this publicly shortly, stay tuned. As for timelines, I'd say that Chrome 21 looks likely.

As always, this is just what we think will happen and we're not making any guarantees. Cheers.

[Szabolcs Péter]

And what is SPDY/2.1? I see it at chrome://flags: Enable experimental SPDY/2.1 for flow control.

And it's not in Canary.

SyP

[Roberto Peon]

SPDY/2.1 was our private testing of flow control. It was never exposed to the public via server, nor is it ever intended to so be..

-=R

[Hark Lee]

I have one question about the difference between the length of Control Frame and Data Frame,

why the length of data frame is  8 bytes + length ,but not just the length of Data.

2012/5/16 Roberto Peon <fe...@google.com>

[William Chan (陈智昌)]

The control bit + version + type + flags + length fields = 8 bytes. The value of the length field represents the length of the payload. Therefore, the total length of the data frame is header fields length + payload length which is 8 + "length".

[Hark Lee]

Sorry my bad questions.

What I want to know is why the definition of the length of Data Frame and the Length of Control frame is different.

2012/5/16 William Chan (陈智昌) <will...@chromium.org>

[Antonio Vicente]

On Wed, May 16, 2012 at 11:53 AM, Hark Lee <lihe...@gmail.com> wrote:

Sorry my bad questions.

What I want to know is why the definition of the length of Data Frame and the Length of Control frame is different.

The length field excludes the first 8 bytes of the frame in the case of both Data and Control frames.

[Hark Lee]

ah I am sorry.

I misunderstood the middle sentence in this line 

"Length: An unsigned 24-bit value representing the number of bytes after the length field. The total size of a data frame is 8 bytes + length. It is valid to have a zero-length data frame."

I've got it now 

thanks.

2012/5/17 Antonio Vicente <a...@google.com>

[William Chan (陈智昌)]

Well, we totally slipped those estimates :P We're looking at this now again. We're currently considering dropping SPDY/2 support in Chrome 23, which should reach stable tentatively around early November. That's over 2 months from now. Would any other implementations/deployments have issues with transitioning to SPDY/3 by this point? If this is problematic, please speak up! Cheers.