Re: [quicwg/base-drafts] TIMEOUT CONNECTION_CLOSE error (#3126)

Rui Paulo <> Mon, 21 October 2019 23:59 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 16B79120A79 for <>; Mon, 21 Oct 2019 16:59:51 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -6.454
X-Spam-Status: No, score=-6.454 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_IMAGE_ONLY_20=1.546, HTML_MESSAGE=0.001, MAILING_LIST_MULTI=-1, RCVD_IN_DNSWL_HI=-5, 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 IyRa-4XvSW_s for <>; Mon, 21 Oct 2019 16:59:49 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id BA448120A7E for <>; Mon, 21 Oct 2019 16:59:49 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id E52626A00F6 for <>; Mon, 21 Oct 2019 16:59:48 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=pf2014; t=1571702388; bh=32QpJqJrXMiLxWfXKb7HQ57WVagNgno2q52qfuoSkR0=; h=Date:From:Reply-To:To:Cc:In-Reply-To:References:Subject:List-ID: List-Archive:List-Post:List-Unsubscribe:From; b=pB667nQJTCcKdF1DafEem0I/jnk23pDFNGTtnKW07swEOR9jjfazdscjjge/oRoWW 0gNiwCa+11rUDxb0hfm3JKM5sADwsxmohzUQbcTPJNoW3cg6y9aprNlTy7DSDig3aF XrmdIgjp9cncZrj96M0y/EZ/qhJ8iHYCJwlcDCIk=
Date: Mon, 21 Oct 2019 16:59:48 -0700
From: Rui Paulo <>
Reply-To: quicwg/base-drafts <>
To: quicwg/base-drafts <>
Cc: Subscribed <>
Message-ID: <quicwg/base-drafts/issues/3126/>
In-Reply-To: <quicwg/base-drafts/issues/>
References: <quicwg/base-drafts/issues/>
Subject: Re: [quicwg/base-drafts] TIMEOUT CONNECTION_CLOSE error (#3126)
Mime-Version: 1.0
Content-Type: multipart/alternative; boundary="--==_mimepart_5dae4674d59a6_4c4d3ff303ecd96c22263"; charset="UTF-8"
Content-Transfer-Encoding: 7bit
Precedence: list
X-GitHub-Sender: rpaulo
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: Mon, 21 Oct 2019 23:59:51 -0000

I was thinking about the case where the idle timeout is long and a peer would be stuck retransmitting data until it hits the idle timeout.  Right now, it can send NO_ERROR, but it just seems like having a specific error code for timeouts would help.  I agree that there's no need to send anything after we reach the idle timeout.

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