Re: [tsvwg] path forward on L4S issue #16

Sebastian Moeller <moeller0@gmx.de> Thu, 18 June 2020 07:39 UTC

Return-Path: <moeller0@gmx.de>
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 9C4EE3A0F0C; Thu, 18 Jun 2020 00:39:17 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.649
X-Spam-Level:
X-Spam-Status: No, score=-1.649 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=gmx.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 6GHuAWT_5CU4; Thu, 18 Jun 2020 00:39:16 -0700 (PDT)
Received: from mout.gmx.net (mout.gmx.net [212.227.17.21]) (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 8C4183A0EF1; Thu, 18 Jun 2020 00:39:11 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gmx.net; s=badeba3b8450; t=1592465941; bh=mlu7JiJ7S5xYvLgVLB9iwBTTlVz+1R/8aVdNY2tPIdA=; h=X-UI-Sender-Class:Subject:From:In-Reply-To:Date:Cc:References:To; b=ExthZWNCXhqbQxLrVr5lTzlELeJXy8XlyKSWbQOKNLXFFIngnU6KbGVEfQS59CyXv lv6WuvfmdhiZCIqoVeDi0P4jW/xOx1CAv0UG3l9vawEy1oHd13Cg8lbOZueDhqi4vv nYOVUcU7D6pAAbbhZ4w6UBoIO388IoXomJCDG+qI=
X-UI-Sender-Class: 01bb95c1-4bf8-414a-932a-4f6e2808ef9c
Received: from [10.11.12.3] ([134.76.241.253]) by mail.gmx.com (mrgmx105 [212.227.17.168]) with ESMTPSA (Nemesis) id 1ML9yc-1jTk3T0qpO-00IAUU; Thu, 18 Jun 2020 09:39:01 +0200
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.14\))
From: Sebastian Moeller <moeller0@gmx.de>
In-Reply-To: <19188328.uKY2rrpm7d@linux-9daj>
Date: Thu, 18 Jun 2020 09:38:56 +0200
Cc: "Black, David" <David.Black@dell.com>, TSVWG <tsvwg@ietf.org>, Ingemar Johansson S <ingemar.s.johansson=40ericsson.com@dmarc.ietf.org>
Content-Transfer-Encoding: quoted-printable
Message-Id: <CBCDBB42-81DF-4DD6-ACB6-2BB8F01F3564@gmx.de>
References: <2DC5C89B-C979-4354-98D7-BBDBC78A42B1@gmail.com> <MN2PR19MB40450A06A919354C8D4CFC74839A0@MN2PR19MB4045.namprd19.prod.outlook.com> <9E403EBC-79D4-4C6E-B000-E53BE8B29228@gmx.de> <19188328.uKY2rrpm7d@linux-9daj>
To: Paul Vixie <paul@redbarn.org>
X-Mailer: Apple Mail (2.3445.104.14)
X-Provags-ID: V03:K1:JND4lVpALabUdqP9T94ry8eN6ArYt2Oa5yRMfQYC9kjAqwEsayp isxv6mQsLnGD1Dsuh4InzBYrfQX15iZu0xvCQV++B0ltcFCC/MdCJLU1AtoMDoPyHVEimHm 3OAi3H/r/9x8TJ9CWdOFV5+hsKo5jnO44xGVCgaml+Gr76rCOy73Riyg/Ijgxb84i9D5+xR sx/T3jwc5v1uiAAsVLuKQ==
X-UI-Out-Filterresults: notjunk:1;V03:K0:4vDGeF/8rWI=:2fwwf3LD6LKnB8h6pHBPMZ ytpkXMZrzgZrzMq4WZwh2kXL21hO3xHoNioN/G8H+MSD7LLZ0e2OMP8h40oKQky7s5vC11EJw d+Cq+4G9FRCypbeLgBKgzr+ZQEad5v9OsFaq10+KFjUOf9qywtY1hDeiosefXB+3HToSVW/oq kp6nIm5neTk/jPIZdjUamwYtSrWF7AoTILh3h3RmLiQQFc5jWCor9un9GhkACXiv/WFB694hA wUS3rwFZOxd8hagj8u6Mm7BwvQWLY+6sOCWdrOEzFAXgB3bV2sqFWfJ7pXGMv92Fm4AQ9K9xv REo5zHibsCLcNJyuEhrKQjg0GRtuzdfP5OBuNe/cjCmkJ7F5cNQpkB/dQP/7PanLCfsDGu8pm Pplvdd0qsWD0bGFTw7zIrfDSqczUdjQvpSTQg26ni0jbZyAlbsrM2O9xCmIsHAfVp2rtV5OyE BYuQx/Y7v2cMBGP5fy+jRlgOYxoSA6RS8W92HksRIQcRDE6Gv8XdzM1Ov5nlAmk46ES9zCTSH 5LmGp5n5zswzESZj9tqRar4CVwfKGWMB4f0q3Mrt0bTRAz6EFJqhGmH2v1kSDOD2/RnObSdyP JZGWojq7sH4vQXwqD072Qc8eJXzuKFFcIEEvWsdkrhK3mSP6K2pQx525fymQijIP9guzmhWjI kzDUeC4dE7HF431jZufpZNdpCIuezAdZayXGeFI41oX9lWHTld6r2xmdGFGcI2A1abmzZ/v20 II6o48ICrmdz8poMymcvJHyPE+wDoOo040eagQ5XPoMPB7VHSfS2be6JOzqOaYF7ed+CGacuQ hF16zGaI6SMetUZ7jeJg6Yw7n9NXP+ZcwOqU3944GAYuOK3DSfoGTtpsDi2/Xu7KrKR2gHO2l NlXsfgruIdARzmdHTHcdhMYAuNIeeLNRBtWEXT7q7/cpZnHJHZ9DlwcFmHpUNkXDB3Ph1nkzl Y62kjsUM9vJ8HzudQeESooT5NbV0bLmJ/BUEuHIXxzCr4oYr4pMNKAqG1tTtwCVAa3BdNDy9R DPwydIcF92nwzS90cYlUFNzz83jbrKcHbpjU9LncjDOBpsInGtDyPnJYctp75xf/E+9V8r7ff g8uh/m9puEQFRuVW7H/rOWzyHYb13s8TpUbR3pkUL5vpnNlyBpR/rpjb5wiT8gVhwvpcHTHpB 4q+dE8gqhSQ40On8DdhL/5okdtFbFpOO0K7AwUv0Nd6bJ7MyYk67D/wGjv7CacR2ErIgo=
Archived-At: <https://mailarchive.ietf.org/arch/msg/tsvwg/bsT0YSKqT83M5OLUiAVrQ2oev20>
Subject: Re: [tsvwg] path forward on L4S issue #16
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, 18 Jun 2020 07:39:22 -0000

Hi Paul,


> On Jun 17, 2020, at 22:50, Paul Vixie <paul@redbarn.org> wrote:
> 
> On Wednesday, 17 June 2020 18:19:23 UTC Sebastian Moeller wrote:
>>> ...
>> 
>> 	[SM] ... my hypothesis that L4S was really only
>> ever intended, designed, and tested for a single use-case, short RTT, low
>> hop-count downlink paths from content/CDNs to consumers. ...
> 
> that's not really a hypothesis, but rather an observation.

	[SM] Good point, I did not want to claim that I could divine the L4S intent and design goals, but I agree that for testing this hypothesis is based on observed facts.


> by the time a 
> packet has traversed a metropolitan area, the scale of its transit time will 
> be greater than the difference in scales between the dual queues of dualq.

	[SM] +1; even with a delay target of 15ms the non-LL queue of the dual queue coupled AQM  will have chopped off the bad multiple dozens or hundreds of milliseconds queueing delay that is the real problem for latency bound services on the internet. Which is nicely demonstrated by how well already deployed combinations of HTB+fq_codel or cake work in the real world. Getting 1/p congestion signalling is still a valid goal IMHO, but let's keep the cost in perspective.

> 
> to those who were confused when i referred to L4S as a datacenter protocol, 
> this is why: getting into the microsecond vs. millisecond queue in an edge 
> switch or router at the far-end campus or home or LAN won't change the lived 
> experience of your application or user in any way since the packet is already 
> a half dozen or more milliseconds from where it was born.

	[SM] Playing advocatus diaboli here, a reduction in RTT variance has the potential to make the work of RTT-equalization methods more effective; methods that are used e.g. in VoIP de-jitter buffers and in on-line games to offer a level playing field to all agents. But the idea that a single hop is typically responsible for all delay variation seems like too strong a claim to me, so I agree that there will be diminishing returns the longer the path gets. I like your description "datacenter protocol", as that better manages expectations that "low-latency-for-all"*.

Best Regards
	Sebastian

*) Which ignores that not all latency is queueing delay, hence reducing queueing delay will not magically make all paths low-latency.

> 
> -- 
> Paul
> 
>