Re: Testing the proposed PRs in a timely fashion

Martin Thomson <martin.thomson@gmail.com> Mon, 26 February 2018 22:57 UTC

Return-Path: <martin.thomson@gmail.com>
X-Original-To: quic@ietfa.amsl.com
Delivered-To: quic@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A89D1124BE8 for <quic@ietfa.amsl.com>; Mon, 26 Feb 2018 14:57:28 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.7
X-Spam-Level:
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: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qBYNOGfCGZSN for <quic@ietfa.amsl.com>; Mon, 26 Feb 2018 14:57:26 -0800 (PST)
Received: from mail-oi0-x233.google.com (mail-oi0-x233.google.com [IPv6:2607:f8b0:4003:c06::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B4B12124B18 for <quic@ietf.org>; Mon, 26 Feb 2018 14:57:26 -0800 (PST)
Received: by mail-oi0-x233.google.com with SMTP id u73so6960473oie.3 for <quic@ietf.org>; Mon, 26 Feb 2018 14:57:26 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; 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; d=1e100.net; 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 10.202.84.132 with SMTP id i126mr7308147oib.295.1519685845686; Mon, 26 Feb 2018 14:57:25 -0800 (PST)
MIME-Version: 1.0
Received: by 10.157.16.85 with HTTP; Mon, 26 Feb 2018 14:57:25 -0800 (PST)
In-Reply-To: <a152835b-9309-ff10-cc97-0481cff2cb56@huitema.net>
References: <a152835b-9309-ff10-cc97-0481cff2cb56@huitema.net>
From: Martin Thomson <martin.thomson@gmail.com>
Date: Tue, 27 Feb 2018 09:57:25 +1100
Message-ID: <CABkgnnVpN+iWQbjNkswv40FvwHR14K_fSXioSAd=7Wtyd2T=SA@mail.gmail.com>
Subject: Re: Testing the proposed PRs in a timely fashion
To: Christian Huitema <huitema@huitema.net>
Cc: "quic@ietf.org" <quic@ietf.org>
Content-Type: text/plain; charset="UTF-8"
Archived-At: <https://mailarchive.ietf.org/arch/msg/quic/xTGTpaObXMss15CvyFCOcnlGLkI>
X-BeenThere: quic@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Main mailing list of the IETF QUIC working group <quic.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/quic>, <mailto:quic-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/quic/>
List-Post: <mailto:quic@ietf.org>
List-Help: <mailto:quic-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/quic>, <mailto:quic-request@ietf.org?subject=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 <huitema@huitema.net> 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
>
>