4 ms·

Summary: Nairobi needs a datacenter, with Akamai and Cloudflare.

by discardorama 11y ago

dweekly 11y ago
Also, QUIC helps a lot.
- aaggarwal 11y ago
  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.
- scurvy 11y ago
  QUIC is OK, but I'm much more interested in 0-RTT TLS 1.3
scurvy 11y ago
A local Cloudflare would definitely help with the TLS setup since that's their magic (fast SSL setup without requiring your private key). Akamai could help, depending on the use case. If the content isn't cacheable, there's not much you can do. They do have a service that keeps open TCP sessions from certain POPs back to your origin, thus cutting down on TCP 3-way handshake time. Clients connect quickly, locally and then send the request because the origin connection is already established. That service is pretty expensive compared to CDN and they don't push it very hard. I used it when I ran an ad network where latency mattered (and could pay for this feature in an explicit increase in conversions and impressions).
- bjt 11y ago
  Both Cloudflare and Cloudfront (when used as a dynamic content CDN) offer persistent open connections to your origin, as a standard feature of their offering. https://blog.cloudflare.com/keep-alive/ https://blog.cloudflare.com/keep-alive/ https://support.cloudflare.com/hc/en-us/articles/200168346-Best-practices-for-Railgun-and-a-Load-Balancer https://support.cloudflare.com/hc/en-us/articles/200168346-B... https://aws.amazon.com/blogs/aws/amazon-cloudfront-support-for-dynamic-content/ https://aws.amazon.com/blogs/aws/amazon-cloudfront-support-f...

Summary: Nairobi needs a datacenter, with Akamai and Cloudflare.

dweekly 11y ago

Also, QUIC helps a lot.

aaggarwal 11y ago
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.
scurvy 11y ago
QUIC is OK, but I'm much more interested in 0-RTT TLS 1.3

scurvy 11y ago

A local Cloudflare would definitely help with the TLS setup since that's their magic (fast SSL setup without requiring your private key). Akamai could help, depending on the use case. If the content isn't cacheable, there's not much you can do. They do have a service that keeps open TCP sessions from certain POPs back to your origin, thus cutting down on TCP 3-way handshake time. Clients connect quickly, locally and then send the request because the origin connection is already established. That service is pretty expensive compared to CDN and they don't push it very hard. I used it when I ran an ad network where latency mattered (and could pay for this feature in an explicit increase in conversions and impressions).

bjt 11y ago
Both Cloudflare and Cloudfront (when used as a dynamic content CDN) offer persistent open connections to your origin, as a standard feature of their offering. https://blog.cloudflare.com/keep-alive/ https://blog.cloudflare.com/keep-alive/ https://support.cloudflare.com/hc/en-us/articles/200168346-Best-practices-for-Railgun-and-a-Load-Balancer https://support.cloudflare.com/hc/en-us/articles/200168346-B... https://aws.amazon.com/blogs/aws/amazon-cloudfront-support-for-dynamic-content/ https://aws.amazon.com/blogs/aws/amazon-cloudfront-support-f...