RE: Demultiplexing HTTP and DNS on the same listener [New Version Notification for draft-dkg-dprive-demux-dns-http-02]

It's ALPN.  At first blush, I would pick a different ALPN token for h2+DNS and define it as a new, derivative protocol.

-----Original Message-----
From: Daniel Kahn Gillmor [mailto:dkg@fifthhorseman.net] 
Sent: Wednesday, May 3, 2017 4:22 PM
To: Patrick McManus <mcmanus@ducksong.com>; Patrick McManus <mcmanus@ducksong.com>
Cc: HTTP Working Group <ietf-http-wg@w3.org>; DNS Privacy Working Group <dns-privacy@ietf.org>
Subject: Re: Demultiplexing HTTP and DNS on the same listener [New Version Notification for draft-dkg-dprive-demux-dns-http-02]

On Wed 2017-05-03 15:13:43 -0400, Patrick McManus wrote:
> I forgot to mention another potential challenge with the demux 
> approach -
> h2 is not client send first.. typically both sides send SETTINGS 
> simultaneously.. and its important to the server not to hold those 
> back .5RTT as it can contain a bunch of configuration information 
> (buffer sizing, levels of parallelism, extension negotiation, etc..) 
> that it wants the client to start honoring asap. (Whether this is 
> actually simultaneous boils down to which flavor of tls handshake is 
> done.)

Ah!  Thanks for this heads-up.  That's definitely an interesting wrinkle.  How does this interact with HTTP/1 clients connecting to the service?  or is it only possible to do this because of the negotiated ALPN?

If so, perhaps the demuxing needs to be done only when not sending an alpn of "h2", and the draft can drop the HTTP/2 section.  What do you think?

     --dkg

Received on Thursday, 4 May 2017 00:15:20 UTC