Re: [tsvwg] FQ & VPNs

"Rodney W. Grimes" <ietf@gndrsh.dnsmgr.net> Mon, 22 February 2021 00:17 UTC

Return-Path: <ietf@gndrsh.dnsmgr.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 F01EF3A138F for <tsvwg@ietfa.amsl.com>; Sun, 21 Feb 2021 16:17:23 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.497
X-Spam-Level:
X-Spam-Status: No, score=-1.497 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, KHOP_HELO_FCRDNS=0.4, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=no 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 XaTaeoVHDnJG for <tsvwg@ietfa.amsl.com>; Sun, 21 Feb 2021 16:17:23 -0800 (PST)
Received: from gndrsh.dnsmgr.net (br1.CN84in.dnsmgr.net [69.59.192.140]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DAD133A138C for <tsvwg@ietf.org>; Sun, 21 Feb 2021 16:17:22 -0800 (PST)
Received: from gndrsh.dnsmgr.net (localhost [127.0.0.1]) by gndrsh.dnsmgr.net (8.13.3/8.13.3) with ESMTP id 11M0HCQm008251; Sun, 21 Feb 2021 16:17:12 -0800 (PST) (envelope-from ietf@gndrsh.dnsmgr.net)
Received: (from ietf@localhost) by gndrsh.dnsmgr.net (8.13.3/8.13.3/Submit) id 11M0H9qj008250; Sun, 21 Feb 2021 16:17:09 -0800 (PST) (envelope-from ietf)
From: "Rodney W. Grimes" <ietf@gndrsh.dnsmgr.net>
Message-Id: <202102220017.11M0H9qj008250@gndrsh.dnsmgr.net>
In-Reply-To: <C9DA0662-4B5F-4E42-8B4E-820C32F75E32@cablelabs.com>
To: Greg White <g.white@CableLabs.com>
Date: Sun, 21 Feb 2021 16:17:09 -0800 (PST)
CC: Jonathan Morton <chromatix99@gmail.com>, Ingemar Johansson S <ingemar.s.johansson@ericsson.com>, TSVWG <tsvwg@ietf.org>
X-Mailer: ELM [version 2.4ME+ PL121h (25)]
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset=US-ASCII
Archived-At: <https://mailarchive.ietf.org/arch/msg/tsvwg/__EV3WQyO5LUuwykttSlVkpSDsM>
Subject: Re: [tsvwg] FQ & VPNs
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, 22 Feb 2021 00:17:24 -0000

> On 2/21/21, 4:25 PM, "tsvwg on behalf of Jonathan Morton" <tsvwg-bounces@ietf.org on behalf of chromatix99@gmail.com> wrote:
> 
>     L4S cannot safely be deployed on existing networks - that is axiomatic in its current form.  Therefore, you have to prepare the network as fully L4S-aware before you can safely deploy your first endpoints - on Internet scale, that is not really feasible within a decade.  It would be easier to start deployment if you had a good way of containing L4S traffic to a small portion of the network (eg. a CDN and an associated ISP) in which dealing with the network preparation is actually feasible in the short term.
> 
> [GW] This is blatantly false. In the vast majority of paths, L4S is considered safe for deployment today.  In a minority of paths there exists the rare possibility of L4S flows achieving more than their "fair" share of the bottleneck link bandwidth, and an extremely rare possibility that this unfairness results in a significant temporary degradation of classic traffic performance.  In these paths there is almost certainly only one network element that will need to be updated in order to prevent any possibility of such degradation, and as far as anyone can discern at the moment those network elements are largely prosumer grade home routers that are increasingly being actively patched already. 

I strongly disagree that it should be considered safe.

"Only one network element" in a path with an internet of millions of paths == millions of nodes to be updated.  One must also realize every path has a bottle neck someplace, and that TCP is a capacity seeking protocol so the probablity of an issue should be rather high, not "extremly rare."

You know its really simple to solve most of these arguments, deploy L4S in an AS behind a DSCP and get some real working data.  All the handwaving and guessing is not going to get anyone there on these issues.
> 
> [snip]
> 
>     Conversely, let's look at SCE from the same perspective.  Remember, SCE is capable of achieving the same performance as L4S, given similar marking and response algorithms.  The difference is in backwards compatibility.
> 
> [GW] The WG considered SCE and has decided against it.  You seem to be repeating the same arguments (with the same transparent hyperbole) that led to that conclusion in hopes that the outcome somehow changes. 

The consideration was weither to use ECT(1) as an input or output or something else.  There was never a question of "SCE" on the table.  IMHO, that whole process was seriously flawed as what was initial presented as "not an SCE vs L4S" decision got baked by the chair(s) into almost exactly that by how they presented and guided that decision process.


> [snip]

-- 
Rod Grimes                                                 rgrimes@freebsd.org