Re: on HTTP/QUIC and HTTPBis

Mike and Patrick,

very well written and very interesting to read your views on this matter. Thank you!

I look forward to see how these protocol/components continue to evolve and very curious at implementation prototypes outside google and how this userland packet handling will be tackled. Eventually, I expect some reusable components to emerge so that we will have some software abstractions that everyone can build upon, again.

Patrick's mention of buffer management I can very much relate to as it is one of the headaches for h2 implementations I try to tackle myself. I look forward to find out if the snake will eat its tail when we go from 6 tcp flows (h1) to 100 flows in 1 tcp (h2) to 100(0?) udp flows (hq).

When I wrote earlier to "abandon all hope" to get h2 and hq perfectly aligned, I meant that more positive than it sounds (excuse my german). What I wanted to say is that treating them as the same in regards to frame definitions/registry is not a good idea and breaking with this is good.

-stefan

> Am 11.03.2017 um 01:16 schrieb Mike Bishop <Michael.Bishop@microsoft.com>:
> 
> 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 08:29:20 UTC