Re: [quicwg/base-drafts] Backoff on CONNECTION_CLOSE (#3157)

Martin Thomson <notifications@github.com> Tue, 29 October 2019 04:12 UTC

Return-Path: <noreply@github.com>
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 <quic-issues@ietfa.amsl.com>; 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 <quic-issues@ietfa.amsl.com>; 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 <quic-issues@ietf.org>; 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 <quic-issues@ietf.org>; 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 <notifications@github.com>
Reply-To: quicwg/base-drafts <reply+AFTOJK5UWMAHEFD7A7X2ALF3YTXJ3EVBNHHB5FPVAE@reply.github.com>
To: quicwg/base-drafts <base-drafts@noreply.github.com>
Cc: Subscribed <subscribed@noreply.github.com>
Message-ID: <quicwg/base-drafts/pull/3157/review/308266995@github.com>
In-Reply-To: <quicwg/base-drafts/pull/3157@github.com>
References: <quicwg/base-drafts/pull/3157@github.com>
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: <https://mailarchive.ietf.org/arch/msg/quic-issues/ZIbRUcVU_LrGwRzINlHLZoQS7jE>
X-BeenThere: quic-issues@ietf.org
X-Mailman-Version: 2.1.29
List-Id: Notification list for GitHub issues related to the QUIC WG <quic-issues.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/quic-issues>, <mailto:quic-issues-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/quic-issues/>
List-Post: <mailto:quic-issues@ietf.org>
List-Help: <mailto:quic-issues-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/quic-issues>, <mailto:quic-issues-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 29 Oct 2019 04:12:17 -0000

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