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

From: Mike Bishop <[email-masked]>
Date: Tue, 22 Aug 2017 22:18:41 +0000 (UTC)

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

---

From: Martin Thomson <[email-masked]>
Date: Wed, 23 Aug 2017 00:34:52 +0000 (UTC)

I don't think that you need to worry about PINGs in both directions.  A PING-ACK exchange initiated by a client is enough for the client NAT, then it should keep the server NAT open.  The only trick being that the keep-alive interval needs to be the lower of the timeouts at the two NATs.

The problem with a connection ID in both directions is that it screws badly with the design of the stateless reset.  We'd probably want to make it appear to be a connection migration, which sticks out a little more than before.

-- 
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#issuecomment-324188324