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

Martin Thomson <> Thu, 16 January 2020 03:31 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 6F168120058 for <>; Wed, 15 Jan 2020 19:31: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 i5x7rS4l94La for <>; Wed, 15 Jan 2020 19:31: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 9F2DE12002F for <>; Wed, 15 Jan 2020 19:31:31 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id C9B111C2F6D for <>; Wed, 15 Jan 2020 19:31:30 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=pf2014; t=1579145490; bh=qiXHjUqsG/u0636Ss29S2+T9mj6SpyTBWPZrm4JKr+M=; h=Date:From:Reply-To:To:Cc:In-Reply-To:References:Subject:List-ID: List-Archive:List-Post:List-Unsubscribe:From; b=mJQk35hZTA9VQoHRYIvV5gGWcuLN24JgBAM4kw1vJ+321TwU2zcRb31FVluyv/8Nv Feo/cngcQ+LpJBaRhrceJXztqTY1FZDm3J+fB9sn6SLbgAz6VPrvAqH7OOzw0IyOY4 yyKfHCBumtR/lEVcxqyoLEkikKiZX69w59lLkqMk=
Date: Wed, 15 Jan 2020 19:31:30 -0800
From: Martin Thomson <>
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_5e1fd912ba602_39143f9d050cd96050822"; charset=UTF-8
Content-Transfer-Encoding: 7bit
Precedence: list
X-GitHub-Sender: martinthomson
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 03:31:33 -0000

Artificial constraints on when the frame can be sent would be terrible to enforce and would introduce a performance cost for using NEW_CONNECTION_ID.  In a great many cases, the 0.5RTT from the server is idle, which makes it a great way to get things like NEW_CONNECTION_ID sent without taking capacity from real work.  Asking the server to defer sending would mean that NEW_CONNECTION_ID could compete with HTTP responses and the like.

I see no reason not to allow use of connection IDs when they are available.  They apply to the connection as a whole.  You will note that we allow changing them with the Initial/Retry mini-protocol in ways that don't correlate with other connection-level events, so this isn't any different in that regard.  Forcing the connection ID state to synchronize with other state changes seems more likely to complicate things than help.

The caution @kazuho mentions is always true.  Whenever an endpoint is forced to retire connection IDs, a short supply is always a risk to the connection.

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