Re: [quicwg/base-drafts] Connection migration must be negotiated (#1271)

[Praveen Balasubramanian <[e-mail]>]

Yes, incremental deployment is important. Until load balancers add QUIC support, you have two options for deployment:
1. Use two-tuple (src IP, dst IP) load balancing to continue working when NAT rebinding happens (port number change).
2. Or client can do keep-alives to keep the NAT mapping open for long running persistent connections. We already have precedence for this with long poll TCP "push notification" connections. 

Connection migration != NAT rebinding. Connection migration is a new scenario that needs opt-in and is driven by app and OS policy. For connection migration the only option for deployment is to upgrade the load balancers. Hence servers must be able to veto it to minimize traffic that looks like DoS attack and also prevent client from falling back to TCP unnecessarily when it could have simply opened a new QUIC connection and carried on. 

@nibanks good point about p2p where the negotiation must be vetoable by both sides. Let's also not discount scenarios like anycast and DoS prevention where knowing that the connection can migrate can help the server side. The traditional negotiation mechanism where initiator requests and acceptor agrees/vetoes is the most generic mechanism and will satisfy all requirements.



-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/issues/1271#issuecomment-379373542