Subject: [quicwg/base-drafts] active_connection_id_limit defaults to 0 (#3197)

From: Mike Bishop <[email-masked]>
Date: Wed, 06 Nov 2019 11:41:09 -0800

The implication, of course, is that 0 => infinite, but we don't actually say that anywhere.  (This part might be editorial; it omits to say what we all know it means.)

1 is also a mostly-invalid value, since you can't avoid exceeding that limit without the peer dropping to zero CIDs in the interim and therefore stalling the connection for an RTT + any recovery time needed.

This is fine, really, so long as the peer SHOULD NOT exceed the limit; if you send (or default to) a stupid value, the peer will ignore you and all is well.  But if we take #3193's suggestion that exceeding the limit be a MUST NOT, the default needs to be infinite and values less than 2 need to be prohibited.

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

---

From: Martin Thomson <[email-masked]>
Date: Wed, 06 Nov 2019 15:10:28 -0800

(Design issue please.)

There is a lower point on the idle_timeout, which is [3 PTO](https://quicwg.org/base-drafts/draft-ietf-quic-transport.html#idle-timeout).  Having 0 imply ♾ is awkward, so I think that Mike's suggestion is the best outcome.

-- 
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/3197#issuecomment-550543177

---

From: Kazuho Oku <[email-masked]>
Date: Wed, 06 Nov 2019 18:29:00 -0800

@MikeBishop 
> 1 is also a mostly-invalid value, since you can't avoid exceeding that limit without the peer dropping to zero CIDs in the interim and therefore stalling the connection for an RTT + any recovery ti…

I am literally not sure if this is the case.

As I've pointed out in https://github.com/quicwg/base-drafts/issues/3200, the normative language suggests that active_connection_id_limit actually means the number of "spare" CIDs that should be available, though the definition of "active connection ID" is defined differently.

_If_ we are to consider the normative language as being correct, it would be totally valid to set active_connection_id_limit to 1 (i.e. I want one spare CID!), or 0 (i.e. I do not want any).

-- 
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/3197#issuecomment-550591900

---

From: Marten Seemann <[email-masked]>
Date: Wed, 06 Nov 2019 18:40:41 -0800

The definition of the transport parameter says:
> The maximum number of connection IDs from the peer that an endpoint is willing to store. This value includes only connection IDs sent in NEW_CONNECTION_ID frames.

So sending a value of 0 (or, as it currently stands, omitting the TP), is a valid thing to do. It's an endpoint declaring that it will never, under no circumstances, change the connection ID, but to keep on using the connection ID provided during the handshake. Of course this also implies that connection migration is effectively disabled.
We might want to decide to make this illegal though. Since the introduction of the Retire Prior To field on the NEW_CONNECTION_ID frame, implementations have the option to retire connection IDs in case their infrastructure requires that. A peer sending a value of 0 would prevent those implementations from rotating their connection ID mapping, which seems like an awkward special case.

As @MikeBishop points out, sending a value of 1 doesn't make any sense, since you can't switch to a new CID without stalling the connection first.

Therefore, I agree with @MikeBishop's suggestion to forbid values below 2. I'm undecided if we should define a default value, and if so, what that value should be.

-- 
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/3197#issuecomment-550594525

---

From: Mark Nottingham <[email-masked]>
Date: Mon, 18 Nov 2019 18:53:27 -0800

Discussed in Singapore; a bit more discussion and then CfC.

-- 
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/3197#issuecomment-555308802