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

Tatsuhiro Tsujikawa <> Thu, 16 January 2020 11:49 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id B384112002E for <>; Thu, 16 Jan 2020 03:49:59 -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 cI31y6irD0IP for <>; Thu, 16 Jan 2020 03:49:53 -0800 (PST)
Received: from ( []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 16B9B12002F for <>; Thu, 16 Jan 2020 03:49:53 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id 16430520082 for <>; Thu, 16 Jan 2020 03:49:52 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=pf2014; t=1579175392; bh=VKWop0EgDwptKgog9EKX4/nntLmcz7KjxSIrH9/z34E=; h=Date:From:Reply-To:To:Cc:In-Reply-To:References:Subject:List-ID: List-Archive:List-Post:List-Unsubscribe:From; b=r5d2bj6wh56NKNoqREa6ufOkCRpNmDy8QSex3lV4Ty5xXdSrwW/XcJO8CJXIuQ3Xt jtg4+Dq0YaHa0fKWD5/GlTGoVlu4MC7Fgv4LuKvkvylE6dAAbVvfs83P6PpypMW4dg tmGI6zGtj/d8k3XIiB8Sdnm202R0q09X7NZn4DKg=
Date: Thu, 16 Jan 2020 03:49:52 -0800
From: Tatsuhiro Tsujikawa <>
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_5e204de04f44_4de13feb81ecd964146288"; charset=UTF-8
Content-Transfer-Encoding: 7bit
Precedence: list
X-GitHub-Sender: tatsuhiro-t
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 11:50:00 -0000

> Unless the QUIC stack allows bundling of two NCID frames when building a QUIC packet, the client might end up not having sufficient amount of CIDs, in which case it might terminate the connection.

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

Now my preference is (a).  If server utilizes retire-prior-to, it should know the consequences and should provide sufficient backup connection IDs.  Otherwise, it would be misconfiguration of server software.

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