Date: Tue, 20 Jun 2017 05:45:32 -0700
From: MikkelFJ <notifications@github.com>
Reply-To: quicwg/base-drafts
 <reply+0166e4abe9472041f1c78603b73e0617c8ab21fe04d16e4f92cf000000011560daec92a169ce0df59194@reply.github.com>
To: quicwg/base-drafts <base-drafts@noreply.github.com>
Cc: Subscribed <subscribed@noreply.github.com>
Message-ID: <quicwg/base-drafts/issues/605/309741686@github.com>
In-Reply-To: <quicwg/base-drafts/issues/605@github.com>
References: <quicwg/base-drafts/issues/605@github.com>
Subject: Re: [quicwg/base-drafts] Wrongly hinting of issues not existing for
 packet number size increase (#605)
Mime-Version: 1.0
Content-Type: multipart/alternative;
 boundary="--==_mimepart_594918ec991eb_61953fc8da5b7c2c58212";
 charset=UTF-8
Content-Transfer-Encoding: 7bit
Precedence: list
Archived-At: <https://mailarchive.ietf.org/arch/msg/quic-issues/b3en-b1ulVy5WjgYkmy7P-VRSXw>


----==_mimepart_594918ec991eb_61953fc8da5b7c2c58212
Content-Type: text/plain;
 charset=UTF-8
Content-Transfer-Encoding: 7bit

>  Maybe I'm misunderstanding you.

Or may be the opposite - I thought you would introduce a gap in the packet number space while advancing the larger range, but that no longer makes sense to me.

Either way, I'm  not sure there is a problem:

If you send 100 packets in 8-bit encoding, then decide to send 100000 packets more, you encode 8 bit until packet 127, use 16 bit until packet 32767, and 32 bit after that.

Regardless of delivery order, there shouldn't be any ambiguity about the packer number.

But this isn't exactly how things are specified currently - it uses a diff against largest received or something like that.

If the spec would state that only half the representable range must be used for any given encoding, except for 64 bit, then I think it should be working.

Simpler yet, use varlen.



-- 
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/605#issuecomment-309741686
----==_mimepart_594918ec991eb_61953fc8da5b7c2c58212
Content-Type: text/html;
 charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<blockquote>
<p>Maybe I'm misunderstanding you.</p>
</blockquote>
<p>Or may be the opposite - I thought you would introduce a gap in the pa=
cket number space while advancing the larger range, but that no longer ma=
kes sense to me.</p>
<p>Either way, I'm  not sure there is a problem:</p>
<p>If you send 100 packets in 8-bit encoding, then decide to send 100000 =
packets more, you encode 8 bit until packet 127, use 16 bit until packet =
32767, and 32 bit after that.</p>
<p>Regardless of delivery order, there shouldn't be any ambiguity about t=
he packer number.</p>
<p>But this isn't exactly how things are specified currently - it uses a =
diff against largest received or something like that.</p>
<p>If the spec would state that only half the representable range must be=
 used for any given encoding, except for 64 bit, then I think it should b=
e working.</p>
<p>Simpler yet, use varlen.</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/605#issuecomment-309741686">view it on GitHub</a>, =
or <a href=3D"https://github.com/notifications/unsubscribe-auth/AWbkq2UjM=
eI4rRzCM0C682mJjK592TTDks5sF77sgaJpZM4Nypwu">mute the thread</a>.<img alt=
=3D"" height=3D"1" src=3D"https://github.com/notifications/beacon/AWbkq_M=
Ow-bt5iJ361soJA1Pt8dYniIOks5sF77sgaJpZM4Nypwu.gif" width=3D"1" /></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/605#issuecomment-309741686"></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":"@mikkelfj in #=
605: \u003e  Maybe I'm misunderstanding you.\r\n\r\nOr may be the opposit=
e - I thought you would introduce a gap in the packet number space while =
advancing the larger range, but that no longer makes sense to me.\r\n\r\n=
Either way, I'm  not sure there is a problem:\r\n\r\nIf you send 100 pack=
ets in 8-bit encoding, then decide to send 100000 packets more, you encod=
e 8 bit until packet 127, use 16 bit until packet 32767, and 32 bit after=
 that.\r\n\r\nRegardless of delivery order, there shouldn't be any ambigu=
ity about the packer number.\r\n\r\nBut this isn't exactly how things are=
 specified currently - it uses a diff against largest received or somethi=
ng like that.\r\n\r\nIf the spec would state that only half the represent=
able range must be used for any given encoding, except for 64 bit, then I=
 think it should be working.\r\n\r\nSimpler yet, use varlen.\r\n\r\n"}],"=
action":{"name":"View Issue","url":"https://github.com/quicwg/base-drafts=
/issues/605#issuecomment-309741686"}}}</script>=

----==_mimepart_594918ec991eb_61953fc8da5b7c2c58212--