[quicwg/base-drafts] Connections SHOULD Respond to Connection Close Frames (#1029)
Nick Banks <notifications@github.com> Wed, 20 December 2017 16:33 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 DAB1F124B17 for <quic-issues@ietfa.amsl.com>; Wed, 20 Dec 2017 08:33:31 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.999
X-Spam-Level:
X-Spam-Status: No, score=-6.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_IMAGE_ONLY_32=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, 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 PtRJ059GxojJ for <quic-issues@ietfa.amsl.com>; Wed, 20 Dec 2017 08:33:30 -0800 (PST)
Received: from github-smtp2b-ext-cp1-prd.iad.github.net (github-smtp2-ext2.iad.github.net [192.30.252.193]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F29351200FC for <quic-issues@ietf.org>; Wed, 20 Dec 2017 08:33:29 -0800 (PST)
Date: Wed, 20 Dec 2017 08:33:29 -0800
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=github.com; s=pf2014; t=1513787609; bh=7684zMYMZFtKGjjWhkhyEeAqKbGdaR+fu02ahQeMoMg=; h=From:Reply-To:To:Cc:Subject:List-ID:List-Archive:List-Post: List-Unsubscribe:From; b=ueL+T5cQfkc6g8M4jMj8o4up12fy/pwm4ZyvSJSa4+63fWIPEgzkazV2xIK3Q0DbV t1Y5ISWwkJIqKCPPNcUvt5f7bX+S2t4RjkCOoAl22dFe0nt+MRSwoQvGZRDef1djYA QmHxBfbCRouKqihrazAvDfOy4rhUcLy4yjH1bOgw=
From: Nick Banks <notifications@github.com>
Reply-To: quicwg/base-drafts <reply+0166e4ab6e805c4745a7e519ce025a8d4a14818221e269ee92cf00000001165252d992a169ce10e7bb4d@reply.github.com>
To: quicwg/base-drafts <base-drafts@noreply.github.com>
Cc: Subscribed <subscribed@noreply.github.com>
Message-ID: <quicwg/base-drafts/issues/1029@github.com>
Subject: [quicwg/base-drafts] Connections SHOULD Respond to Connection Close Frames (#1029)
Mime-Version: 1.0
Content-Type: multipart/alternative; boundary="--==_mimepart_5a3a90d9b6fa_75d93fa0cce4af2843864"; charset="UTF-8"
Content-Transfer-Encoding: 7bit
Precedence: list
X-GitHub-Sender: nibanks
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/orI1LEWp51vjHqLVxIMMNP3LPvk>
X-BeenThere: quic-issues@ietf.org
X-Mailman-Version: 2.1.22
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: Wed, 20 Dec 2017 16:33:32 -0000
The spec currently says the following: > After receiving a closing frame, endpoints enter the draining state. An endpoint that receives a closing frame **MAY** send a single packet containing a closing frame before entering the draining state, using a CONNECTION_CLOSE frame and a NO_ERROR code if appropriate. An endpoint MUST NOT send further packets, which could result in a constant exchange of closing frames until the closing period on either peer ended. I'd like to make a case for changing that MAY to a SHOULD. If we are recommending that the sender of the initial CONNECTION_CLOSE wait the closing/draining period, why not recommend the receiver try to always respond to its frame with a CONNECTION_CLOSE of its own? Assuming it then obeys the rule about not sending any other packets, when (if) the initial closer receives the corresponding close frame, it now know that it shouldn't be receiving any other packets (other than possible reordered packets). In response to receiving the close response, the initial closer can then chose to either continue waiting the draining period to handle reordered packets or just immediately cleanup. -- 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/1029
- Re: [quicwg/base-drafts] Connections SHOULD Respo… Martin Thomson
- [quicwg/base-drafts] Connections SHOULD Respond t… Nick Banks
- Re: [quicwg/base-drafts] Connections SHOULD Respo… martinduke
- Re: [quicwg/base-drafts] Connections SHOULD Respo… Nick Banks
- Re: [quicwg/base-drafts] Connections SHOULD Respo… ianswett
- Re: [quicwg/base-drafts] Connections SHOULD Respo… Nick Banks
- Re: [quicwg/base-drafts] Connections SHOULD Respo… ianswett
- Re: [quicwg/base-drafts] Connections SHOULD Respo… Marten Seemann
- Re: [quicwg/base-drafts] Connections SHOULD Respo… ianswett
- Re: [quicwg/base-drafts] Connections SHOULD Respo… Nick Banks
- Re: [quicwg/base-drafts] Connections SHOULD Respo… ianswett
- Re: [quicwg/base-drafts] Connections SHOULD Respo… Nick Banks
- Re: [quicwg/base-drafts] Connections SHOULD Respo… ianswett
- Re: [quicwg/base-drafts] Connections SHOULD Respo… Martin Thomson
- Re: [quicwg/base-drafts] Connections SHOULD Respo… Martin Thomson