Subject: Re: [quicwg/base-drafts] CID Lifetime Management (#1496)

From: ianswett <[email-masked]>
Date: Thu, 19 Jul 2018 06:11:13 -0700

One detailed point is that it seems best to me to combine these two frames into one.  If you're asking for new CIDs, you're probably retiring some anyway.

Popping up the stack a level, I would like to make both of these issues v2.  We have no experience with changing connection IDs, and given the client can just 0RTT a new connection, if it runs out of connection IDs, it seems there's a simple fix.

-- 
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/pull/1496#issuecomment-406270828

---

From: Kazuho Oku <[email-masked]>
Date: Thu, 19 Jul 2018 09:16:52 -0700

> One detailed point is that it seems best to me to combine these two frames into one. If you're asking for new CIDs, you're probably retiring some anyway.

I agree. In my view, the logic could be as simple as follows:
* during the handshake, the endpoints negotiate the maximum number spare CIDs to be used for the given connection
* the endpoints will try to provide the negotiated amount of spare CIDs to the peers (i.e., after handshake an endpoint sends `max_spare-1` CIDs to peers, then send additional ones as it notices a CID getting retired)
* a CID that both peers know that it is has been used will be retired by an expiration timer
* a CID that an endpoint has used but that peer might not have seen will be explicitly retired by a RETIRE_CONNECTION_ID
* we could have CONNECTION_ID_BLOCKED frame

Instead of using a timer, we could always explicitly signal the retirement using the RETIRE_CONNECTION_ID frame.

As you can see, the design is analogous to how we handle streams. It caps the maximum amount of CIDs that the endpoints need to remember.

-- 
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/pull/1496#issuecomment-406333457

---

From: Martin Thomson <[email-masked]>
Date: Sun, 29 Jul 2018 21:50:46 -0700

martinthomson commented on this pull request.

> +|                         Received (i)                        ...
++-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+| Requested (8) |
++-+-+-+-+-+-+-+-+
+~~~
+
+The fields in the REQUEST_CONNECTION_ID frame are as follows:
+
+Received:
+: The greatest connection ID sequence number received by the sender
+  from the receiver in a NEW_CONNECTION_ID frame, formatted as a
+  variable-length integer.
+
+Requested:
+: A one-byte integer specifying the number of additional connection
+  IDs the sender would like to be issued.

Why not a single integer that says "fill to 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/pull/1496#pullrequestreview-141391583