Subject: Re: Backwards compatibility

From: Mark Nottingham <[email-masked]>
Date: Mon, 2 Apr 2012 12:54:22 -0400

On 31/03/2012, at 12:31 PM, Mark Watson wrote:

> Interesting - I knew this was not a new idea, but did not know about this draft.
> 
> Any idea why it did not catch on back then ? I could imagine at that time pipelining was not widely enough supported to make this interesting.

It'd be interesting to hear from Jeff, but my impression was that layering it into existing implementations was too difficult, and because the risks of it being misinterpreted by a slightly buggy implementation were too great.

In a way, the same reasons have also hurt pipelining adoption.

Cheers,

> 
> ...Mark
> 
> Sent from my iPhone
> 
> On Mar 31, 2012, at 3:06 AM, "Mark Nottingham" <[email-masked]> wrote:
> 
>> Hi Mark,
>> 
>> On 31/03/2012, at 3:03 AM, Mark Watson wrote:
>> 
>>> I was assuming you could avoid the head-of-line blocking with an extension that allows out-of-order responses.
>> 
>> That's been tried in the past; see:
>> http://tools.ietf.org/id/draft-mogul-http-ooo-00.txt
>> 
>> Regards,
>> 
>> --
>> Mark Nottingham
>> http://www.mnot.net/
>> 
>> 
>> 
>> 
>> 

--
Mark Nottingham
http://www.mnot.net/

---

From: Mark Watson <[email-masked]>
Date: Mon, 2 Apr 2012 17:31:03 +0000

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 <[email-masked]<mailto:[email-masked]>> 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" <[email-masked]<mailto:[email-masked]>> wrote:

On Sat, Mar 31, 2012 at 3:03 AM, Mark Watson <[email-masked]<mailto:[email-masked]>> wrote:

On Mar 30, 2012, at 4:46 PM, Mike Belshe wrote:

On Fri, Mar 30, 2012 at 6:53 PM, Mark Watson <[email-masked]<mailto:[email-masked]>> wrote:

On Mar 30, 2012, at 9:29 AM, William Chan (陈智昌) wrote:

On Fri, Mar 30, 2012 at 6:13 PM, Mark Watson <[email-masked]<mailto:[email-masked]>> 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.

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<http://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

---

From: Peter Lepeska <[email-masked]>
Date: Mon, 2 Apr 2012 13:56:39 -0400

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.

Peter

On Mon, Apr 2, 2012 at 1:31 PM, Mark Watson <[email-masked]> wrote:

>  All - the messages exchange below was supposed to be on-list - my
> mistake hitting reply instead of reply-all ...
> On Sat, Mar 31, 2012 at 9:47 AM, Mark Watson <[email-masked]> wrote:
>
>>  Mike, all,
>>
>>  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'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.
>>
>
>  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.
>
>  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 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.
>
>
>> On Mar 30, 2012, at 9:18 PM, "Mike Belshe" <[email-masked]> wrote:
>>
>>
>>
>> On Sat, Mar 31, 2012 at 3:03 AM, Mark Watson <[email-masked]> wrote:
>>
>>>
>>> On Fri, Mar 30, 2012 at 6:53 PM, Mark Watson <[email-masked]>wrote:
>>>
>>>>
>>>> On Fri, Mar 30, 2012 at 6:13 PM, Mark Watson <[email-masked]>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.
>>>>>
>>>>
>>>>> 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.
>>>>
>>>
>>>  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.
>>>
>>>
>>>
>>>
>>>>
>>>>  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?
>>>
>>>
>>>  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)
>>
>>  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
>>>>>
>>>>>
>>>>>
>>>>>
>>>>
>>>>
>>>
>>>
>>
>
>

---

From: Mike Belshe <[email-masked]>
Date: Mon, 2 Apr 2012 10:57:21 -0700

> is use a separate connection.

Oh - the browser doesn't know that any given request is a hanging GET, so
it can't know to use a separate connection in advance.  You can start
forking off new connections for every XMLHttpRequest (since they are more
likely to be hanging GETs).  But this is just one of many hacks to make
pipelining actually work at all in a real world browser.

For more info on hanging GETs - check out this:
http://en.wikipedia.org/wiki/Comet_(programming)

Commonly used for real-time communications like chat.

> get a different overall congestion control behavior in a way that is

Heh :-)  This is one of the things we're intentionally trying to rein back
in.  You should check out Jim Gettys' bufferbloat descriptions -it is
reasonably safe for low numbers of connections.  Right now we've got
browsers opening - on average - 29+ connections per page!  This is both
intentionally and accidentally subverting TCP's congestion control and
needs to be fixed soon.  Further - using fewer connections is just better -
lower latency, fewer bytes, and fewer packets.  All general networking-101
stuff that makes everything faster.  There is one counter point to this,
where you can mitigate some amount of random packet loss by opening a few
parallel connections; this is a complex topic, which I won't go into here,
but I implemented this in Chrome and FF has since implemented it too.
 These techniques will likely continue going forward, as they do work, but
they shouldn't open up the same problems as a zillion connections that HTTP
does today.

---

From: Mike Belshe <[email-masked]>
Date: Mon, 2 Apr 2012 11:04:16 -0700

> chew and so adoption will be much slower b/c of the SSL requirement, in my

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

>>  Prior to starting SPDY, we had tried all sorts of incremental changes
>> to HTTP - header compressors, data compressors, bundling, multiplexing, etc
>>> On Sat, Mar 31, 2012 at 3:03 AM, Mark Watson <[email-masked]>wrote:
>>>
>>>>
>>>>  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.
>>>>
>>>>
>>>>
>>>>
>>>>>
>>>>>> 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).
>>>>>>
>>>>>
>>>>  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
>>>>  Set aside that the significant advantages of small incremental
>>>> changes to a well-understood, widely deployed, very successful protocol vs

---

From: Patrick McManus <[email-masked]>
Date: Mon, 02 Apr 2012 14:20:05 -0400

On Mon, 2012-04-02 at 11:04 -0700, Mike Belshe 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.
> 
> 
> 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 there is a huge pent up demand for privacy. DNT is a
tangentially related concept and it tests with end users extremely well.

SPDY with TLS means we can give privacy without regressing performance.
That's HUGE all by itself.

-P

---

From: Peter Lepeska <[email-masked]>
Date: Mon, 2 Apr 2012 14:23:57 -0400

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.

Thanks,

Peter

On Mon, Apr 2, 2012 at 2:04 PM, Mike Belshe <[email-masked]> wrote:

>
>
> On Mon, Apr 2, 2012 at 10:56 AM, Peter Lepeska <[email-masked]>wrote:
>
> It certainly doesn't make the transition happen faster, I agree with you
> on that front.
>
>>> On Sat, Mar 31, 2012 at 9:47 AM, Mark Watson <[email-masked]>wrote:
>>>
>>>>  Mike, all,
>>>>
>>>> there, so presumably they have goals which would be undermined if
>>>> large amounts of traffic moved to a new protocol.
>>>>
>>>>  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.
>>>>
>>>  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 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.
>>>
>>>
>>>>>>> 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.
>>>>>>>
>>>>>>  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
>>>>>>  The former incurs a large latency cost. The latter depends very
>>>>>> much on how deployable you view pipelining on the overall internet.
>>>>>>
>>>>>>
>>>>>  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.
>>>>>
>>>>>
>>>>>  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.
>>>>>
>>>>>>> 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,
>>>>>>
>>>>>>
>>>>>>  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
>>>>>  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
>>>>>  Not perfect, but I feel you could get a good chunk of the gains,
>>>>> with out-of-order responses and negotiated compression.
>>>>>

---

From: Mike Belshe <[email-masked]>
Date: Mon, 2 Apr 2012 12:04:39 -0700

On Mon, Apr 2, 2012 at 11:23 AM, Peter Lepeska <[email-masked]> wrote:

> 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

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

>>> 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.
>>
>>
>>>>>>  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.
>>>>>>
>>>>>>
>>>>>>
>>>>>>>
>>>>>>>  I am skeptical it is sufficiently deployable and we on Chromium
>>>>>>> are gathering numbers to answer this question (
>>>>>>> http://crbug.com/110794).
>>>>>>>
>>>>>>>
>>>>>>>  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
>>>>>  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
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>>
>>>>>>
>>>>>>>
>>>>>>>>
>>>>>>>  Easily negotiated: an indicator in the first request indicates
>>>>>>> that the client supports it. If that indicator survives to the server, the

---

From: "Adrien W. de Croy" <[email-masked]>
Date: Mon, 02 Apr 2012 20:57:56 +0000

------ Original Message ------
From: "Mike Belshe" [email-masked]
 >>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?
>>
>Oh - the browser doesn't know that any given request is a hanging GET, 
>so it can't know to use a separate connection in advance.  You can 
>start forking off new connections for every XMLHttpRequest (since they 
>are more likely to be hanging GETs).  But this is just one of many 
>hacks to make pipelining actually work at all in a real world browser.
>
>For more info on hanging GETs - check out this:  http://en.wikipedia.org/wiki/Comet_(programming)
>
  
server push?

Adrien

---

From: "Adrien W. de Croy" <[email-masked]>
Date: Mon, 02 Apr 2012 20:59:42 +0000

------ Original Message ------
From: "Mike Belshe" <[email-masked]>
To: "Peter Lepeska" <[email-masked]>
Cc: "[email-masked]" <[email-masked]>
Sent: 3/04/2012 6:04:16 a.m.
Subject: Re: Backwards compatibility
> 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.

  
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:// ...
  
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?
  
Adrien

>  > 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.
>  > 
>  > 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.
>  > 
>  > '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.
>  > 
  > 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...
  > 
  > 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.
  > 
 > >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?
> >
 >>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.
 >>
 >>>
>>>> > >On Fri, Mar 30, 2012 at 6:53 PM, Mark Watson <[email-masked]> wrote:
>>>> > > 
>>>> > > >On Fri, Mar 30, 2012 at 6:13 PM, Mark Watson <[email-masked]> 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.
>>> > > > 
>>> > > >  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.
 > > >  
> > >  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. 
 > >  > >
 > >  > >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). 
> >  > >>
> >  > >>successfully use pipelining. That's an average. On some ISPs 
> >  > >>the figure is much lower.
 >  > >>
>  > >>high, I've a feeling many of those are false negatives where we 
>  > >>avoid pipelining unnecessarily.
>  > >>
>  > >>>
>  > >>> 
>  > >>> 
  > >>> >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.
 > >>> >
 > >>> >
 > >>> > 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.
> >>> >
> >>> >>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.
> >>> >>
> >>> >>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?
> >> > 
> >> > 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)
 >> > 
 >> > 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, 
 >  > > >
 >  > > >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.
>  > > >>
>  > > >>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.
  > > >>
  > > >>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.
 > > >>
> > >> 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.
> > >> 
> > >> 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
> > >> > > 
> > >> > > 
> > >> > > 
 > >> > > 
> >> > > 
 >> > > 
>> > > 
> > > 
> > 
 > 
>

---

From: Mike Belshe <[email-masked]>
Date: Mon, 2 Apr 2012 14:08:55 -0700

On Mon, Apr 2, 2012 at 1:59 PM, Adrien W. de Croy <[email-masked]> wrote:

> On Mon, Apr 2, 2012 at 10:56 AM, Peter Lepeska < <[email-masked]>
> [email-masked]> wrote:
>

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 < <[email-masked]>
>> [email-masked]> wrote:
>>
>>> On Sat, Mar 31, 2012 at 9:47 AM, Mark Watson < <[email-masked]>
>>> [email-masked]> wrote:
>>>
>>>>  Mike, all,
>>>>
>>>> On Mar 30, 2012, at 9:18 PM, "Mike Belshe" < <[email-masked]>
>>>> [email-masked]> wrote:
>>>>
>>>>
>>>>
>>>>  On Sat, Mar 31, 2012 at 3:03 AM, Mark Watson < <[email-masked]>
>>>> [email-masked]> wrote:
>>>>
>>>>>
>>>>> On Fri, Mar 30, 2012 at 6:53 PM, Mark Watson < <[email-masked]>
>>>>> [email-masked]> wrote:
>>>>>
>>>>>>
>>>>>> On Fri, Mar 30, 2012 at 6:13 PM, Mark Watson < <[email-masked]>
>>>>>> [email-masked]> wrote:
>>>>>>
>>>>>>> All,
>>>>>>>
>>>>>> gathering numbers to answer this question ( <http://crbug.com/110794>

---

From: Roberto Peon <[email-masked]>
Date: Mon, 2 Apr 2012 14:32:45 -0700

> chew and so adoption will be much slower b/c of the SSL requirement, in my

Really? I'd say it was two delicious ingredients, personally. I also think
that assuming that deployment is greatly suffering is not validated by
real-world experience.

-=R

---

From: William Chan (陈智昌) <[email-masked]>
Date: Tue, 3 Apr 2012 01:01:34 +0200

> in the clear between the client & proxy.

In case it wasn't obvious, I'm totally on board with this. The thing is
there are times when we want fully end-to-end security (and thus want to
CONNECT via the trusted proxy) and other times when we are happy with
issuing a GET https:// via the proxy. Currently there's no good way for the
browser to decide between which. I think this is a key missing piece in the
trusted https proxy story.

> 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
>>>
>>>>>>> are gathering numbers to answer this question (<http://crbug.com/110794>

---

From: Amos Jeffries <[email-masked]>
Date: Tue, 03 Apr 2012 14:28:45 +1200

On 03.04.2012 09:32, Roberto Peon wrote:
> On Mon, Apr 2, 2012 at 10:56 AM, Peter Lepeska wrote:
>
>> problem

in the past few months there has been a noticeable increase in queries 
about:
* how to decrypt CONNECT tunnels to port 443
* how to implement MITM of port 443 for filtering

followed shortly after by:
* how to force port-443 traffic through the proxy without breaking 
non-HTTPS traffic on that port
* how to decrypt CONNECT traffic without breaking VoIP tunnels and 
other non-HTTPS CONNECT traffic
* how to force https:// to http:// by the browser, then reverse it at 
the proxy outgoing to https://
* how to force http:// to https:// by the browser, then reverse it at a 
proxy outgoing to http:// again

then more recently these have started coming in:
* why some recent browsers are doing things without being logged by 
proxy monitors (use of SPDY/WebSockets connections?)

Now you tell us there is no suffering...

AYJ

---

From: Roberto Peon <[email-masked]>
Date: Tue, 3 Apr 2012 00:13:34 -0700

> * how to implement MITM of port 443 for filtering

The former of these has nothing to do with current SPDY deployments.
The latter could, but is likely for significantly more than just SPDY.

> * how to decrypt CONNECT traffic without breaking VoIP tunnels and other
> non-HTTPS CONNECT traffic
> * how to force https:// to http:// by the browser, then reverse it at the
> proxy outgoing to https://
> * why some recent browsers are doing things without being logged by proxy
> monitors (use of SPDY/WebSockets connections?)
>

None of these requests is SPDY specific. All of them could be correlated
with various sites switching to actually using HTTPS traffic.

I said that it doesn't appear to be hampering deployment.

-=R

---

From: "Adrien W. de Croy" <[email-masked]>
Date: Wed, 04 Apr 2012 09:25:41 +0000

Do Google (or anyone else) have any good stats on:
  
a) how many websites there are
b) on how many servers/IPs
c) how many are currently using SSL
  
Just so we can maybe start to get a feel for what the increase in 
burden would be on the cert validation infrastructure...
  
Adrien

------ Original Message ------
From: "Roberto Peon" <[email-masked]>
To: "Amos Jeffries" <[email-masked]>
Cc: "[email-masked]" <[email-masked]>
Sent: 3/04/2012 7:13:34 p.m.
Subject: Re: Backwards compatibility
>   chew and so adoption will be much slower b/c of the SSL 

   Really? I'd say it was two delicious ingredients, personally. I also 
   think
   that assuming that deployment is greatly suffering is not validated 
   by
   real-world experience.

  in the past few months there has been a noticeable increase in 
  queries about:
  * how to decrypt CONNECT tunnels to port 443
  * how to implement MITM of port 443 for filtering

  followed shortly after by:
  * how to force port-443 traffic through the proxy without breaking 
  non-HTTPS traffic on that port
  * how to decrypt CONNECT traffic without breaking VoIP tunnels and 
  other non-HTTPS CONNECT traffic
  * how to force https:// to http:// by the browser, then reverse it at 
  the proxy outgoing to https://
  * how to force http:// to https:// by the browser, then reverse it at 
  a proxy outgoing to http:// again

 
 None of these requests is SPDY specific. All of them could be 
 correlated with various sites switching to actually using HTTPS 
 traffic.

 -=R

  AYJ