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

Kazuho Oku <> Wed, 05 February 2020 11:57 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 2142B1200B8 for <>; Wed, 5 Feb 2020 03:57:04 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -6.382
X-Spam-Status: No, score=-6.382 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_24=1.618, 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 1yGI51xvMMde for <>; Wed, 5 Feb 2020 03:57:02 -0800 (PST)
Received: from ( []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 65FD1120046 for <>; Wed, 5 Feb 2020 03:57:02 -0800 (PST)
Date: Wed, 05 Feb 2020 03:57:01 -0800
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=pf2014; t=1580903821; bh=huhxeeFY2uGU5w9rZAzBpyfZZ5KRtAIF29fjB5KZHWQ=; h=Date:From:Reply-To:To:Cc:In-Reply-To:References:Subject:List-ID: List-Archive:List-Post:List-Unsubscribe:From; b=Oy6/abmCI6dxjTOiLP/jXghRTwI4FsHaEOCK7DL8rjpuLXhUPc8jY4RycdRwTJ8M9 O0FTpQ15VhXpExMKeg6tLKv47ssOE+2EHd2OTJiR8wZuO8B588JVQjdPU8kJyBQDFl OWisU3egewW6T/AlzffZ6ofWm+pJ7a47ZTz5PCWU=
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_5e3aad8daacbc_1ae13fd37c4cd9681798a7"; 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, 05 Feb 2020 11:57:04 -0000

I think I'd prefer a design that meets the two requirements stated below:
* A server should not be required to withhold NCID frames until it receives an ACK for HANDSHAKE_DONE.
* A client should be allowed to use the original CID until the handshake is confirmed.

The intention is to minimize additional complexity to existing (and future) QUIC stacks.

One solution that meets these requirements is to state that a NCID frame confirms the handshake, exactly the same way as HANDSHAKE_DONE frame does. That would be a trivial change to any of the QUIC stacks, and there would be no ambiguity regarding the state changes.

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