5 ms·

Is QUIC protocol out of experimental phase?

scurvy 11y ago
It's only in Chrome and only supported by Google's web server. They are using it though. You can see the stats by going to chrome://net-internals/#quic They are "working" to get it into Apache Traffic Server.
- aaggarwal 11y ago
  Yeah, its communicating over port 443. Apache Traffic Server would sure be a big step forward, if and when that happens.
  - scurvy 11y ago
    Yeah all QUIC connections are on 443. Here's the most recent public talk from Google about QUIC, given at NANOG 64: https://www.youtube.com/watch?v=cSNT88_gedw https://www.youtube.com/watch?v=cSNT88_gedw
  - mkj 11y ago
    443 UDP though - different to anything else.
dweekly 11y ago
Yes and no. It is a ways off from being solidified as an RFC AFAIK, but it serves a healthy portion of Google's traffic. So, more than an experiment but less than a standard.
- aaggarwal 11y ago
  I was looking for a reliable audio streaming method for a project, I came across QUIC and was in process of studying it. Its definitely seems to be the future, but I am still unsure though about using it for the project.
  - TD-Linux 11y ago
    You should take a look at the WebRTC stack. Opus => RTP => DTLS => SCTP => UDP. For simpler applications you can drop parts of that, for example just RTP over UDP if you don't need retransmissions or encryption.
    - aaggarwal 11y ago
      Yes, WebRTC is also a contender, almost final before I came across QUIC. I was also studying it, the application has to be reliable, so except for the DTLS, I can't skip any other layer of stack. I just have to make a final test to compare the reliability and speed characteristics of TCP vs SCTP (and maybe QUIC) for the application. WebRTC also has excellent P2P features, that's again a big plus. Thanks for the help!
      - TD-Linux 11y ago
        If it has to be reliable as in no loss is allowed, you're going to need slightly higher latency. If TCP-level latencies are acceptable, maybe you should look at icecast. It's super simple to set up, and works in most browsers directly.
        aaggarwal 11y ago
        Thanks for sharing, icecast looks nice. However, it doesn't relate to the type of application I was trying to build. I was trying to improve over TCP latencies, that's why I was looking over reliable but faster protocols at transport level. I will probably benchmark everything later and share it with everyone.

It's only in Chrome and only supported by Google's web server. They are using it though. You can see the stats by going to chrome://net-internals/#quic They are "working" to get it into Apache Traffic Server.

aaggarwal 11y ago
Yeah, its communicating over port 443. Apache Traffic Server would sure be a big step forward, if and when that happens.
- scurvy 11y ago
  Yeah all QUIC connections are on 443. Here's the most recent public talk from Google about QUIC, given at NANOG 64: https://www.youtube.com/watch?v=cSNT88_gedw https://www.youtube.com/watch?v=cSNT88_gedw
- mkj 11y ago
  443 UDP though - different to anything else.

dweekly 11y ago

Yes and no. It is a ways off from being solidified as an RFC AFAIK, but it serves a healthy portion of Google's traffic. So, more than an experiment but less than a standard.

aaggarwal 11y ago
I was looking for a reliable audio streaming method for a project, I came across QUIC and was in process of studying it. Its definitely seems to be the future, but I am still unsure though about using it for the project.
- TD-Linux 11y ago
  You should take a look at the WebRTC stack. Opus => RTP => DTLS => SCTP => UDP. For simpler applications you can drop parts of that, for example just RTP over UDP if you don't need retransmissions or encryption.
  - aaggarwal 11y ago
    Yes, WebRTC is also a contender, almost final before I came across QUIC. I was also studying it, the application has to be reliable, so except for the DTLS, I can't skip any other layer of stack. I just have to make a final test to compare the reliability and speed characteristics of TCP vs SCTP (and maybe QUIC) for the application. WebRTC also has excellent P2P features, that's again a big plus. Thanks for the help!
    - TD-Linux 11y ago
      If it has to be reliable as in no loss is allowed, you're going to need slightly higher latency. If TCP-level latencies are acceptable, maybe you should look at icecast. It's super simple to set up, and works in most browsers directly.
      - aaggarwal 11y ago
        Thanks for sharing, icecast looks nice. However, it doesn't relate to the type of application I was trying to build. I was trying to improve over TCP latencies, that's why I was looking over reliable but faster protocols at transport level. I will probably benchmark everything later and share it with everyone.