Re: [quicwg/base-drafts] How to reject a connection attempt (#3690)

Kazuho Oku <> Sun, 24 May 2020 12:50 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id CFA253A0B2A for <>; Sun, 24 May 2020 05:50:55 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.483
X-Spam-Status: No, score=-1.483 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, DKIM_VALID_EF=-0.1, HTML_IMAGE_ONLY_24=1.618, HTML_MESSAGE=0.001, MAILING_LIST_MULTI=-1, 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 5F5LoO1WWUB4 for <>; Sun, 24 May 2020 05:50:54 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 77ACE3A0B29 for <>; Sun, 24 May 2020 05:50:54 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 5CD0E2612B1 for <>; Sun, 24 May 2020 05:50:53 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=pf2014; t=1590324653; bh=gs9HMPXi6IbKXwbwWxSZvHrG5p/3Q/D1cpCeG8yDtJI=; h=Date:From:Reply-To:To:Cc:In-Reply-To:References:Subject:List-ID: List-Archive:List-Post:List-Unsubscribe:From; b=Nq0BJ4AKruFahQZWQwOVNqFIvMreLRZg574eP5GscxCEff+CxOCxUwH7XA2684rpy WhB7u7SkT2uElkjg0hxGCGsQMKc6ZSAi/IyPVkh++MRi+DsLJNeRl/Rr6fq2TSktb9 PebMmEkutOKNLLt2hwoimvZxkqcKhgvy/yrw7mwM=
Date: Sun, 24 May 2020 05:50:53 -0700
From: Kazuho Oku <>
Reply-To: quicwg/base-drafts <>
To: quicwg/base-drafts <>
Cc: Subscribed <>
Message-ID: <quicwg/base-drafts/issues/3690/>
In-Reply-To: <quicwg/base-drafts/issues/>
References: <quicwg/base-drafts/issues/>
Subject: Re: [quicwg/base-drafts] How to reject a connection attempt (#3690)
Mime-Version: 1.0
Content-Type: multipart/alternative; boundary="--==_mimepart_5eca6dad16b5a_584b3fef0aacd968359221"; charset="UTF-8"
Content-Transfer-Encoding: 7bit
Precedence: list
X-GitHub-Sender: kazuho
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: Sun, 24 May 2020 12:50:56 -0000

> HTTP has 503 to reject request when a server is busy, and still we have SERVER_BUSY at the QUIC layer. There's a value in rejecting connection attempts before spending resources (and round trips) on a handshake.

Yes, TCP or TLS can reject one attempt. QUIC is currently aligned to that, and that's fine.

> Furthermore, there are other application protocols than HTTP. In my use case, nodes in a p2p network want to enforce a local blacklist of IP addresses. In TCP, they can easily do that by resetting the connection, and before spending any resources on the TLS handshake. Having to go through the whole QUIC handshake with a blacklisted peer before being able to reject them would be a serious regression compared to TCP.

I'd point out that how aggressively browsers try connecting in QUIC depends on if they do happy-eyeballing. When browsers do happy-eyeballing, no matter how less you do in QUIC, the probability of establishing a connection always stays higher (or as high as) just doing TLS.

The question is when browsers start doing just QUIC. Would they prefer to cache previous connection failures, as a way to not even try to reconnect when a user requests doing so?

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