Re: Testing the proposed PRs in a timely fashion

Martin Thomson <> Mon, 26 February 2018 22:57 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id A89D1124BE8 for <>; Mon, 26 Feb 2018 14:57:28 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.7
X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id qBYNOGfCGZSN for <>; Mon, 26 Feb 2018 14:57:26 -0800 (PST)
Received: from ( [IPv6:2607:f8b0:4003:c06::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id B4B12124B18 for <>; Mon, 26 Feb 2018 14:57:26 -0800 (PST)
Received: by with SMTP id u73so6960473oie.3 for <>; Mon, 26 Feb 2018 14:57:26 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=HaD+J7wc91abnhBC9wPbDFwZKatvmO/7PbU36LuynHc=; b=qyUlNL2wEGyimLlEr8X3zwsq41Vm+bonLTI1oPPZZnBNG/1nbXZDOF5YhHVfCZhQHq V4dhXAfHh5UvqVysOEx1JPQhFAXHS+amKZDBRvR2a2UZsapgZd1XYnMut38PqNQK2Lxo Cyorjiv698uYiaM4czatLsii6/KA8SU14Ikocz13bDJgmjd7Bnpqr4p6GN++eB6wX7tM 8ni3R97NdAvut0KfPmm5OyZE4/pqQcb7J43DExfh6CL+rRvm/gE8yrH7VDXEnlvYrW59 MrFkHCNJTO4Ox8e/fcshEAfBSNDJeHePL447j2uI9O9G4EGGseAyoRPr0ECY3T7duInn +dSA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=HaD+J7wc91abnhBC9wPbDFwZKatvmO/7PbU36LuynHc=; b=XPHMqd35DPf58ZL7RtoiSoBlA6bJRSGRT2noYH8OPApJE7AQadQdk/RPqsN8TRmew2 Hbo+2+lR6D7MgN/yJSZ4xJJxQn8sdQd5dKaTBYZmgyyN/6Z6pXCJVTPQet/CIKloL6FY NW1EcxE1Y7fajCupv8jvPuEXUQ840gPUzfALp57jGsCiU/2P4UqeKQaQMwXJSdswwWZJ JWBG7j80RDh5LAIf67WkN/tuKwCLYf2TEiQT53kToZsVI4pg1P2cGRSLM3JAuhJ0/ea2 JbLUcN9Xee7ACSkk8R88If1NwmkgIpyMPIgbiF2RJKRaQ8hG6CnGvbbChXeAwRJvmIe0 riJg==
X-Gm-Message-State: APf1xPDW9JXCKZYPp2DHQaEvYMhy3Zrb61c+CPWJE60xJ9RIoKk0ATIX al5X0qzrjQmZzA6D6/4/F1b12qVntgV75KKehcVPuw==
X-Google-Smtp-Source: AG47ELtF07cwLBzhEfjFl3Qx6pYuEJAOsptG/pB+W3naNQAn936agaviX0I+pBlZ4zlX7p8oeCVapEPL0wkHhkjyJ7Q=
X-Received: by with SMTP id i126mr7308147oib.295.1519685845686; Mon, 26 Feb 2018 14:57:25 -0800 (PST)
MIME-Version: 1.0
Received: by with HTTP; Mon, 26 Feb 2018 14:57:25 -0800 (PST)
In-Reply-To: <>
References: <>
From: Martin Thomson <>
Date: Tue, 27 Feb 2018 09:57:25 +1100
Message-ID: <>
Subject: Re: Testing the proposed PRs in a timely fashion
To: Christian Huitema <>
Cc: "" <>
Content-Type: text/plain; charset="UTF-8"
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 22:57:29 -0000

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.

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.

On Tue, Feb 27, 2018 at 6:19 AM, Christian Huitema <> wrote:
> There are a couple of PR in the queue that could bring big changes to
> transport implementations: the proposed changes in the Connection ID
> from 8 to 17 bytes; the proposed encryption of packet numbers; the
> extension mechanism; and the proposed redefinition of the migration
> mechanism. Such changes are very likely to require interop testing, both
> to verify that the specs work as proposed, and to find and correct
> implementation bugs. That will take time. I am also worried that if we
> check in all these PR at once, we will destabilize the implementations.
> My proposal is to pick some but not all of these PR and integrate them
> in the next iteration of the transport draft, so we can start interop
> testing. If I had to start somewhere, I would start with the path
> migration PR. It seems close to ready, it requires significant coding,
> and it replaces the PING/PONG mechanism that we would rather forget and
> not implement. Path migration also requires some testing infrastructure,
> such as opening multiple sockets on the client and migrating the
> connection from one to the other. Not hard to do, but requires some time
> to get it right, so the sooner we start the better.
> What do other developers think?
> -- Christian Huitema