Subject: [quicwg/base-drafts] What to do if address of client changes while in draining state (#946)

From: Subodh Iyengar <[email-masked]>
Date: Sun, 19 Nov 2017 04:23:45 +0000 (UTC)

I think we have 3 potential options:

1. We could send the connection close to the new address 
2. We could just exit draining
3. We could ignore it completely.

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

---

From: ianswett <[email-masked]>
Date: Sun, 19 Nov 2017 17:08:54 +0000 (UTC)

Two options seem equally reasonable to me:
 1) Send the connection close to the new address
 2) Send a public reset and change nothing about the draining state

Ignoring it completely seems bad, and I'm not sure why we'd exit draining due to an address change?

-- 
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/946#issuecomment-345532622

---

From: Subodh Iyengar <[email-masked]>
Date: Sun, 19 Nov 2017 22:33:38 +0000 (UTC)

the connection close could be 1MSS big because of the close reason, and it seemed kind of icky to send a connection close to a random unauthenticated source address someone could send us a small packet and we would send them a larger connection close while the connection is draining. The client may have legitimately transition to a new address due to nat rebinding, however there would be no way to tell. That's the reason just exiting draining might be 1 legitimate option.

-- 
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/946#issuecomment-345555762

---

From: Subodh Iyengar <[email-masked]>
Date: Sun, 19 Nov 2017 22:35:10 +0000 (UTC)

Similarly we recommend in the doc that you can get rid of all state except just the close packet while in draining. So if you can't verify the packet correctly, then it would make sense to ignore it.

-- 
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/946#issuecomment-345555860

---

From: ianswett <[email-masked]>
Date: Mon, 20 Nov 2017 13:27:37 +0000 (UTC)

If you send a connection close, I believe there's a recommendation to use exponential backoff, and the sender decides how large the packet is, so amplification factor shouldn't be a concern.

I'm confused by "if you can't verify the packet correctly, then it would make sense to ignore it because we don't want to verify and let the peer go into idle_timeout".  Avoiding idle timeout involves sending something, either a connection close or public reset.

Honestly, I think the best approach is to do what implementations will likely do by default, which is to send a connection close if you're still storing it and then transition to sending public reset when you've decided to discard the old connection close.

-- 
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/946#issuecomment-345694976

---

From: Subodh Iyengar <[email-masked]>
Date: Mon, 20 Nov 2017 17:47:55 +0000 (UTC)

i don't think implementations will send the packets to the new address by default. In connection close state we have the choice of whether or not to bind to the new client address or not, or keep the old address. Implementations will probably bind to the old address by default, at least that's what I do by default, and while implementing close, this question came to me.

-- 
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/946#issuecomment-345773463

---

From: ianswett <[email-masked]>
Date: Mon, 20 Nov 2017 22:23:03 +0000 (UTC)

The stateless reset text says:
"A stateless reset is provided as an option of last resort for a server that does not have access to the state of a connection. A server crash or outage might result in clients continuing to send data to a server that is unable to properly continue the connection. A server that wishes to communicate a fatal connection error MUST use a CONNECTION_CLOSE or APPLICATION_CLOSE frame if it has sufficient state to do so."

To me, that indicates a server should send a connection close if it's possible/straightforward to look that up.  If not, send a stateless reset.  If you have editorial suggestions for this text, feel free to send out a PR.

-- 
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/946#issuecomment-345851495