When to EOL spdy/2

209 views
Skip to first unread message

Roberto Peon

unread,
Aug 21, 2012, 3:33:44 PM8/21/12
to spdy...@googlegroups.com
(this is forked from thread entitled: "Google SPDY/3 implementations are coming").


 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?

Saying it again, Chrome is proposing to drop SPDY/2 support in two months.

If this is not something you want, please do speak up now so we have your input into these plans before the plan is finalized.

Another potential proposal is to drop SPDY/3, since its version of flow control has been a pain to get working correctly and stay with SPDY/2 only until some moths after the SPDY/4 spec has been finalized.

Now would be a good time to comment...
-=R

Simone Bordet

unread,
Aug 21, 2012, 5:54:26 PM8/21/12
to spdy...@googlegroups.com
Hi,
What is the status of spdy/3 adoption among the "big" sites ?
Webtide.com supports both spdy/2 and spdy/3, but perhaps you have
numbers for others ?

I have the gut feeling that it may be too early to drop spdy/2, but I
may be wrong.
Apache and nginx both support spdy/3 already ?

Simon
--
http://cometd.org
http://webtide.com
Developer advice, services and support
from the Jetty & CometD experts.
----
Finally, no matter how good the architecture and design are,
to deliver bug-free software with optimal performance and reliability,
the implementation technique must be flawless. Victoria Livschitz

Ido Safruti

unread,
Aug 21, 2012, 6:04:56 PM8/21/12
to Roberto Peon, spdy...@googlegroups.com
Hi Roberto,
Thanks for the shout-out.
At Akamai we just rolled out SPDY/2 support onto our network. We are strong supporters of the idea that SPDY is experimental, and that we should EOL previous versions eventually.
That said, I think it would be friendlier to give a longer notice for EOL, as timelines when customers and larger systems are involved tends to be longer…
Given that the dual support is anyhow implemented on the browser side the approach I would like to see is one of the following:
  1. Giving something like a 6 month notice on EOL of a version, so that customers/users/people deploying and experimenting with SPDY can plan ahead for it.
  2. Always supporting the 2 last version – that is, support SPDY/2 until SPDY/4 is out. Personally I believe that once the dual support is already implemented supporting it for a bit longer should be painful, but really help coordinating rollouts
  3. The last option you mentioned may also make sense, but realistically speaking- I think that it will end up to be identical to #2, as I doubt SPDY/3 will be removed…
Bottom line from our end – is that we would appreciate a longer notice, and a "clearer" roadmap on EOL, even though it is an experimental technology. Especially given the efforts by Google and the spdy community to encourage people to implement and test  it.

- Ido

Roy T. Fielding

unread,
Aug 21, 2012, 6:09:16 PM8/21/12
to spdy...@googlegroups.com
On Aug 21, 2012, at 2:54 PM, Simone Bordet wrote:
> Apache and nginx both support spdy/3 already ?

AFAIK, nobody has contributed any SPDY implementation to
Apache HTTP Server, nor volunteered to work on it within
the project. The mod_spdy work is a Google project.

Volunteers are welcome to join d...@httpd.apache.org

....Roy

Hasan Khalil

unread,
Aug 21, 2012, 6:10:34 PM8/21/12
to spdy...@googlegroups.com
mod_spdy has supported SPDY/3 for quite some time now.

    -Hasan

Ryan Hamilton

unread,
Aug 21, 2012, 6:14:33 PM8/21/12
to spdy...@googlegroups.com
Hi Roy,

Can you elaborate what you meant by mod_spdy not being contributed to the Apache HTTP Server?  It's generally available to end users, but I gather you're referring to its availability as part of the core server distribution? 

Cheers,

Ryan

Matthieu Tourne

unread,
Aug 21, 2012, 6:19:09 PM8/21/12
to spdy...@googlegroups.com, Roberto Peon, Valentin Bartenev, and...@nginx.com
Hi Roberto, and thank you for the heads up! 

Nginx just got SPDY/2 support very recently and it's still under development here: http://nginx.org/patches/spdy/
The code is slowly starting to mature, and it would be difficult to jump ship to SPDY/3 right now.

(That's what we're using here at CloudFlare to offer SPDY as a Beta to any customer that already has an SSL cert with us).

I would second Ido here, it would be great if SPDY/2 could be supported up until SPDY/4 is rolled out.

Regards,

Matthieu.

William Chan (陈智昌)

unread,
Aug 21, 2012, 7:02:36 PM8/21/12
to spdy...@googlegroups.com
On Tue, Aug 21, 2012 at 3:04 PM, Ido Safruti <saf...@gmail.com> wrote:
Hi Roberto,
Thanks for the shout-out.
At Akamai we just rolled out SPDY/2 support onto our network. We are strong supporters of the idea that SPDY is experimental, and that we should EOL previous versions eventually.
That said, I think it would be friendlier to give a longer notice for EOL, as timelines when customers and larger systems are involved tends to be longer…
Given that the dual support is anyhow implemented on the browser side the approach I would like to see is one of the following:
  1. Giving something like a 6 month notice on EOL of a version, so that customers/users/people deploying and experimenting with SPDY can plan ahead for it.
While we have slipped our announced dates many times, we did announce our intention to EOL SPDY/2 awhile back https://groups.google.com/forum/#!msg/spdy-dev/zvA6Ohqs9Ew/8kkBLYMniQoJ. Perhaps we slipped our estimates so many times during that thread no one believed that we would actually drop SPDY/2 support :) In any case, while we want to apply some pressure to get people to switch over, we have no intention of screwing anyone over. How much more time would y'all like? 6 months from now? I'd prefer less than that if possible. Basically, I'd like to take the lowest value that you and other implementers think is reasonable, since I think we're all on the same page about deprecating old versions. These emails are simply our attempt to prod everyone forward.
  1. Always supporting the 2 last version – that is, support SPDY/2 until SPDY/4 is out. Personally I believe that once the dual support is already implemented supporting it for a bit longer should be painful, but really help coordinating rollouts
This is a bit harder, since that means we'd have to have 3 versions supported in browsers, which is a minor PITA, although admittedly doable. Is this necessary? Or is it more that you don't want to transition to SPDY/3 and want to go straight to SPDY/4? I think folks in general only want to have to support 2 versions. Since it's generally the browser support that pushes us forward, that means that the browser has to drop the old version before it starts hacking on the next version. I'd like to hear from Firefox (Pat) to see how much work he thinks it'd be to support another version in Firefox without dropping SPDY/2 first. It's really the testing that's annoying for us more than anything. So yeah, my preference is for us (Chromium) to be able to drop SPDY/2 support when we start hacking on SPDY/4. But y'all really require this, it's workable.
  1. The last option you mentioned may also make sense, but realistically speaking- I think that it will end up to be identical to #2, as I doubt SPDY/3 will be removed…
Actually, Roberto and I discussed this and we're willing to consider it. Mainly because we believe the SPDY/3 flow control has proved too broken for us to realize much gain from it, so we'd understand if other implementers didn't really want to support it. We are planning to fix it in SPDY/4. That reminds me, that I'll be very interested to hear from Akamai's perspective about flow control issues with SPDY/2 (how much head of line blocking do you get?). If you can share it, let's do it in a separate email thread.

Bottom line from our end – is that we would appreciate a longer notice, and a "clearer" roadmap on EOL, even though it is an experimental technology. Especially given the efforts by Google and the spdy community to encourage people to implement and test  it.

I'll take responsibility here, I should have been more communicative. Indeed, I forgot about re-pinging the previous email threads until rch@ reminded us at Google. Sorry about that. We'll try to be better. Cheers.

Roy T. Fielding

unread,
Aug 21, 2012, 7:36:14 PM8/21/12
to spdy...@googlegroups.com
On Aug 21, 2012, at 3:14 PM, Ryan Hamilton wrote:

Hi Roy,

Can you elaborate what you meant by mod_spdy not being contributed to the Apache HTTP Server?

I mean that no implementation of SPDY (including mod_spdy) has been
submitted to the ASF as a contribution, so Apache does not support it yet.

It's generally available to end users, but I gather you're referring to its availability as part of the core server distribution? 

Yes.  Third party modules are great, but they aren't Apache
until the nonprofit foundation has change control and agrees
to maintain it on a long-term basis (which only happens if
volunteers show up to do the work).

Google folks have been working on projects at Apache for a
long time, and Google is Apache's oldest and most prolific
sponsor, so I don't know why mod_spdy hasn't been contributed
within the server project.  There's no reason why it can't.
If the goal is to have Apache support SPDY natively, then
that's the obvious next step, but I don't know the opinions of
the mod_spdy developers; Apache only accepts voluntary contributions.

....Roy

William Chan (陈智昌)

unread,
Aug 21, 2012, 7:39:46 PM8/21/12
to spdy...@googlegroups.com, Matthew Steele
+mdsteele

I thought mdsteele said he talked with y'all, but maybe not? Anyway, let's hear from the man himself. Matt, what's the deal here? If the Apache folks are willing to accept it, can we hand mod_spdy over to them?

William Chan (陈智昌)

unread,
Aug 21, 2012, 7:44:30 PM8/21/12
to Matthew Steele, roy.fi...@gmail.com, Roberto Peon, Bryan McQuade
[ bcc: spdy-dev ]
Oh, Matt's on vacation. We'll get an answer next week. Roy, how about we take this offline? I think most of us at Google would like to get SPDY in Apache, so if that's doable, we'd be happy to work with y'all!

Roberto Peon

unread,
Aug 21, 2012, 8:20:18 PM8/21/12
to Safruti, Ido, spdy...@googlegroups.com
On Tue, Aug 21, 2012 at 2:55 PM, Safruti, Ido <i...@akamai.com> wrote:
Hi Roberto,
Thanks for the shout-out.
At Akamai we just rolled out SPDY/2 support onto our network. We are strong supporters of the idea that SPDY is experimental, and that we should EOL previous versions eventually.
That said, I think it would be friendlier to give a longer notice for EOL, as timelines when customers and larger systems are involved tends to be longer…
Given that the dual support is anyhow implemented on the browser side the approach I would like to see is one of the following:
  1. Giving something like a 6 month notice on EOL of a version, so that customers/users/people deploying and experimenting with SPDY can plan ahead for it.
  1. Always supporting the 2 last version – that is, support SPDY/2 until SPDY/4 is out. Personally I believe that once the dual support is already implemented supporting it for a bit longer should be painful, but really help coordinating rollouts
  1. The last option you mentioned may also make sense, but realistically speaking- I think that it will end up to be identical to #2, as I doubt SPDY/3 will be removed…
    It really comes down to what browsers are asking to negotiate-- it is a quick change to eliminate SPDY/3 from the list of offered protocols in NPN, and thus be able to delete the code in the browser.
    Servers can do the same-- all "old" browsers which would offer to speak SPDY/3 also offer SPDY/2, so it should be completely safe to cease to offer SPDY/3 in the list of offered protocols, and then remove the code.

     
    Bottom line from our end – is that we would appreciate a longer notice, and a "clearer" roadmap on EOL, even though it is an experimental technology. Especially given the efforts by Google and the spdy community to encourage people to implement and test it.

    Understood, that is why we're here asking-- we want some good feedback on when and how to do this migration/EOLing!


    -=R

    Roberto Peon

    unread,
    Aug 21, 2012, 8:22:59 PM8/21/12
    to spdy...@googlegroups.com
    Matthieu--

    Would you have any objections to simply skipping SPDY/3 and having SPDY/2 around until some months after SPDY/4 has been finalized (1-2 months from now)?
    I think SPDY/3 was a good learning experience and would prefer for as few people to *have* to learn from it as possible :)

    -=R

    Matthieu Tourne

    unread,
    Aug 21, 2012, 9:16:00 PM8/21/12
    to spdy...@googlegroups.com, Valentin Bartenev
    On Tue, Aug 21, 2012 at 5:22 PM, Roberto Peon <fe...@google.com> wrote:
    Matthieu--

    Would you have any objections to simply skipping SPDY/3 and having SPDY/2 around until some months after SPDY/4 has been finalized (1-2 months from now)?
    I think SPDY/3 was a good learning experience and would prefer for as few people to *have* to learn from it as possible :)
     

    I think this would be great and leave a few months to the Nginx world, to stabilize all the groundwork required around SPDY.

    Otherwise, It sounds very reasonable to retire SPDY/2 shortly after SPDY/4 has been finalized and there is a client/server reference implementation.

    Thank you,
    Matthieu.

    Patrick McManus

    unread,
    Aug 21, 2012, 9:17:38 PM8/21/12
    to spdy...@googlegroups.com
    Tricky stuff.

    I do not favor offering the set of {2,4} - I think that increases the
    risk of spdy/2 becoming a defacto standard which is the biggest risk in
    this process. Skipping revisions sends that signal; imo.

    From a code maintenance pov with Firefox I'm fine with shipping {2,3}
    until 4 comes along at which time I would expect to switch to {3,4}...
    realistically that means ~8 weeks from now for v4 to be written (just to
    take a number roberto mentioned), ~4 weeks for implementation and ~15
    weeks for it to migrate and stabalize through our prelease channels
    before being in full release. That's about 6 months more of v2
    availability. spdy/3 goes to release channel in firefox ~7 weeks from
    now as part of firefox 16.

    Having two versions in tree hasn't been a problem for me - but I've
    structured it to expect that.

    Any variance is probably due to the complexity of v4 both in getting it
    documented, implemented, tested, and scheduled around any other fire drills.

    -P

    Matthieu Tourne

    unread,
    Aug 21, 2012, 10:38:07 PM8/21/12
    to spdy...@googlegroups.com
    I don't think anyone has been talking about keeping {2,4} while killing 3, but merely transitioning from {2,3} to {3,4} with a very short period where {2,3,4} might coexist.
    At least, that's my understanding.

    People who implement the server sides of things, can then decide to skip directly to 4, kill 2 and never really offer 3 in the process.

    Also, if there aren't really any browser supporting it anymore, it doesn't matter if the server still advertises SPDY/2.

    Regards, 
    Matthieu. 

    Piotr Sikora

    unread,
    Aug 22, 2012, 10:53:49 PM8/22/12
    to spdy...@googlegroups.com
    Hey,

    > I do not favor offering the set of {2,4} - I think that increases the risk
    > of spdy/2 becoming a defacto standard which is the biggest risk in this
    > process. Skipping revisions sends that signal; imo.

    But is this really a bad thing? SPDY/2 is "good enough" and I would like to
    see {2,latest} set supported by the browsers for at least a few months after
    SPDY gets standardized.

    I see two reasons for it:

    1) Adoption rate on the server-side is extremely slow.

    People just install whatever stable version of the web server is available
    in packages from the operating system at the installation / system upgrade
    time and then almost never update it.

    To put some numbers behind this, I've checked which web servers are powering
    TOP30k websites (according to Alexa)... Out of the 30k tested websites 13434
    (44.78%) were powered by Apache and 6225 (20.75%) were powered by nginx. Out
    of those only 9209 (46.84%) presented full version string that I could match
    against release dates.

    year | count| percent
    ----------------------
    older | 3239 | 35.17%
    2010 | 2264 | 24.58%
    2011 | 1466 | 15.92%
    2012 | 2240 | 24.32%
    ----------------------
    total | 9209 | 100.00%

    As you can see, only ~25% of the servers is using "fairly recent" (2012)
    releases and only ~40% of the servers is using "non-ancient" (2011+)
    releases.

    I expect to see stable releases of Apache & nginx working with SPDY out ot
    the box around November/December, maybe later, which means that they would
    get deployed and used in production for most of the 2013/2014, which means
    that either SPDY/2 or SPDY/3 should be supported by browsers in that
    timeframe, otherwise we'll end-up with the situation where most of the web
    servers support SPDY/2 and/or SPDY/3, but no browser is negotiating those
    versions anymore.

    Also, if Chrome is really planning to EOL SPDY/2 in November, then nginx's
    SPDY support is virtually dead on arrival.


    2) The risk of unexpected transport degradation.

    If browsers support only {latest-1,latest} set, then we'll definitely see
    situations in which SPDY suddenly stops working without any changes on the
    server-side (i.e. web servers with support for {2,3} and browsers moving
    from {3,4} to {4,5}).

    To make this situation even worse, if people start moving their websites
    from HTTP to HTTPS in order to leverage SPDY and improve performance and
    then, after months of "fast web", SPDY will unexpectedly stop working, the
    performance degradation will be significant (because of the SSL overhead)
    and web will become slow for everybody once again.


    Hopefully my reasoning is enough to keep SPDY/2 support for a while.

    Best regards,
    Piotr Sikora < piotr....@frickle.com >

    William Chan (陈智昌)

    unread,
    Aug 23, 2012, 11:04:13 AM8/23/12
    to spdy...@googlegroups.com
    We (Google) talked about this yesterday and think the schedule Patrick laid out here seems fine to us. So yeah, let's EOL SPDY/2 when SPDY/4 comes out, whenever that is (specwork is ongoing and no code has been written yet) :)

    Let us know if there are concerns with that.


    On Tue, Aug 21, 2012 at 6:17 PM, Patrick McManus <mcm...@ducksong.com> wrote:
    Reply all
    Reply to author
    Forward
    0 new messages