Subject: multiplexing -- don't do it

From: Peter L <[email-masked]>
Date: Thu, 29 Mar 2012 22:07:15 -0400

I'm new to this list but have been studying web performance over high
latency networks for many years and multiplexing seems to me like the wrong
way to go. The main benefit of multiplexing is to work around the 6
connections per domain limit but it reduces transparency on the network,
decreases the granularity/modularity of load balancing and increases object
processing latency in general on the back end as everything has to pass
through the same multiplexer, and introduces its own intractable
inefficiencies. In particular the handling of a low priority in flight
object ahead of a high priority object when packet loss is present is a
step backwards from what we have today for sites that get beyond the 6
connections per domain limit via domain sharding. Why not just introduce an
option in HTTP 2.0 that allows clients and servers to negotiate max
concurrent connections per domain? When web sites shard domains, aren't
they essentially telling the browser that they will happily accept lots
more connections? I'm sure this suggestion has long since been shot  down
but browsing around on the web I'm not finding it.

As for header compression, again this is a trade-off between
transparency/multiple streams and bandwidth savings. But I'd think this
group could come up with ways to reduce the bytes in the protocol
(including cookies) without requiring the use of a single compression
history, resulting in an order-sensitive multiplexed stream.

Thanks,

Peter

On Thu, Mar 29, 2012 at 9:26 AM, Mike Belshe <[email-masked]> wrote:

> I thought the goal was to figure out HTTP/2.0; I hope that the goals of
> SPDY are in-line with the goals of HTTP/2.0, and that ultimately SPDY just
> goes away.
>
> Mike
>
>
> On Thu, Mar 29, 2012 at 2:22 PM, Willy Tarreau <[email-masked]> wrote:
>
>> Hello,
>>
>> after seeing all the disagreements that were expressed on the list these
>> days (including from me) about what feature from SPDY we'd like to have
>> mandatory or not in HTTP, I'm thinking that part of the issue comes from
>> the fact that there are a number of different usages of HTTP right now,
>> all of them fairly legitimate.
>>
>> First I think that everyone here agrees that something needs to be done
>> to improve end user experience especially in the mobile networks. And
>> this is reflected by all proposals, including the http-ng draft from
>> 14 years ago!
>>
>> Second, the privacy issues are a mess because we try to address a social
>> problem by technical means. It's impossible to decide on a protocol if
>> we all give an example of what we'd like to protect and what we'd prefer
>> not to protect because it is useless and possibly counter-productive.
>>
>> And precisely, some of the disagreement comes from the fact that we're
>> trying to see these impacts on the infrastructure we know today, which
>> would obviously be a total breakage. As PHK said it, a number of sites
>> will not want to afford crypto for privacy. I too know some sites which
>> would significantly increase their operating costs by doing so. But
>> what we're designing is not for now but for tomorrow.
>>
>> What I think is that anyway we need a smooth upgrade path from current
>> HTTP/1.1 infrastructure and what will constitute the web tomorrow without
>> making any bigbang.
>>
>> SPDY specifically addresses issues observed between the browser and the
>> server-side infrastructure. Some of its mandatory features are probably
>> not desirable past the server-side frontend *right now* (basically
>> whatever addresses latency and privacy concerns). Still, it would be
>> too bad not to make the server side infrastructure benefit from a good
>> lifting by progressively migrating from 1.1 to 2.0.
>>
>> What does this mean ? Simply that we have to consider HTTP/2.0 as a
>> subset of SPDY or that SPDY should be an add-on to HTTP. And that
>> makes a lot of sense. First, SPDY already is an optimized messaging
>> alternative to HTTP. It carries HTTP/1.1, it can as well carry HTTP/2.0
>> since we're supposed to maintain compatible semantics.
>>
>> We could then get to a point where :
>>  - an http:// scheme indicates a connection to HTTP/1.x or 2.x server
>>  - an https:// scheme indicates a connection to HTTP/1.x or 2.x server
>>    via an SSL/TLS layer
>>  - a spdy:// scheme indicates a connection to HTTP/1.x or 2.x server
>>    via a SPDY layer
>>
>> By having HTTP/2.0 upgradable from 1.1, this split is natural :
>>
>>        +----------------------------+
>>        |       Application          |
>>        +----+-----------------------+
>>        | WS |     HTTP/2.0          |
>>        +----+--------------+        |
>>        |      HTTP/1.1     |        |
>>        |         +-----+---+--------+
>>        |         | TLS | SPDY       |
>>        +---------+-----+------------+   server-side
>>            ^        ^        ^
>>            |        |        |
>>            |        |        |
>>            |        |        |
>>        +---------+-----+------------+  user-agent
>>        |         | TLS | SPDY       |
>>        |         +-----+-------+----+
>>        |  HTTP/1.1, 2.0        |    |
>>        +-------------------+---+    |
>>        |                   |   WS   |
>>        |  Applications     +--------+
>>        |                            |
>>        +----------------------------+
>>
>> The upgrade path would then be much easier :
>>
>>  1) have browsers, intermediaries and servers progressively
>>     adopt HTTP/2.0 and support a seamless upgrade
>>
>>  2) have browsers, some intermediaries and some servers
>>     progressively adopt SPDY for the front-line
>>
>>  3) have a lot of web sites offer URLs as spdy:// instead of http://,
>>     and implement mandatory redirects from http:// to spdy:// like a
>>     few sites are currently doing (eg: twitter)
>>
>>  4) have browsers at some point use the SPDY as the default scheme
>>     for any domain name typed on the URL bar.
>>
>>  5) have browsers at one point disable by default transparent support
>>     for the old http:// scheme (eg: put a warning or have to tweak
>>     some settings for this). This will probably 10-20 years from now.
>>
>> Before we get to point 5, we'd have a number of sites running on the
>> new protocol, with an efficient HTTP/2.0 deployed at many places
>> including the backoffice, and with SPDY used by web browsers for
>> improved performance/privacy. That will not prevent specific agents
>> from still only using a simpler HTTP/2.0 for some uses.
>>
>> So I think that what we should do is to distinguish between what is
>> really desirable to have in HTTP and what is contentious. Everything
>> which increases costs or causes trouble for *some* use cases should
>> not be mandatory in HTTP but would be in the SPDY layer (as it is
>> today BTW).
>>
>> I think that the current SPDY+HTTP mix has shown that the two protocols
>> are complementary and can be efficient together. Still we can
>> significantly
>> improve HTTP to make both benefit from this, starting with the backoffice
>> infrastructure where most of the requests lie.
>>
>> Willy
>>
>>
>>
>

---

From: Brian Pane <[email-masked]>
Date: Thu, 29 Mar 2012 20:11:59 -0700

On Thu, Mar 29, 2012 at 7:07 PM, Peter L <[email-masked]> wrote:
> object ahead of a high priority object when packet loss is present is a step
> backwards from what we have today for sites that get beyond the 6
> concurrent connections per domain? When web sites shard domains, aren't they
> essentially telling the browser that they will happily accept lots more
> connections? I'm sure this suggestion has long since been shot  down but
> browsing around on the web I'm not finding it.

There are a couple of practical problems that happen upon increasing
the number of concurrent connections:

- With N connections, the server or proxy has to be prepared to allocate
  N * receive_window_size bytes of memory for incoming packets.  Large
  values of N thus have a disadvantage for people operating high-traffic
  sites.

- Congestion control happens independently for each of N connections.
  While I'm not a proponent of artificially throttling HTTP to compensate
  for "bufferbloat," multiplexing N HTTP streams over one TCP connection
  does make for easier congestion control (especially in low-end client
  devices) than running N TCP connections.

- If the client and server have to negotiate a value for N, it may add
  an additional round trip.

Brian

---

From: J Ross Nicoll <[email-masked]>
Date: Fri, 30 Mar 2012 10:46:41 +0100

I would consider the congestion/window benefits that Brian raised the 
main benefits, personally. To address a couple of the issues you've raised:

Transparency; whatever tools you're using to monitor network traffic 
will already be pulling individual connections out of a mixture of 
packets. It does mean those tools will need to pull apart another layer 
to be able to see the individual content being sent, but I'm not 
imagining this to be a significant hurdle. I would also point out that 
there's discussion about HTTP 2.0 being SSL only (and I believe 
"encouraged to be SSL where at all possible" is the main alternative), 
and that would impact network transparency a lot more than multiplexing!

Load balancing; do you have cases where individual user load requires 
balancing? I'm not aware of any common cases where high web server load 
is caused by individual users, but typically by a large number of users 
in aggregate. Multiplexing would mean each user's requests would likely 
go to a single server, but users should still be easily re-distributable 
across a cluster of servers.

Increased object processing latency; sorry, I'm not sure why this would 
be the case?

Ross

On 30/03/2012 03:07, Peter L wrote:
> latency networks for many years and multiplexing seems to me like the 
> wrong way to go. The main benefit of multiplexing is to work around 
> the 6 connections per domain limit but it reduces transparency on the 
> network, decreases the granularity/modularity of load balancing and 
> increases object processing latency in general on the back end as 
> everything has to pass through the same multiplexer, and introduces 
> its own intractable inefficiencies. In particular the handling of a 
> low priority in flight object ahead of a high priority object when 
> packet loss is present is a step backwards from what we have today for 
> sites that get beyond the 6 connections per domain limit via domain 
> sharding. Why not just introduce an option in HTTP 2.0 that allows 
> clients and servers to negotiate max concurrent connections per 
> domain? When web sites shard domains, aren't they essentially telling 
> the browser that they will happily accept lots more connections? I'm 
> sure this suggestion has long since been shot  down but browsing 
> around on the web I'm not finding it.
>
> transparency/multiple streams and bandwidth savings. But I'd think 
> this group could come up with ways to reduce the bytes in the protocol 
> On Thu, Mar 29, 2012 at 9:26 AM, Mike Belshe <[email-masked] 
> <mailto:[email-masked]>> wrote:
>
>     I thought the goal was to figure out HTTP/2.0; I hope that the
>     goals of SPDY are in-line with the goals of HTTP/2.0, and that
>     ultimately SPDY just goes away.
>
>     Mike
>
>
>     On Thu, Mar 29, 2012 at 2:22 PM, Willy Tarreau <[email-masked]
>     <mailto:[email-masked]>> wrote:
>
>         Hello,
>

---

From: Mike Belshe <[email-masked]>
Date: Fri, 30 Mar 2012 15:22:12 +0200

On Fri, Mar 30, 2012 at 4:07 AM, Peter L <[email-masked]> wrote:

> inefficiencies.

The CPU processing at the server is one thing we could optimize for.  Or we
could optimize for user's getting their pages faster.

Data suggests that your claims of inefficiency are simply incorrect.  But
if you have a benchmark to report upon, we could discuss that.

> In particular the handling of a low priority in flight object ahead of a
> high priority object when packet loss is present is a step backwards from
> what we have today for sites that get beyond the 6 connections per domain
> limit via domain sharding. Why not just introduce an option in HTTP 2.0
> that allows clients and servers to negotiate max concurrent connections per
> domain?

As you can see from data, websites are not having any trouble getting
around the 6 connection limit already.

We could do this, but it would do nothing to make pages load faster or be
lighter weight on the network.

> When web sites shard domains, aren't they essentially telling the browser
> that they will happily accept lots more connections? I'm sure this
> suggestion has long since been shot  down but browsing around on the web
> I'm not finding it.
>

I'm not sure why you are opposed to compression.  We could reduce the bytes
as well, and nobody is against that.

What is "transparency on the wire"?  You mean an ascii protocol that you
can read?  I don't think this is a very interesting goal, as most people
don't look at the wire.  Further, if we make it a secure protocol, its a
moot point, since the wire is clearly not human readable.

mike

---

From: "Peter L" <[email-masked]>
Date: Fri, 30 Mar 2012 09:43:53 -0400

Responding to Ross and Brian's posts mainly here...

I agree that increasing concurrent connections will increase the burden on
web servers and that is a serious issue for sure but since so many sites are
already working around the 6 per domain limit via sharding, most site owners
are willing to accept higher numbers of TCP connections if it results in
faster page loads. Prevalence of domain sharding is a kind of vote in the
direction of increasing the per domain limit.

Transparency:

.         SPDY compresses HTTP headers using an LZ history based algorithm,
which means that previous bytes are used to compress subsequent bytes. So
any packet capture that does not include all the traffic sent over that
connection will be completely opaque -- no mathematical way to decode the
HTTP. Even with all the traffic, a stream decoder will be a tricky thing to
build b/c packets depend on each other.

.         Loss of transparency impacts intermediary devices (reverse
proxies, caches, layer 7 switches, load balancers) as much as it does packet
capture analysis. For load balancing, multiplexing requires maintaining
state from one request to the next so individual object requests from a
given user will need to be handled by the same de-multiplexing server. In
general, increasing session orientation reduces the scalability of the
overall service. Also, failover is less graceful as a load balancer will
want to be more sure that the previously used server is in fact unavailable
before routing to a new server.

.         SSL kills transparency at the network level completely but also I
think that SSL should be considered as an orthogonal thing to performance.
So that site owners can make a decision based on the cost, security,
performance tradeoffs of going to all encrypted traffic. So while I agree
it's related, it seems like we have to consider these things independently.

Increased Object Processing Latency:

.         Multiplexing requires that objects are encoded serially -- encode
(Object1), encode (Object2), encode (Object3) -- and then decoded in that
same order. On a multi-core server, the three objects arrive truly
concurrently, but due to multiplexing Object2 and Object3 will need to wait
while Object1 is encoded. For SPDY, that encode step involves running an
LZ-type coding function including searching the recent bytes for matches so
even on an unloaded server this can add ~milliseconds of latency. 

.         Multiplexing creates the need for session state. Access to this
state needs to be synchronized, thread synchronization reduces parallelism
and so impacts server scalability and per object latency.

.         CPU gains are increasingly achieved by adding cores and not making
existing cores go faster. So processes that can run concurrently are
friendly to these advances (such as increasing concurrent TCP connections)
and multiplexing goes in the opposite direction -- requiring thread
synchronization and so increasing serialization, and context switching.

Thanks,

Peter

From: J Ross Nicoll [mailto:[email-masked]] 
Sent: Friday, March 30, 2012 5:47 AM
To: Peter L
Cc: [email-masked]
Subject: Re: multiplexing -- don't do it

I would consider the congestion/window benefits that Brian raised the main
benefits, personally. To address a couple of the issues you've raised:

Transparency; whatever tools you're using to monitor network traffic will
already be pulling individual connections out of a mixture of packets. It
does mean those tools will need to pull apart another layer to be able to
see the individual content being sent, but I'm not imagining this to be a
significant hurdle. I would also point out that there's discussion about
HTTP 2.0 being SSL only (and I believe "encouraged to be SSL where at all
possible" is the main alternative), and that would impact network
transparency a lot more than multiplexing!

Load balancing; do you have cases where individual user load requires
balancing? I'm not aware of any common cases where high web server load is
caused by individual users, but typically by a large number of users in
aggregate. Multiplexing would mean each user's requests would likely go to a
single server, but users should still be easily re-distributable across a
cluster of servers.

Increased object processing latency; sorry, I'm not sure why this would be
the case?

Ross

As for header compression, again this is a trade-off between
transparency/multiple streams and bandwidth savings. But I'd think this
group could come up with ways to reduce the bytes in the protocol (including
cookies) without requiring the use of a single compression history,
resulting in an order-sensitive multiplexed stream.

Thanks,

Peter

I thought the goal was to figure out HTTP/2.0; I hope that the goals of SPDY
are in-line with the goals of HTTP/2.0, and that ultimately SPDY just goes
away. 

Mike

Hello,

I think that the current SPDY+HTTP mix has shown that the two protocols
are complementary and can be efficient together. Still we can significantly
improve HTTP to make both benefit from this, starting with the backoffice
infrastructure where most of the requests lie.

Willy

---

From: "Peter L" <[email-masked]>
Date: Fri, 30 Mar 2012 12:02:05 -0400

Hi Steve,

I think I replied to your server load point in the other thread.

In response to this point on prioritization and SPDY...

SPDY multiplexes the streams with consideration to priority, so this
situation wouldn't happen (afaik).  The high priority object (coming
over a higher priority stream) would preempt the lower-priority
in-flight object as soon as it was requested.

I think this actually may be better than existing HTTP:

1) In existing http, if you have 5 low-priority sessions fetching
objects and you need to fetch 1 high priority object, you can create a
high-priority session to fetch it.  By default (assuming no tcp window
size or other manipulation) that tcp connection gets 1/6th the
bandwidth (~17%).

2) With SPDY, assuming the same situation -- the high priority session
would pre-empt all low-priority streams, so the high-priority stream
would be getting ~100% of the bandwidth.

SPDY sits above a single TCP connection. So the order that it sends data to
the TCP stack is the order that the receiver must read it in on the other
side. This means that for in-flight data (which can easily be an entire web
page worth on high latency / bandwidth product links), there is no
prioritization. For example, let's say SPDY receives a small low priority
object from the back end web server and pushes it to the TCP stack and then
receives a small high priority object and pushes that to the TCP stack.
Assuming the objects are small, these objects will go out as two separate
TCP packets -- low and then high. If the first packet gets dropped, then
even if the second packet makes it to the other side, it cannot be delivered
to the browser until the first packet is retransmitted and received at the
user device. In fact, because multiplexing makes the traffic opaque to
intermediary devices, layer 7 switches that perform differential shaping for
web performance (javascript before images say) cannot enforce prioritization
in the network when congested. Much better would be to have the low and high
priority objects on two separate TCP connections so that when congested the
switch can still provide bandwidth for the high priority object.

A multiplexer sitting on top of TCP can only apply prioritization in the
case where it is processing two objects simultaneously but since most web
objects are small this is relatively rare.

Thanks,

Peter

 

From: Steve Padgett [mailto:[email-masked]] 
Sent: Friday, March 30, 2012 11:31 AM
To: Peter L
Subject: Re: multiplexing -- don't do it

Sure, no problem.

On Mar 30, 2012 4:34 PM, "Peter L" <[email-masked]> wrote:

Hi Steve,

Do you mind if I reply to your email and CC the list?

Thanks,

Peter

On Fri, Mar 30, 2012 at 3:49 AM, Steve Padgett <[email-masked]> wrote:

> latency networks for many years and multiplexing seems to me like the
wrong
> decreases the granularity/modularity of load balancing

On sites that have enough traffic to need load balancing, I suspect
that the # of concurrent client connections is several orders of
magnitude higher than the # of web servers - so the load should still
be evenly distributed.  Plus, one of the primary bottlenecks in load
balancers is the # of connections (both concurrent & new-per-second)
so having a 4x to 6x decrease in this would likely actually save a lot
of load balancer resources.

> and increases object
step
> connections per domain limit via domain sharding.

SPDY multiplexes the streams with consideration to priority, so this
situation wouldn't happen (afaik).  The high priority object (coming
over a higher priority stream) would preempt the lower-priority
in-flight object as soon as it was requested.

I think this actually may be better than existing HTTP:

1) In existing http, if you have 5 low-priority sessions fetching
objects and you need to fetch 1 high priority object, you can create a
high-priority session to fetch it.  By default (assuming no tcp window
size or other manipulation) that tcp connection gets 1/6th the
bandwidth (~17%).

2) With SPDY, assuming the same situation -- the high priority session
would pre-empt all low-priority streams, so the high-priority stream
would be getting ~100% of the bandwidth.

I also agree with Brian on the additional issues that exist due to the
increasing the # of concurrent sessions...

Steve

---

From: Brian Pane <[email-masked]>
Date: Fri, 30 Mar 2012 09:17:21 -0700

On Friday, March 30, 2012, Peter L wrote:

> Responding to Ross and Brian's posts mainly here...****
>
> ** **
>
> web servers and that is a serious issue for sure but since so many sites
> are already working around the 6 per domain limit via sharding, most site
> owners are willing to accept higher numbers of TCP connections if it
> results in faster page loads. Prevalence of domain sharding is a kind of
> vote in the direction of increasing the per domain limit.****
>
>
What I've found empirically is that most sites suffer from request
serialization--i.e., insufficient parallelism--despite all the investment
in domain sharding and image spriting. My article in last December's
PerfPlanet calendar
presents the data.

Transparency:****
>
> **·         **SPDY compresses HTTP headers using an LZ history based
> algorithm, which means that previous bytes are used to compress subsequent
> bytes. So any packet capture that does not include all the traffic sent
> over that connection will be completely opaque -- no mathematical way to
> decode the HTTP. Even with all the traffic, a stream decoder will be a
> tricky thing to build b/c packets depend on each other.****
>
>
I know there's a SPDY decoder plugin for Wireshark, but I'll defer to
people more knowledgeable about packet analysis tools to cover that area.

> **·         **Loss of transparency impacts intermediary devices (reverse
> proxies, caches, layer 7 switches, load balancers) as much as it does
> packet capture analysis. For load balancing, multiplexing requires
> maintaining state from one request to the next so individual object
> requests from a given user will need to be handled by the same
> de-multiplexing server.
>
>
For load balancing, you just have to ensure that all packets from the same
TCP connection go to the same place for L6-7 decoding. But that's already
required for HTTP/1.x.  A L7 proxy or load balancer that terminates either
HTTP or SPDY is then free to dispatch successive requests from the same
client to different backend servers.

 In general, increasing session orientation reduces the scalability of the
> before routing to a new server.****
>
> **·         **SSL kills transparency at the network level completely but
> also I think that SSL should be considered as an orthogonal thing to
> performance. So that site owners can make a decision based on the cost,
> security, performance tradeoffs of going to all encrypted traffic. So while
> I agree it's related, it seems like we have to consider these things
> independently.****
>
> ** **
>
> Increased Object Processing Latency:****
>
> **·         **Multiplexing requires that objects are encoded serially --
> encode (Object1), encode (Object2), encode (Object3) -- and then decoded in
> that same order.
>
>
Object1, Object2, and Object3 need not be entire HTTP messages, though. In
SPDY, unlike pipelined HTTP/1.1, a server can interleave little chunks of
different responses.  That's what I consider SPDY's key design concept: not
just multiplexing, but interleaving.

 On a multi-core server, the three objects arrive truly concurrently, but
> due to multiplexing Object2 and Object3 will need to wait while Object1 is
> encoded. For SPDY, that encode step involves running an LZ-type coding
> function including searching the recent bytes for matches so even on an
> unloaded server this can add ~milliseconds of latency. ****
>
>
The last time I looked at gzip perf, the cost was on the order of 50 clock
cycles/byte on x86_64. (Anybody who's studied LZ perf more deeply, please
jump in with more precise numbers.) Given 1KB of response headers, that
works out to ~25 microseconds of latency at 2GHz, not milliseconds.

Having worked at a load balancer company in the past, I do agree that 25us
is a material CPU cost, but it's nowhere near milliseconds.

**·         **Multiplexing creates the need for session state. Access to
> this state needs to be synchronized, thread synchronization reduces
> parallelism and so impacts server scalability and per object latency.****
>
> **·         **CPU gains are increasingly achieved by adding cores and not
> making existing cores go faster. So processes that can run concurrently are
> synchronization and so increasing serialization, and context switching.***
> *
>
>
With separate connections, though, you still have a serialization
bottleneck at the NIC. The locking neede to serialized writes to the
network doesn't go away if you forego multiplexing in favor of lots of
connections; it just moves to the other side of the kernel/userspace
boundary.

-Brian

---

From: Roberto Peon <[email-masked]>
Date: Fri, 30 Mar 2012 19:56:05 +0200

On Fri, Mar 30, 2012 at 6:17 PM, Brian Pane <[email-masked]> wrote:

>> I agree that increasing concurrent connections will increase the burden
>> on web servers and that is a serious issue for sure but since so many sites

Prioritization is key in efficiently utilizing any for of
parallel-requests. It happens to be much, much more difficult if you're
using separate connections because there is no guarantee that they go to
the same machine. As a result, your background image gets to clog the pipe
instead of your browser getting the HTTP and JS it needs to do initial
layout, rendering, and resource discovery.

1 connection means that it becomes trivial to do prioritization properly.
I know that it was argued that 1 connection makes it more difficult because
there is buffering and you can't revoke a write() to a socket. Experience
so far hasn't bourne this fear out, and even if it was true, if you can get
some idea about the depth of your buffer, you can pace your output to
ensure that you're never adding too much buffer-depth at any point in time.

> people more
knowledgeable about packet analysis tools to cover that area.

The OP is right about this, btw. Technically it is possible that you've
flushed the window after 2k of completely new data, but there is no
guarantee and so interpreting a stream in the  middle may be extremely
difficult.

Seems like a fine tradeoff for the latency savings that we get on low-BW
links, though.

> client to different backend servers.

Note that 'the same place' probably means the same IP, but there is no
assurance that the same IP will mean the same machine or network adapter.
With multiplexing over TCP (or any equivalent like SCTP), you're either
guaranteed or at least much more likely to get locality for that user on
one loadbalancer or machine.

Using fewer connections decreases vastly the amount of state necessary to
do proper demux to the right server, and, as noted before, allows the LB or
server to trivially do prioritization.

> just multiplexing, but interleaving.

Multiplexing doesn't have any effect on encoding/decoding unless you're
using something requires serialization (such as the gzip compressor in
SPDY). In the case of SPDY, if you can jettison the header-stream
compression or better, find some compression method that doesn't have as
stringent a compression requirement, you can avoid this issue.

Note anyway that the serialization requirement that gzip imposes in SPDY
only affects the headers, and not the data for the request or response.

>> parallelism and so impacts server scalability and per object latency.
>>
> There are a lot of ways to skin a cat. One need not always resort to
critical-section based synchronization. You could use epoll() instead, for
instance, and process the client's connection within on thread.

> ****
>>
>> **·         **CPU gains are increasingly achieved by adding cores and
>> not making existing cores go faster. So processes that can run concurrently
>> are friendly to these advances (such as increasing concurrent TCP
>> connections) and multiplexing goes in the opposite direction -- requiring
>> thread synchronization and so increasing serialization, and context
>> switching.****
>>
>>

Most of the improvements you would see here for the multi-CPU case should
come in the form of multiqueue NICs which hash based on the TCP tuple (or
similar) and stably select a queue which feeds a non-overlapping subset of
CPUs to do processing of interrupts, etc.

Again, multiplexing as it has been done with SPDY, since it is on one
connection, requires less synchronization than it does for HTTP (the kernel
has to do synchronization of various interactions as you increase the FD
count) to handle the increased parallelism. Even in the case where you
decide to use more than a constant number of threads per core (anything
else will suffer in throughput compared to that design on current kernels,
hardware from my experience), you will still have less contention because
you can manage it yourself with domain knowledge about the connection,
user, problem, method, etc. that the kernel isn't privy to and should
probably never be privy to.

-=R

---

From: "Peter L" <[email-masked]>
Date: Fri, 30 Mar 2012 15:49:46 -0400

What I've found empirically is that most sites suffer from request
serialization--i.e., insufficient parallelism--despite all the investment in
domain sharding and image spriting. My article in last December's PerfPlanet
calendar 

presents the data.

Thanks for pointing me to your article. It's cool the way you attempt to
filter out content interdependencies by looking at images only, though I'm
sure that's not always accurate b/c page load logic can be built to wait for
images to load before issuing subsequent requests. It might be interesting
to include all content types but to count outstanding transactions per host
and only include serialized sequences that have 6 outstanding simultaneously
to filter your data. In any case, your result confirms what SPDY's test
results suggest -- browsers are still bumping up against the per domain
limits.

----

On a multi-core server, the three objects arrive truly concurrently, but due
to multiplexing Object2 and Object3 will need to wait while Object1 is
encoded. For SPDY, that encode step involves running an LZ-type coding
function including searching the recent bytes for matches so even on an
unloaded server this can add ~milliseconds of latency. 

I ran gzip at its default speed setting of 6 to encode 100 MB of highly
compressible text (similar to HTTP) and encoded it in about 9 seconds with a
2.4 GHz CPU, so you are right it only takes about 90us for a 1 KB response
header. And this would be better at faster gzip settings. I was thinking of
the time required to gzip the objects and not just the headers. I agree this
seems small for the gzipping alone.

----

With separate connections, though, you still have a serialization bottleneck
at the NIC. The locking needed to serialized writes to the network doesn't
go away if you forego multiplexing in favor of lots of connections; it just
moves to the other side of the kernel/userspace boundary.

I hadn't thought of it this way. At the NIC level, does it matter that
packets are associated with different TCP connections? I'd think the
serialization to the network would be insensitive to L4 headers but don't
know enough about how this works.

Thanks,

Peter

From: Brian Pane [mailto:[email-masked]] 
Sent: Friday, March 30, 2012 12:17 PM
To: Peter L
Cc: [email-masked]
Subject: Re: multiplexing -- don't do it

What I've found empirically is that most sites suffer from request
serialization--i.e., insufficient parallelism--despite all the investment in
domain sharding and image spriting. My article in last December's PerfPlanet
calendar 

presents the data.

Transparency:

I know there's a SPDY decoder plugin for Wireshark, but I'll defer to people
more knowledgeable about packet analysis tools to cover that area.

given user will need to be handled by the same de-multiplexing server.

same order.

unloaded server this can add ~milliseconds of latency. 

With separate connections, though, you still have a serialization bottleneck
at the NIC. The locking neede to serialized writes to the network doesn't go
away if you forego multiplexing in favor of lots of connections; it just
moves to the other side of the kernel/userspace boundary.

-Brian

---

From: "Peter L" <[email-masked]>
Date: Fri, 30 Mar 2012 16:36:47 -0400

" Prioritization is key in efficiently utilizing any for of
parallel-requests. It happens to be much, much more difficult if you're
using separate connections because there is no guarantee that they go to the
same machine. As a result, your background image gets to clog the pipe
instead of your browser getting the HTTP and JS it needs to do initial
layout, rendering, and resource discovery."

The fact that SPDY enables the browser to tag a request as high priority
when in fact a resource is blocking is awesome. This should be built into
HTTP 2.0 with or without the multiplexing piece. It allows either SPDY
server, or other intermediaries in the network (assuming the HTTP is not
opaque) that are doing shaping to make better decisions. And only the
browser has this information. 

I know that it was argued that 1 connection makes it more difficult because
there is buffering and you can't revoke a write() to a socket. Experience so
far hasn't bourne this fear out, and even if it was true, if you can get
some idea about the depth of your buffer, you can pace your output to ensure
that you're never adding too much buffer-depth at any point in time.

Have you done much testing with packet loss? As expressed earlier, my
biggest concern is head-of-line blocking when low priority objects are at
the head of the line. But it makes sense that you could mitigate this
somewhat by making sure you don't buffer too much in the network.  Also, the
approach I like of allowing a larger pool of persistent connections per
domain increases the likelihood that a SYN or SYN-ACK will be dropped, which
results in the disastrous 3 second reconnect delay.

Re: no decoder plugin for wireshark.

"Seems like a fine tradeoff for the latency savings that we get on low-BW
links, though."

I agree if SPDY could be applied to problematic links only. Otherwise it's a
lot to give up if you spend your days troubleshooting networks and
application performance.

"Again, multiplexing as it has been done with SPDY, since it is on one
connection, requires less synchronization than it does for HTTP (the kernel
has to do synchronization of various interactions as you increase the FD
count) to handle the increased parallelism. Even in the case where you
decide to use more than a constant number of threads per core (anything else
will suffer in throughput compared to that design on current kernels,
hardware from my experience), you will still have less contention because
you can manage it yourself with domain knowledge about the connection, user,
problem, method, etc. that the kernel isn't privy to and should probably
never be privy to."

Are you saying a SPDY-enabled web server outperforms one without SPDY for a
given web page b/c it converts many TCP connections into a single connection
and this actually decreases kernel level thread contention more than the
contention added by SPDY's user mode serialization logic? I wonder if this
is what the adopters (Google and Twitter) have found so far.

Thanks,

Peter

presents the data.

Prioritization is key in efficiently utilizing any for of parallel-requests.
It happens to be much, much more difficult if you're using separate
connections because there is no guarantee that they go to the same machine.
As a result, your background image gets to clog the pipe instead of your
browser getting the HTTP and JS it needs to do initial layout, rendering,
and resource discovery.

I know that it was argued that 1 connection makes it more difficult because
there is buffering and you can't revoke a write() to a socket. Experience so
far hasn't bourne this fear out, and even if it was true, if you can get
some idea about the depth of your buffer, you can pace your output to ensure
that you're never adding too much buffer-depth at any point in time.

Transparency:

more 

 

Note that 'the same place' probably means the same IP, but there is no
assurance that the same IP will mean the same machine or network adapter.
With multiplexing over TCP (or any equivalent like SCTP), you're either
guaranteed or at least much more likely to get locality for that user on one
loadbalancer or machine.

Using fewer connections decreases vastly the amount of state necessary to do
proper demux to the right server, and, as noted before, allows the LB or
server to trivially do prioritization.

 

Again, multiplexing as it has been done with SPDY, since it is on one
connection, requires less synchronization than it does for HTTP (the kernel
has to do synchronization of various interactions as you increase the FD
count) to handle the increased parallelism. Even in the case where you
decide to use more than a constant number of threads per core (anything else
will suffer in throughput compared to that design on current kernels,
hardware from my experience), you will still have less contention because
you can manage it yourself with domain knowledge about the connection, user,
problem, method, etc. that the kernel isn't privy to and should probably
never be privy to.

-=R

-Brian

---

From: "Adrien W. de Croy" <[email-masked]>
Date: Fri, 30 Mar 2012 22:52:21 +0000

------ Original Message ------
From: "Roberto Peon" [email-masked]
>  ·         SPDY compresses HTTP headers using an LZ history based 
>  algorithm, which means that previous bytes are used to compress 
>  subsequent bytes. So any packet capture that does not include all 
>  the traffic sent over that connection will be completely opaque -- 
>  no mathematical way to decode the HTTP. Even with all the traffic, a 
>  stream decoder will be a tricky thing to build b/c packets depend on 
>  each other.

 The OP is right about this, btw. Technically it is possible that 
 you've flushed the window after 2k of completely new data, but there 
 is no guarantee and so interpreting a stream in the  middle may be 
 extremely difficult.
 
 Seems like a fine tradeoff for the latency savings that we get on 
 low-BW links, though.
  
I think it basically means compression or any transport level transform 
needs to be able to be switched off when debugging.  Which means 
optional/negotiated.
  
I have to analyse packet dumps of HTTP most days, as I'm sure do many 
others on this list.  We haven't yet evolved as a species to the stage 
where we don't make mistakes.
  
I think it's a vitally important facility for discovering 
implementation errors, which is required in many cases to resolve 
issues.
  
Adrien

---

From: "Adrien W. de Croy" <[email-masked]>
Date: Fri, 30 Mar 2012 23:19:47 +0000

------ Original Message ------
From: "Alexey Melnikov" <[email-masked]>
To: "Adrien W. de Croy" <[email-masked]>
Cc: "Roberto Peon" <[email-masked]>;"[email-masked]" 
<[email-masked]>
Sent: 31/03/2012 12:12:18 p.m.
Subject: Re: multiplexing -- don't do it
>On 31/03/2012 00:52, Adrien W. de Croy wrote:  
>>
>>>  no mathematical way to decode the HTTP. Even with all the traffic, 
>>>  a stream decoder will be a tricky thing to build b/c packets 
>>>  depend on each other.
>>  
>>  I know there's a SPDY decoder plugin for Wireshark, but I'll defer 
>>  to people more 

   
  I think it basically means compression or any transport level 
  transform needs to be able to be switched off when debugging.  Which 
  means optional/negotiated.
 I think it should be mandatory to implement (so no discovery of the 
 feature is needed), but optional to use. 
for something like TLS or gzip I've absolutely no problem with that. 
  
>>others on this list.  We haven't yet evolved as a species to the 
>>stage where we don't make mistakes.
>>

---

From: Alexey Melnikov <[email-masked]>
Date: Sat, 31 Mar 2012 01:12:18 +0200

On 31/03/2012 00:52, Adrien W. de Croy wrote:
> From: "Roberto Peon" [email-masked] <mailto:[email-masked]>
>>
>>         ·SPDY compresses HTTP headers using an LZ history based
>>         algorithm, which means that previous bytes are used to
>>         compress subsequent bytes. So any packet capture that does
>>         not include all the traffic sent over that connection will be
>>         completely opaque -- no mathematical way to decode the HTTP.
>>         Even with all the traffic, a stream decoder will be a tricky
>>         thing to build b/c packets depend on each other.
>>
>>
>>     I know there's a SPDY decoder plugin for Wireshark, but I'll
>>     defer to people more
>>

> implementation errors, which is required in many cases to resolve issues.
> Adrien
>

---

From: Mike Belshe <[email-masked]>
Date: Sat, 31 Mar 2012 01:53:12 +0200

On Sat, Mar 31, 2012 at 1:19 AM, Adrien W. de Croy <[email-masked]> wrote:

> Cc: "Roberto Peon" <[email-masked]>;"[email-masked]" <
> [email-masked]>
> From: "Roberto Peon" <[email-masked]>[email-masked]
>
>>> tricky thing to build b/c packets depend on each other.
>>>
>>

Before thinking this way we should look at how well other mandatory but
optional to use features have turned out.

One such example is pipelining.  Mandatory for a decade, but optional to
implement. We still can't turn it on.

Another is chunked uploads.  Hugely valuable for data uploads from the
client, mandatory to implement, but completely broken and unusable by
browsers because of it.

Options simply don't work - we need to make this stuff mandatory from the
get-go or it  is very likely to have the same result that we've seen in the
past.

Finally, debugging is the wrong reason to make things optional at the
protocol level. If you are in a position to turn of f the flags, turn them
off via cmdline tricks or what not.  It's fine.  If you're running a
production trace, and we want the feature on (presumably the option to turn
off was not used, right?), you're still going to need real debugging tools.
 The right answer here is to invest in the tools - not to neuter the
protocol features.

BTW - check out chromes about:net-internals.  It's not perfect, but it
takes care of all this for you so that you can see the spdy frames fully
decoded.  It's not a panacea of tools - but this stuff is very
implementable.

Mike

> I think it's a vitally important facility for discovering implementation
> errors, which is required in many cases to resolve issues.
>
> Adrien
>
>
>
>
>
>

---

From: Julian Reschke <[email-masked]>
Date: Sat, 31 Mar 2012 08:57:03 +0200

On 2012-03-31 01:53, Mike Belshe wrote:
> ...
> ...

But then many people have it turned on, and it seems to be on by default 
in Safari mobile. Maybe the situation is much better than you think.

> ...
> Options simply don't work - we need to make this stuff mandatory from
> the get-go or it  is very likely to have the same result that we've seen
> in the past.
> ...

I don't think that's correct.

Options do not work if and only if they are usually not switched on.

For instance, if header compression is optional, but common UAs will use 
it by default, it *will* be implemented.

Also, this is a feature that can trivially tested in a test suite.

Best regards, Julian

---

From: Willy Tarreau <[email-masked]>
Date: Sat, 31 Mar 2012 09:30:04 +0200

Hi Julian,

> it by default, it *will* be implemented.

Mike suggested that mandatory features must not necessarily be used but at
least be implemented. And in fact, whatever concerns the connection setup
from the client to the server has to be implemented ; if a browser sends
compressed headers to a gateway that cannot decompress them, it will fail
(which was my reason to try something cheaper than zlib from the server's
point of view). Not supporting the other direction is not an issue however
since the server knows what the client supports.

Best regards,
Willy

---

From: "Poul-Henning Kamp" <[email-masked]>
Date: Sat, 31 Mar 2012 07:34:47 +0000

>> it by default, it *will* be implemented.

I think for a facility like compression, it would be prefectly justified
to make it a "default-on" feature, which may cost a RTT to disable for
clients which don't grok it.

-- 
Poul-Henning Kamp       | UNIX since Zilog Zeus 3.20
[email-masked]         | TCP/IP since RFC 956
FreeBSD committer       | BSD since 4.3-tahoe    
Never attribute to malice what can adequately be explained by incompetence.

---

From: Willy Tarreau <[email-masked]>
Date: Sat, 31 Mar 2012 10:02:14 +0200

> clients which don't grok it.

I have no issue with that provided it's cheap. I'd like to note that the
additional RTT happens only if it's not supported by the server, so that
the client's request is not understood. If we make compression cheap enough
for both ends, as we proposed as well as Roy proposed in Waka (which looks
more advanced BTW), then there might not be any reason not to support it
and it would be even easier.

Willy

---

From: Ian Fette (イアンフェッティ) <[email-masked]>
Date: Sat, 31 Mar 2012 01:26:19 -0700

I am not sure what "easy" means. Easy to implement? Both are
straightforward enough. Easy to debug? Meh. Our goal should be performance
for billions of users, not the convenience of many orders of magnitude less.

---

From: Willy Tarreau <[email-masked]>
Date: Sat, 31 Mar 2012 10:57:39 +0200

> for billions of users, not the convenience of many orders of magnitude less.

Sorry Ian, I meant "easy to process", which clearly fits in the performance
category.

Willy

---

From: "Adrien W. de Croy" <[email-masked]>
Date: Sat, 31 Mar 2012 10:25:30 +0000

------ Original Message ------
From: "Julian Reschke" <[email-masked]>
To: "Mike Belshe" <[email-masked]>
Cc: "Adrien W. de Croy" <[email-masked]>;"Alexey Melnikov" 
<[email-masked]>;"Roberto Peon" 
<[email-masked]>;"[email-masked]" <[email-masked]>
Sent: 31/03/2012 7:57:03 p.m.
Subject: Re: multiplexing -- don't do it
>But then many people have it turned on, and it seems to be on by 
>default in Safari mobile. Maybe the situation is much better than you 
>think. 
>
>>... 
>For instance, if header compression is optional, but common UAs will 
>use it by default, it *will* be implemented. 
>
  
and trivially implemented.
  
Pipelining wasn't supported in WinGate because basically it's onerous.  
It's hard enough for a proxy taking on the responsibility to deal with 
the problem cases relating to pipelining (which may not be able to be 
simply reflected back through to the client).  But every filter in the 
filter chain also therefore needs to be able to cope with retries etc.
  
In a proxy there can be side-effects in the proxy to every request 
regardless of whether it's safe/idempotent for the server.  Some 
side-effects are user configurable, and may affect subsequent 
processing of requests. Retries even if safe for the web application, 
can cause problems for the proxy.  So, we stop reading off the buffer 
when we've received a whole request, which serializes the whole thing.  
  
Deterministic multiplexing OTOH would be a lot simpler, even if 
upstream is 1.1
  
Adrien

---

From: Mike Belshe <[email-masked]>
Date: Sat, 31 Mar 2012 13:11:53 +0200

> in Safari mobile. Maybe the situation is much better than you think.

The data is overwhelming that it doesn't work.

Data points:
a) chrome study showing connectivity results on port 80, 443, and 61xxx for
websockets showed >10% failures on port 80 for non HTTP protocols.

b) no major browser has deployed pipelining.  It's not like we don't want
to.  We all want to!  Ask Patrick McManus for details - to think this works
is just wishful thinking. If all we had to do was turn on pipelining 3
years ago, we would have done it.

For the record - nobody wants to avoid using port 80 for new protocols.
 I'd love to!  There is no religious reason that we don't - its just that
we know, for a fact, that we can't do it without subjecting a non-trivial
number of users to hangs, data corruption, and other errors.  You might
think its ok for someone else's browser to throw reliability out the
window, but nobody at Microsoft, Google, or Mozilla has been willing to do
that...

As for mobile safari - I mentioned this in my talk the other day - its a
bit of a conundrum.  Android's browser (not chrome) also turns on
pipelining.  But I know that neither Apple nor the Android team have
produced data or analyzed the success or failures of pipelining.  Mobile
browsing is downright awful (due to bad content, networking errors, and
other things).  It could be that mobile networks have fewer interfering
proxies, or it could be that these errors are just getting blamed on other
mobile network glitches.  I honestly don't know.  I'd love to see data on
the matter.

Either way - until someone produces data to contradict the current major
browser data - we need to stop dreaming that port 80 is viable for anything
other than pure HTTP.  The data we have says its not.

Either produce new data or admit you don't know and trust what the browser
developers are telling you.

Mike

---

From: Willy Tarreau <[email-masked]>
Date: Sat, 31 Mar 2012 13:30:17 +0200

> mobile network glitches.  I honestly don't know.  I'd love to see data on

I think that instead, many mobile vendors deploy transparent proxies to
speed up browsing, and since these are recent products, they support
pipelining pretty well. But if the mobile browsers were to connect to
the net directly and try pipelining, there would still be a number of
surprizes. That said, opera ships with pipelining turned on by default
and does pretty well, as I don't remember having observed a single
hang (I don't know how many tricks they involved for this).

> other than pure HTTP.  The data we have says its not.

It would be nice to have the same data with a fallback mechanism, because
I suspect it's much more reliable than what has been measured for a use with
WS, which requires a mandatorily non-compatible upgrade.

None of my corporate customers currently let unknown ports pass through their
proxies, and none of them will be willing to blindly open that without the
ability to inspect requests flowing there. The advantage of port 80+Upgrade
is that current filtering policy still works, and if the product is not 2.0
compatible, 1.1 is kept for all the session, which I expect to result in a
much better overall success than a commonly closed port.

Regards,
Willy

---

From: Mark Nottingham <[email-masked]>
Date: Sat, 31 Mar 2012 13:54:49 +0200

On 31/03/2012, at 1:11 PM, Mike Belshe wrote:

> For the record - nobody wants to avoid using port 80 for new protocols.  I'd love to!  There is no religious reason that we don't - its just that we know, for a fact, that we can't do it without subjecting a non-trivial number of users to hangs, data corruption, and other errors.  You might think its ok for someone else's browser to throw reliability out the window, but nobody at Microsoft, Google, or Mozilla has been willing to do that…

Mike - 

I don't disagree on any specific point (as I think you know), but I would observe that the errors you're talking about can themselves be viewed as transient. I.e., just because they occur in experiments now, doesn't necessarily mean that they won't be fixed in the infrastructure in the future -- especially if they generate a lot of support calls, because they break a lot MORE things than they do now. 

Yes, there will be a period of pain, but I just wanted to highlight one of the potential differences between deploying a standard and a single-vendor effort.  It's true that we can't go too far here; if we specify a protocol that breaks horribly 50% of the time, it won't get traction. However, if we have a good base population and perhaps a good fallback story, we *can* change things.

Just my .02.

> As for mobile safari - I mentioned this in my talk the other day - its a bit of a conundrum.  Android's browser (not chrome) also turns on pipelining.  But I know that neither Apple nor the Android team have produced data or analyzed the success or failures of pipelining.  Mobile browsing is downright awful (due to bad content, networking errors, and other things).  It could be that mobile networks have fewer interfering proxies, or it could be that these errors are just getting blamed on other mobile network glitches.  I honestly don't know.  I'd love to see data on the matter.

I tend to agree with the point you made in the meeting -- this probably falls into the noise of other errors / discomforts in the mobile world. Mobile users have low expectations.

Cheers,

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

---

From: Peter L <[email-masked]>
Date: Sat, 31 Mar 2012 09:25:28 -0400

Multiplexing inefficiencies:

I don't have data on this but I can share my experience developing a web accelerator for satellite networks that does prefetching (similar to Server Push but prefetched objects are buffered in the modem as opposed to the browser itself) and has supported multiplexing similar to SPDY.

Bad performance of hi priority objects (browser requested JavaScript say) when preceded by low priority objects (Images or prefetched objects) is a serious problem when objects are multiplexed, especially for congested networks. The ideal solution is for the optimizer to send in priority order but also mark the priority of packets, maintain original streams, as well as the visibility of headers so that COTS networking equipment can be used to differentially shape the streams based on priority. 

Hypothetical Example: Assuming SPDY's Server Push feature is widely adopted, ISPs will want to be able to treat prefetched data with a lower priority than interactive or user requested data when their networks are congested. They already have the gear in place to do this type of L7 differential shaping. It's good for end users and good for site owners as it allows for good page load times even during peak busy hours. Do you agree HTTP 2.0 should not break this type of functionality?

Thanks,

Peter

On Mar 30, 2012, at 9:22 AM, Mike Belshe <[email-masked]> wrote:

> I'm new to this list but have been studying web performance over high latency networks for many years and multiplexing seems to me like the wrong way to go. The main benefit of multiplexing is to work around the 6 connections per domain limit but it reduces transparency on the network, decreases the granularity/modularity of load balancing and increases object processing latency in general on the back end as everything has to pass through the same multiplexer, and introduces its own intractable inefficiencies.
> 
> The CPU processing at the server is one thing we could optimize for.  Or we could optimize for user's getting their pages faster.
> 
> Data suggests that your claims of inefficiency are simply incorrect.  But if you have a benchmark to report upon, we could discuss that.
> 
> 
>  
> In particular the handling of a low priority in flight object ahead of a high priority object when packet loss is present is a step backwards from what we have today for sites that get beyond the 6 connections per domain limit via domain sharding. Why not just introduce an option in HTTP 2.0 that allows clients and servers to negotiate max concurrent connections per domain?
> 
> As you can see from data, websites are not having any trouble getting around the 6 connection limit already.  
> 
> We could do this, but it would do nothing to make pages load faster or be lighter weight on the network.
> 
>  
> When web sites shard domains, aren't they essentially telling the browser that they will happily accept lots more connections? I'm sure this suggestion has long since been shot  down but browsing around on the web I'm not finding it.
> 
> As for header compression, again this is a trade-off between transparency/multiple streams and bandwidth savings. But I'd think this group could come up with ways to reduce the bytes in the protocol (including cookies) without requiring the use of a single compression history, resulting in an order-sensitive multiplexed stream.
> 
> I'm not sure why you are opposed to compression.  We could reduce the bytes as well, and nobody is against that.
> 
> What is "transparency on the wire"?  You mean an ascii protocol that you can read?  I don't think this is a very interesting goal, as most people don't look at the wire.  Further, if we make it a secure protocol, its a moot point, since the wire is clearly not human readable.
> 
> mike
> 
> 
> 
> 
>  
> 
> Thanks,
> 
> Peter
> 
> 
> I thought the goal was to figure out HTTP/2.0; I hope that the goals of SPDY are in-line with the goals of HTTP/2.0, and that ultimately SPDY just goes away.
> 
> Mike
> 
>

---

From: Peter L <[email-masked]>
Date: Sat, 31 Mar 2012 09:44:06 -0400

Perhaps one multiplexed persistent connection for each priority and priority info alone visible in the headers would alleviate this playing nicely with network QoS gear issue.

Peter

---

From: Adam Barth <[email-masked]>
Date: Sat, 31 Mar 2012 10:17:38 -0700

> Yes, there will be a period of pain, but I just wanted to highlight one of the potential differences between deploying a standard and a single-vendor effort.  It's true that we can't go too far her…

That's not our experience as browser vendors.  If browsers offer an
HTTP/2.0 that has a bad user experience for 10% of users, then major
sites (e.g., Twitter) won't adopt it.  They don't want to punish their
users any more than we do.

Worse, if they do adopt the new protocol, users who have trouble will
try another browser (e.g., one that doesn't support HTTP/2.0 such as
IE 9), observe that it works, and blame the first browser for being
buggy.  The net result is that we lose a user and no pressure is
exerted on the intermediaries who are causing the problem in the first
place.

These are powerful market force that can't really be ignored.

Adam

---

From: Roberto Peon <[email-masked]>
Date: Sun, 1 Apr 2012 06:18:45 +0200

On Sat, Mar 31, 2012 at 3:25 PM, Peter L <[email-masked]> wrote:

> I don't have data on this but I can share my experience developing a web
> accelerator for satellite networks that does prefetching (similar to Server
> Push but prefetched objects are buffered in the modem as opposed to the
> browser itself) and has supported multiplexing similar to SPDY.
>
> Bad performance of hi priority objects (browser requested JavaScript say)
> when preceded by low priority objects (Images or prefetched objects) is a
> serious problem when objects are multiplexed, especially for congested
> networks. The ideal solution is for the optimizer to send in priority order
> but also mark the priority of packets, maintain original streams, as well
> as the visibility of headers so that COTS networking equipment can be used
> to differentially shape the streams based on priority.
>
>
If we are on a transport such as SCTP, we can do some of these things and
avoid some HOL blocking cases that can occur with multiplexing over TCP. I
could see defining a mapping for HTTP2 onto such pre-multiplexed protocols,
but Mark would know best if that is something we can do. It'd make sense to
me, though you'd end up with two dufferent

> Hypothetical Example: Assuming SPDY's Server Push feature is widely
> adopted, ISPs will want to be able to treat prefetched data with a lower
> priority than interactive or user requested data when their networks are
> congested.
>

Bleh! You have to consider the second-order consequences of doing things
like that.  If you do that, then server push is effectively optional and
people will just inline again, and the likely outcome is that you'll
neither have an effective cache, nor decrease overall bandwidth. Anything
that forces people to inline has strongly negative effects on efficiency
and latency as compared to server push.

I am, however, all in support of the browser declaring what it will or will
not support w.r.t. server push. The client-side's incentives align with the
user, and so putting the policy decision there makes sense so long as it
doesn't incur an extra RT from negotiation.

> They already have the gear in place to do this type of L7 differential
> shaping. It's good for end users and good for site owners as it allows for
> good page load times even during peak busy hours. Do you agree HTTP 2.0
> should not break this type of functionality?
>

Traffic shaping is an awesome technology, but the interests of the
middleware providers rarely aligns with the user. Look at the manoeuvring
that AT&T is doing these days w.r.t. bandwidth on mobile devices, or the
debacle of putting the full set of HTTP over port 80 (even when the
endpoints agree and are tested to speak the full set) as examples.

I don't want to be in a world where they look at which site (as opposed to
port) you're going to and potentially raise or lower the priority of your
packets because someone pays them more? Screw that!

In any case, do we believe that even an elightened and altruistic
middleware provider can separate and distinguish between the hi-pri things
within the one protocol effectively? I think that alone is a difficult
problem... and thankfully probably out of the purvue of the WG.

-=R

> The CPU processing at the server is one thing we could optimize for.  Or
> we could optimize for user's getting their pages faster.
>
> I'm not sure why you are opposed to compression.  We could reduce the
> bytes as well, and nobody is against that.
>

---

From: Willy Tarreau <[email-masked]>
Date: Sun, 1 Apr 2012 06:39:43 +0200

On Fri, Mar 30, 2012 at 03:22:12PM +0200, Mike Belshe wrote:
> don't look at the wire.

I agree with you here Mike, despite being used to look at network captures
all the day and testing proxies with "printf|netcat" at both ends. But we
must admit that if developers need tools, they will develop their tools.
Having an HTTP option for netcat would work well, or even having an 1.1-to-2.0
and 2.0-to-1.1 message converter on stdin/stdout would do the trick. So I
prefer to lose the ability to easily debug and have something efficient than
the opposite. And it costs me a lot to say this :-)

Willy