QUIC was Inets http2 support

[Lukas Larsson]

On Thu, 21 Nov 2019, 17:50 Loïc Hoguin, <essen@REDACTED> wrote:

> Mind you I also change my mind on the complexity every other week...
> Ultimately it's just something that has to be done so it doesn't really
> matter how big the task is.


Indeed. The question  however is if it is best to do it like we've done for
crypto or for ssl/ssh.

Gotta get started first. From what I've seen
> of the progress June 2020 or so would be a good time to start as the
> protocol should be close to completion by then.
>

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.


> 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?


> 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.

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.

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.


> --
> Loïc Hoguin
> https://ninenines.eu
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://erlang.org/pipermail/erlang-questions/attachments/20191121/4cc633be/attachment.htm>