Subject: [quicwg/base-drafts] Ben Kaduk's Transport Comment 7 (#4614)

From: Lucas Pardue <[email-masked]>
Date: Wed, 06 Jan 2021 17:03:49 -0800

@kaduk said

> Section 5.1.1
>
> > An endpoint SHOULD ensure that its peer has a sufficient number of
> > available and unused connection IDs.  Endpoints advertise the number
> > of active connection IDs they are willing to maintain using the
> > active_connection_id_limit transport parameter.  An endpoint MUST NOT
> > provide more connection IDs than the peer's limit.  [...]
>
> IIUC, the reason that a negotiated limit is needed here is not exactly
> for the storage of the connection ID values themselves (though the
> requirement to explicitly use RETIRE_CONNECTION_ID makes it not as
> simple as it might be), but rather due to the requirement to recognize
> the associated stateless reset tokens.  Is that correct?  If so, perhaps
> it could be mentioned as a factor, 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/4614

---

From: Martin Thomson <[email-masked]>
Date: Wed, 06 Jan 2021 17:28:24 -0800

As the recipient of a connection ID, you need to store both.  The concern was that tracking these could be onerous.  That's all.  No need to mention the tokens specially here in my view.

(The original method devised for handling this, which was to throw out any excess without any signaling, could result in starvation.)

Propose no action for this one.

-- 
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/4614#issuecomment-755824726

---

From: kaduk <[email-masked]>
Date: Sat, 09 Jan 2021 20:45:18 -0800

I don't understand why I, as a recipient of NEW_CONNECTION_ID, need to actually remember the connection ID itself.  I am not obligated to ever send packets using that value as a destination connection ID, so what harm comes if I forget 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/4614#issuecomment-757414903

---

From: Martin Thomson <[email-masked]>
Date: Sun, 10 Jan 2021 18:01:25 -0800

If you never intend to use another NEW_CONNECTION_ID ever, then sure.  But we assume that you might.

-- 
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/4614#issuecomment-757588301

---

From: Lars Eggert <[email-masked]>
Date: Tue, 12 Jan 2021 00:05:26 -0800

@kaduk is there any further need for clarification?

-- 
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/4614#issuecomment-758481613

---

From: Mike Bishop <[email-masked]>
Date: Tue, 12 Jan 2021 16:53:29 -0800

Remembering is necessary because the peer isn't required to replenish your supply of CIDs.  If you forget one without retiring it, the peer might conclude you still have one you could use, you aren't, so clearly you're comfortable continuing to use the CID you've currently got.

It is perfectly legitimate to forget the CID and delay retiring it until you want it replaced, however.  That seems like a messy implementation design, however.

-- 
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/4614#issuecomment-759131273

---

From: Martin Thomson <[email-masked]>
Date: Tue, 12 Jan 2021 16:53:45 -0800

Another piece that might be missing here is that stateless reset tokens only apply if you use the associated connection ID.  Not sure if that helps at all.

Either way, this issue is phrased as a challenge to the design, but I believe the design is OK and this issue does not justify any changes.

-- 
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/4614#issuecomment-759131360

---

From: Jana Iyengar <[email-masked]>
Date: Tue, 12 Jan 2021 16:54:13 -0800

I'm not sure how to read this issue. If this is a clarification question, I might be missing it. Either way, I'm not sure there's any action here besides further explanation 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/4614#issuecomment-759131494

---

From: kaduk <[email-masked]>
Date: Tue, 12 Jan 2021 17:06:12 -0800

> Another piece that might be missing here is that stateless reset tokens only apply if you use the associated connection ID. Not sure if that helps at all.

Thanks, that does help me reset my internal model to match reality.  I had erroneously expected the reset tokens to be associated with the broader connection and not the specific connection ID (the only thing I can find now to remotely support that misunderstanding is the bit about "associated with the remote address on which the datagram was received", but even that has a matching "datagrams it has recently sent" just a few sentences prior.
I'm sorry that my misunderstanding caused so much effort to be spent, and thanks to everyone for helping me understand.

-- 
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/4614#issuecomment-759135580

---

From: Jana Iyengar <[email-masked]>
Date: Tue, 12 Jan 2021 17:35:24 -0800

This can be closed 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/4614#issuecomment-759145127

---

From: Lucas Pardue <[email-masked]>
Date: Tue, 12 Jan 2021 17:38:33 -0800

Closing, thanks 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/4614#issuecomment-759146487

---

From: Lucas Pardue <[email-masked]>
Date: Tue, 12 Jan 2021 17:38:33 -0800

Closed #4614.

-- 
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/4614#event-4198990240