3 ms·

The protocol has been designed so that both the endpoints of a stream can seamlessly change IP addresses. This ought to make load balancing easier?

X-Istence 8y ago
Not unless you want to get through firewalls seamlessly. UDP "state" tracking is a thing, and if my firewall sees a UDP packet destined for it without knowing the remote IP address it's going to drop it.
- vertex-four 8y ago
  Which is yet another reason to migrate to IPv6, which doesn’t require stateful NAT.
  - wmf 8y ago
    Although stateful connection tracking is still a best practice for IPv6 firewalls and home routers.
  - greglindahl 8y ago
    There are a ton of IPv4 firewalls and middleboxes that have stateful tracking even when NAT is not in use.
  - X-Istence 8y ago
    My firewall doesn't do NAT yet is still stateful for IPv6. Also, most firewalls on end-point devices (think built-in to the OS) are stateful firewalls.
- bb88 8y ago
  If the client side changes it's IP address, it's a lot easier say than if the server side does. Typically because the server won't reject new UDP packets coming in from the internet. The load balancer will route any ongoing sessions with the session id, and not the ip address.
  - X-Istence 8y ago
    Absolutely, but the original commenter was stating that it would allow either endpoint to their their IP easily (and thus making load balancing easier). I was disputing that.
    - bb88 8y ago
      Ah... apologies for my confusion. Thanks for the clarification.
- amaccuish 8y ago
  I think it's more about the client changing their IP, i.e. moving wifi networks or from wifi to mobile. Not so much the server changing.
  - X-Istence 8y ago
    Client changing their IP address is fine, the comment I was replying to was stating that it would allow both sides to change their IP at will (and allow for better load balancing). I was disputing that.
- algesten 8y ago
  You can solve that with STUN which is how WebRTC does it. Each end sends a STUN packet to get the NAT statefullness going. Granted, it requires transferring of ICE connection candidates out of band (via the horrors of SDP)
denormalfloat 8y ago
While this is true, a lot of software is not prepared to have connections change IP address. Lot's of networking software works on the idea of a loop which assigns each connection (5-tuple) to a thread. If QUIC were to be more widely used, the association of the connection would have to be linked to the connection identifier in QUIC, which is different than the 5-tuple. Basically, any software that assumed 1 connection maps to 1 file descriptor, is going to have to be rewritten. This also means the kernel, which could previously steer traffic to a connection onto a single core. Realistically, QUIC will need a BPF filter to inspect the connection identifier and steer to the same core in the event of an IP address change. All this is to say: I don't think most software is ready for QUIC, even if the protocol allows for cool things.
- bb88 8y ago
  > Basically, any software that assumed 1 connection maps to 1 file descriptor, is going to have to be rewritten. Yeah, but I don't think that's a hard thing to do, realistically speaking. Instead of mapping a source ip/port to a destination in the LB it's mapping a QUIC session ID instead. > This also means the kernel, which could previously steer traffic to a connection onto a single core. Most likely the kernel will not be rewritten to support this, since QUIC is a user space protocol. Also, the LB might just be able to rewrite the packet so it looks like it came from the LB when it sends it on to the server. The end server would never see the ip address change.

X-Istence 8y ago

Not unless you want to get through firewalls seamlessly. UDP "state" tracking is a thing, and if my firewall sees a UDP packet destined for it without knowing the remote IP address it's going to drop it.

vertex-four 8y ago
Which is yet another reason to migrate to IPv6, which doesn’t require stateful NAT.
- wmf 8y ago
  Although stateful connection tracking is still a best practice for IPv6 firewalls and home routers.
- greglindahl 8y ago
  There are a ton of IPv4 firewalls and middleboxes that have stateful tracking even when NAT is not in use.
- X-Istence 8y ago
  My firewall doesn't do NAT yet is still stateful for IPv6. Also, most firewalls on end-point devices (think built-in to the OS) are stateful firewalls.
bb88 8y ago
If the client side changes it's IP address, it's a lot easier say than if the server side does. Typically because the server won't reject new UDP packets coming in from the internet. The load balancer will route any ongoing sessions with the session id, and not the ip address.
- X-Istence 8y ago
  Absolutely, but the original commenter was stating that it would allow either endpoint to their their IP easily (and thus making load balancing easier). I was disputing that.
  - bb88 8y ago
    Ah... apologies for my confusion. Thanks for the clarification.
amaccuish 8y ago
I think it's more about the client changing their IP, i.e. moving wifi networks or from wifi to mobile. Not so much the server changing.
- X-Istence 8y ago
  Client changing their IP address is fine, the comment I was replying to was stating that it would allow both sides to change their IP at will (and allow for better load balancing). I was disputing that.
algesten 8y ago
You can solve that with STUN which is how WebRTC does it. Each end sends a STUN packet to get the NAT statefullness going. Granted, it requires transferring of ICE connection candidates out of band (via the horrors of SDP)

denormalfloat 8y ago

While this is true, a lot of software is not prepared to have connections change IP address. Lot's of networking software works on the idea of a loop which assigns each connection (5-tuple) to a thread. If QUIC were to be more widely used, the association of the connection would have to be linked to the connection identifier in QUIC, which is different than the 5-tuple. Basically, any software that assumed 1 connection maps to 1 file descriptor, is going to have to be rewritten. This also means the kernel, which could previously steer traffic to a connection onto a single core. Realistically, QUIC will need a BPF filter to inspect the connection identifier and steer to the same core in the event of an IP address change. All this is to say: I don't think most software is ready for QUIC, even if the protocol allows for cool things.

bb88 8y ago
> Basically, any software that assumed 1 connection maps to 1 file descriptor, is going to have to be rewritten. Yeah, but I don't think that's a hard thing to do, realistically speaking. Instead of mapping a source ip/port to a destination in the LB it's mapping a QUIC session ID instead. > This also means the kernel, which could previously steer traffic to a connection onto a single core. Most likely the kernel will not be rewritten to support this, since QUIC is a user space protocol. Also, the LB might just be able to rewrite the packet so it looks like it came from the LB when it sends it on to the server. The end server would never see the ip address change.