Re: [tsvwg] Reasons for WGLC/RFC asap

Roland Bless <roland.bless@kit.edu> Thu, 19 November 2020 10:35 UTC

Return-Path: <roland.bless@kit.edu>
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 872873A13C7 for <tsvwg@ietfa.amsl.com>; Thu, 19 Nov 2020 02:35:36 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, NICE_REPLY_A=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
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 wP0dVnk0TbcJ for <tsvwg@ietfa.amsl.com>; Thu, 19 Nov 2020 02:35:35 -0800 (PST)
Received: from iramx2.ira.uni-karlsruhe.de (iramx2.ira.uni-karlsruhe.de [IPv6:2a00:1398:2::10:81]) (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 05F4E3A13CA for <tsvwg@ietf.org>; Thu, 19 Nov 2020 02:35:34 -0800 (PST)
Received: from [2a00:1398:2:4006:9c76:600d:2ab1:c2e0] (helo=i72vorta.tm.kit.edu) by iramx2.ira.uni-karlsruhe.de with esmtpsa port 25 iface 2a00:1398:2::10:8 id 1kfhHm-0003tz-CE; Thu, 19 Nov 2020 11:35:30 +0100
Received: from [IPv6:::1] (localhost [127.0.0.1]) by i72vorta.tm.kit.edu (Postfix) with ESMTPS id 235C342046B; Thu, 19 Nov 2020 11:35:30 +0100 (CET)
To: Lars Eggert <lars@eggert.org>, Ingemar Johansson S <ingemar.s.johansson@ericsson.com>
Cc: tsvwg IETF list <tsvwg@ietf.org>
References: <AM8PR07MB747626CB7622CB89209018A8B9E10@AM8PR07MB7476.eurprd07.prod.outlook.com> <5dff4f73463c2a7e7cc8dc8255ae9825e78f4c11.camel@petri-meat.com> <4FF8800F-B618-4818-AF5E-1E997EA9FBF3@eggert.org> <HE1PR0701MB2876C4FDA655284D4E563042C2E00@HE1PR0701MB2876.eurprd07.prod.outlook.com> <3EAC47AC-5937-4DB2-8B3C-D8C8A4459FBA@eggert.org>
From: Roland Bless <roland.bless@kit.edu>
Autocrypt: addr=roland.bless@kit.edu; prefer-encrypt=mutual; keydata= mQINBFi0OxABEACy2VohJ7VhSu/xPCt4/6qCrw4Pw2nSklWPfAYEk1QgrbiwgvLAP9WEhAIU w45cojBaDxytIGg8eaYeIKSmsXjHGbV/ZTfo8r11LX8yPYR0WHiMWZpl0SHUd/CZIkv2pChO 88vF/2FKN95HDcp24pwONF4VhxJoSFk6c0mDNf8Em/Glt9BcWX2AAvizTmpQDshaPje18WH3 4++KwPZDd/sJ/hHSXiPg1Gdhs/OG/C0CJguOAlqbgSVAe3qKOr1M4K5M+wVpsk373pXRfxd7 ZAmZ05iBTn+LfgVcz+AfaKKcsWri5CdTT+7JDL6QNQpox+b5FXZFSHnEIST+/qzfG7G2LqqY mml6TYY8XbaNyXZP0QKncfSpRx8uTRWReHUa1YbSuOxXYh6bXpcugD25mlC/Lu0g7tz4ijiK iIwq9+P2H1KfAAfYyYZh6nOoE6ET0TjOjUSa+mA8cqjPWX99kEEgf1Xo+P9fx9QLCLWIY7zc mSM+vjQKgdUFpMSCKcYEKOuwlPuOz8bVECafxaEtJJHjCOK8zowe2eC9OM+G+bmtAO3qYcYZ hQ/PV3sztt/PjgdtnFAYPFLc9189rHRxKsWSOb4xPkRw/YQAI9l15OlUEpsyOehxmAmTsesn tSViCz++PCdeXrQc1BCgl8nDytrxW+n5w1aaE8aL3hn8M0tonQARAQABtChSb2xhbmQgQmxl c3MgKFRNKSA8cm9sYW5kLmJsZXNzQGtpdC5lZHU+iQJABBMBCAAqAhsDBQkSzAMABQsJCAcC BhUICQoLAgQWAgMBAh4BAheABQJYtYdHAhkBAAoJEKON2tlkOJXuzWkP+wfjUnDNzRm4r34a AMWepcQziTgqf4I1crcL6VD44767HhyFsjcKH31E5G5gTDxbpsM4pmkghKeLrpPo30YK3qb7 E9ifIkpJTvMu0StSUmcXq0zPyHZ+HxHeMWkosljG3g/4YekCqgWwrB62T7NMYq0ATQe1MGCZ TAPwSPGCUZT3ioq50800FMI8okkGTXS3h2U922em7k8rv7E349uydv19YEcS7tI78pggMdap ASoP3QWB03tzPKwjqQqSevy64uKDEa0UgvAM3PRbJxOYZlX1c3q/CdWwpwgUiAhMtPWvavWW Tcw6Kkk6e0gw4oFlDQ+hZooLv5rlYR3egdV4DPZ1ugL51u0wQCQG9qKIMXslAdmKbRDkEcWG Oi2bWAdYyIHhhQF5LSuaaxC2P2vOYRHnE5yv5KTV3V7piFgPFjKDW+giCRd7VGfod6DY2b2y zwidCMve1Qsm8+NErH6U+hMpMLeCJDMu1OOvXYbFnTkqjeg5sKipUoSdgXsIo4kl+oArZlpK qComSTPhij7rMyeu/1iOwbNCjtiqgb55ZE7Ekd84mr9sbq4Jm/4QGnVI30q4U2vdGSeNbVjo d1nqjf3UNzP2ZC+H9xjsCFuKYbCX6Yy4SSuEcubtdmdBqm13pxua4ZqPSI0DQST2CHC7nxL1 AaRGRYYh5zo2vRg3ipkEuQINBFi0OxABEAC2CJNp0/Ivkv4KOiXxitsMXZeK9fI0NU2JU1rW 04dMLF63JF8AFiJ6qeSL2mPHoMiL+fG5jlxy050xMdpMKxnhDVdMxwPtMiGxbByfvrXu18/M B7h+E1DHYVRdFFPaL2jiw+Bvn6wTT31MiuG9Wh0WAhoW8jY8IXxKQrUn7QUOKsWhzNlvVpOo SjMiW4WXksUA0EQVbmlskS/MnFOgCr8q/FqwC81KPy+VLHPB9K/B65uQdpaw78fjAgQVQqpx H7gUF1EYpdZWyojN+V8HtLJx+9yWAZjSFO593OF3/r0nDHEycuOjhefCrqr0DDgTYUNthOdU KO2CzT7MtweRtAf0n27zbwoYvkTviIbR+1lV1vNkxaUtZ6e1rtOxvonRM1O3ddFIzRp/Qufu HfPe0YqhEsrBIGW1aE/pZW8khNQlB6qt20snL9cFDrnB6+8kDG3e//OjK1ICQj9Y/yyrJVaX KfPbdHhLpsgh8TMDPoH+XXQlDJljMD0++/o7ckO3Sfa8Zsyh1WabyKQDYXDmDgi9lCoaQ7Lf uLUpoMvJV+EWo0jE4RW/wBGQbLJp5usy5i0fhBKuDwsKdLG3qOCf4depIcNuja6ZmZHRT+3R FFjvZ/dAhrCWpRTxZANlWlLZz6htToJulAZQJD6lcpVr7EVgDX/y4cNwKF79egWXPDPOvQAR AQABiQIlBBgBCAAPBQJYtDsQAhsMBQkSzAMAAAoJEKON2tlkOJXukMoP/jNeiglj8fenH2We 7SJuyBp8+5L3n8eNwfwY5C5G+etD0E6/lkt/Jj9UddTazxeB154rVFXRzmcN3+hGCOZgGAyV 1N7d8xM6dBqRtHmRMPu5fUxfSqrM9pmqAw2gmzAe0eztVvaM+x5x5xID2WZOiOq8dx9KOKrp Zorekjs3GEA3V1wlZ7Nksx/o8KZ04hLeKcR1r06zEDLN/yA+Fz8IPa0KqpuhrL010bQDgAhe 9o5TA0/cMJpxpLqHhX2As+5cQAhKDDsWJu3oBzZRkN7Hh/HTpWurmTQRRniLGSeiL0zdtilX fowyxGXH6QWi3MZYmpOq+etr7o4EGGbm2inxpVbM+NYmaJs+MAi/z5bsO/rABwdM5ysm8hwb CGt+1oEMORyMcUk/uRjclgTZM1NhGoXm1Un67+Rehu04i7DA6b8dd1H8AFgZSO2H4IKi+5yA Ldmo+ftCJS83Nf6Wi6hJnKG9aWQjKL+qmZqBEct/D2uRJGWAERU5+D0RwNV/i9lQFCYNjG9X Tew0BPYYnBtHFlz9rJTqGhDu4ubulSkbxAK3TIk8XzKdMvef3tV/7mJCmcaVbJ2YoNUtkdKJ goOigJTMBXMRu4Ibyq1Ei+d90lxhojKKlf9yguzpxk5KYFGUizp0dtvdNuXRBtYrwzykS6vB zTlLqHZ0pvGjNfTSvuuN
Organization: Institute of Telematics, Karlsruhe Institute of Technology (KIT)
Message-ID: <25463376-5905-c00c-a542-70f04510d50b@kit.edu>
Date: Thu, 19 Nov 2020 11:35:29 +0100
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8.0.1) Gecko/20060111 Thunderbird/1.5 Mnenhy/0.7.3.0
MIME-Version: 1.0
In-Reply-To: <3EAC47AC-5937-4DB2-8B3C-D8C8A4459FBA@eggert.org>
Content-Type: text/plain; charset="windows-1252"
Content-Language: en-US
Content-Transfer-Encoding: 8bit
X-ATIS-AV: ClamAV (iramx2.ira.uni-karlsruhe.de)
X-ATIS-Checksum: v3zoCAcc32ckk
X-ATIS-Timestamp: iramx2.ira.uni-karlsruhe.de esmtpsa 1605782130.512099735
Archived-At: <https://mailarchive.ietf.org/arch/msg/tsvwg/jH5dzKxnwIA3htAWrBYBibTEhxQ>
Subject: Re: [tsvwg] Reasons for WGLC/RFC asap
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: Thu, 19 Nov 2020 10:35:36 -0000

Hi Lars and all,

I agree with every point that Lars made and want to emphasize that
I would also expect to have a working TCP scheme that fulfills at least
most of the promises that L4S made. It should'nt be necessary for others
to find the flaws within the current approach, I'd rather expect that
the proponents show what currently works and even what doesn't work so well.

I think it's then up to the WG to decide whether the remaining issues
are acceptable or if further improvements are necessary.

Regards,
 Roland

On 19.11.20 at 11:13 Lars Eggert wrote:
> On 2020-11-19, at 11:43, Ingemar Johansson S <ingemar.s.johansson@ericsson.com> wrote:
>> My opinion is that this work has stalled due to an endless discussion on the severity of the listed issues. Do you foresee that a year or so more of equally endless discussion will make anybody more wise ?
> 
> I'd hope so. But maybe I am optimistic.
> 
> One problem is that there have been two camps that are mostly talking to (or shouting at) each other. That makes it quite unappealing to join the discussion for someone who isn't part of those camps. I agree that more of that kind of "discussion" is not going to be helpful. I think the two camps need to realize that they need to convince the *rest of the WG* of their respective views, not each other.
> 
>> , between meetings there are only a few people engaged in this debate that floods the TSVWG list, it is a safe bet that most outsiders hit the delete button.
> 
> Yes. Because mostly, as I wrote above, the discussion is very inwardly focused, highly detailed, very fast-paced, references email threads that go back years (without pointers) and so makes it very, very hard for someone who has not participated to engage and stay engaged.
> 
>> I can understand the incentives to try and delay WGLC/RFC, perhaps some hopes that there will by some magic emerge a much better high-fidelity congestion marking in some form. In short, tear the whole thing apart and come up with something much better.
> 
> That's certainly not what I tried to say, and I didn't get that from Steven's email either.
> 
> My point (don't want to speak for Steven) was that without a TCP scheme that delivers some benefits when operating over a path with some new-style queuing while at the same time not suffering from serious regressions, it's kinda hard to argue that that new-style queueing is performing as desired. (And we can certainly debate what counts as a serious regression and what doesn't.) Basically, a strawman that satisfies (some of) the Prague requirements without regressions.
> 
> Maybe we have that TCP scheme already, but at least the recent results that Pete shared show that there are maybe still some question marks.
> 
> And we don't need the perfect scheme. But we need something that delivers enough benefit that the entities that are required to deploy this feel motivated to do so. Deploying this is a pretty big investment, after all.
> 
>> The problem is that we are talking at least 2 years extra work to get into the state that the L4S drafts are today.
> 
> I can't quite parse that sentence. Are you saying this would delay L4S for two years before we can LC it?
> 
> Like Steven, I don't understand where this extreme pressure comes from to LC something. Experimentation is not contingent on the LC, even large-scale experimentation.
> 
>> The use of the ECT(1) code point tend to often lead to questions like "what do we do when L4S fails?". Well the nonce has been declared historic so the process for this is in place, but besides this it is perhaps good to consider that L4S can actually fly ?.
> 
> I don't actually care at all that L4S uses ECT(1). I'm still unconvinced - at the moment - that L4S delivers on its promises. *That* is why I am questioning whether we're ready for a LC.
> 
>> I really think that it is high time to move this to WGLC, this has dragged on for too long.
> 
> "Time spent in WG" is not a useful criteria for determining whether something is ready for a LC.
> 
> Thanks,
> Lars
>