Subject: [quicwg/base-drafts] endpoints don't know how many connection IDs the peer is willing to store (#1994)

From: Marten Seemann <[email-masked]>
Date: Mon, 12 Nov 2018 02:46:20 -0800

As discussed on the list and in #1992, the fact that endpoints don't know how many connection IDs the peer is willing to store, leads to some undesirable consequences, which I described in https://github.com/quicwg/base-drafts/pull/1992#pullrequestreview-173829561:

Issuing too many connection IDs doesn't hurt in the case where the server uses a deterministic routing scheme to associate connection IDs to connections (except for the obviously wasted bandwidth). However, there's a different approach (which I chose in my implementation). I'm keeping a mapping connection ID => connection around for every single connection ID I issue. This allows me to use very short (4 bytes) connection IDs. If an implementation like this issues too many connection IDs, and the peer starts dropping them, it will have to keep state for every dropped connection ID until the end of the connection.

I'm preparing a PR to introduce a transport parameter, which will allow an endpoint to declare how many connection IDs it is willing to receive. It's late in Thailand already, so please give me until tomorrow this time to finalize the text for that.

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

---

From: MikkelFJ <[email-masked]>
Date: Mon, 12 Nov 2018 02:58:37 -0800

Supporting this.

Please include text on how to handle too many CID's received (probably protocol violation).

I wonder if some kind of delay is meaningful e.g. waiting until 1/4 is retired before issuing new CID's rather than dripping. Or, retire could retire multiple in a batch to achieve the same effect. Or maybe that is altogether unimportant?

-- 
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/1994#issuecomment-437838871

---

From: Dmitri Tikhonov <[email-masked]>
Date: Mon, 12 Nov 2018 13:55:24 +0000 (UTC)

Once the issuer knows how many the other side stores, it can batch connection IDs as it will be able to assess whether the peer has available CIDs.

-- 
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/1994#issuecomment-437889186

---

From: Mike Bishop <[email-masked]>
Date: Tue, 13 Nov 2018 11:26:05 -0800

I'm not convinced this is dire, since you're only going to issue as many CIDs as you're comfortable maintaining.  However, it is a waste of bandwidth and mapping resources to send more than the peer wants to work with, so I suspect this is marginally better.

-- 
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/1994#issuecomment-438403608

---

From: janaiyengar <[email-masked]>
Date: Wed, 14 Nov 2018 03:40:05 -0800

What @MikeBishop said.

-- 
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/1994#issuecomment-438633538

---

From: ekr <[email-masked]>
Date: Fri, 23 Nov 2018 11:09:16 -0800

I'm not sure we need this, but if we are going to bother to have it, then it should be a target. I.e., the other side should be required to keep you full, not just not to send you any more than this.

I'm also concerned by the semantics of having exceeding the max be an error, because it introduces pressure to increase max. The issue is that what you want to have is spare CIDs, and right now the only real way to elicit new CIDs is to RETIRE, but while that's in flight, if the other side is at max it can't send more, so this makes things more brittle.

-- 
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/1994#issuecomment-441305154

---

From: ianswett <[email-masked]>
Date: Fri, 23 Nov 2018 17:43:25 -0800

One idea: In an effort to enforce the principles, but not be overly strict or complex, maybe allow the connection to be closed with an error if a NEW_CONNECTION_ID frame is received with an ID that's more than the max_connection_ids from the largest retired connection id(or 0 if no ids have been retired)?

-- 
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/1994#issuecomment-441336338

---

From: Martin Thomson <[email-masked]>
Date: Sun, 25 Nov 2018 19:41:07 -0800

As others have said, this makes things more deterministic, but more complex.  I'm going to suggest that this is fertile ground for extensions. We can't know what the right answer is today, and it's going to take some deployment experience to get it right.  More machinery will likely only interfere with our ability to deploy fixes if they are needed.  And if no fixes are needed...success.

-- 
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/1994#issuecomment-441510297

---

From: ianswett <[email-masked]>
Date: Thu, 29 Nov 2018 12:25:30 -0800

The current default number of ids is 8, which I think is wrong.  However, the design team thought it was reasonable.

I think the fact my preferences are so different is an indication one-size-fits-all is wrong, so I favor adding this transport param.

Re: closing the connection, I'm going to have to do something if I receive too many, and it's really easy to not send too many, and it's really obvious when the connection is closed, so I think it's the more straightforward way to implement this.

But ask @ekr said, if a peer indicates a value, it should be the target, unless you can't supply that many.

-- 
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/1994#issuecomment-442980727

---

From: Ryan Hamilton <[email-masked]>
Date: Fri, 30 Nov 2018 23:56:06 +0000 (UTC)

I agree with ianswett here. If there's a limit that an endpoint is allowed
to set on the number of connection IDs that it stores, it should
communicate that limit to the peer. Anything else seems like it sets us up
for subtle interop bugs down the road. (And if I have a limit which the
peer knows and exceeds, then closing the connection seems great.)

On Thu, Nov 29, 2018 at 12:25 PM ianswett <[email-masked]> wrote:

> The current default number of ids is 8, which I think is wrong. However,
> the design team thought it was reasonable.
>
> I think the fact my preferences are so different is an indication
> one-size-fits-all is wrong, so I favor adding this transport param.
>
> Re: closing the connection, I'm going to have to do something if I receive
> too many, and it's really easy to not send too many, and it's really
> obvious when the connection is closed, so I think it's the more
> straightforward way to implement this.
>
> But ask @ekr <https://github.com/ekr> said, if a peer indicates a value,
> it should be the target, unless you can't supply that many.
>
> —
> Reply to this email directly, view it on GitHub
> <https://github.com/quicwg/base-drafts/issues/1994#issuecomment-442980727>,
> or mute the thread
> <https://github.com/notifications/unsubscribe-auth/ASp6ynEd0zphwjL8mpy9OOZOr_zYCBymks5u0EK6gaJpZM4YZZG9>
> .
>

-- 
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/1994#issuecomment-443375260