Date: Mon, 09 Dec 2019 20:08:43 -0800
From: Martin Thomson <notifications@github.com>
Reply-To: quicwg/base-drafts
 <reply+AFTOJK4VHSWWM54MQGOTLDF37RGMXEVBNHHB7XUJLA@reply.github.com>
To: quicwg/base-drafts <base-drafts@noreply.github.com>
Cc: Subscribed <subscribed@noreply.github.com>
Message-ID: <quicwg/base-drafts/pull/3292/review/329579420@github.com>
In-Reply-To: <quicwg/base-drafts/pull/3292@github.com>
References: <quicwg/base-drafts/pull/3292@github.com>
Subject: Re: [quicwg/base-drafts] Curtail CONNECTION_CLOSE for small Initial
 (#3292)
Mime-Version: 1.0
Content-Type: multipart/alternative;
 boundary="--==_mimepart_5def1a4b8ecd1_1d8c3fcf1a0cd9641032f4";
 charset=UTF-8
Content-Transfer-Encoding: 7bit
Precedence: list
Archived-At: <https://mailarchive.ietf.org/arch/msg/quic-issues/l74LCx-a8aO2yOdfhykLRSNeXII>


----==_mimepart_5def1a4b8ecd1_1d8c3fcf1a0cd9641032f4
Content-Type: text/plain;
 charset=UTF-8
Content-Transfer-Encoding: 7bit

martinthomson commented on this pull request.



> @@ -3476,10 +3485,12 @@ Datagrams containing Initial packets MAY exceed 1200 bytes if the client
 believes that the Path Maximum Transmission Unit (PMTU) supports the size that
 it chooses.
 
-A server MAY send a CONNECTION_CLOSE frame with error code PROTOCOL_VIOLATION in
-response to an Initial packet it receives from a client if the UDP datagram is
-smaller than 1200 bytes. It MUST NOT send any other frame type in response, or
-otherwise behave as if any part of the offending packet was processed as valid.
+A server that has no existing state for a connection MUST discard an Initial
+packet that is carried in a UDP datagram that is smaller than 1200 bytes.  Other
+packets in the datagram SHOULD also be discarded.  A server MAY send a
+CONNECTION_CLOSE frame with error code PROTOCOL_VIOLATION in addition to
+discarding a packet if that does not affect a connection for which the server
+has established state; see {{immediate-close}}.

Let's see if I can keep this thread alive.  This is sending a packet with a CONNECTION_CLOSE, not an immediate close (I was under the impression that the shorthand was OK here, but it was clearly a mistake).  The goal is to use CONNECTION_CLOSE as a signal only, with the intent of triggering the corresponding logic at the client.  But the server is discarding this packet and so it won't have any connection state.  This won't result in creation or destruction of server state.

-- 
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/pull/3292#discussion_r355835905
----==_mimepart_5def1a4b8ecd1_1d8c3fcf1a0cd9641032f4
Content-Type: text/html;
 charset=UTF-8
Content-Transfer-Encoding: 7bit

<p><b>@martinthomson</b> commented on this pull request.</p>

<hr>

<p>In <a href="https://github.com/quicwg/base-drafts/pull/3292#discussion_r355835905">draft-ietf-quic-transport.md</a>:</p>
<pre style='color:#555'>&gt; @@ -3476,10 +3485,12 @@ Datagrams containing Initial packets MAY exceed 1200 bytes if the client
 believes that the Path Maximum Transmission Unit (PMTU) supports the size that
 it chooses.
 
-A server MAY send a CONNECTION_CLOSE frame with error code PROTOCOL_VIOLATION in
-response to an Initial packet it receives from a client if the UDP datagram is
-smaller than 1200 bytes. It MUST NOT send any other frame type in response, or
-otherwise behave as if any part of the offending packet was processed as valid.
+A server that has no existing state for a connection MUST discard an Initial
+packet that is carried in a UDP datagram that is smaller than 1200 bytes.  Other
+packets in the datagram SHOULD also be discarded.  A server MAY send a
+CONNECTION_CLOSE frame with error code PROTOCOL_VIOLATION in addition to
+discarding a packet if that does not affect a connection for which the server
+has established state; see {{immediate-close}}.
</pre>
<p>Let's see if I can keep this thread alive.  This is sending a packet with a CONNECTION_CLOSE, not an immediate close (I was under the impression that the shorthand was OK here, but it was clearly a mistake).  The goal is to use CONNECTION_CLOSE as a signal only, with the intent of triggering the corresponding logic at the client.  But the server is discarding this packet and so it won't have any connection state.  This won't result in creation or destruction of server state.</p>

<p style="font-size:small;-webkit-text-size-adjust:none;color:#666;">&mdash;<br />You are receiving this because you are subscribed to this thread.<br />Reply to this email directly, <a href="https://github.com/quicwg/base-drafts/pull/3292?email_source=notifications&amp;email_token=AFTOJKYFY5K755BKY6MIS5LQX4I4XA5CNFSM4JYC4LYKYY3PNVWWK3TUL52HS4DFWFIHK3DMKJSXC5LFON2FEZLWNFSXPKTDN5WW2ZLOORPWSZGOCOSPXHA#discussion_r355835905">view it on GitHub</a>, or <a href="https://github.com/notifications/unsubscribe-auth/AFTOJK6TOKN3FKHRB52OOF3QX4I4XANCNFSM4JYC4LYA">unsubscribe</a>.<img src="https://github.com/notifications/beacon/AFTOJK2TEDEZNMXCUHNNBZ3QX4I4XA5CNFSM4JYC4LYKYY3PNVWWK3TUL52HS4DFWFIHK3DMKJSXC5LFON2FEZLWNFSXPKTDN5WW2ZLOORPWSZGOCOSPXHA.gif" height="1" width="1" alt="" /></p>
<script type="application/ld+json">[
{
"@context": "http://schema.org",
"@type": "EmailMessage",
"potentialAction": {
"@type": "ViewAction",
"target": "https://github.com/quicwg/base-drafts/pull/3292?email_source=notifications\u0026email_token=AFTOJKYFY5K755BKY6MIS5LQX4I4XA5CNFSM4JYC4LYKYY3PNVWWK3TUL52HS4DFWFIHK3DMKJSXC5LFON2FEZLWNFSXPKTDN5WW2ZLOORPWSZGOCOSPXHA#discussion_r355835905",
"url": "https://github.com/quicwg/base-drafts/pull/3292?email_source=notifications\u0026email_token=AFTOJKYFY5K755BKY6MIS5LQX4I4XA5CNFSM4JYC4LYKYY3PNVWWK3TUL52HS4DFWFIHK3DMKJSXC5LFON2FEZLWNFSXPKTDN5WW2ZLOORPWSZGOCOSPXHA#discussion_r355835905",
"name": "View Pull Request"
},
"description": "View this Pull Request on GitHub",
"publisher": {
"@type": "Organization",
"name": "GitHub",
"url": "https://github.com"
}
}
]</script>
----==_mimepart_5def1a4b8ecd1_1d8c3fcf1a0cd9641032f4--