Re: on HTTP/QUIC and HTTPBis

Hi Patrick,

On Fri, Mar 10, 2017 at 02:38:36PM -0500, Patrick McManus wrote:
> I'm going to include an *opinion* here on the value of the quic work from
> the perspective of the http ecosystem. I think its useful to have something
> like this that isn't flavored quite as strongly by the Google experience as
> most of the material out there is. (though we can only thank them for their
> work and experience - its simply that diversity is valuable).  An important
> element of the quic-wg charter is that they work closely with httpbis -
> let's consider this part of that cooperation.
(...)

Thank you very much for this detailed overview. It's more or less what
I was already aware of, but much more clear :-)

> Further, TCP Tuning for HTTP (1 or 2) is operationally complicated. One of
> the complications is the administrative separation between transport and
> application. How do you set IW? Are you doing TLP? RACK? Is Fast Open an
> option for you? QUIC, because it can be bundled with an application in
> userspace, provides a deployment option for getting best of breed transport
> algorithms deployed to hosts that may be running legacy TCP stacks.
(...)

In fact, as one developer having encountered many difficulties when
trying to implement H2 on an existing proxy, especially during the
early days, I think that being forced to implement a new transport layer
will give many of us a good excuse for breaking a lot of existing code,
resulting in more flexibility and choice for the new implementations.
This will definitely come with a cost but starting from scratch is often
easier than bending existing stuff enough so that it more or less adapts.

As a WG participant I suffered from not being able to experiment with
H2 in the product I cared about during the design discussions. There
was so much an offset between running implementations and those
scratching their heads trying to identify what to break to approach
the goal that the design was mostly driven by existing implementations
and those written from scratch. Here we may have a chance to involve
more people since a lot of work will have to be implemented from scratch
in most products, granting a bit more of "equity" in front of the design
constraints.

I personnaly am not yet convinced about the performance a program like
haproxy could achieve by dealing with packets in userland, there are
pros and cons. However I'm seeing a benefit. We're seeing more and more
applications relying on frameworks like DPDK though these ones require
you to add a full TCP stack which generally requires totally different
semantics. That's why often they're just switches and routers. Mapping
UDP in such a packet-oriented framework can be much easier and I predict
we'll see much more adoption there.

Best regards,
Willy

Received on Friday, 10 March 2017 20:40:21 UTC