[tsvwg] Fwd: Qs on your 5G L4S slides

Bob Briscoe <ietf@bobbriscoe.net> Wed, 10 March 2021 17:41 UTC

Return-Path: <ietf@bobbriscoe.net>
X-Original-To: tsvwg@ietfa.amsl.com
Delivered-To: tsvwg@ietfa.amsl.com
Received: from localhost (localhost []) by ietfa.amsl.com (Postfix) with ESMTP id 02E793A1455 for <tsvwg@ietfa.amsl.com>; Wed, 10 Mar 2021 09:41:25 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.432
X-Spam-Status: No, score=-1.432 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, HTML_MESSAGE=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 ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id K1Xu7XYc09MQ for <tsvwg@ietfa.amsl.com>; Wed, 10 Mar 2021 09:41:23 -0800 (PST)
Received: from mail-ssdrsserver2.hosting.co.uk (mail-ssdrsserver2.hosting.co.uk []) (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 1CDB53A144F for <tsvwg@ietf.org>; Wed, 10 Mar 2021 09:41:22 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=bobbriscoe.net; s=default; h=Content-Type:In-Reply-To:MIME-Version:Date: Message-ID:From:To:References:Subject:Sender:Reply-To:Cc: Content-Transfer-Encoding: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=04FvZm80U2kVTdJPKLe0xM4r8oz0I4IdNKmFlsFrYRo=; b=cH0Jw9ZopN7FuBuGddAL3qywC OXgCGRriG3Ar1TtKdI1QedphB9/T5CgyYIdAZiA6EAs9a5ZsYxN+rgSC9HYKAtRjyilp4ffMuWfym p/OshADU6ttTz5wFDWtsrWnkkxbYFonj4xWzmteDR5U6jD2+8dPetTYSRsNK5Luih6UHYMIUAxLGM BGGvjWBoHqf4eozjKvlJyE3C73cabo1WPrMvGmCkbtmHzvmpX9hK6l1lUm20v/7xu9HyIRcjzeXrN 7fiam3sf2kZOwixwEJDIvp9tFZrS8nTF4N4fVQpLd0iSou31wxrSL4aqL1FPIZnf2Aq8SQuTS2WR0 UQYKCLotw==;
Received: from ([]:44916 helo=[]) 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 1lK2pl-0000nT-Nq for tsvwg@ietf.org; Wed, 10 Mar 2021 17:41:21 +0000
References: <HE1PR0701MB22994BB36811BDAB98F464B9C2919@HE1PR0701MB2299.eurprd07.prod.outlook.com>
To: tsvwg IETF list <tsvwg@ietf.org>
From: Bob Briscoe <ietf@bobbriscoe.net>
X-Forwarded-Message-Id: <HE1PR0701MB22994BB36811BDAB98F464B9C2919@HE1PR0701MB2299.eurprd07.prod.outlook.com>
Message-ID: <4cf84500-756f-9da9-81d2-b29e1aebad4a@bobbriscoe.net>
Date: Wed, 10 Mar 2021 17:41:20 +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: <HE1PR0701MB22994BB36811BDAB98F464B9C2919@HE1PR0701MB2299.eurprd07.prod.outlook.com>
Content-Type: multipart/alternative; boundary="------------B796C6E393271C341FA16398"
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
Archived-At: <https://mailarchive.ietf.org/arch/msg/tsvwg/JvEdDofvToWAaIcL1Umg7oaDvhk>
Subject: [tsvwg] Fwd: Qs on your 5G L4S slides
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: Wed, 10 Mar 2021 17:41:25 -0000


Fwd'ing to list, with permission...
In case anyone else had the same questions

-------- Forwarded Message --------
Subject: 	RE: Qs on your 5G L4S slides
Date: 	Wed, 10 Mar 2021 14:33:42 +0000
From: 	Ingemar Johansson S <ingemar.s.johansson@ericsson.com>
To: 	Bob Briscoe <research@bobbriscoe.net>
CC: 	Ingemar Johansson S <ingemar.s.johansson@ericsson.com>

Please see inline [IJ]


> -----Original Message-----
> From: Bob Briscoe <research@bobbriscoe.net>
> Sent: den 10 mars 2021 14:46
> To: Ingemar Johansson S <ingemar.s.johansson@ericsson.com>
> Subject: Qs on your 5G L4S slides
> Ingemar,
> #5 "Dedicated bearer / QoS flow for L4S traffic"
> Is this a per-app microflow or a per-user flow?
[IJ] It is per-user flows, i.e each bearer can handle many flows

> And I think you'll need to explain where the UPF is typically located. 
> I believe
> it's close to the edge, isn't i?
> Further into the network (beyond the UPF) these flows just become an
> aggregate of all the users.
[IJ] The UPF is close to the edge somehow, it is hard to say for certain 
where they are located, they can be real close to the base stations or 
 >100km away.

> #6 Question:
> Do you have any feel for qDelay & throughput if a "Classic ECN AQM" 
> like PIE
> or CoDel was used?
[IJ] No, it was not studied in the master thesis work.

> #6 - #11:
> Is the DBS scheduler between users, or between flows?
[IJ] Per user (bearer)

> #12: L4S is meant to greatly reduce the throughput-delay tradeoff, and 
> in our
> results it did.
> Any idea why not here? I guess, with video, it's the 'getting up to 
> speed' fast
> problem (that I'm working on with Joakim).
[IJ] One reason is the large variation in frame sizes that video coders 
Another is that SCReAM paces out the video frames as 50% higher rate 
than the nominal video target bitrate. This pacing overhead can be 
configured lower but then the video frames (RTP packets) are more likely 
to become queued up in the sender instead. I really believe that it can 
be done better, was hoping to have time to improve SCReAM in this 
respect but the work hours fly in other directions .
With that said. Also a DCTCP flow (with L4S) marking will get a reduced 
throughput compared to e.g a Cubic flow (without L4S) over cellular. The 
reason is that the large buffers with Cubic absorb the fast fading dips 
in LTE and NR. With DCTCP + L4S some extra headroom is needed to avoid 
queue build up.

> Bob
> --
> __________________________________________________________
> ______
> Bob Briscoe https://protect2.fireeye.com/v1/url?k=828d3ddc-
> dd1604f1-828d7d47-8692dc8284cb-1ab58b5eb7943901&q=1&e=b0160f51-
> 6418-41ea-9221-efaca6b7cec8&u=http%3A%2F%2Fbobbriscoe.net%2F