QUIC was Inets http2 support

[Loïc Hoguin]

On 21/11/2019 18:21, Lukas Larsson wrote:
> I don't think it is too bad an idea to start now either. From what I can 
> tell the rfc:s are pretty stable already.

The QUIC ones yes, minus the priority mechanism. But HTTP/3 depends on 
both priorities being figured out and also the pushed mechanism. I'm not 
sure how far the latter got or if it's going to be supported at all 
initially. So for my use case it's not as stable as it could be.

>     On 21/11/2019 17:22, Lukas Larsson wrote:
>      > One of the use-cases (besides the obvious HTTP/3 use-case) that
>     we have
>      > been thinking about would be to allow the Erlang distribution to run
>      > over QUIC.
> 
>     That's what I want for RabbitMQ and based on experiments emulating some
>     aspects of QUIC, this is an insanely promising prospect. I expect QUIC
>     to triple the throughput for mirrored RabbitMQ queues *at the very
>     least*.
> 
> 
> Do you? Why? What aspect of it do you think would do that?

I said too much. :-)

>     Some aspects of the distribution do not play well with QUIC though,
>     like
>     `monitor(process, {Name, Node})`. This is the one thing in the
>     distribution protocol for which you can't guarantee ordering over
>     multiple QUIC streams because you don't have the pid that you have for
>     all other messages. 
> 
> 
> Hmm, yes. Not trivial to solve but should be doable.

My current solution is "don't use it". rpc:call(whereis) plus monitor is 
almost the same as well.

>     Right now you also must parse the message in order
>     to figure out on which stream you have to send it, it would probably be
>     better to have this info readily available. 
> 
> 
> Fixing this should be very simple. The information is there we just need 
> to put it in the tuple returned.

I'd love to have this today. :-)

>     Of course you could always
>     use a single QUIC channel but then what's the point. :-)
> 
>      > We were thinking about re-using the ssl applications TLS 1.3
>      > implementation. It is not trivial as transport and TLS are
>     upsidedown
>      > for QUIC, but should be doable sais Ingela and Peter :p
> 
>     If we can have a good interface that has TLS return the
>     encrypted/decrypted binary data rather than write it directly to the
>     socket, I could also use it in Gun to support TLS connections over TLS
>     proxies. Right now it uses the callback module and while it works it's
>     fairly complex.
> 
> 
> Maybe this would be a good starting point for us. Building an API that 
> makes this possible.

So much to do so little time. :-)

-- 
Loïc Hoguin
https://ninenines.eu