Re: [quicwg/base-drafts] Idle timeout needs more description and a recommendation (#2602)

Jana Iyengar <notifications@github.com> Wed, 10 April 2019 01:04 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 CA7EA12036B for <quic-issues@ietfa.amsl.com>; Tue, 9 Apr 2019 18:04:37 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -8.002
X-Spam-Level:
X-Spam-Status: No, score=-8.002 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, RCVD_IN_MSPIKE_H2=-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 vns1S56nErDz for <quic-issues@ietfa.amsl.com>; Tue, 9 Apr 2019 18:04:36 -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 EF4FC1200E0 for <quic-issues@ietf.org>; Tue, 9 Apr 2019 18:04:35 -0700 (PDT)
Date: Tue, 09 Apr 2019 18:04:35 -0700
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=github.com; s=pf2014; t=1554858275; bh=2npncP0FTiN10eVQmRvTFaKs0U3yGo7WffznB+ZvLr0=; h=Date:From:Reply-To:To:Cc:In-Reply-To:References:Subject:List-ID: List-Archive:List-Post:List-Unsubscribe:From; b=s/qFvFkx3a7FK8ZEW0XPZV7iWcGKt/QTsxkTn6tB6ZUnKqncmP89zyyusu66+it0s sNk++g34LY9YHP1oAtD6HlQx0VUfupAZ+OzFm7C3bHbomSsA+xkBwuV9rN+Q5hMPk3 37NFRXkj774peFOTPHXyHjO2zmQZuDCauo7Z4LaQ=
From: Jana Iyengar <notifications@github.com>
Reply-To: quicwg/base-drafts <reply+0166e4abce38d01abc5db9b5a2ac4bdd65419ffb428fa42a92cebaba73a392a169ce19b4675e@reply.github.com>
To: quicwg/base-drafts <base-drafts@noreply.github.com>
Cc: Subscribed <subscribed@noreply.github.com>
Message-ID: <quicwg/base-drafts/issues/2602/481494142@github.com>
In-Reply-To: <quicwg/base-drafts/issues/2602@github.com>
References: <quicwg/base-drafts/issues/2602@github.com>
Subject: Re: [quicwg/base-drafts] Idle timeout needs more description and a recommendation (#2602)
Mime-Version: 1.0
Content-Type: multipart/alternative; boundary="--==_mimepart_5cad41231fe6e_194d3ff32ead45c438545"; charset=UTF-8
Content-Transfer-Encoding: 7bit
Precedence: list
X-GitHub-Sender: janaiyengar
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/PHV4MPgKEfB0bfKaFP7ONMLPAYI>
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: Wed, 10 Apr 2019 01:04:38 -0000

The recommendation is not for how long an endpoint is willing to wait, but a default recommendation for general purpose QUIC implementations. We have default recommendations in both the transport and the recovery draft based on best known practices. My suggestion for using 30 seconds as the default is based on GQUIC experience.

The min() thing is important IMO. Again, this is not a requirement, but keeping and trying a connection _after_ you believe the peer to have closed it potentially wastes an RTT.  HTTP connections using TCP do this all the time, and incur an RTT of delay. I'm not suggesting that we don't accommodate implementations that want to keep connections open for past the timeout period, but it's worth explicitly noting the cost of using a potentially dead connection. For an unconstrained implementation, what value do you see in continuing with a connection after it is likely to have been discarded by the peer?

Endpoints need to keep not only NAT bindings alive but also potentially QUIC state at the peer alive. If a server is taking time to generate a response and there is a risk of the idle timeout closing the connection  before the server sends a response. The application (HTTP) knows this, and is expected to send PINGs to keep the connection open, but without knowledge of the idle timeout at the peer, it has to guess how often to send a PING.

-- 
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/2602#issuecomment-481494142