Subject: Re: [quicwg/base-drafts] Stateless Reset from clients, bis (#1505)

From: Martin Thomson <[email-masked]>
Date: Sun, 01 Jul 2018 17:59:10 -0700

Isn't it easier to switch to a new connection ID?

-- 
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/1505#issuecomment-401646123

---

From: Igor Lubashev <[email-masked]>
Date: Mon, 02 Jul 2018 00:09:02 -0700

The client can only switch to a new connection id, if it was given one by the server. A server that does not want clients to stay connected after a network reconnection event will likely not supply additional connection ids.

-- 
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/1505#issuecomment-401692061

---

From: Martin Thomson <[email-masked]>
Date: Mon, 02 Jul 2018 00:41:14 -0700

We had that discussion when talking about migration.  I think that there is still value in having some new connection IDs available.  If a server doesn't want to support connection migration, there's a transport parameter for that now.

-- 
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/1505#issuecomment-401699057

---

From: Igor Lubashev <[email-masked]>
Date: Mon, 02 Jul 2018 08:39:11 -0700

Are you suggesting that a server that would like to learn a Stateless Reset Token (STR) needs to wait for a CONNECTION_ID frame with a new CID from the client and then start using that new CID?

Since servers would always prefer to know a SRT, and clients would know that and oblige by generating a new CONNECTION_ID frame.  The servers would also need to generate an extra CONNECTION_ID, since once the server switches to a new CID, the client will likely switch as well.

All this is basically creating a lot of extra messaging, logic, and busy work for the common case QUIC connection.  It seems easier for the client to send just one message supply a SRT for the current CID and be done with 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/1505#issuecomment-401846417

---

From: Martin Thomson <[email-masked]>
Date: Mon, 02 Jul 2018 16:22:39 -0700

I don't expect that a client sending a stateless reset will be common at all.

-- 
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/1505#issuecomment-401966505

---

From: Igor Lubashev <[email-masked]>
Date: Mon, 02 Jul 2018 20:35:15 -0700

@martinthomson This is very true!

I was thinking to TCP world, where clients sent RST all the time (when they crash or otherwise).  However, if a QUIC client crashes, it will very likely send ICMP Unreachable.

Your statement seems so true that I actually start to wonder if clients even need to send SRT with CONNECTION_ID...

-- 
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/1505#issuecomment-402003193

---

From: MikkelFJ <[email-masked]>
Date: Mon, 02 Jul 2018 20:54:28 -0700

Clientside stateless resets apply in P2P where the client is more like a server - especially when it is random which endpoint becomes a client. I’m not generally a fan of resets though.

-- 
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/1505#issuecomment-402005645

---

From: Igor Lubashev <[email-masked]>
Date: Mon, 02 Jul 2018 23:07:22 -0700

Even in P2P, would not you have the client pick an ephemeral port as a source port? If so, once the client restarts, there is nothing listening on that ephemeral port.

-- 
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/1505#issuecomment-402023536

---

From: MikkelFJ <[email-masked]>
Date: Mon, 02 Jul 2018 23:30:08 -0700

@igorlord : in P2P you could argue that ephemeral ports are not so easily exchausted when the client has long living connections to peers, as opposed to short lived loadbalancer forwards.

But in a mesh network it is much more convenient to just stick to a single port and avoid all problems with ports differing, especially when use interfaces like netmap where you have to manage to ephemeral port. It is vastly simpler to just reuse fixed port, also client side.

-- 
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/1505#issuecomment-402027524

---

From: MikkelFJ <[email-masked]>
Date: Mon, 02 Jul 2018 23:31:16 -0700

Essentially you avoid the problem of calling "connect" to the OS all the time and handling its lifetime.

-- 
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/1505#issuecomment-402027772

---

From: Igor Lubashev <[email-masked]>
Date: Sat, 07 Jul 2018 19:10:28 -0700

@mikkelfj , got it.  So SRT may indeed be useful for clients in such applications.

-- 
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/1505#issuecomment-403256329

---

From: Martin Thomson <[email-masked]>
Date: Tue, 10 Jul 2018 17:49:41 -0700

Have we reached a resolution here?

-- 
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/1505#issuecomment-404010114

---

From: Mike Bishop <[email-masked]>
Date: Tue, 10 Jul 2018 22:48:15 -0700

I don't think a clear one, no.  It's in my CID deck for next week; I'm inclined to just leave it until then.

-- 
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/1505#issuecomment-404052381