search

matrix-org / matrix-spec

The Matrix protocol specification
Apache License 2.0
197 stars 97 forks source link

RFC: QUIC transport #1460

Open spacekitteh opened 7 years ago

spacekitteh commented 7 years ago

From the overview

What is QUIC? QUIC (Quick UDP Internet Connections) is a new transport protocol for the internet, developed by Google.

QUIC solves a number of transport-layer and application-layer problems experienced by modern web applications, while requiring little or no change from application writers. QUIC is very similar to TCP+TLS+HTTP2, but implemented on top of UDP. Having QUIC as a self-contained protocol allows innovations which aren’t possible with existing protocols as they are hampered by legacy clients and middleboxes.

Key advantages of QUIC over TCP+TLS+HTTP2 include:

  • Connection establishment latency
  • Improved congestion control
  • Multiplexing without head-of-line blocking
  • Forward error correction
  • Connection migration

IETF drafts

50-minute overview video

In the matrix client-server spec, it mentions this:

More efficient optional transports will in future be supported as optional extensions - e.g. a packed binary encoding over stream-cipher encrypted TCP socket for low-bandwidth/low-roundtrip mobile usage.

I propose QUIC be selected and implemented as such an extension. It seems to be perfectly suited for Matrix: interactive, low-latency, low-bandwidth, multiplexed, encrypted, with natural support for roaming connections (e.g. smartphones). It's a fairly straightforward protocol to implement (see an example Go implementation), and appears to support user-defined congestion control algorithms.

Further, there is a rather straightforward mapping of HTTP2 onto QUIC.

ara4n commented 7 years ago

yup, this'd be great. just need someone to do it! the best way to do it would be to write a golang impl that proxied through to normal matrix HTTP, similar to https://github.com/matrix-org/matrix-websockets-proxy. In future golang homeservers we could then merge the transport to speak directly too.

farribeiro commented 5 years ago

The QUIC protocol graduates to IETF http/3 draft ... Any work in that direction?

ara4n commented 5 years ago

yes ;)

ShadowJonathan commented 4 years ago

Shouldn't this issue be moved to the matrix-doc repository? This looks like a spec change/addition.

BNationsDEV commented 2 years ago

how about Matrix support for QUIC protocol & webtransport? When do you plan to adding QUIC related development tasks to Matrix's roadmap?

Element Call could support QUIC in WebRTC? https://element.io/blog/introducing-native-matrix-voip-with-element-call/

https://www.youtube.com/watch?v=C8ClVgqUKvk https://github.com/open-webrtc-toolkit/owt-sdk-quic

https://github.com/yomorun/presencejs

Thank you

LecrisUT commented 2 years ago

On the receiving end, the reverse proxy can do all the heavy lifting. Even caddy has an experimental http/3 implementation. I am not familiar enough on the native implementation of http/3 into python as a client, but maybe aioquic.

The thing is that lately I have noticed a considerable downgrade in performance when interacting with big servers like matrix.org via federation. I have noticed that there are many connections to various other federated servers. So I am wondering how much of the performance downgrade is due to unreliable connections dropping a whole package sequence (like in the gif in this guide), which http/3 is suppose to address. Can anyone suggest troubleshooting methods for that?

squahtx commented 2 years ago

how about Matrix support for QUIC protocol & webtransport? When do you plan to adding QUIC related development tasks to Matrix's roadmap?

It's going to be a long time before the Synapse team focuses its development efforts on QUIC, and it will require a spec proposal first.

The thing is that lately I have noticed a considerable downgrade in performance when interacting with big servers like matrix.org via federation. I have noticed that there are many connections to various other federated servers. So I am wondering how much of the performance downgrade is due to unreliable connections dropping a whole package sequence (like in the gif in this guide), which http/3 is suppose to address. Can anyone suggest troubleshooting methods for that?

It's very unlikely that packet loss is causing performance issues with federation. Synapse performance issues are usually due to CPU or database usage rather than extra request latency from packet loss.

LecrisUT commented 2 years ago

t's very unlikely that packet loss is causing performance issues with federation.

That's why a way to debug and rule out this issue would be appreciated. Others may have a similar issue to troubleshoot where checking this issue would be important.

Synapse performance issues are usually due to CPU or database usage

It was not cpu or memory usage, but didn't troubleshoot against database. But I don't think that should be the case because, I would not get flooded with messages or other such events when the performance came back to normal. These federation issues are quite a showstopper so it would be good to have guides on troubleshooting it, at the very least to narrow down a cause: resources, database transaction, missing media, reverse proxy, latency, etc.

farribeiro commented 2 years ago

Some service/webserver has fallback to http/2