Subject: [quicwg/base-drafts] clarify what happens when consuming CIDs excessively (#2428)

From: Kazuho Oku <[email-masked]>
Date: Tue, 05 Feb 2019 19:38:46 -0800

While we allow the consumer to start using new CIDs anytime, there are consequences of consuming them excessively, as discussed in #2403 starting from [this comment]( 
https://github.com/quicwg/base-drafts/issues/2403#issuecomment-460255684).

The text clarifies that excessive consumption is not what the issuer needs to support.
You can view, comment on, or merge this pull request online at:

  https://github.com/quicwg/base-drafts/pull/2428

-- Commit Summary --

  * clarify what happens when consuming CIDs excessively

-- File Changes --

    M draft-ietf-quic-transport.md (7)

-- Patch Links --

https://github.com/quicwg/base-drafts/pull/2428.patch
https://github.com/quicwg/base-drafts/pull/2428.diff

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

---

From: Marten Seemann <[email-masked]>
Date: Tue, 05 Feb 2019 19:43:38 -0800

marten-seemann commented on this pull request.

While I can see why you'd limit the frequency of issuing new connection IDs, I don't think you should limit the number of total connection IDs per connection.

-- 
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/2428#pullrequestreview-200403801

---

From: Kazuho Oku <[email-masked]>
Date: Tue, 05 Feb 2019 20:10:44 -0800

@marten-seemann 
> I don't think you should limit the number of total connection IDs per connection.

For HTTP3, it is natural to assume that the connections would not survive for very long time. In such case, capping the number of total connection IDs is a practical countermeasure against excessive issuance of CIDs. Implementations need not to be as complicated as capping the frequency.

-- 
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/2428#issuecomment-460895194

---

From: Martin Thomson <[email-masked]>
Date: Wed, 06 Feb 2019 04:14:26 +0000 (UTC)

I don't want to put this in the draft.  It tells endpoints not to change connection IDs based on some unspecified (scary!) constraints that may or may not be present in a peer.

I realize that there might be a limited supply in some implementations, but artificial constraints on the rate of use is not the way I would address the problem.  Refusing or slowing issuance of new connection IDs if someone retires too many is a better approach.  In other words, implementations should deal with this on their own.

-- 
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/2428#issuecomment-460895656

---

From: Kazuho Oku <[email-masked]>
Date: Tue, 05 Feb 2019 20:20:26 -0800

@martinthomson If that's the concern, do you think clarifying that the issue can "refuse or slow issuance of new connection IDs" in section 5.1.1 would be fine?

The problem I have with current text is that section 5.1.1 only says that the issuer SHOULD issue new CIDs as the consumer retires them. I think we need to clarify that doing that without limitation could be dangerous.

-- 
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/2428#issuecomment-460896463

---

From: Kazuho Oku <[email-masked]>
Date: Tue, 05 Feb 2019 20:31:33 -0800

@kazuho pushed 2 commits.

88fac6e73653b10c6963af152ab93327c8102f80  Revert "clarify what happens when consuming CIDs excessively"
a0ae02995b37cd83d163f334c7b71e0b1ddb13f6  move the statement to the issuer side

-- 
You are receiving this because you are subscribed to this thread.
View it on GitHub:
https://github.com/quicwg/base-drafts/pull/2428/files/1bb6c3e804945f7adda97c2e7ec1785bda04a18d..a0ae02995b37cd83d163f334c7b71e0b1ddb13f6

---

From: Kazuho Oku <[email-masked]>
Date: Tue, 05 Feb 2019 20:32:47 -0800

@martinthomson Moved the clarification to the issuer side. PTAL.

-- 
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/2428#issuecomment-460898114

---

From: Martin Thomson <[email-masked]>
Date: Tue, 05 Feb 2019 20:46:41 -0800

martinthomson approved this pull request.

This is better, certainly.

-- 
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/2428#pullrequestreview-200411606

---

From: Martin Thomson <[email-masked]>
Date: Tue, 05 Feb 2019 20:47:17 -0800

martinthomson commented on this pull request.

> @@ -961,12 +961,15 @@ cannot expect its peer to store and use all issued connection IDs.
 An endpoint SHOULD ensure that its peer has a sufficient number of available and
 unused connection IDs.  While each endpoint independently chooses how many
 connection IDs to issue, endpoints SHOULD provide and maintain at least eight
-connection IDs.  The endpoint SHOULD do this by always supplying a new
-connection ID when a connection ID is retired by its peer or when the endpoint
-receives a packet with a previously unused connection ID.  Endpoints that
-initiate migration and require non-zero-length connection IDs SHOULD provide
-their peers with new connection IDs before migration, or risk the peer closing
-the connection.
+connection IDs.  The endpoint SHOULD do this by supplying a new connection ID
+when a connection ID is retired by its peer or when the endpoint receives a
+packet with a previously unused connection ID, though it MAY limit the frequency
+or the total number of connection IDs issued for each connection to avoid the
+risk of running out of connection IDs (see {{reset-token}}).
+
+Endpoints that initiate migration and require non-zero-length connection IDs
+SHOULD provide their peers with new connection IDs before migration, or risk the
+peer closing the connection.

Now that I read this paragraph again, I think that we need to rework it, but that's a separate problem.

-- 
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/2428#pullrequestreview-200411674

---

From: MikkelFJ <[email-masked]>
Date: Wed, 06 Feb 2019 01:16:11 -0800

One low-level observation:

CID's need to be looked up in a hash table or similar. For a busy server multiplexing many connections, it want this table in fast cache, also to reject invalid CID's fast. You may be able to handle 5000 connections efficiently, but if you are required to handle 8x5000 this can degrade performance, especially on rejection. You can counter this by cryptographically mapping multiple CID's a single internal CID but that is not the simplest approach.

Therefore, choosing a minimum number of CID's should be done with care. Would 2 or 3 not be sufficient for most use cases?

-- 
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/2428#issuecomment-460951783

---

From: ianswett <[email-masked]>
Date: Wed, 06 Feb 2019 02:04:24 -0800

ianswett approved this pull request.

-- 
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/2428#pullrequestreview-200493094

---

From: Martin Thomson <[email-masked]>
Date: Wed, 06 Feb 2019 18:15:55 -0800

Unfortunately, this is a design change, and a new one.

>From an abundance of caution, we'll need an issue for this, and chair assessment of consensus.

-- 
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/2428#pullrequestreview-200896573

---

From: MikkelFJ <[email-masked]>
Date: Wed, 06 Feb 2019 23:10:05 -0800

@martinthomson > Unfortunately, this is a design change, and a new one.

just to be clear, are you referring to my comment on a limit of eight, or something earlier?

-- 
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/2428#issuecomment-461310592

---

From: erickinnear <[email-masked]>
Date: Fri, 08 Feb 2019 16:48:30 -0800

@mikkelfj I think we should have a separate discussion around a sensible default. Part of the idea here was to make sure that we were very unlikely to run out, even around lost/retransmitted packets on different paths. Choosing a very low number brings with it other potential issues which probably should hold up this change? 

-- 
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/2428#issuecomment-461995108

---

From: MikkelFJ <[email-masked]>
Date: Fri, 08 Feb 2019 23:34:37 -0800

@erickinnear yes, I realised this relates to #1998 max_connection_ids.

-- 
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/2428#issuecomment-462022180

---

From: Martin Thomson <[email-masked]>
Date: Sun, 10 Feb 2019 14:32:56 -0800

@martinthomson pushed 1 commit.

99e52fd4ebec4af1927828416189d52d7a91cc60  Ted's comments

-- 
You are receiving this because you are subscribed to this thread.
View it on GitHub:
https://github.com/quicwg/base-drafts/pull/2428/files/a0ae02995b37cd83d163f334c7b71e0b1ddb13f6..99e52fd4ebec4af1927828416189d52d7a91cc60

---

From: Jana Iyengar <[email-masked]>
Date: Thu, 21 Feb 2019 18:12:43 -0800

janaiyengar approved this pull request.

A few nits, but this looks good to me. That said, this issue will need consensus.

> @@ -961,12 +961,16 @@ cannot expect its peer to store and use all issued connection IDs.

```suggestion
packet with a previously unused connection ID.  However, it MAY limit the frequency
```

> @@ -961,12 +961,16 @@ cannot expect its peer to store and use all issued connection IDs.

```suggestion
An endpoint that initiates migration and requires non-zero-length connection IDs
```

> @@ -961,12 +961,16 @@ cannot expect its peer to store and use all issued connection IDs.
+SHOULD ensure that the pool of connection IDs available to their peers allows

```suggestion
SHOULD ensure that the pool of connection IDs available to its peer allows
```

> @@ -961,12 +961,16 @@ cannot expect its peer to store and use all issued connection IDs.
+SHOULD ensure that the pool of connection IDs available to their peers allows
+them to use a new connection ID on migration, as the peer will close the

```suggestion
the peer to use a new connection ID on migration, as the peer will close the
```

-- 
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/2428#pullrequestreview-206630866

---

From: Kazuho Oku <[email-masked]>
Date: Thu, 21 Feb 2019 18:16:10 -0800

@kazuho pushed 1 commit.

0f9343bb1bace2205da6cba14ac20ea6e1c2f5b9  Update draft-ietf-quic-transport.md

-- 
You are receiving this because you are subscribed to this thread.
View it on GitHub:
https://github.com/quicwg/base-drafts/pull/2428/files/99e52fd4ebec4af1927828416189d52d7a91cc60..0f9343bb1bace2205da6cba14ac20ea6e1c2f5b9

---

From: Kazuho Oku <[email-masked]>
Date: Thu, 21 Feb 2019 18:16:22 -0800

@kazuho pushed 1 commit.

d1759eba7ed116861a44d960461a606e73353c52  Update draft-ietf-quic-transport.md

-- 
You are receiving this because you are subscribed to this thread.
View it on GitHub:
https://github.com/quicwg/base-drafts/pull/2428/files/0f9343bb1bace2205da6cba14ac20ea6e1c2f5b9..d1759eba7ed116861a44d960461a606e73353c52

---

From: Kazuho Oku <[email-masked]>
Date: Thu, 21 Feb 2019 18:16:30 -0800

@kazuho pushed 1 commit.

b5c3945f5931aa1eba5db7b57033b6b6f43ab324  Update draft-ietf-quic-transport.md

-- 
You are receiving this because you are subscribed to this thread.
View it on GitHub:
https://github.com/quicwg/base-drafts/pull/2428/files/d1759eba7ed116861a44d960461a606e73353c52..b5c3945f5931aa1eba5db7b57033b6b6f43ab324

---

From: Kazuho Oku <[email-masked]>
Date: Thu, 21 Feb 2019 18:16:58 -0800

@kazuho pushed 1 commit.

6efa27b7fb38316400cb767a2dbd7ae03c4bfcb9  Update draft-ietf-quic-transport.md

-- 
You are receiving this because you are subscribed to this thread.
View it on GitHub:
https://github.com/quicwg/base-drafts/pull/2428/files/b5c3945f5931aa1eba5db7b57033b6b6f43ab324..6efa27b7fb38316400cb767a2dbd7ae03c4bfcb9

---

From: Kazuho Oku <[email-masked]>
Date: Thu, 21 Feb 2019 18:23:14 -0800

@kazuho pushed 1 commit.

24fddef652d8cae49c614e4fe634a7895c355021  wordwrap

-- 
You are receiving this because you are subscribed to this thread.
View it on GitHub:
https://github.com/quicwg/base-drafts/pull/2428/files/6efa27b7fb38316400cb767a2dbd7ae03c4bfcb9..24fddef652d8cae49c614e4fe634a7895c355021

---

From: Mike Bishop <[email-masked]>
Date: Wed, 27 Feb 2019 19:23:23 +0000 (UTC)

MikeBishop approved this pull request.

I'm not convinced this is a design change -- there was previously a SHOULD, and this adds additional text (including a MAY) around when you might choose to violate the SHOULD.  However, no mandatory behavior is added, changed, or removed.

-- 
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/2428#pullrequestreview-208717492

---

From: Martin Thomson <[email-masked]>
Date: Wed, 27 Feb 2019 12:47:52 -0800

I'm going with editorial then.

-- 
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/2428#issuecomment-468024035

---

From: Martin Thomson <[email-masked]>
Date: Wed, 27 Feb 2019 12:47:58 -0800

Merged #2428 into master.

-- 
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/2428#event-2169197669