Date: Mon, 12 Nov 2018 10:16:36 +0000 (UTC)
From: Marten Seemann <notifications@github.com>
Reply-To: quicwg/base-drafts
 <reply+0166e4ab0883bc7eafc3ecd78e75e43e396f38d28c67440c92cf000000011801150492a169ce16a1bb2f@reply.github.com>
To: quicwg/base-drafts <base-drafts@noreply.github.com>
Cc: Subscribed <subscribed@noreply.github.com>
Message-ID: <quicwg/base-drafts/pull/1992/review/173829561@github.com>
In-Reply-To: <quicwg/base-drafts/pull/1992@github.com>
References: <quicwg/base-drafts/pull/1992@github.com>
Subject: Re: [quicwg/base-drafts] Endpoint MAY discard CIDs (#1992)
Mime-Version: 1.0
Content-Type: multipart/alternative;
 boundary="--==_mimepart_5be953042af99_43f63fa588cd45c01118f3";
 charset=UTF-8
Content-Transfer-Encoding: 7bit
Precedence: list
Archived-At: <https://mailarchive.ietf.org/arch/msg/quic-issues/4f2MzRZ7MPkpjDBPr2U-PIIWidY>

----==_mimepart_5be953042af99_43f63fa588cd45c01118f3
Content-Type: text/plain;
 charset=UTF-8
Content-Transfer-Encoding: 7bit

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
----==_mimepart_5be953042af99_43f63fa588cd45c01118f3
Content-Type: text/html;
 charset=UTF-8
Content-Transfer-Encoding: 7bit

<p><b>@marten-seemann</b> requested changes on this pull request.</p>

<p>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 =&gt; 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.</p>
<p>This is trivially solved if each peer declares the number of connection IDs it is willing to store in a transport parameter. Based on <a class="user-mention" data-hovercard-type="user" data-hovercard-url="/hovercards?user_id=4528576" data-octo-click="hovercard-link-click" data-octo-dimensions="link_type:self" href="https://github.com/dtikhonov">@dtikhonov</a>'s thread on the mailing list, I was planning to contribute a PR for this.</p>

<p style="font-size:small;-webkit-text-size-adjust:none;color:#666;">&mdash;<br />You are receiving this because you are subscribed to this thread.<br />Reply to this email directly, <a href="https://github.com/quicwg/base-drafts/pull/1992#pullrequestreview-173829561">view it on GitHub</a>, or <a href="https://github.com/notifications/unsubscribe-auth/AWbkq8peYLOv4aSZp2ykQMCAZB2zjnyYks5uuUqEgaJpZM4YZTGe">mute the thread</a>.<img src="https://github.com/notifications/beacon/AWbkq7gJQ1mFqzQu2dxIVlJVLxVV-j-9ks5uuUqEgaJpZM4YZTGe.gif" height="1" width="1" alt="" /></p>
<script type="application/json" data-scope="inboxmarkup">{"api_version":"1.0","publisher":{"api_key":"05dde50f1d1a384dd78767c55493e4bb","name":"GitHub"},"entity":{"external_key":"github/quicwg/base-drafts","title":"quicwg/base-drafts","subtitle":"GitHub repository","main_image_url":"https://assets-cdn.github.com/images/email/message_cards/header.png","avatar_image_url":"https://assets-cdn.github.com/images/email/message_cards/avatar.png","action":{"name":"Open in GitHub","url":"https://github.com/quicwg/base-drafts"}},"updates":{"snippets":[{"icon":"PERSON","message":"@marten-seemann requested changes on #1992"}],"action":{"name":"View Pull Request","url":"https://github.com/quicwg/base-drafts/pull/1992#pullrequestreview-173829561"}}}</script>
<script type="application/ld+json">[
{
"@context": "http://schema.org",
"@type": "EmailMessage",
"potentialAction": {
"@type": "ViewAction",
"target": "https://github.com/quicwg/base-drafts/pull/1992#pullrequestreview-173829561",
"url": "https://github.com/quicwg/base-drafts/pull/1992#pullrequestreview-173829561",
"name": "View Pull Request"
},
"description": "View this Pull Request on GitHub",
"publisher": {
"@type": "Organization",
"name": "GitHub",
"url": "https://github.com"
}
},
{
"@type": "MessageCard",
"@context": "http://schema.org/extensions",
"hideOriginalBody": "false",
"originator": "AF6C5A86-E920-430C-9C59-A73278B5EFEB",
"title": "@marten-seemann requested changes on 1992",
"sections": [
{
"text": "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 =\u003e 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.\r\n\r\nThis 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.",
"activityTitle": "**Marten Seemann**",
"activityImage": "https://assets-cdn.github.com/images/email/message_cards/avatar.png",
"activitySubtitle": "@marten-seemann",
"facts": [

]
}
],
"potentialAction": [
{
"targets": [
{
"os": "default",
"uri": "https://github.com/quicwg/base-drafts/pull/1992#pullrequestreview-173829561"
}
],
"@type": "OpenUri",
"name": "View on GitHub"
},
{
"name": "Unsubscribe",
"@type": "HttpPOST",
"target": "https://api.github.com",
"body": "{\n\"commandName\": \"MuteNotification\",\n\"threadId\": 409285022\n}"
}
],
"themeColor": "26292E"
}
]</script>
----==_mimepart_5be953042af99_43f63fa588cd45c01118f3--