Date: Wed, 19 Dec 2018 03:07:18 -0800
From: MikkelFJ <notifications@github.com>
Reply-To: quicwg/base-drafts
 <reply+0166e4abb81cd1323f3de7b97ddf47d1f8948c2756cecb4192cf000000011831e86692a169ce1753c928@reply.github.com>
To: quicwg/base-drafts <base-drafts@noreply.github.com>
Cc: Subscribed <subscribed@noreply.github.com>
Message-ID: <quicwg/base-drafts/issues/2192/448556712@github.com>
In-Reply-To: <quicwg/base-drafts/issues/2192@github.com>
References: <quicwg/base-drafts/issues/2192@github.com>
Subject: Re: [quicwg/base-drafts] Optimistic ACK in early handshake (#2192)
Mime-Version: 1.0
Content-Type: multipart/alternative;
 boundary="--==_mimepart_5c1a26667315e_7283fdd620d45c43956e6";
 charset=UTF-8
Content-Transfer-Encoding: 7bit
Precedence: list
Archived-At: <https://mailarchive.ietf.org/arch/msg/quic-issues/i_3exX31jlKkPwr7VszhZL-1zHE>


----==_mimepart_5c1a26667315e_7283fdd620d45c43956e6
Content-Type: text/plain;
 charset=UTF-8
Content-Transfer-Encoding: 7bit

@gloinul 
> Thus, if you actually have a packet loss, the whole connection will be screwed as you can't get retransmission of the lost data.

I don't think (hope not) that there is text preventing acknowledging a packet multiple times, but it SHOULD not be acknowledge again once an endpoint knows that the peer received the acknowledgment.

As to renege in the current text:

section 19.3.: 
> QUIC acknowledgements are irrevocable. Once acknowledged, a packet remains acknowledged, even if it does not appear in a future ACK frame. This is unlike TCP SACKs ([RFC2018]).

section 21.3.:
> An endpoint that acknowledges packets it has not received might cause a congestion controller to permit sending at rates beyond what the network supports. An endpoint MAY skip packet numbers when sending packets to detect this behavior. An endpoint can then immediately close the connection with a connection error of type PROTOCOL_VIOLATION (see Section 10.3).


-- 
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/2192#issuecomment-448556712
----==_mimepart_5c1a26667315e_7283fdd620d45c43956e6
Content-Type: text/html;
 charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<p><a class=3D"user-mention" data-hovercard-type=3D"user" data-hovercard-=
url=3D"/hovercards?user_id=3D11295323" data-octo-click=3D"hovercard-link-=
click" data-octo-dimensions=3D"link_type:self" href=3D"https://github.com=
/gloinul">@gloinul</a></p>
<blockquote>
<p>Thus, if you actually have a packet loss, the whole connection will be=
 screwed as you can't get retransmission of the lost data.</p>
</blockquote>
<p>I don't think (hope not) that there is text preventing acknowledging a=
 packet multiple times, but it SHOULD not be acknowledge again once an en=
dpoint knows that the peer received the acknowledgment.</p>
<p>As to renege in the current text:</p>
<p>section 19.3.:</p>
<blockquote>
<p>QUIC acknowledgements are irrevocable. Once acknowledged, a packet rem=
ains acknowledged, even if it does not appear in a future ACK frame. This=
 is unlike TCP SACKs ([RFC2018]).</p>
</blockquote>
<p>section 21.3.:</p>
<blockquote>
<p>An endpoint that acknowledges packets it has not received might cause =
a congestion controller to permit sending at rates beyond what the networ=
k supports. An endpoint MAY skip packet numbers when sending packets to d=
etect this behavior. An endpoint can then immediately close the connectio=
n with a connection error of type PROTOCOL_VIOLATION (see Section 10.3).<=
/p>
</blockquote>

<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/2192#issuecomment-448556712">view it on GitHub</a>,=
 or <a href=3D"https://github.com/notifications/unsubscribe-auth/AWbkq8fZ=
-n93NU2aEwE-KMOJS2DvjKSuks5u6h3mgaJpZM4ZUrjj">mute the thread</a>.<img sr=
c=3D"https://github.com/notifications/beacon/AWbkqwxzIbbvIuEemSstZUOp9Dqz=
llkWks5u6h3mgaJpZM4ZUrjj.gif" height=3D"1" width=3D"1" alt=3D"" /></p>
<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://github.githubassets.com/images/email/message_cards/header.png","avata=
r_image_url":"https://github.githubassets.com/images/email/message_cards/=
avatar.png","action":{"name":"Open in GitHub","url":"https://github.com/q=
uicwg/base-drafts"}},"updates":{"snippets":[{"icon":"PERSON","message":"@=
mikkelfj in #2192: @gloinul \r\n\u003e Thus, if you actually have a packe=
t loss, the whole connection will be screwed as you can't get retransmiss=
ion of the lost data.\r\n\r\nI don't think (hope not) that there is text =
preventing acknowledging a packet multiple times, but it SHOULD not be ac=
knowledge again once an endpoint knows that the peer received the acknowl=
edgment.\r\n\r\nAs to renege in the current text:\r\n\r\nsection 19.3.: \=
r\n\u003e QUIC acknowledgements are irrevocable. Once acknowledged, a pac=
ket remains acknowledged, even if it does not appear in a future ACK fram=
e. This is unlike TCP SACKs ([RFC2018]).\r\n\r\nsection 21.3.:\r\n\u003e =
An endpoint that acknowledges packets it has not received might cause a c=
ongestion controller to permit sending at rates beyond what the network s=
upports. An endpoint MAY skip packet numbers when sending packets to dete=
ct this behavior. An endpoint can then immediately close the connection w=
ith a connection error of type PROTOCOL_VIOLATION (see Section 10.3).\r\n=
"}],"action":{"name":"View Issue","url":"https://github.com/quicwg/base-d=
rafts/issues/2192#issuecomment-448556712"}}}</script>
<script type=3D"application/ld+json">[
{
"@context": "http://schema.org",
"@type": "EmailMessage",
"potentialAction": {
"@type": "ViewAction",
"target": "https://github.com/quicwg/base-drafts/issues/2192#issuecomment=
-448556712",
"url": "https://github.com/quicwg/base-drafts/issues/2192#issuecomment-44=
8556712",
"name": "View Issue"
},
"description": "View this Issue on GitHub",
"publisher": {
"@type": "Organization",
"name": "GitHub",
"url": "https://github.com"
}
}
]</script>=

----==_mimepart_5c1a26667315e_7283fdd620d45c43956e6--