add QUIC support

[joeblew99]

https://github.com/lucas-clemente/quic-go
quic is a network protocol using UDP.
fast and NAT aware. So great for Mobile.
it also works in Chrome browsers. Still might need flags
It also has been submitted to the IETF

[lenovouser]

I am pretty sure NATS is using their own protocol? What is QUIC going to change there?

[mcqueary]

TL;DR It's not clear what the benefits of QUIC would be versus TCP for a connection-oriented protocol like NATS.

The primary value of QUIC (as I understand it) is in reducing latency for secure, browser-style (i.e. connectionless) interactions with a web server, where every single interaction involves connecting, requesting data and getting a response. To this end, one of its key advantages over TCP is in multiplexing streams over a single connection for efficiency, thereby sharply reducing the kind of per-stream connection overhead typically associated with (e.g.) a connectionless protocol like HTTP, and improving compression performance.

So here's the rub: NATS is a connection-oriented protocol. A client application needs only a single TCP connection to service multiple streams of data, regardless of whether it's request/reply or streaming data in one direction or the other. The overhead that QUIC eliminates is chiefly in reducing round trip times (RTT) associated with setting up a connection and sending a request-reply every single time you interact with the server. While you could use NATS that way, and I'm sure some people do, I think the majority of users employ a small number of long-lived connections for most of their needs, vs. creating new connections for every new request.

Obviously we're interested in community feedback on this. If people see compelling value in supporting NATS over a QUIC transport for specific use cases, we'd love to hear more!

[joeblew99]

@mcqueary
Thanks for the due diligence on QUIC in relation to NATS.

i ended up writing my own semantic addressing layer above NATS.. But here is why i did it.

I raised it because i wanted to use NATS behind a proxy (any golang one) with mobile and IOT client devices on mobile telephone networks.
QUIC is UDP based and thats a big bonus on Mobile networks.
The two types of flows are:

• client sending in sensor data over QUIC that is stored in minio before processing.
• clients participating in shared data that is changing often. When one client changes common data, it sends the mutation to NATS and NATS rebroadcasts it to all client subscribers.

I also use loRaWAN for IOT and SMPP for mobile devices. QUIC cant help me there because these networks cant use QUIC so use a different proxy in front of NATS.
So i tend to use different gateways / proxies in front of NATS depending on the protocol, with NATS being the core message gateway, and then logic behind that.

So, what i was really asking for is semantic addressing in essence.

[joeblew99]

I closed this because I ended up just making wrappers for QUIC and other network transports and bindings.

Used go-kit which is very good for these situations with some go generators.
The generators run of protocol buffers with annotations hinting to the code generator writers what topics to use on Nats.

In hindsight this would be much easier if NATS supported running embedded properly because there would be less network layers and so would be much higher performance.
But I could not work out a way to modify Nats to use go routines instead of TCP. So I was for ed to run Nats on a sperate process from the gateway.

@ mcqueary did I explain this well enough ?
Basically I don't want you to change what training sports bars uses, I just would like to be able to run Nats embedded and allow the pub sub to use go routines, instead of tcpip.

[ColinSullivan1]

@joeblew99 , I can see the advantage of a pluggable protocol, but this won't in the roadmap of NATS at this time. The beauty of OSS is that you can fork to develop on your own; if you implement something along these lines, we'd certainly be interested in checking it out.

[jdrews]

I noticed that the roadmap for NATS lists QUIC Support in 2021-Q3. Very excited about this!

https://nats.io/about/

Can someone from the NATS team point me to more information about the plan for QUIC support?

[jdrews]

I jumped on the NATS Slack and talked to the NATS maintainers. No details yet. Sounded like the goal was to make QUIC Support transparent to client and servers.

[jdrews]

Looks like QUIC has now moved on the roadmap to 2021-Q4
https://nats.io/about/

[derekcollison]

https://www.fastly.com/blog/quic-is-now-rfc-9000

[KristoferHansson]

Very much looking forward to the QUIC + Advanced Edge / 5G Support previously planned for Q3
We are operating fleet of robots indoors with shared WiFi link to backend, highly varying radio conditions, why QUIC is of high interest. Currently running reliable UDP implementation to backend(where we use NATS).

[derekcollison]

I am interested in learning more about your situation. Since RFC-9000 just made it out we would imagine basing on something around that. It will take some time for the ecosystem to get everything updated etc.

Is your interest around QUIC about noisy comm paths or head of line blocking?

[jdrews]

@derekcollison My use case for QUIC on NATS is definitely the "noisy comm paths". In particular I'm interested in using NATS JetStream with QUIC for SATCOM between datacenters and distant, ephemeral edge nodes that have low bandwidth (2mbps or less), high latency (650ms-2sec), high packet loss (5% or more), and intermittent access (weeks of downtime with queued up data).

You can read more about the use cases here:
https://tools.ietf.org/id/draft-kuhn-quic-4-sat-06.html
https://datatracker.ietf.org/meeting/103/materials/slides-103-maprg-quic-and-satcom-nicolas-kuhn-01

[derekcollison]

Will take a look for sure. We may be looking to reach out to partners and customers on this work as well to make sure we have a good understanding of what is desired.

If you have any interest shoot me an email.

[tysonrm]

Looks like support is on the roadmap. The advantage of QUIC, the transport protocol for HTTP/3, is that it does not block other streams in the event of a missing or malformed packet.

[jdrews]

I don't see QUIC on the roadmap for 2023 anymore. However there is Leaf Node Enhancements in 2023-1H which I think might be QUIC. Is that the case?

[derekcollison]

Yes we are considering QUIC in that timeframe and if we proceed will start with leafnodes.

[hwinkel]

@derekcollison is the roadmap above still valid?

[derekcollison]

Needs updating.

[NoahHahm]

CoreNATS is TCP-based.
I wonder if the latency will be faster if QUIC-based technology is also available.
(Especially in super multi-cluster environment)
I'm curious if you've tried an experiment.

[derekcollison]

TCP with short RTT and no loss will beat QUIC. QUIC will have an advantage over long RTT and lossy networks.