Date: Sun, 06 Jan 2019 23:16:46 -0800
From: Christian Huitema <notifications@github.com>
Reply-To: quicwg/base-drafts
 <reply+0166e4ab72a415e1c06fecdc936894664238ec604a0cedfe92cf00000001184abede92a169ce1784eaec@reply.github.com>
To: quicwg/base-drafts <base-drafts@noreply.github.com>
Cc: Subscribed <subscribed@noreply.github.com>
Message-ID: <quicwg/base-drafts/issues/2267/451842773@github.com>
In-Reply-To: <quicwg/base-drafts/issues/2267@github.com>
References: <quicwg/base-drafts/issues/2267@github.com>
Subject: Re: [quicwg/base-drafts] loss of only two packets can lead to an
 unrecoverable situation (#2267)
Mime-Version: 1.0
Content-Type: multipart/alternative;
 boundary="--==_mimepart_5c32fcdee8abe_2b0d3fe214cd45c07812b7";
 charset=UTF-8
Content-Transfer-Encoding: 7bit
Precedence: list
Archived-At: <https://mailarchive.ietf.org/arch/msg/quic-issues/68iBGgiKKgRUXjUzrYfYYzehYhE>


----==_mimepart_5c32fcdee8abe_2b0d3fe214cd45c07812b7
Content-Type: text/plain;
 charset=UTF-8
Content-Transfer-Encoding: 7bit

I think this issue is an indirect justification for implicit ACK. The server may have dropped the handshake key, but it can send and receive 1-RTT packets. So can the client. If the client sends an 1-RTT packet after sending the CFIN, it should receive an ACK from the server. At that point, it knows there is no point in retransmitting the CFIN. If neither the 1-RTT not the CFIN handshake are acked, both can be repeated. If the handshake CFIN was received but the ACK lost, as @marten-seemann envisages, the server may not be able to process handshake packets anymore, but it can receive and ACK the 1-RTT packet.

Of course, that falls apart if the handshake and 1-RTT packets are coalesced. Maybe we need a warning there... 

-- 
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/2267#issuecomment-451842773
----==_mimepart_5c32fcdee8abe_2b0d3fe214cd45c07812b7
Content-Type: text/html;
 charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<p>I think this issue is an indirect justification for implicit ACK. The =
server may have dropped the handshake key, but it can send and receive 1-=
RTT packets. So can the client. If the client sends an 1-RTT packet after=
 sending the CFIN, it should receive an ACK from the server. At that poin=
t, it knows there is no point in retransmitting the CFIN. If neither the =
1-RTT not the CFIN handshake are acked, both can be repeated. If the hand=
shake CFIN was received but the ACK lost, as <a class=3D"user-mention" da=
ta-hovercard-type=3D"user" data-hovercard-url=3D"/hovercards?user_id=3D14=
78487" data-octo-click=3D"hovercard-link-click" data-octo-dimensions=3D"l=
ink_type:self" href=3D"https://github.com/marten-seemann">@marten-seemann=
</a> envisages, the server may not be able to process handshake packets a=
nymore, but it can receive and ACK the 1-RTT packet.</p>
<p>Of course, that falls apart if the handshake and 1-RTT packets are coa=
lesced. Maybe we need a warning there...</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/2267#issuecomment-451842773">view it on GitHub</a>,=
 or <a href=3D"https://github.com/notifications/unsubscribe-auth/AWbkq3bn=
hM0RO5EpVSE0y6aCX35uxXseks5vAvRegaJpZM4ZjodA">mute the thread</a>.<img sr=
c=3D"https://github.com/notifications/beacon/AWbkq8lmr-esJHJIiBnEfsJBIZIj=
lNzaks5vAvRegaJpZM4ZjodA.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":"@=
huitema in #2267: I think this issue is an indirect justification for imp=
licit ACK. The server may have dropped the handshake key, but it can send=
 and receive 1-RTT packets. So can the client. If the client sends an 1-R=
TT packet after sending the CFIN, it should receive an ACK from the serve=
r. At that point, it knows there is no point in retransmitting the CFIN. =
If neither the 1-RTT not the CFIN handshake are acked, both can be repeat=
ed. If the handshake CFIN was received but the ACK lost, as @marten-seema=
nn envisages, the server may not be able to process handshake packets any=
more, but it can receive and ACK the 1-RTT packet.\r\n\r\nOf course, that=
 falls apart if the handshake and 1-RTT packets are coalesced. Maybe we n=
eed a warning there... "}],"action":{"name":"View Issue","url":"https://g=
ithub.com/quicwg/base-drafts/issues/2267#issuecomment-451842773"}}}</scri=
pt>
<script type=3D"application/ld+json">[
{
"@context": "http://schema.org",
"@type": "EmailMessage",
"potentialAction": {
"@type": "ViewAction",
"target": "https://github.com/quicwg/base-drafts/issues/2267#issuecomment=
-451842773",
"url": "https://github.com/quicwg/base-drafts/issues/2267#issuecomment-45=
1842773",
"name": "View Issue"
},
"description": "View this Issue on GitHub",
"publisher": {
"@type": "Organization",
"name": "GitHub",
"url": "https://github.com"
}
}
]</script>=

----==_mimepart_5c32fcdee8abe_2b0d3fe214cd45c07812b7--