<div dir="ltr"><div dir="ltr">On Thu, Nov 21, 2019 at 4:17 PM Loïc Hoguin <<a href="mailto:essen@ninenines.eu" target="_blank">essen@ninenines.eu</a>> wrote:<br></div><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">I've contemplated starting work on a QUIC implementation but I've queued <br>
it back to second place so I might only start in 6 months if nobody does <br>
before me.</blockquote><div><br></div><div>We have also considered doing this. I've already written a nif wrapper for the CloudFlare rust code that can do the very basics, however the steps from basic to fully-fledged implementation seems huge. Also, from what I understand, the cloud flare implementation is not ready for production use, but that will hopefully change in the future.</div><div><br></div><div>So far my impression has been more similar to what Jesper describes. It will be a lot of work to get correct and fast enough in Erlang. Using some other stack (like the mvfst for instance) would cut out a lot of the complexity, but we lose all of the control of what is going on. Though I suppose that is the same as what happens with TCP today.</div><div><br></div><div>I've been changing opinion on every other week for a while whether I think it would be a good idea for us to implement it or not, this week I'm against :) The things that I think make this job huge is the flow control, congestion control things and the constant changes to the protocol that seem to be planned. However, if there are more people than us at the OTP team that are interested in helping out to build good support for QUIC, it becomes a lot more interesting.</div><div><br></div><div>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.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">* Write the network layer. The hard part is TLS 1.3 (including 0-RTT!), <br></blockquote><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
but it can be skipped by using a custom cleartext "encryption" mechanism <br>
so you can still progress even if you don't have TLS 1.3 yet. Since it's <br>
being worked on, waiting is good!<br></blockquote><div><br></div><div>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</div><div><br></div><div>Lukas</div></div></div>