Re: [quicwg/base-drafts] Idle timeout indicates you will timeout (#3099)

Mike Bishop <> Wed, 30 October 2019 20:20 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 02ED712008C for <>; Wed, 30 Oct 2019 13:20:47 -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, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, 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 51zTTqnfX0xN for <>; Wed, 30 Oct 2019 13:20:45 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 5C7A212011C for <>; Wed, 30 Oct 2019 13:20:45 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 9B872A121A for <>; Wed, 30 Oct 2019 13:20:44 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=pf2014; t=1572466844; bh=x5juIIAnYQoP1znxGDyMGNvUY5nR6zjjGG9ZKFNV56U=; h=Date:From:Reply-To:To:Cc:In-Reply-To:References:Subject:List-ID: List-Archive:List-Post:List-Unsubscribe:From; b=BF6rC9iiIzeNI84gapPwycZYODSvpJX8TMTWq6883w72WGvSaq7tjAMla0NkerGc/ vF/o/NqCMGbIHOgxys9CnYjF++/sudg7CZuOqdoea7M77elyRRdhrFOUNVYKkGXdpW zXlHmwFkCdlsuxGWpvD5ZMf0I9y32QTy/mCYcugE=
Date: Wed, 30 Oct 2019 13:20:44 -0700
From: Mike Bishop <>
Reply-To: quicwg/base-drafts <>
To: quicwg/base-drafts <>
Cc: Subscribed <>
Message-ID: <quicwg/base-drafts/pull/3099/review/>
In-Reply-To: <quicwg/base-drafts/pull/>
References: <quicwg/base-drafts/pull/>
Subject: Re: [quicwg/base-drafts] Idle timeout indicates you will timeout (#3099)
Mime-Version: 1.0
Content-Type: multipart/alternative; boundary="--==_mimepart_5db9f09c8ce0a_4f963feb9c4cd96c2955d8"; charset="UTF-8"
Content-Transfer-Encoding: 7bit
Precedence: list
X-GitHub-Sender: MikeBishop
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, 30 Oct 2019 20:20:47 -0000

MikeBishop approved this pull request.

> -draining state before the packets arrive.  If a peer could timeout within a
-Probe Timeout (PTO; see Section 6.3 of {{QUIC-RECOVERY}}), it is advisable to
-test for liveness before sending any data that cannot be retried safely.  Note
-that it is likely that only applications or application protocols will
-know what information can be retried.
+Each endpoint advertises a different max idle timeout, but the effective value
+is determined by taking the minimum of the two advertised values. By announcing
+a max idle timeout, endpoints commit to initiating an immediate close
+({{immediate-close}}) if it abandons a connection prior to the effective value.
+An endpoint restarts any timer it maintains when a packet from its peer is
+received and processed successfully.  The timer is also restarted when sending
+a packet containing frames other than ACK or PADDING (an ack-eliciting packet;
+see {{QUIC-RECOVERY}}), but only if no other ack-eliciting packets have been
+sent since last receiving a packet.  Restarting when sending packets ensures
+that connections do not prematurely time out when initiating new activity.

If you're going to explain why you restart when sending, you might need to explain why you _don't_ restart when sending subsequent packets.  Perhaps "when sending _one or more_ packets" might help point this explanation at bursts, rather than at individual packets?

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