Re: Backwards compatibility

On Mon, Apr 2, 2012 at 11:23 AM, Peter Lepeska <bizzbyster@gmail.com> wrote:

> Right. But a more effective strategy in terms of achieving wider adoption
> of both might be to do the one and then the other b/c adoption of the speed
> part of SPDY (fewer TCP connections, multiplexing, etc) will make it much
> easier for many web sites to go HTTPS b/c it hugely reduces the performance
> hit of switching. Also, making two giant changes to your infrastructure and
> application simultaneously is daunting operationally. Much better to be
> able to roll out one and then the other.
>
> Also I've noticed that the sites that have switched to HTTPS are more
> AJAXy style web applications that do not re-download top level html with
> every click, which means fewer TCP connections to be made slower by adding
> the SSL round trip penalty. For instance, any reason why google news still
> seems to be plain HTTP? Maybe you don't know the answer to this but in
> general I'm still waiting for the first big news type site to make the
> switch. How much slower would CNN be over mobile networks if it were 100%
> https?
>
> Lastly, you had to run SPDY over 443 b/c you said you ran into problems
> with proxies and other intermediaries running over port 80. But I think
> that was primarily an issue b/c SPDY was deployed stealthily and had
> to inter-operate with existing gear to some extent whereas HTTP 2.0 will be
> publicly announced and intermediaries will have a chance to make changes to
> support it or at least insure that a fall back to 1.1 goes smoothly if not.
>


Sorry for the confusion on this last point.  No, we never tried to deploy
spdy on port 80.  We did experiments of running non-http protocols on port
80 and detected the failures.  We also knew from experience why pipelining
had failed.

Mike




>
> Thanks,
>
> Peter
>
> On Mon, Apr 2, 2012 at 2:04 PM, Mike Belshe <mike@belshe.com> wrote:
>
>>
>>
>> On Mon, Apr 2, 2012 at 10:56 AM, Peter Lepeska <bizzbyster@gmail.com>wrote:
>>
>>> Big bites do seem to go down easier than lots of little ones. The
>>> problem is that SPDY is eating *two* shit sandwiches, trying to make
>>> the web both fast and secure, at the same time. This bite is more than most
>>> can chew and so adoption will be much slower b/c of the SSL requirement, in
>>> my opinion.
>>
>>
>> It certainly doesn't make the transition happen faster, I agree with you
>> on that front.
>>
>> But responsible content providers are already moving to SSL (twitter,
>> facebook, google, etc) because they need to for user protection, data
>> integrity, and legal reasons.  We, as protocol designers, need to be making
>> secure communications much easier for everyone.  We have an opportunity to
>> do this now which may never come up again.
>>
>> Mike
>>
>>
>>
>>>
>>> Peter
>>>
>>> On Mon, Apr 2, 2012 at 1:31 PM, Mark Watson <watsonm@netflix.com> wrote:
>>>
>>>>  All - the messages exchange below was supposed to be on-list - my
>>>> mistake hitting reply instead of reply-all ...
>>>>  On Apr 1, 2012, at 1:15 PM, Mike Belshe wrote:
>>>>
>>>>
>>>>
>>>> On Sat, Mar 31, 2012 at 9:47 AM, Mark Watson <watsonm@netflix.com>wrote:
>>>>
>>>>>  Mike, all,
>>>>>
>>>>>  This thread has gone into the weeds rather and is missing the point
>>>>> of my original comment.
>>>>>
>>>>>  I did not intend a single throw-away paragraph to be a complete
>>>>> technical
>>>>> proposal.
>>>>>
>>>>>  My point was that deploying a new protocol at scale is hard. Look at
>>>>> IPv6. It's not even mainly a technical problem. There are HTTP1.x-specific
>>>>> assumptions throughout the network - people have paid money to put them
>>>>> there, so presumably they have goals which would be undermined if
>>>>> large amounts of traffic moved to a new protocol.
>>>>>
>>>>>  Whilst the fraction of HTTP1.x-compatible traffic stays close to its
>>>>> current value you will not see deployment problems with new protocols. But
>>>>> if you want to migrate large swathes of traffic to a new protocol, many
>>>>> things have to be upgraded.
>>>>>
>>>>>  Before embarking on this, then, we should have a very firm idea of
>>>>> the expected gains. Which means comparing with what can be achieved with a
>>>>> new protocol to what can be achieved through simple extensions to the
>>>>> existing one.
>>>>>
>>>>>  It seems to me, superficially, that several of the proposed
>>>>> enhancements could be done this way.
>>>>>
>>>>>  It's true that there is a region where the difference between
>>>>> 'extensions' and 'new protocol' is partly marketing. I'm not sure we should
>>>>> go there. But it's also true there is a social engineering aspect to this
>>>>> problem: people are often overly resistant to revolutionary changes and
>>>>> prefer changes that appear evolutionary.
>>>>>
>>>>>  Having said all the above, it may be sufficient that there is
>>>>> single-RTT fallback to HTTP1.1 in the presence of HTTP1.1 intermediaries.
>>>>>
>>>>
>>>>  Heh - I think we're in more agreement than it might seem.
>>>>
>>>>  We had a philosophy when designing spdy:  "If you're going to eat a
>>>> shit sandwich, take big bites".
>>>>
>>>>  What does that mean, you might ask?
>>>>
>>>>  Prior to starting SPDY, we had tried all sorts of incremental changes
>>>> to HTTP - header compressors, data compressors, bundling, multiplexing, etc
>>>> etc.  Some of these could be done with very small semantic changes to HTTP.
>>>>  But, each of those semantic changes meant that every existing HTTP
>>>> implementation out there (browsers, servers, or proxies) had to be made
>>>> aware of the change and deal with appropriately...
>>>>
>>>>  In the end, the shitty part of changing HTTP is that changing the
>>>> infrastructure is a ton of work (this is what you're rightly pointing out).
>>>>  We knew we had several significant changes to make to HTTP.   Rather than
>>>> doing them incrementally, and each one needing to figure out how to
>>>> rechange the infrastructure, we decided taking one big bite is a preferred
>>>> approach.  Solve all of these problems, but only change the infrastructure
>>>> once.
>>>>
>>>>  I hope this metaphor isn't too off color and that it demonstrates the
>>>> point.
>>>>
>>>>
>>>>  MW: Sure. Fortunately I wasn't eating breakfast at the time ...
>>>>
>>>>
>>>>
>>>>  Regarding interleaved vs non-interleaved streams:  It sure seems
>>>> easier to do what you're proposing, but I suspect that your proposal won't
>>>> work.  For example, how would you do a comet-style hanging-GET without
>>>> interleaved streams?
>>>>
>>>>
>>>>  MW: I'm not familiar with exactly what that is, but I think the
>>>> answer is use a separate connection.
>>>>
>>>>   This could be mitigated by opening up more parallel connections, but
>>>> that is non-desirable too.
>>>>
>>>>
>>>>  MW: I'm not really sure why. I can see that a parallel connections
>>>> arms race is not a good idea - but we are all talking about things that
>>>> reduce the need for parallel connections. Parallel connections are, also, a
>>>> way to get a different overall congestion control behavior in a way that is
>>>> reasonably safe.
>>>>
>>>>
>>>>  BTW - did you mean to reply to all?
>>>>
>>>>
>>>>  Yes, fixed.
>>>>
>>>>  Mike
>>>>
>>>>
>>>>
>>>>>
>>>>>  ...Mark
>>>>>
>>>>>
>>>>> Sent from my iPhone
>>>>>
>>>>> On Mar 30, 2012, at 9:18 PM, "Mike Belshe" <mike@belshe.com> wrote:
>>>>>
>>>>>
>>>>>
>>>>> On Sat, Mar 31, 2012 at 3:03 AM, Mark Watson <watsonm@netflix.com>wrote:
>>>>>
>>>>>>
>>>>>>  On Mar 30, 2012, at 4:46 PM, Mike Belshe wrote:
>>>>>>
>>>>>>
>>>>>>
>>>>>> On Fri, Mar 30, 2012 at 6:53 PM, Mark Watson <watsonm@netflix.com>wrote:
>>>>>>
>>>>>>>
>>>>>>>  On Mar 30, 2012, at 9:29 AM, William Chan (陈智昌) wrote:
>>>>>>>
>>>>>>> On Fri, Mar 30, 2012 at 6:13 PM, Mark Watson <watsonm@netflix.com>wrote:
>>>>>>>
>>>>>>>> All,
>>>>>>>>
>>>>>>>> I'd like to make a plea/request/suggestion that wherever possible
>>>>>>>> new features be added incrementally to HTTP1.1, in a backwards compatible
>>>>>>>> way, in preference to a "new protocol" approach. A "new protocol" is
>>>>>>>> required only if it is not technically possible (or especially awkward) to
>>>>>>>> add the feature in a backwards compatible way.
>>>>>>>>
>>>>>>>> The object should be to enable incremental implementation and
>>>>>>>> deployment on a feature by feature basis, rather than all-or-nothing.
>>>>>>>> HTTP1.1 has been rather successful and there is an immense quantity of code
>>>>>>>> and systems - including intermediaries of various sorts - that work well
>>>>>>>> with HTTP1.1. It should be possible to add features to that code and those
>>>>>>>> systems without forklifting substantial amounts of it. It is better if
>>>>>>>> intermediaries that do not support the new features cause fallback to
>>>>>>>> HTTP1.1 vs the alternative of just blocking the new protocol. In
>>>>>>>> particular, it should not cost a round trip to fall back to HTTP1.1. It is
>>>>>>>> often lamented that the Internet is now the "port-80 network", but at least
>>>>>>>> it is that.
>>>>>>>>
>>>>>>>
>>>>>>>  Don't forget port 443. And I agree, it should not cost a round
>>>>>>> trip to fallback to HTTP/1.1.
>>>>>>>
>>>>>>>
>>>>>>>>
>>>>>>>> Many of the features contemplated as solutions to the problems of
>>>>>>>> HTTP1.1 can be implemented this way: avoiding head-of-line blocking of
>>>>>>>> responses just requires a request id that is dropped by intermediaries that
>>>>>>>> don't support it and echoed on responses. Request and response header
>>>>>>>> compression can be negotiated - again with a request flag that is just
>>>>>>>> dropped by unsupporting intermediaries. Pipelined requests could be
>>>>>>>> canceled with a new method. These things are responsible for most of the
>>>>>>>> speed improvements of SPDY, I believe.
>>>>>>>>
>>>>>>>
>>>>>>>  It's unclear to me how this would work. Are you suggesting waiting
>>>>>>> a HTTP request/response pair to figure out if the id gets echoed, before
>>>>>>> trying to multiplex requests? Or would you rely on HTTP pipelining as a
>>>>>>> fallback if the ids don't get echoed?
>>>>>>>
>>>>>>>
>>>>>>>  Send the requests (yes, pipelined). If they come back without ids,
>>>>>>> then they are coming back in the order they were sent. If they come back
>>>>>>> with ids, then that tells you which response is which.
>>>>>>>
>>>>>>
>>>>>>  You can't do this until you've got confirmation that the server is
>>>>>> going to give you a HTTP/1.1 response.  It could come back HTTP/1.0.
>>>>>>
>>>>>>  So do we first have to do a 1.1 request successfully (with 1.1
>>>>>> response) before we can ever attempt to do a pipelined upgrade?
>>>>>>
>>>>>>
>>>>>>  For each server, yes. Servers don't often get downgraded from 1.1
>>>>>> to 1.0, so you could cache that result for quite a while.
>>>>>>
>>>>>>
>>>>>>
>>>>>>>
>>>>>>>  The former incurs a large latency cost. The latter depends very
>>>>>>> much on how deployable you view pipelining on the overall internet.
>>>>>>>
>>>>>>>
>>>>>>>  It's certainly widely deployed in servers and non-transparent
>>>>>>> proxies. Non-supporting non-transparent proxies are easily detected. Yes,
>>>>>>> broken transparent proxies are a (small) problem, but you can also detect
>>>>>>> these.
>>>>>>>
>>>>>>>  I am skeptical it is sufficiently deployable and we on Chromium
>>>>>>> are gathering numbers to answer this question (
>>>>>>> http://crbug.com/110794).
>>>>>>>
>>>>>>>
>>>>>>>  Our internal figures suggest that more than 95% of users can
>>>>>>> successfully use pipelining. That's an average. On some ISPs the figure is
>>>>>>> much lower.
>>>>>>>
>>>>>>
>>>>>>  Do you a research result to cite here?  Sounds interesting.  5%
>>>>>> failures is pretty high.
>>>>>>
>>>>>>
>>>>>>  No, these are just internal figures right now. Yes, it does seem
>>>>>> high, I've a feeling many of those are false negatives where we avoid
>>>>>> pipelining unnecessarily.
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>>
>>>>>>>  Also, pipelining is clearly inferior to multiplexing.
>>>>>>>
>>>>>>>
>>>>>>>  Yes, but perhaps in practice not by much. To render a page you
>>>>>>> need all the objects, so from a time-to-page-load perspective it makes no
>>>>>>> difference how you multiplex them, as long as the link remains fully
>>>>>>> utilized. To see some difference you need some notion of object importance
>>>>>>> and some metric for 'page loaded except for the unimportant bits'. You send
>>>>>>> the most important requests first. Even then it's not clear that
>>>>>>> multiplexing within objects will perform significantly better than object
>>>>>>> by object sending.
>>>>>>>
>>>>>>
>>>>>>
>>>>>>  Don't forget that pipelining does *not* apply to all resources.
>>>>>>  Even when pipelining works end-to-end, browsers need to take great care
>>>>>> not to accidentally pipeline a critical resource behind a slow one (like a
>>>>>> hanging GET).  This leads to browsers doing tricks like "only pipeline
>>>>>> images together" or other subsets of pipelining.
>>>>>>
>>>>>>
>>>>>>  I was assuming you could avoid the head-of-line blocking with an
>>>>>> extension that allows out-of-order responses.
>>>>>>
>>>>>>
>>>>>>  But when we consider pipelining a fallback for SPDY, this all falls
>>>>>> apart.  SPDY did not have these restrictions.  So now, SPDY would need to
>>>>>> run in some sort of degraded mode for what types of requests are pipelined
>>>>>> just so fallback to a HTTP/1.1 protocol that the server might not support
>>>>>> (because it could be HTTP/1.0) or which the user might not support because
>>>>>> he's one of the unlucky 5% (according to Mark's data) where pipelining just
>>>>>> breaks altogether.
>>>>>>
>>>>>>  All in all, we've now compounded 3 unique restrictions on the
>>>>>> initial set of requests in order to work around past bugs in order to
>>>>>> support use of the Upgrade header.
>>>>>>
>>>>>>  Realistically, you're going to get one request on the upgrade, and
>>>>>> you'll have to wait to open up the parallel requests.  This is a
>>>>>> significant restriction of the Upgrade process - it requires a round trip
>>>>>> to kick into the real protocol at full gear.
>>>>>>
>>>>>>  This is highly annoying, but for initial web page loads, probably
>>>>>> won't be a significant burden because the browser initially only has one
>>>>>> URL.  For page reloads, or validations, or subsequent pages on reconnect,
>>>>>> it will be a performance hit.
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>> Interleaving within responses does require some kind of framing
>>>>>>>> layer, but I'd like to learn why anything more complex than interleaving
>>>>>>>> the existing chunked-transfer chunks is needed (this is also especially
>>>>>>>> easy to undo).
>>>>>>>>
>>>>>>>
>>>>>>>  Sorry, I'm not sure I understand what you mean by interleaving
>>>>>>> existing chunked-transfer chunks. Are these being interleaved across
>>>>>>> different responses (that requires framing, right?).
>>>>>>>
>>>>>>>
>>>>>>>  Interleaving data from multiple responses requires some kind of
>>>>>>> framing, yes. Chunked transfer encoding is a kind of framing that is
>>>>>>> already supported by HTTP. Allowing chunks to be associated with different
>>>>>>> responses would be a simple change. Maybe it feels like a hack ? That was
>>>>>>> my question: why isn't a small enhancement to the existing framing
>>>>>>> sufficient ?
>>>>>>>
>>>>>>>
>>>>>>  Even if you could hack it into a chunk, thats a real jumbled mess.
>>>>>>  Why do you want to do this?  It doesn't give you backward compatibility in
>>>>>> any way (existing browsers won't know what to do with these nonstandard
>>>>>> chunks anyway), its just a mess for the sake of a mess?
>>>>>>
>>>>>>
>>>>>>  So, your answer to my question is fairly clear ;-)
>>>>>>
>>>>>>  It doesn't feel like such a 'mess' to me - we're talking about
>>>>>> negotiating use of new protocol elements. They're only used if both ends
>>>>>> support them so, yes, the only kind of backwards compatibility is that the
>>>>>> use of framing is negotiated, rather than assumed from the start. My point
>>>>>> was that you don't need a whole shim layer to do this, because HTTP already
>>>>>> has framing. Perhaps it makes little difference, but it means you can
>>>>>> develop and deploy functionality incrementally, rather than all-or-nothing.
>>>>>>
>>>>>
>>>>>  Your approach is just out-of-order pipelining, right?  It's not an
>>>>> interleaved multiplexing system.  And you're right, you don't necessarily
>>>>> need a full framing layer to support that.  (unless you want flow control,
>>>>> which you probably do, but haven't considered yet)
>>>>>
>>>>>  We can do a lot better than that, thats all.
>>>>>
>>>>>  BTW - more than one implementor has come to me and said, "wow - spdy
>>>>> framing was really easy to implement".  It's not like the framing layer is
>>>>> a hard concept.
>>>>>
>>>>>  I guess overall - I'm just not sure what your goals are.  You seem
>>>>> to want it to look like HTTP even though it won't be HTTP and even though
>>>>> you sacrificed a key part of the performance.  But what is the point of
>>>>> that?  You're no longer trying to make it as fast as you can, so who is
>>>>> your target market?
>>>>>
>>>>> Mike
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>>
>>>>>>
>>>>>>>
>>>>>>>>
>>>>>>>> Putting my question another way, what is the desired new feature
>>>>>>>> that really *requires* that we break backwards compatibility with the
>>>>>>>> extremely successful HTTP1.1 ?
>>>>>>>>
>>>>>>>
>>>>>>>  Multiplexing,
>>>>>>>
>>>>>>>
>>>>>>>  See my question above
>>>>>>>
>>>>>>>  header compression,
>>>>>>>
>>>>>>>
>>>>>>>  Easily negotiated: an indicator in the first request indicates
>>>>>>> that the client supports it. If that indicator survives to the server, the
>>>>>>> server can start compressing response headers right away. If the client
>>>>>>> receives a compressed response it can start compressing future requests on
>>>>>>> that connection. It's important that this indicator be one which is dropped
>>>>>>> by intermediaries that don't support compression.
>>>>>>>
>>>>>>>  prioritization.
>>>>>>>
>>>>>>>
>>>>>>>  I think you mean "re-priortization". I can send requests in
>>>>>>> priority order - what I can't do is change that order to response to user
>>>>>>> actions. How big a deal is this, vs closing the connection and re-issuing
>>>>>>> outstanding requests in the new order ?
>>>>>>>
>>>>>>
>>>>>>  Its the difference between web pages rendering faster or slower.
>>>>>>  Load up 100 image requests on your twitter page, and then fetch the images
>>>>>> before the JS.  The page loads slower unless you lower the priority of the
>>>>>> images.  But you still don't want to add serialization delays that HTTP has.
>>>>>>
>>>>>>  BTW - the effects of priorities has been measured, and you're
>>>>>> welcome to use the existing benchmarking harness to verify yourself that
>>>>>> these things are true in real code rather than just theory.  (see
>>>>>> dev.chromium.org/spdy).  I wish I had published the tests when I did
>>>>>> this long ago - spent a lot of time on it.
>>>>>>
>>>>>>
>>>>>>  Again, I don't think you need anything more than the basic
>>>>>> possibility to return responses out-of-order to get most of the gains.
>>>>>>
>>>>>
>>>>>
>>>>>
>>>>>>  Send the requests in priority order and have the server return them
>>>>>> in priority order, unless a response is not available in which case other
>>>>>> responses can push ahead. The absence of interleaving within responses just
>>>>>> reduces the granularity. Request the JS first, then the 100 images. With
>>>>>> interleaving, if the JS is available half way through sending image 3, we
>>>>>> can start sending the JS right there. Without interleaving you have to wait
>>>>>> until the end of image 3.
>>>>>>
>>>>>>  What you don't have is, as I said, "re-prioritization", where the
>>>>>> client can change its mind about the priority order after sending the
>>>>>> requests - you'd have to close the connection and send the requests again.
>>>>>>
>>>>>>  Not perfect, but I feel you could get a good chunk of the gains,
>>>>>> with out-of-order responses and negotiated compression.
>>>>>>
>>>>>>  Set aside that the significant advantages of small incremental
>>>>>> changes to a well-understood, widely deployed, very successful protocol vs
>>>>>> invention and all-at-once deployment of a new one.
>>>>>>
>>>>>>  …Mark
>>>>>>
>>>>>>
>>>>>> Mike
>>>>>>
>>>>>>
>>>>>>
>>>>>>>
>>>>>>>  …Mark
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>>
>>>>>>>> …Mark
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>
>>>>
>>>
>>
>