8 ms·

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 hi

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 ?

yello_downunder 1y 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 1y ago
  You still have latency, legacy window sizes, and packet schedulers to deal with.
  - spwa4 1y 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.
m00x 1y 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.
extropy 1y 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.
- beeflet 1y ago
  NAT is the devil. bring on the IPoc4lypse
  - hdgvhicv 1y ago
    Nat is massively useful for all sorts of reasons which has nothing to do with ip limitations.
    - unethical_ban 1y ago
      Rather, NAT is a bandage for all sorts of reasons besides IP exhaustion. Example: Janky way to get return routing for traffic when you don't control enterprise routes. Source: FW engineer
      - hdgvhicv 1y ago
        Sure. When I can bgp advertise my laptop with my phone provider and have it update is a second or so globally when I move from tethering to wifi, or one network to another. No doubt you think I should simply renumber all my VMs every time that happens, breaking internal connections. Or perhaps run a completely separate addrsssing in each vm in parallel and make sure each vm knows which connection to use. Perhaps the vms peer with my laptop and then the laptop decides what to push out which way via localprefs, as paths etc. that sounds so much simpler than a simple masquerade. What happens when I want vm1 out of connection A, vm 3 out of connection B, vm 4-7 out of connection C. Then I want to change them quickly and easily. I’m balancing outbound and inbound rules, reaching for communities, and causing bgp dampening all over the place. What when they aren’t VMs but instead physical devices. My $40 mifi is now processing the entire DFZ routing table? What happens when I want a single physical device like a tv to contact one service via connection 1 and another via connection 2 but the device doesn’t support multiple routing tables or selection of that. What if it does support it but I just want to be able to shift my ssh sessions to a low latency higher loss link but keep my streaming ups on the high latency no loss link. All this is trivial with nat. Now sure I can use NAT66, and do a 1:1 natting (no PAT here), but then I’m using nat and that breaks the ipv6 cult that believes translating network addresses is useless.
dan-robertson 1y 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.
exabrial 1y ago
For starters, why encrypt something literally in the same datacenter 6 feet away? Add significant latency and processing overhead.
- 20k 1y ago
  Because the NSA actively intercepts that traffic. There's a reason why encryption is non optional
  - Karrot_Kream 1y 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?
    - viraptor 1y ago
      > 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 It doesn't have to be one or the other. We've known for over a decade that the traffic between DCs was tapped https://www.theguardian.com/technology/2013/oct/30/google-reports-nsa-secretly-intercepts-data-links https://www.theguardian.com/technology/2013/oct/30/google-re... Extending that to intra-DC wouldn't be surprising at all. Meanwhile backdoored chips and firmware attacks are a constant worry and shouldn't be discounted regardless of the first point.
    - adgjlsfhk1 1y ago
      The difference between tapping intra-DC and in computer spying is that in computer spying is much more likely to get caught and much less easily able to get data out. There's a pretty big difference between software/hardware weaknesses that require specific targeting to exploit and passive scooping everything up and scanning
    - 1y 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 ?

yello_downunder 1y 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 1y ago
You still have latency, legacy window sizes, and packet schedulers to deal with.
- spwa4 1y 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.

m00x 1y 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.

extropy 1y 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.

beeflet 1y ago
NAT is the devil. bring on the IPoc4lypse
- hdgvhicv 1y ago
  Nat is massively useful for all sorts of reasons which has nothing to do with ip limitations.
  - unethical_ban 1y ago
    Rather, NAT is a bandage for all sorts of reasons besides IP exhaustion. Example: Janky way to get return routing for traffic when you don't control enterprise routes. Source: FW engineer
    - hdgvhicv 1y ago
      Sure. When I can bgp advertise my laptop with my phone provider and have it update is a second or so globally when I move from tethering to wifi, or one network to another. No doubt you think I should simply renumber all my VMs every time that happens, breaking internal connections. Or perhaps run a completely separate addrsssing in each vm in parallel and make sure each vm knows which connection to use. Perhaps the vms peer with my laptop and then the laptop decides what to push out which way via localprefs, as paths etc. that sounds so much simpler than a simple masquerade. What happens when I want vm1 out of connection A, vm 3 out of connection B, vm 4-7 out of connection C. Then I want to change them quickly and easily. I’m balancing outbound and inbound rules, reaching for communities, and causing bgp dampening all over the place. What when they aren’t VMs but instead physical devices. My $40 mifi is now processing the entire DFZ routing table? What happens when I want a single physical device like a tv to contact one service via connection 1 and another via connection 2 but the device doesn’t support multiple routing tables or selection of that. What if it does support it but I just want to be able to shift my ssh sessions to a low latency higher loss link but keep my streaming ups on the high latency no loss link. All this is trivial with nat. Now sure I can use NAT66, and do a 1:1 natting (no PAT here), but then I’m using nat and that breaks the ipv6 cult that believes translating network addresses is useless.

dan-robertson 1y 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.

exabrial 1y ago

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

20k 1y ago
Because the NSA actively intercepts that traffic. There's a reason why encryption is non optional
- Karrot_Kream 1y 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?
  - viraptor 1y ago
    > 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 It doesn't have to be one or the other. We've known for over a decade that the traffic between DCs was tapped https://www.theguardian.com/technology/2013/oct/30/google-reports-nsa-secretly-intercepts-data-links https://www.theguardian.com/technology/2013/oct/30/google-re... Extending that to intra-DC wouldn't be surprising at all. Meanwhile backdoored chips and firmware attacks are a constant worry and shouldn't be discounted regardless of the first point.
  - adgjlsfhk1 1y ago
    The difference between tapping intra-DC and in computer spying is that in computer spying is much more likely to get caught and much less easily able to get data out. There's a pretty big difference between software/hardware weaknesses that require specific targeting to exploit and passive scooping everything up and scanning
  - 1y ago