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

From: janaiyengar <[email-masked]>
Date: Fri, 08 Sep 2017 14:49:57 -0700

I like this idea of having different connection IDs in the two directions, and I think it's useful. Why does it mess with the design of Stateless Reset?

-- 
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-328222136

---

From: Mike Bishop <[email-masked]>
Date: Fri, 08 Sep 2017 15:14:27 -0700

Let's say we configure a connection to use ID A when sending from client-to-server, but ID B when sending from server-to-client.  Now the server receives a packet with connection ID A, but has lost all its state.

In the current model, the server generates a Stateless Reset packet that looks like any other packet it would send to the client, re-creates the token by deriving it from A, and pads out the packet with random nonsense.

With dual connection IDs, the server has no idea what connection ID it's supposed to use in reply packets, so it necessarily looks different from a "real" response packet.  It could reuse 'A' in the wrong direction, or could omit the Connection ID entirely, but both of those will be different from "real" responses.  (And if the Connection ID is actually needed to route back to the client, then neither of those will actually reach the other end anyway.)

-- 
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-328226218

---

From: janaiyengar <[email-masked]>
Date: Fri, 08 Sep 2017 15:42:25 -0700

Hm, ok, I'm not so worried about the looking different part, but there's the addition issue of the load balancer not routing the stateless reset back to the right receiver.

-- 
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-328230507

---

From: Igor Lubashev <[email-masked]>
Date: Mon, 11 Sep 2017 12:07:06 -0700

I wonder how realistic the need for double load balancing would be.

In a datacenter, all machines will typically have unique globally routable IPs (maybe IPv6-only).  You'd want to initiate connections from your unique IP.  I would be puzzled to see a design that requires initiating connections sourced from a load balanced IP, since the load balancer would just be in the way on the return path.

For peer-to-peer users, the NAT on the client's side is not likely to be a problem, since it is not a "load balancer".  Even if a NAT could also do load balancing and had to use a single IP (why? RFC 6177 suggests for end site to be allocated at least /64), that NAT would "load balance" only some UDP ports (the ports used by known apps) and do ordinary NAT port mapping for other ports.

-- 
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-328628226

---

From: mirjak <[email-masked]>
Date: Wed, 13 Sep 2017 06:24:13 -0700

We could put two congestion IDs in all packets, or use half the connection ID for each direction... 

However, I guess if the stateless reset gets lost/mis-routed somehow, the client might keep sending data but will never get a response and might therefore stop at some point.... a load balancer could even learn to understand a stateless reset and block an additional packets from the client on that connection. Not sure if that is a great idea...

-- 
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-329166527