I am curious what Erlang Core Team thinks about QUIC and whether there are plans to add support for it.
If yes, I am curious what would be the prefered way of implementing it. In particular, would plain Erlang implementation be acceptable?
9 Likes
I really expect Erlang to support QUIC, and more and more scenarios will use QUIC in the future, such as HTTP3, Web3, IM, Game Server and so on.
4 Likes
We have no firm plans regarding QUIC right now. QUIC is interesting and we have looked briefly at it. Currently we have no use case that motivates us to make a QUIC implementation or binding for Erlang.
If we should support it in OTP it is a question if it should be in pure Erlang or if we just should have a binding to a library for QUIC like the one from Microsoft which the EMQX people presented on the Code Beam conference in May. They have implemented NIF bindings towards the Microsoft library and the component is called “Quicer”.
Having QUIC implemented in pure Erlang has the advantage that it is portable and does not introduce any new dependencies. But such a solution might not get as good performance as a C/C++ implementation or binding. Such an implementation would be a very big job to implement compared with just have a binding towards an existing library in C/C++/Rust.
So we are following the development around QUIC and it would be interesting to have support for it. But there must be a good use case first.
8 Likes
In general, QUIC is the future and early support is good. I think using NIF based on the existing QUIC implementation is an easier way to implement it. In particular, Microsoft’s Msquic provides dynamic libraries and cross-platform. I’m going to wrap the NIF binding based on MSQUic, in order to learn and do something, probably implementing it will take me a few months of free time
4 Likes
MQTT over QUIC may be a good UC. E.g., like explained here: https://www.researchgate.net/publication/328380610_Implementation_and_Analysis_of_QUIC_for_MQTT
6 Likes
ENQX based on msqic implements MQTT over quic in this project:GitHub - emqx/nanomq: An ultra-lightweight and blazing-fast MQTT broker for IoT edge
and here’s an article about it: https://mp.weixin.qq.com/s/TQ-TQc-VDkyv6RWRH_61rw
my main interest is in the use of QUIC in game server
3 Likes
I think that community is the use case and this would broaden Erlang/Elixir possibilities.
4 Likes
Yes, MQTT over QUIC is a very good use case as blogged by EMQX.
RabbitMQ’s MQTT implementation would hugely benefit if there was a QUIC library provided by OTP.
3 Likes
Curious, why does it need to be provided by OTP (very highly unlikely is my understanding) and Rabbit not use the QUIC lib from EMQX?
Or do you not want a NIF and just mean a pure Erlang implementation, not necessarily in OTP?
2 Likes
It doesn’t need to be provided by OTP. I suppose RabbitMQ could also use the QUIC lib from EMQX or some other implementation.
However, in general it’s safer to depend on the standard libraries provided by the core language (be it Erlang/OTP or Java or Golang or whatever language) than on third party libraries. By “safer” I mean that standard libraries tend to be more stable and better maintained in the long term compared to third party libraries.
Either way, what I tried to say is that we have a very good use case for QUIC 
3 Likes
Gotcha, and makes sense, but so very unlikely to happen I’m hoping a couple users will work together on a quic and http/3 community lib – and emqx seems to have a good starting point. Maybe if Ericsson has a use case in the future it can then be upstreamed or in someway adopted but out of the main tree.
4 Likes
I would be terribly curious to see benchmarks against a nif version vs a pure erlang version.
3 Likes
I would be terribly curious to see benchmarks against a gen_sctp implementation…especially given the actual environments Erlang tends to be deployed into.
It has been mentioned before and the whole middleware argument is a distraction as:
- if you have problems with middleware boxen between your nodes, fix/burn/nuke-from-orbit those boxen
- if your corporate IT department really is wedded to their broken ‘security’ appliance (as a grumpy {sys,net}admin myself) most kernel implementations natively will tunnel SCTP over UDP
Yet to see a strong argument for using QUIC as a distribution protocol over SCTP, and arguably even elsewhere over a tuned TCP or SCTP connection given the actual tangible lack of benefits it is supposedly meant to bring.
2 Likes
Yeah, I don’t know about QUIC for an alternative dist transport. Not sure how that would work. I’m interested in pure data plane usage myself.
1 Like