Return-Path: X-Original-To: quic-issues@ietfa.amsl.com Delivered-To: quic-issues@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C763F120046 for ; Mon, 28 Oct 2019 21:12:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8 X-Spam-Level: X-Spam-Status: No, score=-8 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, MAILING_LIST_MULTI=-1, RCVD_IN_DNSWL_HI=-5, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=github.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id X__qPFbKPqlU for ; Mon, 28 Oct 2019 21:12:14 -0700 (PDT) Received: from out-5.smtp.github.com (out-5.smtp.github.com [192.30.252.196]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 839F712008C for ; Mon, 28 Oct 2019 21:12:14 -0700 (PDT) Received: from github-lowworker-f144ac1.va3-iad.github.net (github-lowworker-f144ac1.va3-iad.github.net [10.48.16.59]) by smtp.github.com (Postfix) with ESMTP id DF2D596068D for ; Mon, 28 Oct 2019 21:12:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=github.com; s=pf2014; t=1572322333; bh=tkzFlwh5rjfjOVinXA6Bv1UUl42YLc4S+QZc/3nnEHY=; h=Date:From:Reply-To:To:Cc:In-Reply-To:References:Subject:List-ID: List-Archive:List-Post:List-Unsubscribe:From; b=YyVEg8YKl/aKvUk7e/KzEsYoC022EZ9o8P8Gh7kHC6p4r6LxIgVfbpijAwXd0ipv+ Nk9g/hJsYCN2+lNwmi4PfHl20YY64ymVa1ZWLvjx7Ef7VOrtllAKEnAQnyIe8a+uOt xbVq0SX5WxZdaXT1GE8L7hU2nq35L3/NrRCrH2o8= Date: Mon, 28 Oct 2019 21:12:13 -0700 From: Martin Thomson Reply-To: quicwg/base-drafts To: quicwg/base-drafts Cc: Subscribed Message-ID: In-Reply-To: References: Subject: Re: [quicwg/base-drafts] Backoff on CONNECTION_CLOSE (#3157) Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="--==_mimepart_5db7bc1dd087a_58803fe616ecd95c1103c2"; charset=UTF-8 Content-Transfer-Encoding: 7bit Precedence: list X-GitHub-Sender: martinthomson X-GitHub-Recipient: quic-issues X-GitHub-Reason: subscribed X-Auto-Response-Suppress: All X-GitHub-Recipient-Address: quic-issues@ietf.org Archived-At: X-BeenThere: quic-issues@ietf.org X-Mailman-Version: 2.1.29 List-Id: Notification list for GitHub issues related to the QUIC WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Oct 2019 04:12:17 -0000 ----==_mimepart_5db7bc1dd087a_58803fe616ecd95c1103c2 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit martinthomson requested changes on this pull request. > @@ -2379,15 +2379,23 @@ terminate the connection immediately. A CONNECTION_CLOSE frame causes all streams to immediately become closed; open streams can be assumed to be implicitly reset. -After sending a CONNECTION_CLOSE frame, endpoints immediately enter the closing -state. During the closing period, an endpoint that sends a CONNECTION_CLOSE -frame SHOULD respond to any packet that it receives with another packet -containing a CONNECTION_CLOSE frame. To minimize the state that an endpoint -maintains for a closing connection, endpoints MAY send the exact same packet. -However, endpoints SHOULD limit the number of packets they generate containing a -CONNECTION_CLOSE frame. For instance, an endpoint could progressively increase -the number of packets that it receives before sending additional packets or -increase the time between packets. +After sending a CONNECTION_CLOSE frame, an endpoint immediately enters the +closing state. + +During the closing period, an endpoint that sends a CONNECTION_CLOSE frame +SHOULD respond to any incoming packet that can be decrypted with another packet The "that can be decrypted" is new. If you keep it, then it needs to be paired with something in the following paragraph that allows the endpoint to send the prebuilt packet in response to any received packet. > -However, endpoints SHOULD limit the number of packets they generate containing a -CONNECTION_CLOSE frame. For instance, an endpoint could progressively increase -the number of packets that it receives before sending additional packets or -increase the time between packets. +After sending a CONNECTION_CLOSE frame, an endpoint immediately enters the +closing state. + +During the closing period, an endpoint that sends a CONNECTION_CLOSE frame +SHOULD respond to any incoming packet that can be decrypted with another packet +containing a CONNECTION_CLOSE frame. Such an endpoint SHOULD limit the number +of packets it generates containing a CONNECTION_CLOSE frame. For instance, an +endpoint could progressively increase the number of packets that it receives +before sending additional packets or increase the time between packets. + +An endpoint is allowed to drop the packet protection keys when entering the +closing period ({{draining}}). However, an endpoint without the packet This probably blows the line length limit, but this is what I'm thinking. ```suggestion closing period ({{draining}}) and send a packet containing a CONNECTION_CLOSE in response to any UDP datagram that is received. However, an endpoint without the packet ``` -- 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/3157#pullrequestreview-308266995 ----==_mimepart_5db7bc1dd087a_58803fe616ecd95c1103c2 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

@martinthomson requested changes on this pull request.

=0D =0D
=0D =0D

In draft-ietf-quic-transport.md:

=0D 
> @@ -2379,15 +2379,23 @@ terminate the conn=
ection immediately.  A CONNECTION_CLOSE frame causes all=0D
 streams to immediately become closed; open streams can be assumed to be=0D=

 implicitly reset.=0D
 =0D
-After sending a CONNECTION_CLOSE frame, endpoints immediately enter the =
closing=0D
-state.  During the closing period, an endpoint that sends a CONNECTION_C=
LOSE=0D
-frame SHOULD respond to any packet that it receives with another packet=0D=

-containing a CONNECTION_CLOSE frame.  To minimize the state that an endp=
oint=0D
-maintains for a closing connection, endpoints MAY send the exact same pa=
cket.=0D
-However, endpoints SHOULD limit the number of packets they generate cont=
aining a=0D
-CONNECTION_CLOSE frame.  For instance, an endpoint could progressively i=
ncrease=0D
-the number of packets that it receives before sending additional packets=
 or=0D
-increase the time between packets.=0D
+After sending a CONNECTION_CLOSE frame, an endpoint immediately enters t=
he=0D
+closing state.=0D
+=0D
+During the closing period, an endpoint that sends a CONNECTION_CLOSE fra=
me=0D
+SHOULD respond to any incoming packet that can be decrypted with another=
 packet=0D
=0D

The "that can be decrypted" is new. If you keep it, then it needs to = be paired with something in the following paragraph that allows the endpo= int to send the prebuilt packet in response to any received packet.

=0D= =0D
=0D =0D

In draft-ietf-quic-transport.md:

=0D 
> -However, endpoints SHOULD limit the numbe=
r of packets they generate containing a=0D
-CONNECTION_CLOSE frame.  For instance, an endpoint could progressively i=
ncrease=0D
-the number of packets that it receives before sending additional packets=
 or=0D
-increase the time between packets.=0D
+After sending a CONNECTION_CLOSE frame, an endpoint immediately enters t=
he=0D
+closing state.=0D
+=0D
+During the closing period, an endpoint that sends a CONNECTION_CLOSE fra=
me=0D
+SHOULD respond to any incoming packet that can be decrypted with another=
 packet=0D
+containing a CONNECTION_CLOSE frame.  Such an endpoint SHOULD limit the =
number=0D
+of packets it generates containing a CONNECTION_CLOSE frame.  For instan=
ce, an=0D
+endpoint could progressively increase the number of packets that it rece=
ives=0D
+before sending additional packets or increase the time between packets.=0D=

+=0D
+An endpoint is allowed to drop the packet protection keys when entering =
the=0D
+closing period ({{draining}}).  However, an endpoint without the packet=0D=
=0D

This probably blows the line length limit, but this is what I'm thinki= ng.

=0D =E2=AC=87=EF=B8=8F Suggested change=0D 
-closing period ({{draining}}).  However, an e=
ndpoint without the packet=0D
+closing period ({{draining}}) and send a packet containing a CONNECTION_=
CLOSE in=0D
+response to any UDP datagram that is received.  However, an endpoint wit=
hout the packet=0D
=0D =0D =0D

&m= dash;
You are receiving this because you are subscribed to this thre= ad.
Reply to this email directly, view it on GitHub, or unsubscribe= .3D""<= /p>=0D = ----==_mimepart_5db7bc1dd087a_58803fe616ecd95c1103c2--