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

Jana Iyengar <> Wed, 10 April 2019 20:50 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 6B0AF1205FF for <>; Wed, 10 Apr 2019 13:50:16 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -8.001
X-Spam-Status: No, score=-8.001 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_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (1024-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id nq-56pTtaOL4 for <>; Wed, 10 Apr 2019 13:50:15 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 23D41120114 for <>; Wed, 10 Apr 2019 13:50:15 -0700 (PDT)
Date: Wed, 10 Apr 2019 13:50:14 -0700
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=pf2014; t=1554929414; bh=c/9kKaVw+ccbpbIivdj4sQ1Hovqf5jsOgkzz4aEAroI=; h=Date:From:Reply-To:To:Cc:In-Reply-To:References:Subject:List-ID: List-Archive:List-Post:List-Unsubscribe:From; b=l0xcCPH7ALDlPs8jfyXn+uFX53qN8CRNYJslvB13CQr3xeye7IcPm+W5fkyMtRF9b PMXyC3EF1smAuv8fFrgwOq+bsQDfU9FcJdov4Xw78IfN8R0nOXFgVINo6COHl9cX4Y 8o3+1OjCab1Ll7yQUAuI9lzi/XqDyun8dXB0e4iw=
From: Jana Iyengar <>
Reply-To: quicwg/base-drafts <>
To: quicwg/base-drafts <>
Cc: Subscribed <>
Message-ID: <quicwg/base-drafts/issues/2602/>
In-Reply-To: <quicwg/base-drafts/issues/>
References: <quicwg/base-drafts/issues/>
Subject: Re: [quicwg/base-drafts] Idle timeout needs more description and a recommendation (#2602)
Mime-Version: 1.0
Content-Type: multipart/alternative; boundary="--==_mimepart_5cae57062a11_41003fdd548d45c04254ae"; 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
Archived-At: <>
X-Mailman-Version: 2.1.29
List-Id: Notification list for GitHub issues related to the QUIC WG <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Wed, 10 Apr 2019 20:50:16 -0000

I like @kazuho's formulation of the min(), but I don't think we need to state what the server or client _should_ do, rather we note the cost of using a dead connection. (I'm not opposed to saying that the endpoints _should not_ use potentially dead connections, but I don't think it's necessary.)

The discussion on PINGs is not about NATs, to be clear. The text we have right now on keeping connections alive with PINGs leaves it up to the application to decide when to send a PING. Without knowing when this connection might be closed by QUIC underneath due to an idle timeout, when should the application send a PING? 

I believe there's a problem here that QUIC "negotiates" its idle timeout with the peer (I know @martinthomson doesn't agree, but an endpoint does need to figure out how to use the peer's value), and HTTP is expected to keep the connection alive based on whether requests are pending or not, but we don't talk anywhere about the interaction between the two.

You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub: