QUIC was Inets http2 support

[Lukas Larsson]

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

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

Ah yes, I've not been following those at all as they don't matter for the
distribution case.


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

Mhm, it is rare enough that using some slow fall back would work.

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

I'll see what we can do.


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

Indeed.


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