Re: [tsvwg] Requesting TSVWG adoption of SCE draft-morton-tsvwg-sce

Kyle Rose <krose@krose.org> Mon, 18 November 2019 03:32 UTC

Return-Path: <krose@krose.org>
X-Original-To: tsvwg@ietfa.amsl.com
Delivered-To: tsvwg@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2747A12008A for <tsvwg@ietfa.amsl.com>; Sun, 17 Nov 2019 19:32:08 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level:
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=krose.org
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 XyhbGLX5RBYk for <tsvwg@ietfa.amsl.com>; Sun, 17 Nov 2019 19:32:06 -0800 (PST)
Received: from mail-yb1-xb29.google.com (mail-yb1-xb29.google.com [IPv6:2607:f8b0:4864:20::b29]) (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 EEF6112004C for <tsvwg@ietf.org>; Sun, 17 Nov 2019 19:32:05 -0800 (PST)
Received: by mail-yb1-xb29.google.com with SMTP id k206so6630211ybb.5 for <tsvwg@ietf.org>; Sun, 17 Nov 2019 19:32:05 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=krose.org; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=DYidI/r405KZk1+jQxeebUSf91oDCaheWR/vIXEYH1I=; b=UM9VP5tY6PLiNme83ahC21m56qHmLtBhVOuOpGrsqIxMqFJ+QjeQZ7ilZHe3H6rchK XfsmxR0GaePLrOFcRt2an3f1ZEyXRhKpWHezje4JHsNFhVEjQqDDrpP98HdZbEZ/E1zk 0rNZcixUVVLvVldEsj0No6RvVY6ZJvmtlXHHc=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=DYidI/r405KZk1+jQxeebUSf91oDCaheWR/vIXEYH1I=; b=bCnYmkoOdI3vsL9944wyQTI3pt266a673Ov5lx2ZJtOiI0+oHCQJyY07E2k88YaI6C IX1+WEqbpql2OlveIAmVt9EeJnmp76KNr7oyM5rLjMVDxYrxsBLYKzx+oDiA5bJQzUCc 6Fcd2+ROvrY2QqqukLPYG29k4ZX/poCua5zT2aVUafsGnsuByaVVK3e4Hfajbt7rzHQR KoYtHNmulN7S2BP3gQnZEzM/LJBv8ed9NtqBlj4nK5y+o+iuVvofD+uG13E3tYQAEifk LKv8q6zb+d0mdbC5fOJtk+kcXLZxLESHGpHDToD4Zb8LwS0HvTAVp5uI91tCInE2PxSS 2ydA==
X-Gm-Message-State: APjAAAWRwzVMHvG943uxnjXWFyX1+zSs1Un3IXgq8nRsJWyT1H73i+d5 Rwf/bSGLxjkWJvRmzp4yvRsypS8Zb3YOFuQKuWaqgw==
X-Google-Smtp-Source: APXvYqy3PWNZvEo1ttWy8GE+/85S5LIVJ1AnCoT68kVn5cgV9+m8i4UPfhsjmTrEQ/VzbnL5lOSHDScPBMUvMaicMWU=
X-Received: by 2002:a25:b993:: with SMTP id r19mr2883699ybg.82.1574047924775; Sun, 17 Nov 2019 19:32:04 -0800 (PST)
MIME-Version: 1.0
References: <201911141350.xAEDo99J048928@gndrsh.dnsmgr.net> <39d0435d-e22b-7b4b-bba7-3988a67aba76@bobbriscoe.net> <6E58094ECC8D8344914996DAD28F1CCD23DC49BC@dggemm526-mbx.china.huawei.com> <MN2PR19MB4045BE3FD897412DA03D2396834D0@MN2PR19MB4045.namprd19.prod.outlook.com> <5DD209FC.2060104@erg.abdn.ac.uk>
In-Reply-To: <5DD209FC.2060104@erg.abdn.ac.uk>
From: Kyle Rose <krose@krose.org>
Date: Mon, 18 Nov 2019 11:31:53 +0800
Message-ID: <CAJU8_nU4am5dq_KgfAC1fyVKTipLjDfS3HAspgF+NXCAkjvjGA@mail.gmail.com>
To: G Fairhurst <gorry@erg.abdn.ac.uk>
Cc: tsvwg IETF list <tsvwg@ietf.org>, tsvwg chair <tsvwg-chairs@tools.ietf.org>
Content-Type: multipart/alternative; boundary="0000000000006a842b0597969729"
Archived-At: <https://mailarchive.ietf.org/arch/msg/tsvwg/w7o1ei1YPsFwm4tWQnCyyV_X9N0>
Subject: Re: [tsvwg] Requesting TSVWG adoption of SCE draft-morton-tsvwg-sce
X-BeenThere: tsvwg@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Transport Area Working Group <tsvwg.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tsvwg>, <mailto:tsvwg-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/tsvwg/>
List-Post: <mailto:tsvwg@ietf.org>
List-Help: <mailto:tsvwg-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tsvwg>, <mailto:tsvwg-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 18 Nov 2019 03:32:08 -0000

On Mon, Nov 18, 2019 at 11:03 AM G Fairhurst <gorry@erg.abdn.ac.uk> wrote:

> The phrase: "is not an automatic barrier to WG adoption" - is true, but
> I would expect there to be a barrier to *immediate* adoption.
>
> Thw WG has a chartered work item, following a BOF and adoption
> procedure. The Chairs work with the AD to manage the chartered work
> items, so I expect there will be no immediate change to the milestones
> (list of adopted drafts).
>
> To clarify my own Chair position, I would not expect a WG to consider
> lightly starting a second deployment experiment in parallel using the
> same set of codepoints.
>

I'll offer a counterpoint as a former co-chair of tcpinc, the early history
of which this work area increasingly resembles.

When there are two competing proposals for the same deliverable (in this
case, high-fidelity congestion signaling) such that rough consensus does
not seem obviously forthcoming, the right approach may very well be to
adopt both and see which pans out.

If multiple experimental uses of the ECT(1) codepoint are not deployable
simultaneously, this might suggest withholding publication of any
experimental RFC making use of that codepoint until rough consensus is
achieved, which would suggest a longer period of evaluation and comparison
in synthetic environments.

OTOH, if the two experiments are deployable simultaneously (because the
consequences of conflict are not dire), perhaps an experimental RFC
outlining success criteria for evaluation of the two approaches would be
helpful in breaking the logjam.

What I don't want to see are variants of the sunk cost fallacy or
preference given to one experiment over the other for reasons other than
consensus based on demonstrated technical superiority. I've witnessed too
much of that on this mailing list over the past several months.

Kyle