[quicwg/base-drafts] Dual-NAT / Dual-load-balancer scenarios (#745)

[Mike Bishop <[e-mail]>]

When thinking about peer-to-peer use-cases, it will obviously be common for both ends to be behind a NAT or (in a datacenter) behind a load balancer.  If we're talking about having load-balancer routing information baked into the Connection ID, we might need different connection IDs in each direction.

This would be relatively easy, since we're already talking about putting the Connection ID into the transport parameters -- each party just declares what Connection ID it wants the other party to use when sending packets to it, and the client's initial Connection ID is just a throw-away.  (Which might coincidentally be the same as one or both of the Connection IDs they agree to use.)  If you don't want/need a Connection ID included in your direction, simply don't provide a value for this setting.  At the same time, you'd want to make the NEW_CONNECTION_ID frame symmetric rather than server-only.

Dual NATs would also imply that PING frames need to be sent in both directions for keep-alive purposes, which affects the guidance being added to HTTP in #744.

-- 
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/745