W3C home > Mailing lists > Public > ietf-http-wg@w3.org > April to June 2012

Re: multiplexing -- don't do it

From: Peter Lepeska <bizzbyster@gmail.com>
Date: Sun, 1 Apr 2012 15:43:54 -0400
Message-ID: <CANmPAYGbT1iZe+9T77NueuBt16wXcT+_XC_b+EWAW_xe_uxmGg@mail.gmail.com>
To: Roberto Peon <grmocg@gmail.com>
Cc: Mike Belshe <mike@belshe.com>, "ietf-http-wg@w3.org" <ietf-http-wg@w3.org>
Hi Roberto,

Comments inline.

Peter

On Sun, Apr 1, 2012 at 12:18 AM, Roberto Peon <grmocg@gmail.com> wrote:

>
>
> On Sat, Mar 31, 2012 at 3:25 PM, Peter L <bizzbyster@gmail.com> 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 <mike@belshe.com> wrote:
>>
>>
>>
>> On Fri, Mar 30, 2012 at 4:07 AM, Peter L <bizzbyster@gmail.com> 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 <mike@belshe.com> 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 <w@1wt.eu> 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
>>>>>
>>>>>
>>>>>
>>>>
>>>
>>
>
Received on Sunday, 1 April 2012 19:44:23 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Friday, 27 April 2012 06:51:59 GMT