Subject: Re: multiplexing -- don't do it

From: Peter Lepeska <[email-masked]>
Date: Sun, 1 Apr 2012 15:43:54 -0400

Hi Roberto,

Comments inline.

Peter

On Sun, Apr 1, 2012 at 12:18 AM, Roberto Peon <[email-masked]> wrote:

>
>
> On Sat, Mar 31, 2012 at 3:25 PM, Peter L <[email-masked]> wrote:
>
>> 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.
>>
>>
> 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
>

SCTP solves some of this but still it doesn't help the network make better
decisions when congested.

>
>
>> 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.
>

De-prioritizing server push was just an example. If the server knows the
state of the browser cache, then server push is not really speculative. In
that case I can't see why it would be de-prioritized. But I was just using
it as an example. Consider instead browser-set object priorities. When
congested, ISPs can deliver a better service to their users if they know
which objects have a bigger impact on page load time. A related example,
COTS shapers can already be configured to prioritize SYNs and SYN-ACKs for
port 80/443 packets over TCP  data packets since its known that dropping
these has a bigger impact on page load.

>
> 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.
>

I think exposing browser-marked priority on HTTP objects to the network is
a really great idea. And based on my experience, ISPs will gladly take
advantage of this information to decrease page load times during peak busy
hours for their users.

>
> -=R
>
>
>>
>> Thanks,
>>
>> Peter
>>
>>
>> On Mar 30, 2012, at 9:22 AM, Mike Belshe <[email-masked]> wrote:
>>
>>
>>
>> On Fri, Mar 30, 2012 at 4:07 AM, Peter L <[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
>>>
>>>
>>> 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: Amos Jeffries <[email-masked]>
Date: Mon, 02 Apr 2012 11:34:39 +1200

On 02.04.2012 07:43, Peter Lepeska wrote:
> On Sun, Apr 1, 2012 at 12:18 AM, Roberto Peon wrote:
>
<snip>
> advantage of this information to decrease page load times during peak 

Indeed they will. Websites downloading without images, styles, or 
scripts until the second or third force-reload is a *very* common user 
complaint on some ISP here in NZ. From precisely that ISP enthusiasm. 
When the user traffic exceeds the upstream bandwidth queueing occurs, 
and the result is an almost steady stream of high priority requests, and 
a continual delaying of low priority ones until the client times out or 
aborts.

I think there is a small factor which has been overlooked in this whole 
discussion about HOL and multiplexing. Cache latency.

Given the presence of caching intermediaries its almost certain that a 
downstream cache closer to the client will encounter the scenario of 
choosing between a high priority request that is some (possibly 
hundreds) of ms RTT away and a low priority response that is immediately 
accessible in its cache. Blocking the cached response until the high 
priority can be found and transmitted would be damaging to the overall 
latency. Multiplexing is the only way to pause the low priority response 
when the high priority response starts arriving for delivery.

To be fair IMHO the best thing for MUX nodes is to service all requests 
equally and interleave responses prioritised by order requested foremost 
and by availability second. Browsers etc can then prioritise the order 
of requests for whatever the local need is and expect that priority to 
be followed in a best-effort manner with any deviation performed being 
beneficial to overall latency. Chunking and interleaving of chunks by 
priority is not optional.

AYJ