Re: Backwards compatibility

On Mon, Apr 2, 2012 at 1:59 PM, Adrien W. de Croy <adrien@qbik.com> wrote:

>
> ------ Original Message ------
> From: "Mike Belshe" <mike@belshe.com>
> To: "Peter Lepeska" <bizzbyster@gmail.com>
> Cc: "ietf-http-wg@w3.org" <ietf-http-wg@w3.org>
> Sent: 3/04/2012 6:04:16 a.m.
> Subject: Re: Backwards compatibility
>
>
>
> On Mon, Apr 2, 2012 at 10:56 AM, Peter Lepeska < <bizzbyster@gmail.com>
> 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.
>
>
> I think we will need to make an intermediate step in 1.1 land.
>
> adoption of proxy support for SSL without tunnelling, e.g.
>
> GET https:// ...
>

Sounds good to me!  But, this needs to combine with SSL to the proxy
itself.  Otherwise, you're sending an otherwise end-to-end secure request
in the clear between the client & proxy.



> Even just Gmail, FB and search etc moving to SSL/TLS is creating more and
> more pressure for proxy vendors to implement MITM.  Do we really want to
> force it in that direction?
>

Exactly - I think you and I were writing the same thing in separate threads
at the same time :-)  Even without HTTP/2.0, the world is moving to SSL at
such a rate that proxy solutions are no longer able to provide adequate
protection for corporations.

Mike




>
> Adrien
>
>
>
>
> Mike
>
>
>
>>
>>  Peter
>>
>> On Mon, Apr 2, 2012 at 1:31 PM, Mark Watson < <watsonm@netflix.com>
>> 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>
>>> 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>
>>>> mike@belshe.com> wrote:
>>>>
>>>>
>>>>
>>>>  On Sat, Mar 31, 2012 at 3:03 AM, Mark Watson < <watsonm@netflix.com>
>>>> 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>
>>>>> 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>
>>>>>> 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>
>>>>>> 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
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>
>>>
>>>
>>
>