Re: Testing the proposed PRs in a timely fashion

Christian Huitema <> Mon, 26 February 2018 23:52 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id BD019124235 for <>; Mon, 26 Feb 2018 15:52:22 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.601
X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 34F8bRHc2ocs for <>; Mon, 26 Feb 2018 15:52:21 -0800 (PST)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 515481201F8 for <>; Mon, 26 Feb 2018 15:52:17 -0800 (PST)
Received: from ([]) by with esmtps (TLSv1:AES256-SHA:256) (Exim 4.89) (envelope-from <>) id 1eqSYg-0007eW-Q1 for; Tue, 27 Feb 2018 00:51:52 +0100
Received: from [] ( by with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.63) (envelope-from <>) id 1eqSY9-0004RW-V8 for; Mon, 26 Feb 2018 18:51:48 -0500
Received: (qmail 15892 invoked from network); 26 Feb 2018 23:50:57 -0000
Received: from unknown (HELO []) ([]) (envelope-sender <>) by (qmail-ldap-1.03) with ESMTPA for <>; 26 Feb 2018 23:50:56 -0000
To: Martin Thomson <>
Cc: "" <>
References: <> <>
From: Christian Huitema <>
Message-ID: <>
Date: Mon, 26 Feb 2018 15:50:52 -0800
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.6.0
MIME-Version: 1.0
In-Reply-To: <>
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
Content-Language: en-US
Subject: Re: Testing the proposed PRs in a timely fashion
Authentication-Results:; auth=pass smtp.auth=
X-AntiSpamCloud-Outgoing-Class: unsure
X-AntiSpamCloud-Outgoing-Evidence: Combined (0.40)
X-Recommended-Action: accept
X-Filter-ID: EX5BVjFpneJeBchSMxfU5ifFSE0NBluyKg/MqXHP++l602E9L7XzfQH6nu9C/Fh9KJzpNe6xgvOx q3u0UDjvO37pNwwF1lRXh5rzvPzo9Jts1ujulqUFmMITHM77eiVidNkAw/hfnCrJncrgZuEEr87i TvJ2/ZGzVWB9scFAaCdIFaUvXN+CI+RGy3Me16pBiuj1YIZWyGteeTEbAD/lb/vRa7MR4hgRIg8N 1QlY4G7x1YBTEs55LirRLgpsvCFtid7SQi4NE/job5y2wAN3GZxznd8NXwc/vKJtfZaXo5QAJAfA 9MMVcQ9WVjD1q+Rbd9IPG/DQ2p+GU04sTuYFs91jhnM/Mbva2XLV/LIEzaKyLm0zESXAkIAT8ZKA DvsGI5uh86ZVnyOrYkLMWyEaRt9fxN2oReTDHAyOynaY0ClKHhIXfDbmhz3DoftFSAfVIRFsicyJ MEhQFtD8PLoiniWmsFByBoXAuCZEyg59LM81CaOu2xwDQxDsUgSvK+nII1IRruUYLOgUnyoTu5lV X1MKVprlQYwN+KHznEQNFP3OZTvgiCjhIZF4Y76uWrdlx3STuqJ0TIH+SWjiF9Q0pQfG/OGabeQO D+JyvmSUpW+ZQTl/k5oRlt1ErWfaEWxe22o4BNBy+bVfxj88zI41K1O7B0jvACHkMSS0WCQUO4D1 rYsclUPWfsYbR8/iz5oiSGG/BQd7r2NVEaNhWos5pl2H4dyBB98UmiRmBFCitykccBIk1Sag4dKi qCrF8eZZeNMTAWyxeqt3BjCO03tBtixP5LFurlz8Yikuq9Id3lmBi6owqeb+h1kbxIVWYdC7ygC2 BNoAMaYuKRPezBphPleqv/VOJZnHunWcIBzbsDrLaeA4pl20N4bgeYf9w8whIRFsicyJMEhQFtD8 PLoinpgjWjpMfsxmWdg884icSQEZwRvSfvkJh2VafuDhMcA1uHlEIbR8fMtAowK0FL525g==
Archived-At: <>
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Main mailing list of the IETF QUIC working group <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Mon, 26 Feb 2018 23:52:23 -0000

On 2/26/2018 2:57 PM, Martin Thomson wrote:

> The 17-byte thing seems unlikely to be adopted.  Based on the outcome
> of the design team discussion, a double connection ID mechanism is
> more likely.

Yes. But then moving to double connection ID of variable length is also
going to require serious development and testing effort. To evaluate
that, I changed the "connection_id" type in Picoquic from uint64_t to an
opaque type. This was not simple, since the connection ID is used pretty
much every where, not just in protocol code but also in logging code,
test code, and of course test vectors. And doing that caused a couple
regression bugs, which I only found weeks later. Of course I am sure
that other developers can do it better, but still, they will need time
to work it out.  If we want to be done in November, we may want to test
that kind of stuff sooner rather than later.
> As for merging, I think that we are close to merging the migration PR.
> It's mostly editorial issues that are holding it back now.

Cool. Do you think we could have that spec merged before the London
meeting? Or should we start preparing for interop days in April and May?

-- Christian Huitema