Don't kill SPDY/2 (just yet)

[Piotr Sikora]

Hello,
I asked you guys to keep SPDY/2 support around for a while
in the past [0], but apparently my reasoning wasn't good enough
and both Chrome [1] and Firefox [2] decided to drop it anyway,
so let's try this one more time...

I scanned Alexa's top 100k websites to check the adoption
of SPDY and the results aren't very suprising:

| SPDY | count |
------------------------------------------------------
Google (properties) | 4a4, 3.1, 3 | 624 |
Google (App Engine, PageSpeed) | 4a4, 3.1, 3 | 58 |
Twitter | 3.1, 3 | 3 |
------------------------------------------------------
Facebook | 3, 2 | 6 |
Apache | 3, 2 | 25 |
unknown | 3, 2 | 5 |
------------------------------------------------------
CloudFlare (nginx) | 2 | 1504 |
WordPress.com (nginx) | 2 | 78 |
nginx | 2 | 290 |
unknown | 2 | 18 |
------------------------------------------------------
total | 3+ | 721 |
total | 2 | 1890 |

By dropping SPDY/2, you're effectively dropping SPDY support
for 72% of SPDY-enabled websites...

If we exclude "big installations" (Google, Twitter, Facebook,
CloudFlare & WordPress.com) then you're dropping SPDY support
for 91% (!!!) of SPDY-enabled websites...

Is that really what you want to do?

If you really need to drop one version to ease the development
then why not SPDY/3? All SPDY-enabled websites support either
SPDY/2 or SPDY/3.1, so this change wouldn't hurt anyone.

Also, SPDY/2 was supposed to be EOL'ed a few months after SPDY/4
was finalized and that didn't happen yet, so...

Any chance for you guys to reconsider your decision?

[0] https://groups.google.com/d/msg/spdy-dev/A0sCEnZBEcs/J7lVYt8JenkJ
[1] https://code.google.com/p/chromium/issues/detail?id=303957
[2] https://bugzilla.mozilla.org/show_bug.cgi?id=912550

Best regards,
Piotr Sikora

[Mike Belshe]

Cloudflare could ship an open source Spdy 3.... :-)

--

---
You received this message because you are subscribed to the Google Groups "spdy-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to spdy-dev+u...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

[Ilya Grigorik]

Pedantic point: number of hosts != amount of traffic. I think just looking
at host count misses the larger picture...

Besides, I think the actual issue here is that both Wordpress and
Cloudflare run on nginx, which is currently behind the ball on SPDYv3. In
other words, we should push on nginx to get their stuff in order and then
get you guys to upgrade your servers! (Same goes for wordpress).

[Piotr Sikora]

Hey Ilya,

> Pedantic point: number of hosts != amount of traffic. I think just looking
> at host count misses the larger picture...

I'm very well aware of that, but I can't measure the amount of SPDY
traffic worldwide.

If you can and/or want to share a better data than number of hosts
then I'm all ears :)

> Besides, I think the actual issue here is that both Wordpress and
> Cloudflare run on nginx, which is currently behind the ball on SPDYv3. In
> other words, we should push on nginx to get their stuff in order and then
> get you guys to upgrade your servers! (Same goes for wordpress).

I disagree. The issue is that before SPDY/3.1 (spec released a bit
over a month ago) there was nothing to work on.

It was said number of times on this mailing list that there were some
bad decisions made for SPDY/3, so from my point of view SPDY/3 wasn't
worth any development time and I was waiting for SPDY/4 (or SPDY/3.1
for that matter) spec to get finalized before I would even start
thinking about it.

Best regards,
Piotr Sikora

[William Chan (陈智昌)]

Thanks for raising this concern. How much time do you think you need?

Best regards,
Piotr Sikora

[Patrick McManus]

Hi Piotr,

I don't think of it as dropping spdy support - we're asking people to stay on the spdy development train because spdy is an experimental protocol meant to inform the standardization of http/2 (and beyond). We've learned all we need to know about spdy/2 - some wider experience with the changes in spdy/3. beyond the big implementations you cite below would be very welcome. Indeed, turning spdy/2 off is meant to incent that kind of deployment! These changes are paced over a year apart - so it isn't moving too fast to track imo.

spdy/2 is removed in firefox 27 - that won't hit the release channel until Jan 2014. So there is time to work on server side code and stay on the trains by doing a spdy/3.1 imlpementation. How much time would you anticipate needing to do such a thing?

-P

[Hasan Khalil]

On Fri, Nov 1, 2013 at 12:04 AM, Piotr Sikora <pi...@cloudflare.com> wrote:

It was said number of times on this mailing list that there were some
bad decisions made for SPDY/3, so from my point of view SPDY/3 wasn't
worth any development time and I was waiting for SPDY/4 (or SPDY/3.1
for that matter) spec to get finalized before I would even start
thinking about it.

As a SPDY implementor, I've found the delta between SPDY 2 and SPDY 3 to be fairly small and easily implemented. Please do let us know if you run into any problems implementing it -- we appreciate the feedback!

    -Hasan

[Piotr Sikora]

Hey Will,

> How much time do you think you need?

If I could drop everything I work on right now, then I'd say ~2
months... But I can't ;)

I think that's reasonable (if not a little optimistic) timeframe:
- end of 03/2014 (SPDY/3.1 + 6 months) - SPDY/3.1 available as a
patchset for nginx, deployed on CloudFlare and possibly WordPress.com,
- end of 06/2014 (SPDY/3.1 + 9 months) - SPDY/3.1 released as part of nginx,
- end of 09/2014 (SPDY/3.1 + 12 months) - SPDY/3.1 actually deployed
on significant portion of the SPDY installations.

Keep in mind that this is timeframe from my point of view, and not Nginx, Inc.

Best regards,
Piotr Sikora

[Piotr Sikora]

Hey Patrick,

> we're asking people to stay on the spdy development train

That's a nice description of the problem, but a little longer "heads
up" would be appreciated ;)

> Indeed, turning spdy/2 off is meant to incent that kind of deployment! These
> changes are paced over a year apart - so it isn't moving too fast to track
> imo.

Maybe I missed a memo (or this was discussed off-list), but from my
point of view, SPDY/4 was supposed to be the next "stable" release and
last time we had this discussion, William said [0] that SPDY/2 will be
retired months after SPDY/4 was finalized.

SPDY/3.1 came out of nowhere (at least for me) and was finalized a
month ago. While I'm more than happy to consider SPDY/3.1 as the next
"stable" release, having less than 4 months from spec to production
seems a little fast to me and it's definitely not "over a year apart".

> spdy/2 is removed in firefox 27 - that won't hit the release channel until
> Jan 2014. So there is time to work on server side code and stay on the
> trains by doing a spdy/3.1 imlpementation.

I think what upsets me the most about this is the fact that there is
no real technical reason to kill SPDY/2 right now... Chrome is able to
support (at least) 3 SPDY versions at the same time, Firefox is able
to support (at least?) 2 versions, so it's not like you can handle
only one version at the time and it would require a lot of work to add
support for another one without killing SPDY/2.

[0] https://groups.google.com/d/msg/spdy-dev/A0sCEnZBEcs/7bDcHgsP00MJ

Best regards,
Piotr Sikora

[Hasan Khalil]

On Fri, Nov 1, 2013 at 7:13 PM, Piotr Sikora <pi...@cloudflare.com> wrote:

I think what upsets me the most about this is the fact that there is
no real technical reason to kill SPDY/2 right now...

The #1 reason that I want to kill SPDY 2 right now is entirely technical. The maintenance overhead was too high for me as a server implementor.

    -Hasan

[Piotr Sikora]

Hi Hasan,

> The #1 reason that I want to kill SPDY 2 right now is entirely technical.
> The maintenance overhead was too high for me as a server implementor.

I should have been more clear about that - I meant on the browser-side.

Thanks to the hard work of the browser guys, servers need to support
only one version (IMHO) and I intend to replace SPDY/2 with SPDY/3.1,
not support both. Please correct me if I'm wrong.

Best regards,
Piotr Sikora

[Hasan Khalil]

I agree that servers have less pressure to support multiple simultaneous versions than browsers do, but what doesn't change as much is implementation overhead -- supporting multiple protocols is a pain regardless of endpoint type, IMHO.

    -Hasan

Best regards,
Piotr Sikora

[Patrick McManus]

As discussed, we need to keep the spdy trains moving and that inherently means removing support for old versions as new one become available and the standards track moves forward.

However, after talking to some of the server operators I don't see any harm in a slight delay to help ease the transition. Based on that, we will slip the removal of spdy by one release from Firefox 27 to Firefox 28. My understanding is that Chrome will do something similar so that we can assure similar levels of support on the Internet, but they'll speak for themselves (as always :)).

That would put the release date of both browsers without spdy/2 ROUGHLY at the end of February 2014. (there is a fair bit of uncertainty about release dates).

-P

[Chris Bentzel]

Plan is to keep SPDY/2 in for Chrome 32 but remove for Chrome 33.

https://code.google.com/p/chromium/issues/detail?id=318651
https://code.google.com/p/chromium/issues/detail?id=304955