Subject: [quicwg/base-drafts] Endpoint MAY discard CIDs (#1992)

From: janaiyengar <[email-masked]>
Date: Mon, 12 Nov 2018 01:52:59 -0800

An endpoint should not assume that its peer will not drop any received CIDs.
You can view, comment on, or merge this pull request online at:

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

-- Commit Summary --

  * endpoint MAY discard CIDs

-- File Changes --

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

-- Patch Links --

https://github.com/quicwg/base-drafts/pull/1992.patch
https://github.com/quicwg/base-drafts/pull/1992.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/1992

---

From: Martin Thomson <[email-masked]>
Date: Mon, 12 Nov 2018 02:00:55 -0800

martinthomson approved this pull request.

 When an endpoint issues a connection ID, it MUST accept packets that carry this
 connection ID for the duration of the connection or until its peer invalidates
 the connection ID via a RETIRE_CONNECTION_ID frame
 ({{frame-retire-connection-id}}).
 
+Endpoints store received connection IDs for future use.  An endpoint that
+receives excessive connection IDs MAY discard those it cannot store.  An
+endpoint that issues connection IDs should expect that its peer might not store

```suggestion
endpoint that issues connection IDs cannot expect its peer to store
```

-- 
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/1992#pullrequestreview-173823447

---

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

I think this is messy - I know there have been lengthy discussions. But sender also may have to track state. It would be better to have a fixed TP length of say, 5 CID's and only replenish when one is 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/pull/1992#issuecomment-437825414

---

From: Marten Seemann <[email-masked]>
Date: Mon, 12 Nov 2018 10:16:36 +0000 (UTC)

marten-seemann requested changes on this pull request.

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.

This is trivially solved if each peer declares the number of connection IDs it is willing to store in a transport parameter. Based on @dtikhonov's thread on the mailing list, I was planning to contribute a PR for this.

-- 
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/1992#pullrequestreview-173829561

---

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

If I understand @marten-seemann correctly, this is in line with what I propose, and which others have proposed 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/1992#issuecomment-437828060

---

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

@janaiyengar pushed 1 commit.

af65127  nit

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

---

From: janaiyengar <[email-masked]>
Date: Mon, 12 Nov 2018 02:33:54 -0800

c4d3a83  reflow

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

---

From: janaiyengar <[email-masked]>
Date: Mon, 12 Nov 2018 02:35:23 -0800

@marten-seemann @mikkelfj : Like I said on list, I think it's fine to drive that issue (please do file an issue first), and send a PR along (ASAP). I'm merely clarifying existing text.

-- 
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/1992#issuecomment-437832211

---

From: janaiyengar <[email-masked]>
Date: Mon, 12 Nov 2018 10:35:58 +0000 (UTC)

Merged #1992 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/1992#event-1959913199

---

From: ianswett <[email-masked]>
Date: Tue, 13 Nov 2018 11:12:18 -0800

ianswett commented on this pull request.

+Endpoints store received connection IDs for future use.  An endpoint that
+receives excessive connection IDs MAY discard those it cannot store.  An
+endpoint that issues connection IDs cannot expect its peer to store and use all
+issued connection IDs.

Belated question: when you discard them, it seems you should not send a RETIRE_CONNECTION_ID frame, otherwise you may just get more?

-- 
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/1992#pullrequestreview-174538949

---

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

MikeBishop commented on this pull request.

The idea is that you can have an uncoordinated negotiation:  I'm willing to issue 64, you only need 8.  You take the 8 you want, let the remaining 56 fall on the floor, and then I'll replace the 8 you kept as you RETIRE them.  If you RETIREd the 56 you didn't need, I'd replace *those*, and we'd get into an endless RETIRE/NEW drop for no purpose.

-- 
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/1992#discussion_r233188533