Re: [quicwg/base-drafts] Silent close (#61)

Martin Thomson <notifications@github.com> Fri, 10 March 2017 03:52 UTC

Return-Path: <bounces+848413-a050-quic-issues=ietf.org@sgmail.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 492F8129519 for <quic-issues@ietfa.amsl.com>; Thu, 9 Mar 2017 19:52:39 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.002
X-Spam-Level:
X-Spam-Status: No, score=-2.002 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H2=-0.001, RP_MATCHES_RCVD=-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 mkBeH4VyIXc6 for <quic-issues@ietfa.amsl.com>; Thu, 9 Mar 2017 19:52:37 -0800 (PST)
Received: from o6.sgmail.github.com (o6.sgmail.github.com [192.254.113.101]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B1A5C12959D for <quic-issues@ietf.org>; Thu, 9 Mar 2017 19:52:37 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=github.com; h=from:reply-to:to:cc:in-reply-to:references:subject:mime-version:content-type:content-transfer-encoding:list-id:list-archive:list-post:list-unsubscribe; s=s20150108; bh=8s2DTOskHtjmMG4MYaH1KUHxmYc=; b=T6NYk8JcwgxZrSwl 9GXLfDstkIdP/EKIrNk2bKewDlNRfuf2s/9g9KH9bO1xfxQmHk5kSDuffOY1zkVv G7SIiDzZvxzkM1mHFIcQODab1CfImmK6ikOKkLFZj+GSdAfnZXaXe0NZivXQpYMD bApRCvxm6rJiBV5zpgAGxN3HXnI=
Received: by filter0947p1mdw1.sendgrid.net with SMTP id filter0947p1mdw1-20975-58C22305-6 2017-03-10 03:52:37.056527981 +0000 UTC
Received: from github-smtp2a-ext-cp1-prd.iad.github.net (github-smtp2a-ext-cp1-prd.iad.github.net [192.30.253.16]) by ismtpd0005p1iad1.sendgrid.net (SG) with ESMTP id S84s3W4pTeqZBGSuqP20Iw for <quic-issues@ietf.org>; Fri, 10 Mar 2017 03:52:36.956 +0000 (UTC)
Date: Thu, 09 Mar 2017 19:52:36 -0800
From: Martin Thomson <notifications@github.com>
To: quicwg/base-drafts <base-drafts@noreply.github.com>
Message-ID: <quicwg/base-drafts/issues/61/285566401@github.com>
In-Reply-To: <quicwg/base-drafts/issues/61@github.com>
References: <quicwg/base-drafts/issues/61@github.com>
Subject: Re: [quicwg/base-drafts] Silent close (#61)
Mime-Version: 1.0
Content-Type: multipart/alternative; boundary="--==_mimepart_58c22304d5d76_78a83f9bd48a9c38987c4"; 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
X-SG-EID: l64QuQ2uJCcEyUykJbxN122A6QRmEpucztpreh3Pak2I+vsMgO4ZgrGTkuCXlAmHytM8hWL6fXB0Zf QbcLXGagNDTvwH2v8FIigwV6eIvUZOblbg4ap1zEyDXAOTCSLN+2zU6SL4Q+t2f7W7OD5zHfY3cEDf QBrDC4wcwTTgBaNZpNE6ywNesUOfWuKX/r0PfpvpSsGCtHs3tolUsRp4lioigCPecS+bB9PAUV0a7d s=
Archived-At: <https://mailarchive.ietf.org/arch/msg/quic-issues/CbvfwIwgI6Ijit50O0JV7IHGDQM>
Cc: Subscribed <subscribed@noreply.github.com>
X-BeenThere: quic-issues@ietf.org
X-Mailman-Version: 2.1.17
Reply-To: quic@ietf.org
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: Fri, 10 Mar 2017 03:52:39 -0000

It's probably timely that we have the "how do you close a connection" discussion.

@janaiyengar and I were discussing one possibility.  In that model, the transport only has an explicit message for error-related closes.  The transport also has an idle timer that starts as soon as there are no open streams (note that this means nothing to send, nothing to receive).  The connection silently closes if that timer runs down without a new stream being opened.

The application protocol could define a message that could negotiate a graceful close to trigger this.  HTTP would need this, otherwise stream 3 would hold the connection open indefinitely.  To speed things up, the application protocol could force the timer to be shortened to basically FIN_WAIT2 (a couple of RTOs) by telling the transport that it was done.  (You need to wait around a little for retransmissions and reordering.)

-- 
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/61#issuecomment-285566401