Re: multiplexing -- don't do it

Hi Mike,

On Wed, Apr 04, 2012 at 10:10:05AM +0200, Mike Belshe wrote:
> > Personally I'm still thinking that if we only pipeline on http/2 and not
> > on http/1, we'll avoid all the associated risks. The real issue I can
> > imagine with broken intermediaries is related to those still parsing
> > requests in *packets* without reassembling them as a stream. Once your
> > requests exceeds 1 packet (or the product's limit), you can run into
> > trouble. Seen that on Alteon years ago (was an excellent L3/L4 LB but
> > marketing made it L7 and caused issues everywhere).
> >
> > As we suggested in our draft, once the requests are reduced, it's possible
> > to send the next ones along with the first request in a header field, this
> > protects us against 1.1-only intermediaries which can't see them.
> >
> 
> No - you can't rely on packet boundaries at the TCP layer to solve race
> conditions at the app layer.  Example, at the time of the first request,
> you may not have a second request to bundle with it, but 2ms later, you
> might.  So, you'd end up with packet splitting again. And I haven't even
> mentioned that the app layer has no idea how big the packet payload is
> anyway....

It seems we're talking about different things. I'm not saying that we can
shrink the requests to make them fit into TCP segments, I know this is pure
crap and must never be done. I'm saying that we can use HTTP headers to send
some requests once we manage to shrink a request size so that they do not
represent a significant overhead for the fallback case.

Let me be clear on one point : I don't want to rely on any form of HTTP/1.1
pipelining as we know it breaks from time to time. I just want to use plain
non-pipelined HTTP/1.1 to ensure maximum reliability. For instance :

    GET /index.html HTTP/1.1
    Upgrade: HTTP/2.0
    Http2-Req: "/css/style.css", "/js/menu.js", "/favicon.ico", "/img/top.png"
    Connection: Upgrade, Http2-Req

This does not involve 1.1-based pipelining and cleanly falls back to 1.1
when some non-2.0 compatible gateways are in the middle.

I'm clearly aware of a number of issues which come with existing deployments,
some more or less serious, and as much as possible I want the future design
not to rely on too many assumptions.

Regards,
Willy

Received on Wednesday, 4 April 2012 09:07:24 UTC