Re: [quicwg/base-drafts] Which DCID do Handshake retransmissions use? (#3348)

Kazuho Oku <> Wed, 15 January 2020 04:45 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 74F80120128 for <>; Tue, 14 Jan 2020 20:45:33 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -7.999
X-Spam-Status: No, score=-7.999 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] 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 173Ivt2A10uW for <>; Tue, 14 Jan 2020 20:45:31 -0800 (PST)
Received: from ( []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 58CCD12006B for <>; Tue, 14 Jan 2020 20:45:31 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id 31C3B5206CA for <>; Tue, 14 Jan 2020 20:45:23 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=pf2014; t=1579063523; bh=6KfEvb13CEYkYcYW+O3dV8UkGARXta3Zv0jR2+MJFrA=; h=Date:From:Reply-To:To:Cc:In-Reply-To:References:Subject:List-ID: List-Archive:List-Post:List-Unsubscribe:From; b=Si4+NGk8r5T+6Rs35dlnaL52AVVYv2B3ANOcyxU02V8cm1u8WR57tY5xCEdGDfSqt WEuIac5qKLU5vgpvjgEBGWj9OinZshbtSLgD5CUikjoOiv36VvQAHFkO/PbTgXj2+3 Lj0PMwQ+/wKa4ENBfFlEJSHQkYvFViuMSS0Q2fMc=
Date: Tue, 14 Jan 2020 20:45:23 -0800
From: Kazuho Oku <>
Reply-To: quicwg/base-drafts <>
To: quicwg/base-drafts <>
Cc: Subscribed <>
Message-ID: <quicwg/base-drafts/issues/3348/>
In-Reply-To: <quicwg/base-drafts/issues/>
References: <quicwg/base-drafts/issues/>
Subject: Re: [quicwg/base-drafts] Which DCID do Handshake retransmissions use? (#3348)
Mime-Version: 1.0
Content-Type: multipart/alternative; boundary="--==_mimepart_5e1e98e32269a_78b03fe3248cd95c26917c"; 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: Wed, 15 Jan 2020 04:45:33 -0000

As I can see, there are three options:
* a) let the receiver of NCID to send Handshake packets using the new CIDs
* b) require (or recommend) receiver of NCID to continue using the original DCID until the handshake is confirmed
* c) require (or recommend) the sender to withhold the emission NCID (with a non-zero RTP) to until it sees an ACK for handshake confirmation

I prefer requiring (c) (or maybe (b)), because (a) has corner cases even though it might seem easy.

Consider the case where a server sends TP.preferred_address then as the first packet, sends the NCID frame with RTP set to 2. If we adopt (a), this would mean that the client would have only one CID that it can use (the one being embedded in the NCID frame) even though it needs two (one for the original path, and another for the path specified by TP.preferred_address).

As you can see, the design of the NCID has been based on the assumption that providing one new CID alongside a retirement request guarantees that the receiver would have enough active CIDs. But in this particular case, that is not the case.

Based on this observation, and based on my assumption that a non-zero RTP would be sent by only some of the endpoints (the necessity of CID retirement is questionable for HTTP/3, the scope of QUIC v1, as the HTTP connections can be short-lived and most likely be gracefully terminated to induce a new connection), my preference goes to (c): a server that uses RTP should cover the cost.

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