Re: [tcpm] [tsvwg] L4S related activity in 3GPP

Sebastian Moeller <moeller0@gmx.de> Sat, 09 November 2019 17:13 UTC

Return-Path: <moeller0@gmx.de>
X-Original-To: tcpm@ietfa.amsl.com
Delivered-To: tcpm@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DE0A11200C5; Sat, 9 Nov 2019 09:13:32 -0800 (PST)
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_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-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 VRdNC_4GnYuw; Sat, 9 Nov 2019 09:13:31 -0800 (PST)
Received: from mout.gmx.net (mout.gmx.net [212.227.15.18]) (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 5A74E120137; Sat, 9 Nov 2019 09:13:31 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gmx.net; s=badeba3b8450; t=1573319598; bh=v8UuJirJYqdSMbRhJluD+Tfl3uB+92e+1R5eUyqouRM=; h=X-UI-Sender-Class:Subject:From:In-Reply-To:Date:Cc:References:To; b=EsLhnMtxSOMGnyBIuvSsXrjwUxZ6ndAferDW92cvY8pX7AId7QN90s7kmQhRECJCL EcS2l0ESa+j+79ODnVxA5gqHMhV9dwXPswhQvA2qRnlL5fK9KX/6SGAut02zvGXfFE c3Ri7ORF6UV/+2bqIejkpbgvbOqkx9JlzUE2PSMU=
X-UI-Sender-Class: 01bb95c1-4bf8-414a-932a-4f6e2808ef9c
Received: from hms-beagle2.lan ([77.10.100.216]) by mail.gmx.com (mrgmx005 [212.227.17.190]) with ESMTPSA (Nemesis) id 1MFbW0-1ihCCm2QzW-00H9pm; Sat, 09 Nov 2019 18:13:18 +0100
Content-Type: text/plain; charset="utf-8"
Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\))
From: Sebastian Moeller <moeller0@gmx.de>
In-Reply-To: <HE1PR07MB4425A148B5BB1E6FD8E5A3FBC27A0@HE1PR07MB4425.eurprd07.prod.outlook.com>
Date: Sat, 09 Nov 2019 18:13:12 +0100
Cc: "tsvwg@ietf.org" <tsvwg@ietf.org>, "tcpm@ietf.org" <tcpm@ietf.org>, "iccrg@irtf.org" <iccrg@irtf.org>, Ingemar Johansson S <ingemar.s.johansson@ericsson.com>, "koen.de_schepper@nokia.com" <koen.de_schepper@nokia.com>
Content-Transfer-Encoding: quoted-printable
Message-Id: <2083E62F-0E6D-40B1-B726-A198BFA36220@gmx.de>
References: <HE1PR07MB4425A148B5BB1E6FD8E5A3FBC27A0@HE1PR07MB4425.eurprd07.prod.outlook.com>
To: Ingemar Johansson S <ingemar.s.johansson=40ericsson.com@dmarc.ietf.org>
X-Mailer: Apple Mail (2.3445.104.11)
X-Provags-ID: V03:K1:9Uq5TBBEIW+d23IvyGkJktdGse9NtX48Sg+WtW8OZEiNfa71l6/ cSV7Rl3lTNKrSO2x54OPo4wsp3GB0AXx+W/9LJZJaZ4ekcsH2lGEr7GZqQdYYm/iBAxSZiZ WctQdEhX+RXdZ6QsR4ISkadFys0zScl5ZxJbDmq4EewSTROmtu1SUku0daf6CwxXk9OEs1V IXu0yygcpxZvRQpDpLLmg==
X-UI-Out-Filterresults: notjunk:1;V03:K0:/xBilaWombg=:iEcapDolwgBrICpHZxzFwG 9SXzFiCFEYTYUSyJKDIuoEWyc3W7NyaYtjYVwQJcU8VbX6WZ/RYVVHznDEtooTDXDgmLf1iDM na55K0T60wvqhbuExv0MdSr/7Sb0sQNc+nl+YhGxjzH+KzGXWymXZg0KaPyd1AILOJlvnCKg0 hG4rKlbBAYV5o/Y2c4AqWWSLW/AZOqoJv38+hLOjJcO3hKzpGZbfNS3VwhpdKRjn6mHAvzY+O MIeu45IT5YDOTYUiGb47YjNVBGlZ9tWSAxoU/K62kksPexxbIOonE6eLU5BjHj033haWzyIWc lZ+62cWTMisYeYAzXTSjpEpytcbngDQpty26DIGRS6LV2rQUKiwJ0actF1op7tmVgbbiRVGUe KVAbd8boqm4O9RuJOWHLzLb3WPtI455HgebAItEDNsunz6leXmyf8YsbuQ2ngHLOUi34L3F8t T00sKGUohIhZpZu/n7X+U2kzqiSP9rILbgFFHvB2P9bZMGRLGzLyqn2zRCpI10UdTkMdrthG4 9MyhAcDa690JmnlUaEz1b1kKvjHdh9IdOKmH5XhPL+cHbAWNJUiQU5NWJToz1CIrFJgpkBq4S LisX6uLDL4d/HVFicRy9+ggHx2qmA+FC1FcUIPU8q903LZ8U25+IW3MVYLgw8lHkiCuzGGR9/ W7b+mF19fzGdoZ2Uobv2RyMPOaP09A+7pt3Hyd+JZKuWKXTtnSkeTOvYS1cbTQoC928NMLude JE8MCN6SeZgiHiiDOiqlpFe13QbeBBqfXBXCK8OvwqnU84vmv9Dtaml+I1tPLYaBcL/i2Uzd7 JpC1hEB+fCktQ62eGEh4t67s0d/MW+csdzh0sgh1n/VvXgTUs8g6B6bEdZd+s8laXujmULUdH lPlDaZJRvp3j6PrNwvX5QKUnonQpGz50KrxHcKjqH6QgBmbTAwSEGeiGdioFYCfOoym8yh42V hp+ZnHI2DYmwg2gnHuh7Gk7INxCG1qbDQWy+FkCM0TysZr64mgXemFN1jAAZZlx1/+erCjC5X 4LioOIRAIpZFdNFzmp065INjMBQ7lTU8QfNULplE+o7Wzc7zDhVm6rOrbyH+l0ragpbJD4MJt 3fP2uzQ+CFZaglsgS9CXHUUrFstYbCrII70PZBBA6MbjN11VPdPZ6kofQA8jmO2JRgm/FJoVD 1oUN43gU6/9hMg8uVVrsbM59r6ehih/HfcNBStzS0CdXvxxYgqPQrRGPcf3DbnT70FW0HQ8Xt mySERvKDsz8oCrRjBX0fe9wZiU10pPCVuCSSMSilyayh5l2/qeL+yGIA6e2g=
Archived-At: <https://mailarchive.ietf.org/arch/msg/tcpm/ncn7NU1RvH_JyyiV7oR_IuBQs8U>
Subject: Re: [tcpm] [tsvwg] L4S related activity in 3GPP
X-BeenThere: tcpm@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: TCP Maintenance and Minor Extensions Working Group <tcpm.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tcpm>, <mailto:tcpm-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/tcpm/>
List-Post: <mailto:tcpm@ietf.org>
List-Help: <mailto:tcpm-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tcpm>, <mailto:tcpm-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sat, 09 Nov 2019 17:13:33 -0000

Dear Ingemar,

thanks for posting this. I read "This document describes an Active Queue Management mechanism, ‘L4S’, that can support low-latency services in a way that does not degrade the performance of other traffic." and I wonder whether 3GPP has run any experiments to confirm/support this claim, that you are willing to share?

Sidenote: in the powerpoint file it says about L4s " Standardized in IETF [1]", which seems premature, in the process of being standardized seems a better description of the status quo...


I ask about test data from your side as the recent test data is quite sobering from a number of angles, including quality of isolation:

	Looking at the current L4S tests from the various testbeds I see severe breakdown of the promised isolation between bulk and the "low-latency" queue, apparently making the current implementation, if not the concept itself IMHO unfit for release into the wider internet, before these issues have been sufficiently addressed. Especially the observation that the weighted scheduler built in as a safety mechanism in the dualQ aqm seems to trigger considerably more often than expected/predicted from reading the dualQ draft (giving 1/16 of the bandwidth to on of two classes _might_ be justified as a temporary stop-gap measure in extremely unlikely cases, but this already triggers in a simple one-flow-per queue scenario at low RTTs). In short it currently looks like the "does not degrade performance of other traffic" part is not yet finished. 

	To illustrate my criticism, here is a link to a test comparing the simplest functionality test imaginable, running one L4S-style and one non-L4S-style TCP connection through the L4S dual queue AQM at a intranet like RTT (nomnally 0ms, but in reality):
https://l4s.cablelabs.com/l4s-testing/key_plots/batch-l4s-s1-2-cubic-vs-prague-50Mbit-0ms_var.png
As can be seen the L4S flow (labeled prague) ends up very quickly taking ~90% of the available bandwidth, leaving only 10% to the non-L4S flow (labeled cubic), wit increasing RTT this bias gets less extreme, but even at 80ms the prague flow still gets around 1.5 times the bandwidth of the cubic flow (https://l4s.cablelabs.com/l4s-testing/key_plots/batch-l4s-s1-2-cubic-vs-prague-50Mbit-80ms_var.png), indicating an RTT dependent performance degradation for "other traffic". Test from another testbed confirm the break-down of fairness between L4S and non-L4S traffic at short RTTs (https://www.heistp.net/downloads/sce-l4s-bakeoff/bakeoff-2019-09-13T045427-r1/l4s-s1-2/batch-l4s-s1-2-cubic-vs-prague-50Mbit-0ms_fixed.png).



	Personally, I can not help thinking that it might be better to first make sure there is a complete, real-world tested implementation that reliably demonstrates that dualQ delivers the required isolation between the two traffic classes and that the L4S approach actually delivers the reported reliable low latency performance under adverse real-world conditions while not degrading the performance of other traffic, before trying to codify L4S into RFCs.


Best Regards
	Sebastian


> On Nov 9, 2019, at 17:00, Ingemar Johansson S <ingemar.s.johansson=40ericsson.com@dmarc.ietf.org> wrote:
> 
> Gentlepeople!
>  
> This 3GPP SA2 contribution is recently submitted
> https://www.3gpp.org/ftp/tsg_sa/WG2_Arch/TSGS2_136_Reno/Docs/S2-1911250.zip
> Title “5QI values for efficient handling of congestion control marked IP packets”
> The contribution introduces L4S to the SA2 audience and explains where the technology is useful. The contribution also proposes a method to bake L4S into the 5G QoS framework.
> If agenda time permits, it will be discussed at the SA WG2 meeting in Reno on Nov 18-22, hopefully with good results. 
>  
> Also a RAN2 contribution was submitted and discussed at an earlier RAN2 meeting.
> https://www.3gpp.org/ftp/TSG_RAN/WG2_RL2/TSGR2_107bis/Docs/R2-1913888.zip
>  
> Enjoy
> /Ingemar
> ================================
> Ingemar Johansson  M.Sc. 
> Master Researcher
>  
> Ericsson Research
> Network Protocols & E2E Performance
> Labratoriegränd 11
> 971 28, Luleå, Sweden
> Phone +46-1071 43042
> SMS/MMS +46-73 078 3289
> ingemar.s.johansson@ericsson.com
> www.ericsson.com
>  
>       The best way to find out if you 
>   can trust somebody is to trust them               
>               Ernest Hemingway
> =================================