Re: on HTTP/QUIC and HTTPBis

Hey Mike, I really don't think we're that far apart except maybe in your
use of the term layers. quic is being effectively componentized but not
into layers that create full abstractions in the way a traditional stack
works. So while transport and crypto are definitely blended (you cannot
implement the transport without doing both transport'y things and crypto
things and then transporty things again) I wouldn't call them layers. I'm
trying out the term blended functions :) ietf quic has effectively been
able to use the services of TLS 1.3 without modification - and thank
goodness as we really don't need another security protocol - but the
layering of cleartext->ciphertext->packets no longer exists (retransmits
being an easy example). But these components definitely have logical
interfaces and can be expressed in code in many many different ways which I
hope makes them suitable to a great deal of diverse environments. This
seems pretty close to your pluggable component vision and I support that as
at least a model for describing what's going on.

That's all really an interesting side-discussion distracting from the
original question (roughly: what feature motivates this thing?) I'm
curious, do you have different answers?

On Fri, Mar 10, 2017 at 7:16 PM, Mike Bishop <Michael.Bishop@microsoft.com>
wrote:

> While Patrick approaches it from a standpoint of how we can squeeze out
> extra performance by intertwining the layers, I see them as different
> stand-alone system binaries owned by different teams, and as things we will
> almost certainly want to modularize for different uses.  And there's value
> in diversity of viewpoints, since Patrick and I are in very different
> implementation situations despite both sitting on the browser side.
>
> That's a big reason why the original monolithic design of QUIC has been
> separated into a transport draft which has pluggable crypto and flow
> control algorithms, drafts defining instances of those algorithms, and an
> HTTP mapping on top of that transport.  I'm trying to make the separation
> between the drafts as clean as possible, because I know that in my system
> they will remain separate components that want to have an interface that's
> as minimal as possible.  TLS concerns should remain at the TLS layer, and
> all the transport should know is what bytes to relay and when the keys have
> been generated.  HTTP should not *have to* know or care about flow control
> windows, ACKs, etc.
>
> Patrick's also correct that, if the components' interfaces aren't minimal,
> you might be able to get some interesting efficiencies by pulling out extra
> information.  But I'd argue the RFCs should not assume that -- those are
> optimizations an implementation can make locally, at its own risk, which
> should not influence wire compatibility.  If you'd like to step over into
> the QUIC side of things and argue for clean separation, we'd love to have
> your input.
>
> -----Original Message-----
> From: Poul-Henning Kamp [mailto:phk@phk.freebsd.dk]
> Sent: Friday, March 10, 2017 12:22 PM
> To: Patrick McManus <mcmanus@ducksong.com>
> Cc: Adrien de Croy <adrien@qbik.com>; Mike Bishop <
> Michael.Bishop@microsoft.com>; HTTP working group mailing list <
> ietf-http-wg@w3.org>
> Subject: Re: on HTTP/QUIC and HTTPBis
>
> --------
> In message <CAOdDvNqc3nCH-55GPsCVhsWiFt4dXkNTQPFLizpuGPF
> jbQOg4Q@mail.gmail.com>
> , Patrick McManus writes:
>
> Thanks for an excellent summary of QUIC.
>
> I am amazed by how unashamed you applaud movement, nay, rush towards
> "mixing application and transport" and "mixing application and crypto"
> considering that our entire 50 year experience in computing has
> consistently shown that to be The Worst Idea Ever, no matter how many times
> people try it.
>
> Given the current state of affairs, I find that course even more baffeling
> in light of IETFs snobby "We don't do APIs" attitude, which is not going to
> make it any easier for the people who will be writing the
> applicryptotransications.
>
> >I think the question for our working group is how we want to engage
> >with all this change - [...]
>
> May I suggest: "Recoil in Horror" ?
>
> Poul-Henning
>
> PS: Have you considered sending your (excellent!) summary of QUIC to RISKS
> Digest preemptively ?  I for one would love to hear PGN's reaction...
>
> --
> Poul-Henning Kamp       | UNIX since Zilog Zeus 3.20
> phk@FreeBSD.ORG         | TCP/IP since RFC 956
> FreeBSD committer       | BSD since 4.3-tahoe
> Never attribute to malice what can adequately be explained by incompetence.
>
>