Date: Fri, 04 May 2018 05:29:43 -0700
From: ianswett <notifications@github.com>
Reply-To: quicwg/base-drafts
 <reply+0166e4ab28a1674570d0c933724f537ec81934326f597b8e92cf000000011704143792a169ce131475f5@reply.github.com>
To: quicwg/base-drafts <base-drafts@noreply.github.com>
Cc: Subscribed <subscribed@noreply.github.com>
Message-ID: <quicwg/base-drafts/issues/1336/386586397@github.com>
In-Reply-To: <quicwg/base-drafts/issues/1336@github.com>
References: <quicwg/base-drafts/issues/1336@github.com>
Subject: Re: [quicwg/base-drafts] Consistent presenting Connection ID in
 packet or frame (#1336)
Mime-Version: 1.0
Content-Type: multipart/alternative;
 boundary="--==_mimepart_5aec523731526_45c32af5f1056f6021295c";
 charset=UTF-8
Content-Transfer-Encoding: 7bit
Precedence: list
Archived-At: <https://mailarchive.ietf.org/arch/msg/quic-issues/QrUYhUwHbNg2n-NXYLImUqE594g>


----==_mimepart_5aec523731526_45c32af5f1056f6021295c
Content-Type: text/plain;
 charset=UTF-8
Content-Transfer-Encoding: 7bit

Differentiating between 0-len and non 0-len CIDs is a problem, but I'm not sure it's an important use case.  0-len CIDs are very much designed for cases when you expect the 4-tuple to identify the connection.  Non-0 are for all other cases.  Those cases seem quite distinct, so I don't see a need to support both on the same 4-tuple at once.

If you're using a load balancer, you should almost certainly be using a non-0 length CID.  And you can choose to encode the length in that CID however you'd like, since the CID is receiver chosen.

@mcmanus  Bringing back the bit is sad, and making the min length 1 byte would require some substantial changes to the invariants, which I'd really rather not do.

-- 
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/1336#issuecomment-386586397
----==_mimepart_5aec523731526_45c32af5f1056f6021295c
Content-Type: text/html;
 charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<p>Differentiating between 0-len and non 0-len CIDs is a problem, but I'm=
 not sure it's an important use case.  0-len CIDs are very much designed =
for cases when you expect the 4-tuple to identify the connection.  Non-0 =
are for all other cases.  Those cases seem quite distinct, so I don't see=
 a need to support both on the same 4-tuple at once.</p>
<p>If you're using a load balancer, you should almost certainly be using =
a non-0 length CID.  And you can choose to encode the length in that CID =
however you'd like, since the CID is receiver chosen.</p>
<p><a class=3D"user-mention" data-hovercard-user-id=3D"260531" data-octo-=
click=3D"hovercard-link-click" data-octo-dimensions=3D"link_type:self" hr=
ef=3D"https://github.com/mcmanus">@mcmanus</a>  Bringing back the bit is =
sad, and making the min length 1 byte would require some substantial chan=
ges to the invariants, which I'd really rather not do.</p>

<p style=3D"font-size:small;-webkit-text-size-adjust:none;color:#666;">&m=
dash;<br />You are receiving this because you are subscribed to this thre=
ad.<br />Reply to this email directly, <a href=3D"https://github.com/quic=
wg/base-drafts/issues/1336#issuecomment-386586397">view it on GitHub</a>,=
 or <a href=3D"https://github.com/notifications/unsubscribe-auth/AWbkqzrG=
GtDkRIl--5RkQlJ_hqrOZjcfks5tvEm3gaJpZM4Tx5-h">mute the thread</a>.<img sr=
c=3D"https://github.com/notifications/beacon/AWbkq40VR0TuXvgQr6jlA9ddJzQg=
ub0vks5tvEm3gaJpZM4Tx5-h.gif" height=3D"1" width=3D"1" alt=3D"" /></p>
<div itemscope itemtype=3D"http://schema.org/EmailMessage">
<div itemprop=3D"action" itemscope itemtype=3D"http://schema.org/ViewActi=
on">
  <link itemprop=3D"url" href=3D"https://github.com/quicwg/base-drafts/is=
sues/1336#issuecomment-386586397"></link>
  <meta itemprop=3D"name" content=3D"View Issue"></meta>
</div>
<meta itemprop=3D"description" content=3D"View this Issue on GitHub"></me=
ta>
</div>

<script type=3D"application/json" data-scope=3D"inboxmarkup">{"api_versio=
n":"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":"http=
s://cloud.githubusercontent.com/assets/143418/17495839/a5054eac-5d88-11e6=
-95fc-7290892c7bb5.png","avatar_image_url":"https://cloud.githubuserconte=
nt.com/assets/143418/15842166/7c72db34-2c0b-11e6-9aed-b52498112777.png","=
action":{"name":"Open in GitHub","url":"https://github.com/quicwg/base-dr=
afts"}},"updates":{"snippets":[{"icon":"PERSON","message":"@ianswett in #=
1336: Differentiating between 0-len and non 0-len CIDs is a problem, but =
I'm not sure it's an important use case.  0-len CIDs are very much design=
ed for cases when you expect the 4-tuple to identify the connection.  Non=
-0 are for all other cases.  Those cases seem quite distinct, so I don't =
see a need to support both on the same 4-tuple at once.\r\n\r\nIf you're =
using a load balancer, you should almost certainly be using a non-0 lengt=
h CID.  And you can choose to encode the length in that CID however you'd=
 like, since the CID is receiver chosen.\r\n\r\n@mcmanus  Bringing back t=
he bit is sad, and making the min length 1 byte would require some substa=
ntial changes to the invariants, which I'd really rather not do."}],"acti=
on":{"name":"View Issue","url":"https://github.com/quicwg/base-drafts/iss=
ues/1336#issuecomment-386586397"}}}</script>=

----==_mimepart_5aec523731526_45c32af5f1056f6021295c--