RE: on HTTP/QUIC and HTTPBis

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-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         | TCP/IP since RFC 956
FreeBSD committer       | BSD since 4.3-tahoe    
Never attribute to malice what can adequately be explained by incompetence.

Received on Saturday, 11 March 2017 00:17:08 UTC