RE: on HTTP/QUIC and HTTPBis

For me, the biggest answer is agility.  The reality is that we’ve heavily invested in our TCP stacks, and QUIC going over UDP is likely to require time to catch up, so I’m unconvinced of an instant performance benefit.  I’d be thrilled if we even get parity with TFO+TLS 1.3+HTTP/2 at first.  But there’s been good work happening in TCP for years that isn’t reliably deployable on the Internet – how long has TFO been an RFC?  And yet, it spent a long time off by default in each OS.  In Windows, we aren’t turning it on by default until we’ve added mitigations for the middleboxes that don’t play well when they see a different TCP behavior than they expected.  They exist, and they’re numerous.

HTTP has faced the same problem.  We (Microsoft) have HTTP features that we recommend not be deployed over the Internet, because we know of middleboxes that panic or behave badly.  More recently, several new standards have been, formally or informally, restricted to HTTPS-only for the same reason.  We’re freer to innovate inside the HTTPS tunnel, because there’s better control of which devices can see those bits.

By having encryption and integrity protection at the transport level, the transport gets the same freedom to innovate in the future.  And HTTP will reap the benefit of those future improvements over time.  It’s an investment, but one I hope will eventually pay dividends.

From: Patrick McManus [mailto:mcmanus@ducksong.com]
Sent: Friday, March 10, 2017 5:45 PM
To: Mike Bishop <Michael.Bishop@microsoft.com>
Cc: Poul-Henning Kamp <phk@phk.freebsd.dk>; Patrick McManus <mcmanus@ducksong.com>; Adrien de Croy <adrien@qbik.com>; HTTP working group mailing list <ietf-http-wg@w3.org>
Subject: 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<mailto: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<mailto:phk@phk.freebsd.dk>]
Sent: Friday, March 10, 2017 12:22 PM
To: Patrick McManus <mcmanus@ducksong.com<mailto:mcmanus@ducksong.com>>
Cc: Adrien de Croy <adrien@qbik.com<mailto:adrien@qbik.com>>; Mike Bishop <Michael.Bishop@microsoft.com<mailto:Michael.Bishop@microsoft.com>>; HTTP working group mailing list <ietf-http-wg@w3.org<mailto:ietf-http-wg@w3.org>>
Subject: Re: on HTTP/QUIC and HTTPBis

--------
In message <CAOdDvNqc3nCH-55GPsCVhsWiFt4dXkNTQPFLizpuGPFjbQOg4Q@mail.gmail.com<mailto:CAOdDvNqc3nCH-55GPsCVhsWiFt4dXkNTQPFLizpuGPFjbQOg4Q@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<mailto: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.