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

Mike Bishop <> Tue, 25 June 2019 18:19 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id A008F120320 for <>; Tue, 25 Jun 2019 11:19:56 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -7.998
X-Spam-Status: No, score=-7.998 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_32=0.001, HTML_MESSAGE=0.001, MAILING_LIST_MULTI=-1, RCVD_IN_DNSWL_HI=-5, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=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 eE4QMciJHXob for <>; Tue, 25 Jun 2019 11:19:55 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 241501200E9 for <>; Tue, 25 Jun 2019 11:19:55 -0700 (PDT)
Date: Tue, 25 Jun 2019 11:19:54 -0700
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=pf2014; t=1561486794; bh=nOe8R6sHI1VBynLkpVz5p+/5XC91b7/JsvwLu/zlPeE=; h=Date:From:Reply-To:To:Cc:In-Reply-To:References:Subject:List-ID: List-Archive:List-Post:List-Unsubscribe:From; b=M7P0LxIiiauSREdOAoRzi85tZVQYXidWqDlKkJdJqsY2pXEyuNdFpRbW+/3JcfowK /AthI/b40vTYnMab2KppJMNGeGz0xAwaIVKFC75jOkYAHv1Trrbj5FvQFp/tuvA/kR 3sgGF25TeIdDC2wERGjCS9dTytC4eTWMjukOXpjE=
From: Mike Bishop <>
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_5d1265ca9e70_40533fc756ecd9683433e1"; 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: Tue, 25 Jun 2019 18:19:57 -0000

This also bears on #2837.  If the DCID doesn't change, then the server won't be able to differentiate the first flight of 0-RTT packets, which you're proposing to drop, from the second flight of 0-RTT packets which it accepts.

The current text says that the server MAY buffer and process them later; you're saying that servers probably won't.  I think that's fine, but some might -- hence, I favor @kazuho's suggestion to retain the permission to buffer but the caution to the client that the packets were quite possibly lost/dropped.  In terms of actual spec change, I think that means this text in [17.2.3](

> After a client receives a Retry packet, 0-RTT packets are likely to have been lost or discarded by the server. A client MAY attempt to resend data in 0-RTT packets after it sends a new Initial packet.

...becomes a SHOULD instead of a MAY.

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