Re: [tsvwg] L4S drafts: Next Steps
Bob Briscoe <ietf@bobbriscoe.net> Fri, 12 March 2021 01:48 UTC
Return-Path: <ietf@bobbriscoe.net>
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 612BC3A18AF for <tsvwg@ietfa.amsl.com>; Thu, 11 Mar 2021 17:48:22 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.434
X-Spam-Level:
X-Spam-Status: No, score=-1.434 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, NICE_REPLY_A=-0.001, SPF_HELO_NONE=0.001, SPF_SOFTFAIL=0.665, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=bobbriscoe.net
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 yEr1O2DUjHRR for <tsvwg@ietfa.amsl.com>; Thu, 11 Mar 2021 17:48:20 -0800 (PST)
Received: from mail-ssdrsserver2.hosting.co.uk (mail-ssdrsserver2.hosting.co.uk [185.185.84.51]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E1E183A18AE for <tsvwg@ietf.org>; Thu, 11 Mar 2021 17:48:19 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=bobbriscoe.net; s=default; h=Content-Transfer-Encoding:Content-Type: In-Reply-To:MIME-Version:Date:Message-ID:From:References:Cc:To:Subject:Sender :Reply-To:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Id:List-Help: List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=pIsshyGbUfeT7QfZeHQ/rZUFeJw2xYb6/m4CW74r5KY=; b=7kXHwITyaES7cSxTogbxLzaoTK jhMTdUIgIkTAzUiWW4Pjv6byMwC6MJU/FSex/UlIc+QI/7NtqMuEocuGI+8W7xMKb/IE1eqmwESBi +uGFg0ZDe9gjt0x3pYrszhVH1SxV8+JhEpJOk7IGlUjA5w/mdTm2WANfbCC9mC8GW3NlEYiChJRAv hPOO7CdH3B59vcL6QwcDplT7Vtt8/OsoZqbx1ECVJS1Wv7N7CZcO1hNYEbQU1p+kA7RXYh4mPwAzf aQFYk9OzNU/ZqGmXszRIMKZimpCbQGXK6oWdzf/CT0ILxpfKboCMl3CzbVRmNIaw5ngw756VLS1Fn s/s8g29w==;
Received: from 67.153.238.178.in-addr.arpa ([178.238.153.67]:51450 helo=[192.168.1.11]) by ssdrsserver2.hosting.co.uk with esmtpsa (TLS1.2) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.93) (envelope-from <ietf@bobbriscoe.net>) id 1lKWuW-0007j6-RT; Fri, 12 Mar 2021 01:48:16 +0000
To: "Black, David" <David.Black@dell.com>
Cc: "tsvwg@ietf.org" <tsvwg@ietf.org>, Jonathan Morton <chromatix99@gmail.com>
References: <MN2PR19MB4045FAC079C74FC262005BF483F10@MN2PR19MB4045.namprd19.prod.outlook.com> <92283815-f81a-ba86-fe63-7925e23e31f6@bobbriscoe.net> <MN2PR19MB404513C22FE4025C31261BC783CC0@MN2PR19MB4045.namprd19.prod.outlook.com> <5d8f0031-1aee-9e41-7860-04a46a89607e@bobbriscoe.net> <MN2PR19MB4045305CA7D5673C554BCBA383919@MN2PR19MB4045.namprd19.prod.outlook.com> <ee0c9cd2-608c-ef69-ef84-892cd4f17204@bobbriscoe.net> <MN2PR19MB404522F073A03BA2F866604E83909@MN2PR19MB4045.namprd19.prod.outlook.com> <83559d3f-6004-118a-cde2-ec999fc8c483@bobbriscoe.net> <DE5B87E4-DD60-435E-80AD-01C09F13D173@gmail.com> <375666b8-1123-a635-1cd6-eb496835369a@bobbriscoe.net> <2963CA47-2A15-4335-96A5-EB5F653498F2@gmail.com> <MN2PR19MB40451F89402B39619947EFAA836F9@MN2PR19MB4045.namprd19.prod.outlook.com>
From: Bob Briscoe <ietf@bobbriscoe.net>
Message-ID: <ed8c4042-026e-f3f0-01c7-fb50c47ecc9c@bobbriscoe.net>
Date: Fri, 12 Mar 2021 01:48:16 +0000
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.7.1
MIME-Version: 1.0
In-Reply-To: <MN2PR19MB40451F89402B39619947EFAA836F9@MN2PR19MB4045.namprd19.prod.outlook.com>
Content-Type: text/plain; charset="utf-8"; format="flowed"
Content-Transfer-Encoding: 7bit
Content-Language: en-GB
X-AntiAbuse: This header was added to track abuse, please include it with any abuse report
X-AntiAbuse: Primary Hostname - ssdrsserver2.hosting.co.uk
X-AntiAbuse: Original Domain - ietf.org
X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12]
X-AntiAbuse: Sender Address Domain - bobbriscoe.net
X-Get-Message-Sender-Via: ssdrsserver2.hosting.co.uk: authenticated_id: in@bobbriscoe.net
X-Authenticated-Sender: ssdrsserver2.hosting.co.uk: in@bobbriscoe.net
X-Source:
X-Source-Args:
X-Source-Dir:
Archived-At: <https://mailarchive.ietf.org/arch/msg/tsvwg/5Xht79Z8auMw-KxtdDtDQC8U5hQ>
Subject: Re: [tsvwg] L4S drafts: Next Steps
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: Fri, 12 Mar 2021 01:48:22 -0000
David, On 12/03/2021 00:20, Black, David wrote: >> What I believe David Black is referring to - and I'm sure he'll correct me if necessary - is the (hopefully uncontroversial) notion that a specification >> is useless if it cannot be implemented, and indeed not very useful if distinct implementations are not automatically interoperable with each other. > That's the core idea. In more detail, the transport requirements for use of the L4S service (section 4 of draft-ietf-tsvwg-ecn-l4s-id-14, particularly section 4.3 on congestion response) define a functional interface between the network and transport protocols, an interface that needs to interoperate with a variety of transport protocols in order to realize the L4S goal of being a widely usable service. Looking back over the past few years, in 20/20 hindsight, some of these requirements were initially written too strictly to the point of being infeasible. I am not questioning that there is work to be done to implement those requirements (by us - the authors). I am questioning the notion that at least one developer (other than the authors) has to do all the same work as well, irrespective of how many other developers do many parts of the work. The functional interfaces are a tiny part of the job, i.e. the ECT(1) codepoint and e2e transport feedback. However, 90% of the requirements are about performance impact on other hosts (mostly latency but also throughput). I.e. all the safety requirements in 4.3. These are /not/ functional interfaces. Functional interface requirements are relatively easy to set up tests for. In contrast performance safety testing requires huge resources to test satisfactorily. And the results are easy to rubbish as meaningless if not done over the real Internet (Jonathan can give you the playbook on that). But no-one can do this over the real Internet without the codepoint. So this type of testing requires even more resources to set up an artificial but realistic environment. I agree this stuff has to be done. It just makes a hugely hard task even harder if you arbitrarily set the bar so that at least one of the developers has to do it /all/ *as well as the authors*. When it would be no less meaningful if testing of each requirement was covered by at least one of the developers (as well as the authors). > > Turning to the current situation, the claim (in email below) that "No-one expects that [meeting these requirements] to be a problem for L4S implementers" does not align with the two "Needs experimental data" slides in Koen's meeting presentation on these requirements (see slides 6 and 7 of: https://datatracker.ietf.org/meeting/110/materials/slides-110-tsvwg-sessb-73-prague-requirements-00) [BB] You're now quoting me out of context (presumably due to Jonthan's snippers). My words were: > >> Where does the concern about transport protocol independence come >> from? No-one expects that to be a problem for L4S implementers. I was arguing against your specific focus on *transport protocol independence*. That suddenly adds another dimension to the test matrix. Say, for instance that the second implementer likely to do the first full set of testing is Google with BBRv2. They have done person-years of work but, with this sudden call to bring you a different rock, all their work suddenly won't count, 'cos their implementation is over TCP, which is the same transport protocol as TCP Prague. Yes, Google could probably do the work over QUIC instead". But only if you had asked them 2 years ago. Suddenly inventing this new requirement throws a spanner into everyone's plans. The projects are set up. The people involved have expertise in the particular protocols, then suddenly there's a click of the fingers for a different rock. Which transport protocol is used is not even important to the requirements in the draft. it's just an arbitrarily different rock. > I have no problem with evaluation of some of these requirements being goals of the L4S experiment - if that is done, then mandating that the requirements involved be met in order to participate in the L4S experiment appears to set the bar for experimental use of ECT(1) too high. To make this concrete, one of the "Needs experimental data" items (first item on slide 7) is: > > o MUST implement monitoring to detect non_L4S ECN AQM... > - Is detection itself required? > - Robust detection scheme needs real deployment experience. > - Combination with delay based control could minimize potential issues > - Develop during experiment as needed. > > To purse such a course of action, "MUST implement monitoring to detect non_L4S ECN AQM..." cannot survive as a normative requirement (MUST) for use of the ECT(1) codepoint in the L4S experiment, although it would be fine to encourage that monitoring to be implemented. If this sort of approach of converting problematic requirements to implementation guidance and/or goals to be evaluated by the experiment is followed for all of the "Needs experimental data" items, then the resulting WG consensus call on feasibility of the remaining requirements (effectively the rest of the contents of Koen's slides, including removal of the objectionable documentation requirements) should be quick and easy. > > The l4s-ops draft would need to align with any resulting changes. [BB] This is fine, and good, and consistent with what we've been led to understand. Thank you. It's the sudden demands for different rocks I am picking up on: sudden demands about how many transport protocols, sudden constraints on which implementers have to do how much, etc. Bob > > Thanks, --David > > -----Original Message----- > From: Jonathan Morton <chromatix99@gmail.com> > Sent: Thursday, March 11, 2021 5:56 PM > To: Bob Briscoe > Cc: Black, David; tsvwg@ietf.org > Subject: Re: [tsvwg] L4S drafts: Next Steps > > > [EXTERNAL EMAIL] > >> On 12 Mar, 2021, at 12:07 am, Bob Briscoe <ietf@bobbriscoe.net> wrote: >> >> The concern is requiring unnecessary work to prove things that are "bring me a different rock" exercises. > That does appear to be *your* concern at the moment. I am merely trying to interpret the concerns of other people for your benefit. Neither you nor I are the sole arbiters of what valid concerns may or may not exist. I would however encourage you to consider what I have recently said about "externalised risk"; I can find a link to the YouTube recording of my talk the other day, if that would be helpful. > > What I believe David Black is referring to - and I'm sure he'll correct me if necessary - is the (hopefully uncontroversial) notion that a specification is useless if it cannot be implemented, and indeed not very useful if distinct implementations are not automatically interoperable with each other. This is part of the IETF credo of "rough consensus and running code". > > As he explained, it is not necessary for two independent implementations to actually exist for an Experimental or Proposed Standard RFC, so long as there's a reasonable expectation that a second complete implementation is achievable by an ordinarily skilled practitioner of the art (to borrow some patent law jargon). The existence of *one* complete implementation would, however, appear to be a prerequisite for such a determination. If such an implementation is open-source and well documented, it's reasonable to expect a second implementer to refer to it in minor cases of doubt - but the major facets of requirement must also be well described in the specification. > > I have entirely separate concerns about the specification itself, which I will keep to other threads. > > - Jonathan Morton -- ________________________________________________________________ Bob Briscoe http://bobbriscoe.net/
- [tsvwg] L4S drafts: Next Steps Black, David
- Re: [tsvwg] L4S drafts: Next Steps Bob Briscoe
- Re: [tsvwg] L4S drafts: Next Steps Black, David
- Re: [tsvwg] L4S drafts: Next Steps Jonathan Morton
- Re: [tsvwg] L4S drafts: Next Steps Sebastian Moeller
- Re: [tsvwg] L4S drafts: Next Steps Wesley Eddy
- Re: [tsvwg] L4S drafts: Next Steps Ingemar Johansson S
- Re: [tsvwg] L4S drafts: Next Steps Bob Briscoe
- Re: [tsvwg] L4S drafts: Next Steps Black, David
- Re: [tsvwg] L4S drafts: Next Steps Bob Briscoe
- Re: [tsvwg] L4S drafts: Next Steps Black, David
- Re: [tsvwg] L4S drafts: Next Steps Bob Briscoe
- Re: [tsvwg] L4S drafts: Next Steps Jonathan Morton
- Re: [tsvwg] L4S drafts: Next Steps Bob Briscoe
- Re: [tsvwg] L4S drafts: Next Steps Jonathan Morton
- Re: [tsvwg] L4S drafts: Next Steps Black, David
- Re: [tsvwg] L4S drafts: Next Steps Bob Briscoe
- Re: [tsvwg] L4S drafts: Next Steps Black, David
- Re: [tsvwg] L4S drafts: Next Steps Gorry Fairhurst
- Re: [tsvwg] L4S drafts: Next Steps Greg White
- Re: [tsvwg] L4S drafts: Next Steps Gorry Fairhurst
- Re: [tsvwg] L4S drafts: Next Steps Sebastian Moeller
- Re: [tsvwg] L4S drafts: Next Steps Livingood, Jason
- Re: [tsvwg] L4S drafts: Next Steps Jonathan Morton
- Re: [tsvwg] L4S drafts: Next Steps Livingood, Jason
- Re: [tsvwg] L4S drafts: Next Steps Gorry Fairhurst
- Re: [tsvwg] L4S drafts: Next Steps Jonathan Morton
- Re: [tsvwg] L4S drafts: Next Steps Sebastian Moeller
- Re: [tsvwg] L4S drafts: Next Steps Sebastian Moeller
- Re: [tsvwg] L4S drafts: Next Steps Pete Heist
- Re: [tsvwg] L4S drafts: Next Steps Sebastian Moeller
- Re: [tsvwg] L4S drafts: Next Steps Sebastian Moeller