Exhausting a supply of connection IDs

[martinthomson]

What - if anything - do we want to say about connection migration in the face of a server that provides too few (including 0) connection IDs? It's a fairly simple trade-off that we can explain. I suspect that different clients will adopt different policies though.

And, should we provide a means to request more?

[kazuho]

I do not have an opinion on if the client behavior needs to be documented.

OTOH, I would prefer having a way to request more, considering the fact that the client could run out of spare connection IDs without the server noticing it, when a path probe fails to reach the server.

[ianswett]

I'd prefer to stick to the "if you run out of connection IDs and you want to use a new one, 0RTT a new connection" answer unless we think there's a really compelling case for the extra complexity.

A server that cares about giving a client enough IDs should be able to do that without too much work, and it can see which ones have been used.

[MikeBishop]

I thought we'd discussed and resolved that in St. Pancras', but I don't see it in the spec. There are two versions of this:

• Client wants to migrate, but is out of CIDs: 0-RTT is probably the right answer here.
• Client has migrated, but server is out of CIDs: Clients should be allowed / encouraged to include NCID in probing frames to avoid this. Should servers be prohibited from sending until they get a new CID?

[janaiyengar]

Proposal from editors' meeting: Each endpoint ensures that it sends at least one additional CID if it has at least one spare CID from the peer. Additionally, if an endpoint that needs to migrate doesn't have any new CIDs from the peer, it closes the connection.