Re: [tcpPrague] [iccrg] Realistic Queue delay targets

Ingemar Johansson S <ingemar.s.johansson@ericsson.com> Mon, 02 November 2020 08:30 UTC

Return-Path: <ingemar.s.johansson@ericsson.com>
X-Original-To: tcpprague@ietfa.amsl.com
Delivered-To: tcpprague@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5E8193A0A6F; Mon, 2 Nov 2020 00:30:24 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.102
X-Spam-Level:
X-Spam-Status: No, score=-2.102 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.com
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 VZ1PLqEn3aYJ; Mon, 2 Nov 2020 00:30:22 -0800 (PST)
Received: from EUR01-HE1-obe.outbound.protection.outlook.com (mail-eopbgr130070.outbound.protection.outlook.com [40.107.13.70]) (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 17B583A0A6C; Mon, 2 Nov 2020 00:30:21 -0800 (PST)
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=nRb003sF5umqFZoONSvOfOrYZtRq6nQT0PcZ0iGXXKjPmu3Pye3UuRBqdCQKjge0An3yhDwp0l+tEXDXNbkrCDYmH/F2bj/LhzOvLJdd91pPh3s9mzNrYCG680KHV3EMSJ8maJsbtT/edSn0mI+cg5r9/zOq0H0YCExL8vFtcyk3aCwFXddgA6bk9Vvk47tz0q5c1q/uaPwuIsPpRwLVR6t/x1bxcapp7MitIaUt42lapaGpMxd1W23AdlrR+BVSnK2AgBa9+/hCJa4YfFtPbigpTdUJxWtyEIaIzCrhSjHceHNl5RMKSm0cgwZpSx8Q9MhNPXx6yWRNwP7YwClSaQ==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=vFjdvOYh59q8Q2gEjuEqPkBBywubzkXkTOFaVndgG9Q=; b=Jisttw2FSm7QR0Ccs2Rjc7M7wFvuguH7ONcIbSOojSmGnZZKxFySATIecugT1u67FTGz0oCEg4LB24SzsEFhFeek+5sJ5VDGazBhDa7ybb1893dnvPtF6W5Ey9GYhQnC+WZtJv1SmKHM5Ae5EM0bbEStmT4/o2tv6USIUDlrtj9IXBAW4lW39Ro5xvq30Y5xK7RKzbgpQRShcUXiU1mPP3o7G95EaMYiSy+tmXR6k7nx/zxJ3TG5c5FFvV0RSdDib3bP5zRsyg8l6bUU+C7eWG35JcynPRy99nPvdcBJ36/6RoOMeR4XRfF85W5PWVsJODHjf2ZTo1uzJD2S/eIWFQ==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=ericsson.com; dmarc=pass action=none header.from=ericsson.com; dkim=pass header.d=ericsson.com; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ericsson.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=vFjdvOYh59q8Q2gEjuEqPkBBywubzkXkTOFaVndgG9Q=; b=CtaRe7O6u/Vdb5b2Y5T8NkQNC4+emNDW0iTOY3pmFkkKuaFELQ9gaDeHgmhYRZx/3sagDiQCkfZeP9iFWEi0v0IcmEDWgr2fh5baENI1TUu3cF7OOj5Zb12JO5squKZV3xpfPT7q9UKTr68SnqIsmWpCAJJxCh9E79cwiYME3bY=
Received: from HE1PR0701MB2876.eurprd07.prod.outlook.com (2603:10a6:3:56::8) by HE1PR07MB4156.eurprd07.prod.outlook.com (2603:10a6:7:9b::16) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3541.10; Mon, 2 Nov 2020 08:30:15 +0000
Received: from HE1PR0701MB2876.eurprd07.prod.outlook.com ([fe80::a4a1:d6b5:1254:923a]) by HE1PR0701MB2876.eurprd07.prod.outlook.com ([fe80::a4a1:d6b5:1254:923a%11]) with mapi id 15.20.3541.011; Mon, 2 Nov 2020 08:30:15 +0000
From: Ingemar Johansson S <ingemar.s.johansson@ericsson.com>
To: "Rodney W. Grimes" <ietf@gndrsh.dnsmgr.net>, Bob Briscoe <ietf@bobbriscoe.net>
CC: Christian Huitema <huitema@huitema.net>, tsvwg IETF list <tsvwg@ietf.org>, iccrg IRTF list <iccrg@irtf.org>, TCP Prague List <tcpPrague@ietf.org>, "De Schepper, Koen (Koen)" <koen.de_schepper@nokia.com>, Ingemar Johansson S <ingemar.s.johansson@ericsson.com>
Thread-Topic: [iccrg] Realistic Queue delay targets
Thread-Index: AQHWsPJjPxAUbDfzuUaS/obDyN9yVQ==
Date: Mon, 2 Nov 2020 08:30:15 +0000
Message-ID: <HE1PR0701MB2876C75B0F58EDF71B4A3CD1C2100@HE1PR0701MB2876.eurprd07.prod.outlook.com>
References: <69a73308-6718-7304-be24-0eb84f77e50d@bobbriscoe.net> <202011012023.0A1KNkue011764@gndrsh.dnsmgr.net>
In-Reply-To: <202011012023.0A1KNkue011764@gndrsh.dnsmgr.net>
Accept-Language: sv-SE, en-US
Content-Language: en-US
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator:
authentication-results: gndrsh.dnsmgr.net; dkim=none (message not signed) header.d=none;gndrsh.dnsmgr.net; dmarc=none action=none header.from=ericsson.com;
x-originating-ip: [83.227.122.88]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: 36fd5d5e-9c57-4f2e-61df-08d87f09866a
x-ms-traffictypediagnostic: HE1PR07MB4156:
x-ms-exchange-transport-forked: True
x-microsoft-antispam-prvs: <HE1PR07MB41565486B9B39E1EF76384DFC2100@HE1PR07MB4156.eurprd07.prod.outlook.com>
x-ms-oob-tlc-oobclassifiers: OLM:10000;
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info: LydnCF40qvWbZFi2G2PntyakvWPy8xovcsfhv849uzFabUaG2fezcO+2PUENdOAPFX+18BG2Idy0kW0eDQT9Rxe0l7Wvp+pKdXqKMeeaBD1ly35FUG2x2UnqBVVzAIMe7SAmRtNOxO6YDfINwg9/MumrQmz2a86AgwsjL9rwFv9G8hGqbl4GNny4mah+mMLlVgZQ9u8XynWq/WEswXWawjgeIJe1sPBg/7xNAgyX67CeX/c4O8nwPfnUoFdw0bHA2MCp9R3UpDC75bFcduEu2emMxtIKy3EZXiKBEEFG/N0Beb9Kl7p3A6Ezf1sgY15mqkKEZU1UXBO7gKfH0XcgTCa7YiJOe2XCgTOQ637Qd051AMSkgiRb3YaRbHlYadYBlQED+3aGPIxfL+iiCLsquQ==
x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:HE1PR0701MB2876.eurprd07.prod.outlook.com; PTR:; CAT:NONE; SFS:(4636009)(136003)(39860400002)(376002)(346002)(366004)(396003)(33656002)(86362001)(4326008)(8676002)(8936002)(9686003)(5660300002)(71200400001)(7696005)(478600001)(966005)(55016002)(66574015)(83380400001)(66616009)(6506007)(53546011)(110136005)(186003)(99936003)(26005)(54906003)(107886003)(66556008)(66476007)(66946007)(52536014)(2906002)(76116006)(64756008)(66446008)(316002); DIR:OUT; SFP:1101;
x-ms-exchange-antispam-messagedata: bhjcO6ERRooPjYBK4uGwoqcgZe0XjFyZDeKAQVP3NP3c81nKhJxuPeWa5JWT8/LySEM0RPZ+sZvgKVMZkxMPed8+9ttlqUjnOenWOQG7NQtY4XSZalQnPIElr4TEwR+VWJtu4ypQdtIINOK8L1nemYH50CTkmSz8oGC2v8fDmfj2afxDSgiKs9Pp9iIg/hR0FDJWLJ975cEVepiSvW2I+0jG3M/uQxc8AB5QgGTwc5hnGodAeORpzfAX14VaPPqgbzYfznwShscrLrdgK/eCcla72ZmbMmGORJjs2nL0YSCOK4yInwQNvQ3Hw2cUYwJNWdCAC6bLrKPQsOZEjbzI9lTsqcWLUNe9DwMo3Wn00PRVZhiwOiVU9sXNiSEmjQeWqtsp6CSor7oDOYhzLyQBw5YvwwKieK/eEkIEoz1/2qmYjhE2j1pnlU63p5m4yl2++N7VYYMW3iVjCnyVMtiT0NPQ7zzsMDniGnVaP32LiBoAtQSiFI2LyJT7TJVYW87wmXkcqOITcdxhFtK4RYdwfd4GOIkxm2DZQ2+E47ASTulECRVHlFOYKTY+eF2Ban4cRPCd/zY8pCRgoBpLWSa9n+1ctHpCmsLgobAaYz3htjpbzUzSu+eHLcSvuGx/KncEVVnhldH/zmToRpzer5QbLQ==
Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="----=_NextPart_000_002D_01D6B0FA.C4CBA000"
MIME-Version: 1.0
X-OriginatorOrg: ericsson.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-AuthSource: HE1PR0701MB2876.eurprd07.prod.outlook.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 36fd5d5e-9c57-4f2e-61df-08d87f09866a
X-MS-Exchange-CrossTenant-originalarrivaltime: 02 Nov 2020 08:30:15.7388 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 92e84ceb-fbfd-47ab-be52-080c6b87953f
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: ca+LPbhRVXFMyLBg2J//qn8NJlKMAaxWCd6ucaHVITWMvY00+e/TN0X17rkh09szxyfedgbFB2XeV4WV17PHKXwOeGCqN/eo75+N+Hr9FgkSXUUkRS3M+I8touqThi/Q
X-MS-Exchange-Transport-CrossTenantHeadersStamped: HE1PR07MB4156
Archived-At: <https://mailarchive.ietf.org/arch/msg/tcpprague/zE7jdxJ6VQ7X0e3yf6_JCSBEpfo>
Subject: Re: [tcpPrague] [iccrg] Realistic Queue delay targets
X-BeenThere: tcpprague@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "To coordinate implementation and standardisation of TCP Prague across platforms. TCP Prague will be an evolution of DCTCP designed to live alongside other TCP variants and derivatives." <tcpprague.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tcpprague>, <mailto:tcpprague-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/tcpprague/>
List-Post: <mailto:tcpprague@ietf.org>
List-Help: <mailto:tcpprague-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tcpprague>, <mailto:tcpprague-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 02 Nov 2020 08:30:25 -0000

Hi Rodney

I believe part of the answer to your question is found in
https://tools.ietf.org/html/draft-ietf-tsvwg-l4s-arch-07#section-6.3 . The
fact that we begin to see the scheduling jitter does not invalidate L4S as a
means to reduce the congestion related jitter.

Scheduling jitter exist also in cellular technology. Scheduling jitter is
however generally not evidence of congestion. L4S congestion marking should
therefore be designed to not trigger on this. The master thesis** the L4S
marking threshold was set sufficiently high to avoid this but it should be
understood that L4S marking in cellular can be implemented in smarter ways.
In the master thesis, the L4S marker only inspected the queue on the RLC
layer.
There are other causes to delay jitter in cellular, HARQ retransmissions and
handover delays are two examples. There is work in progress to reduce all
kinds on delay jitter, L4S is a tool to reduce congestion related jitter.
In any case, non-congestion related jitter is not an argument against L4S

/Ingemar

**
https://kth.diva-portal.org/smash/record.jsf?dswid=-6303&pid=diva2%3A1484466
&c=1&searchType=SIMPLE&language=en&query=brunello&af=%5B%5D&aq=%5B%5B%5D%5D&
aq2=%5B%5B%5D%5D&aqe=%5B%5D&noOfRows=50&sortOrder=author_sort_asc&sortOrder2
=title_sort_asc&onlyFullText=false&sf=all 

> -----Original Message-----
> From: Rodney W. Grimes <ietf@gndrsh.dnsmgr.net>
> Sent: den 1 november 2020 21:24
> To: Bob Briscoe <ietf@bobbriscoe.net>
> Cc: Christian Huitema <huitema@huitema.net>et>; tsvwg IETF list
> <tsvwg@ietf.org>rg>; iccrg IRTF list <iccrg@irtf.org>rg>; TCP Prague List
> <tcpPrague@ietf.org>rg>; De Schepper, Koen (Koen)
> <koen.de_schepper@nokia.com>
> Subject: [iccrg] Realistic Queue delay targets
> 
> Bob,
> 
> > Christian,
> >
> > I've changed the subject line given it's no longer appropriate.
> > See inline tagged [BB]...
> 
> And I am changing it again... as only addressing a statement that I have
great
> concerns about.
> 
> See inline ragged [RWG]
> 
> > On 01/11/2020 01:07, Christian Huitema wrote:
> ... [ much text deleted ] ...
> 
> > [BB] Yes, once the IETF assigns the codepoint, BBRv2 will be 'allowed'
> > to send packets over the Internet as ECT(1). Then, yes, an L4S DualQ
> > Coupled AQM will classify BBRv2 packets into the L4S queue. This
> > should have a very shallow ECN marking threshold (500us - 1ms), so
> > even if the flow (whether QUIC or TCP) is flying just under the
> > available capacity, bunching of packets means it is unlikely to
> > completely avoid ECN marking between probes. If it could avoid ECN
> > marking, you are right that it would get a bump of ECN marks during
> > the probe. I haven't studied the code, but when it experiences ECN
> > marking I believe it switches into an L4S ECN mode for a while, and
> > uses ECN rather than delay probing to track available capacity. I
> > assume it switches back to BBR's delay probing mode if it gets no ECN
> > for a while (e.g. the bottleneck might have moved). But I haven't looked
at
> BBRv2's ECN behaviour in detail.
> 
>  [RWG] I have great concern about this 500uS to 1mS ECN marking threshold
> given that I have recently learned the latest WiFi standards actually run
with a
> packet aggregation time of 4mS thus making it probably impossible to have
> such traffic work in such a targeted low latency queue.
> 
>  [RWG] Has any consideration been given to what is already deployed on the
> Internet as link layer technologies that would preclude the operation of
the
> L4S low latency queue?
> 
> Regards,
> --
> Rod Grimes
rgrimes@freebsd.org
>