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

Kazuho Oku <> Thu, 16 January 2020 13:57 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 1F544120045 for <>; Thu, 16 Jan 2020 05:57:20 -0800 (PST)
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 wglGOn7e171j for <>; Thu, 16 Jan 2020 05:57:18 -0800 (PST)
Received: from ( []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 9DED4120026 for <>; Thu, 16 Jan 2020 05:57:18 -0800 (PST)
Date: Thu, 16 Jan 2020 05:57:17 -0800
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=pf2014; t=1579183037; bh=zvNywx9sRHUq67Dxi33e/vmAQz8RnHoTqp6yepDZVQY=; h=Date:From:Reply-To:To:Cc:In-Reply-To:References:Subject:List-ID: List-Archive:List-Post:List-Unsubscribe:From; b=l5i1hX53buvFKWQRSqOplVW4kfvNJh/2hKK4KdNj9I9KbJytz2FQo9IViiFbwWU+Y N+yxd0+4MzjB90TQKtGTwO/k5JLo5QZj7vF0GgBcClMGwMGGYUAhpwz1zQM+u4AYLo zdzaWe3SpL0KbB84LIE0o00yBuYSui18JLJLtqYA=
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_5e206bbdbb903_2e0a3fbbcdecd95c17959f"; 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: Thu, 16 Jan 2020 13:57:20 -0000

> I think QUIC allows more than 1 NCID frames in a single QUIC packet.

The problem is that the client might end up receiving only some of the NCID frames, unless the server always sends (and retransmits) the set of NCID frames as a whole.

But anyways, I agree that (a) is probably fine.

That is because it is trivial to design a server that never requests CID retirement during the handshake. All you need to do is start issuing the new generation of CIDs at least _N_ seconds before sending NCID frames that asks for the retirement of the previous generation, where _N_ is your handshake timeout.

Knowing that this design is why I initially preferred (c), not realizing that it works equally well with (a). But know that I understand that, I prefer (a) as it is simpler.

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