Re: [quicwg/base-drafts] Does it make sense to try 0-RTT after Retry? (#2842)

Kazuho Oku <> Tue, 25 June 2019 02:30 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 4458E1200B4 for <>; Mon, 24 Jun 2019 19:30:43 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -6.596
X-Spam-Status: No, score=-6.596 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_28=1.404, 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 EOVLc3utxTTi for <>; Mon, 24 Jun 2019 19:30:41 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 246B3120161 for <>; Mon, 24 Jun 2019 19:30:41 -0700 (PDT)
Date: Mon, 24 Jun 2019 19:30:39 -0700
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=pf2014; t=1561429839; bh=vGLvgoVpmVqtLJllk3/7FuR//4jcnyucJlwrQ0CVKbY=; h=Date:From:Reply-To:To:Cc:In-Reply-To:References:Subject:List-ID: List-Archive:List-Post:List-Unsubscribe:From; b=UzlloAtdiuoa0uFXutjYCn9enE0EvVTEi/GnMoItm1HgGIcp44XMDvNEAqGkCUuTo Vp+dRkcXL5cor6QvR978SpyxZwkAdhQYB2vmmXzttOs6FatwbasjSnSwjO6Z0h4Ga/ 79lAQWbMRoue/3PQoWoh8idfeA+oxIsQ/Sao6VgE=
From: Kazuho Oku <>
Reply-To: quicwg/base-drafts <>
To: quicwg/base-drafts <>
Cc: Subscribed <>
Message-ID: <quicwg/base-drafts/issues/2842/>
In-Reply-To: <quicwg/base-drafts/issues/>
References: <quicwg/base-drafts/issues/>
Subject: Re: [quicwg/base-drafts] Does it make sense to try 0-RTT after Retry? (#2842)
Mime-Version: 1.0
Content-Type: multipart/alternative; boundary="--==_mimepart_5d11874f74502_30a63fdc14ecd9681407dd"; 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: Tue, 25 Jun 2019 02:30:43 -0000

Yeah, I can envision a server that considers buffering some number of packets to be cheaper than doing a TLS handshake. For such servers, delaying the TLS handshake until client proves it's existence but buffering the 0-RTT packets in the meantime would make sense.

That said,

> 1. A server that performs a Retry MUST discard 0-RTT packets.

I'd be fine with this, assuming that the discarded 0-RTT packets are the ones that carry the original DCID.

>  2. A client MUST NOT use 0-RTT after a Retry was performed.

I would prefer not having this requirement. Once the client is known to exist, a server needs to communicate with the client. Use of 0-RTT helps reduce the server load, because when used, average lifetime of connections becomes 1-RTT less. That leads us to having less concurrent connections.

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