IETF Logo Mail Archive

Re: [quicwg/base-drafts] Refactor the section on connection termination (#721)

Martin Thomson <notifications@github.com> Thu, 24 August 2017 22:30 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 790EA132803 for <quic-issues@ietfa.amsl.com>; Thu, 24 Aug 2017 15:30:24 -0700 (PDT)
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 PUluOrTbs8W1 for <quic-issues@ietfa.amsl.com>; Thu, 24 Aug 2017 15:30:23 -0700 (PDT)
Received: from github-smtp2a-ext-cp1-prd.iad.github.net (github-smtp2-ext1.iad.github.net [192.30.252.192]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D3754132719 for <quic-issues@ietf.org>; Thu, 24 Aug 2017 15:30:22 -0700 (PDT)
Date: Thu, 24 Aug 2017 15:30:22 -0700
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=github.com; s=pf2014; t=1503613822; bh=S4BpsGb6S/mUcEi7MkcmrIGeVr/HWnvI3hceYaPlW38=; h=From:Reply-To:To:Cc:In-Reply-To:References:Subject:List-ID: List-Archive:List-Post:List-Unsubscribe:From; b=UGqQFUWI5Ljq03cjm0POI6c2kiPs9wtWw9QLdGK4x1sABSPzYX4qit3OXsBF2pzfJ G7TouYt2W6UuCqhL78i/RqTqkh2wjDITe8X5nm0llnQ0r7ao1/9RfCEzNRV3P+f3F+ +QtfwcUpV3Jcs0al7MNZfKggSrStjSl+Ed+3n1Ug=
From: Martin Thomson <notifications@github.com>
Reply-To: quicwg/base-drafts <reply+0166e4ab8a53e9fab68bfc0ca2a529278084334b66e3a3ea92cf0000000115b7157e92a169ce0edf94fd@reply.github.com>
To: quicwg/base-drafts <base-drafts@noreply.github.com>
Cc: Subscribed <subscribed@noreply.github.com>
Message-ID: <quicwg/base-drafts/pull/721/c324774857@github.com>
In-Reply-To: <quicwg/base-drafts/pull/721@github.com>
References: <quicwg/base-drafts/pull/721@github.com>
Subject: Re: [quicwg/base-drafts] Refactor the section on connection termination (#721)
Mime-Version: 1.0
Content-Type: multipart/alternative; boundary="--==_mimepart_599f537e6664_1e53f3f8f6b64dc349836c"; 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/MCChfeRklV01nKoapn9qPNtViDQ>
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: Thu, 24 Aug 2017 22:30:24 -0000

If an endpoint receives an ACK for a CONNECTION_CLOSE, it still needs to handle more packets (it remains in its draining period) because of the chance that packets sent before the ACK are still in transit.  Thus, the shortcut isn't really that useful here.  Obviously the endpoint that acknowledges the CONNECTION_CLOSE won't send any more packets, but if its own packets are still in flight, then it might get a few more CONNECTION_CLOSE frames (as a result of packets sent before it acknowledged the CONNECTION_CLOSE). 

The only real trimming we might do is to have the endpoint that sends the CONNECTION_CLOSE stop sending more CONNECTION_CLOSE frames in response to receiving more packets.

-- 
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/721#issuecomment-324774857

v2.39.1 | Report a Bug | By Email | System Status