← Back to context

Comment by thickice

3 days ago

Why doesn't QUIC work well for machine-to-machine traffic ? Is it due to the lack of offloads/optimizations for TCP and machine-to-machine traffic tend to me high volume/high rate ?

50 comments

thickice

Reply
yello_downunder  3 days ago

QUIC would work okay, but not really have many advantages for machine-to-machine traffic. Machine-to-machine you tend to have long-lived connections over a pretty good network. In this situation TCP already works well and is currently handled better in the kernel. Eventually QUIC will probably be just as good for TCP in this use case, but we're not there yet.

  • jabart  3 days ago

    You still have latency, legacy window sizes, and packet schedulers to deal with.

    • spwa4  3 days ago

      But that is the huge advantage of QUIC. It does NOT totally outcompete TCP traffic on links (we already have bittorrent over udp for that purpose). They redesigned the protocol 5 times or so to achieve that.

extropy  3 days ago

The NAT firewalls do not like P2P UDP traffic. Majoritoy of the routers lack the smarts to passtrough QUIC correctly, they need to treat it the same as TCP essentially.

dan-robertson  3 days ago

I think basically there is currently a lot of overhead and, when you control the network more and everything is more reliable, you can make tcp work better.

m00x  3 days ago

It's explained in the reddit thread. Most of it is because you have to handle a ton of what TCP does in userland.

exabrial  3 days ago

For starters, why encrypt something literally in the same datacenter 6 feet away? Add significant latency and processing overhead.

  • sleepydog  3 days ago

    Encryption gets you data integrity "for free". If a bit is flipped by faulty hardware, the packet won't decrypt. TCP checksums are not good enough for catching corruption in many cases.

    • lll-o-lll  2 days ago

      Interesting. When I read this I was thinking “that can’t be right, the whole internet relies on tcp being “reliable”. But it is right; https://dl.acm.org/doi/10.1145/347059.347561. It might be rare, but an unencrypted RPC packet might accidentally set that “go nuclear” bit. ECC memory is not enough people! Encrypt your traffic for data integrity!

  • lll-o-lll  3 days ago

    To stop or slow down the attacker who is inside your network and trying to move horizontally? Isn’t this the principle of defense in depth?

  • mschuster91  3 days ago

    Because any random machine in the same datacenter and network segment might be compromised and do stuff like running ARP spoofing attacks. Cisco alone has had so many vendor-provided backdoors cropping up that I wouldn't trust anything in a data center with Cisco gear.

    • subscribed  2 days ago

      Ummm, no, The network is completely isolated. No one enters the cage and just plugs something into my switches/routers.

      Any communication between the cage and the outside world is through the cross-connects.

      Unless it's some state-adversary, no one taps us like this. This is not a shared hosting. No one runs serious workloads like this.

      "Unserious"? Sure, everything is encrypted p2p.

      1 reply →

  • 20k  3 days ago

    Because the NSA actively intercepts that traffic. There's a reason why encryption is non optional

    • Karrot_Kream  3 days ago

      To me this seems outlandish (e.g. if you're part of PRISM you know what's happening and you're forced to comply.) But to think through this threat model, you're worried that the NSA will tap intra-DC traffic but not that it will try to install software or hardware on your hosts to spy traffic at the NIC level? I guess it would be harder to intercept and untangle traffic at the NIC level than intra-DC, but I'm not sure?

      4 replies →

  • switchbak  3 days ago

    Service meshes often encrypt traffic that may be running on the same physical host. Your security policy may simply require this.