Date: Tue, 20 Jun 2017 05:24:39 -0700
From: Patrick McManus <notifications@github.com>
Reply-To: quicwg/base-drafts
 <reply+0166e4ab49a2ec4b4d119eafcfd56d0bc2b86d84a9720b0992cf000000011560d60792a169ce0df59194@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/309736878@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_594914075f64b_54853f8afddb1c2c594bb";
 charset=UTF-8
Content-Transfer-Encoding: 7bit
Precedence: list
Archived-At: <https://mailarchive.ietf.org/arch/msg/quic-issues/kpNkteKC_0CCRu4bXMB4aBy6ubM>


----==_mimepart_594914075f64b_54853f8afddb1c2c594bb
Content-Type: text/plain;
 charset=UTF-8
Content-Transfer-Encoding: 7bit

I don't think gapless creates a problem with the existing spec (though I also support #595). Maybe I'm misunderstanding you.

Gap is a property of the sender, and there would be no gap just by virtue of moving to a bigger encoding - that's obvious to the receiver if the packets are delivered in order but its true whether the receiver realizes it or not.  So out of order delivery would basically just be a form of loss/corruption (the misinterpreted number would cause a decrypt fail) fixed in the usual way (retransmit of data). 

To me, the most important part of this issue is that the current design is prone to this self-induced loss and while not a critical fail, it should be improved.

-- 
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-309736878
----==_mimepart_594914075f64b_54853f8afddb1c2c594bb
Content-Type: text/html;
 charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<p>I don't think gapless creates a problem with the existing spec (though=
 I also support <a href=3D"https://github.com/quicwg/base-drafts/issues/5=
95" class=3D"issue-link js-issue-link" data-url=3D"https://github.com/qui=
cwg/base-drafts/issues/595" data-id=3D"233893653" data-error-text=3D"Fail=
ed to load issue title" data-permission-text=3D"Issue title is private">#=
595</a>). Maybe I'm misunderstanding you.</p>
<p>Gap is a property of the sender, and there would be no gap just by vir=
tue of moving to a bigger encoding - that's obvious to the receiver if th=
e packets are delivered in order but its true whether the receiver realiz=
es it or not.  So out of order delivery would basically just be a form of=
 loss/corruption (the misinterpreted number would cause a decrypt fail) f=
ixed in the usual way (retransmit of data).</p>
<p>To me, the most important part of this issue is that the current desig=
n is prone to this self-induced loss and while not a critical fail, it sh=
ould be improved.</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-309736878">view it on GitHub</a>, =
or <a href=3D"https://github.com/notifications/unsubscribe-auth/AWbkqzcrJ=
HRkaCfVrkW-TVW9wlMrRpqBks5sF7oHgaJpZM4Nypwu">mute the thread</a>.<img alt=
=3D"" height=3D"1" src=3D"https://github.com/notifications/beacon/AWbkq3l=
NvR1cJdbiNmGLCPg31COCsCj-ks5sF7oHgaJpZM4Nypwu.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-309736878"></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":"@mcmanus in #6=
05: I don't think gapless creates a problem with the existing spec (thoug=
h I also support #595). Maybe I'm misunderstanding you.\r\n\r\nGap is a p=
roperty of the sender, and there would be no gap just by virtue of moving=
 to a bigger encoding - that's obvious to the receiver if the packets are=
 delivered in order but its true whether the receiver realizes it or not.=
  So out of order delivery would basically just be a form of loss/corrupt=
ion (the misinterpreted number would cause a decrypt fail) fixed in the u=
sual way (retransmit of data). \r\n\r\nTo me, the most important part of =
this issue is that the current design is prone to this self-induced loss =
and while not a critical fail, it should be improved."}],"action":{"name"=
:"View Issue","url":"https://github.com/quicwg/base-drafts/issues/605#iss=
uecomment-309736878"}}}</script>=

----==_mimepart_594914075f64b_54853f8afddb1c2c594bb--