IETF Logo Mail Archive

Re: [tsvwg] [iccrg] IETF104 ICCRG TCP Prague presentation

Greg White <g.white@CableLabs.com> Thu, 04 April 2019 17:06 UTC

Return-Path: <g.white@CableLabs.com>
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 053141201DC for <tsvwg@ietfa.amsl.com>; Thu, 4 Apr 2019 10:06:25 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level:
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, 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=cablelabs.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 GiEigdm93T7L for <tsvwg@ietfa.amsl.com>; Thu, 4 Apr 2019 10:06:23 -0700 (PDT)
Received: from NAM03-CO1-obe.outbound.protection.outlook.com (mail-eopbgr790127.outbound.protection.outlook.com [40.107.79.127]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0BB0B120104 for <tsvwg@ietf.org>; Thu, 4 Apr 2019 10:06:22 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cablelabs.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=okr8I2vE4XkUoLkaPUBGQ9LvgbpidJupCdijcDUaSXM=; b=QmYjtE3v0X7iv/WTCAxzEZQk8OPf1I5aDzKC7nUic526eIXLNiMP7NAL4JKTfRUNVxwOh8KPKN6Rlu+1FTRNk2vfA6MyaNCE0Ip9rVTsG6CCmKqfNmq6Nma87yLa7c87+uUO+ly04uLVFxNFsKyQgtRQOlhGkFPJmrfgDVMHrAE=
Received: from SN6PR06MB4655.namprd06.prod.outlook.com (52.135.117.85) by SN6PR06MB4607.namprd06.prod.outlook.com (52.135.115.93) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1750.17; Thu, 4 Apr 2019 17:06:18 +0000
Received: from SN6PR06MB4655.namprd06.prod.outlook.com ([fe80::75ce:14bc:e5e2:573c]) by SN6PR06MB4655.namprd06.prod.outlook.com ([fe80::75ce:14bc:e5e2:573c%6]) with mapi id 15.20.1750.021; Thu, 4 Apr 2019 17:06:18 +0000
From: Greg White <g.white@CableLabs.com>
To: Sebastian Moeller <moeller0@gmx.de>
CC: Jonathan Morton <chromatix99@gmail.com>, Bob Briscoe <in@bobbriscoe.net>, "iccrg@irtf.org" <iccrg@irtf.org>, tsvwg IETF list <tsvwg@ietf.org>
Thread-Topic: [iccrg] [tsvwg] IETF104 ICCRG TCP Prague presentation
Thread-Index: AQHU6ksFATQlV6AwuEyVhJCWJn+a66YrJhqAgACn9oCAAH+LAA==
Date: Thu, 04 Apr 2019 17:06:18 +0000
Message-ID: <AD99A4E5-B7F9-49CC-BFAC-E33DDD97BCCC@cablelabs.com>
References: <623CA1C6-3425-46E6-AFD9-6FD7D0DBE422@gmx.de> <a7bf3c8d-bb9e-e7e8-3343-ccdbac795591@bobbriscoe.net> <82B40A22-F2C2-4D56-868A-F53D7AEA37D7@gmail.com> <4507BFFD-A68A-4E8A-8FFB-347F95E3F2E8@cablelabs.com> <59D6B58C-C966-493C-B3B9-CAD3AD7AD5F9@gmx.de>
In-Reply-To: <59D6B58C-C966-493C-B3B9-CAD3AD7AD5F9@gmx.de>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
user-agent: Microsoft-MacOutlook/10.14.0.181208
authentication-results: spf=none (sender IP is ) smtp.mailfrom=g.white@CableLabs.com;
x-originating-ip: [176.12.107.132]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: ce942540-7bdf-488b-7bf6-08d6b91fdabb
x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(5600139)(711020)(4605104)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(2017052603328)(7193020); SRVR:SN6PR06MB4607;
x-ms-traffictypediagnostic: SN6PR06MB4607:
x-microsoft-antispam-prvs: <SN6PR06MB460740D466F57EA5B5564440EE500@SN6PR06MB4607.namprd06.prod.outlook.com>
x-forefront-prvs: 0997523C40
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(376002)(136003)(39850400004)(396003)(366004)(346002)(199004)(189003)(476003)(97736004)(486006)(82746002)(446003)(33656002)(11346002)(36756003)(2616005)(2906002)(5660300002)(14454004)(26005)(68736007)(6916009)(3846002)(6116002)(25786009)(4326008)(76176011)(81166006)(81156014)(256004)(6506007)(99286004)(71200400001)(8936002)(71190400001)(229853002)(102836004)(6246003)(83716004)(93886005)(186003)(54906003)(316002)(6512007)(53936002)(478600001)(66066001)(7736002)(106356001)(58126008)(86362001)(6436002)(305945005)(105586002)(6486002)(53546011)(8676002)(85282002); DIR:OUT; SFP:1102; SCL:1; SRVR:SN6PR06MB4607; H:SN6PR06MB4655.namprd06.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1;
received-spf: None (protection.outlook.com: CableLabs.com does not designate permitted sender hosts)
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam-message-info: iVFLwozEVT6jFQhmTC6xgGvJTplG1V+u1rupRLGaekxzRlQL1qMWAafHCBEG4C4OfSgJenRYvwkRh1X+rZ/CEq4LD3d7qQw7t2inGGVgZ7S1NhamodpTCCGFvFNoiuP2gjMlXx0NuoU/H/O+8dVkFJiAFtwJbqWQq05jmz7pHwpmemBYbeGlyALCh4g+84Aneewr0YTNim6tf3/+611k7mRyLUhRtdTM9XDyUH2bEjU/iyiuEPhbHur+27zFhhGH9Xg377XUOvsjP2JymewJbg3oAcz/fdaz1AFbpuJJ07SiOWlhaOH6sKGDi21rIZVjBPZPesw/S5MBZAuwJ1K8aavmSboDvmmNvLvwL7LO2rmf4uZY5C97/jpP+td4WzPq5BLwvPN8VVa4M+gwzGW5tNgICGy/0SZDhNLcM9XUgiI=
Content-Type: text/plain; charset="utf-8"
Content-ID: <D9D1D83BD93F3C4FBD8B86CFFC25C9D9@namprd06.prod.outlook.com>
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-OriginatorOrg: cablelabs.com
X-MS-Exchange-CrossTenant-Network-Message-Id: ce942540-7bdf-488b-7bf6-08d6b91fdabb
X-MS-Exchange-CrossTenant-originalarrivaltime: 04 Apr 2019 17:06:18.2857 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: ce4fbcd1-1d81-4af0-ad0b-2998c441e160
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-Transport-CrossTenantHeadersStamped: SN6PR06MB4607
Archived-At: <https://mailarchive.ietf.org/arch/msg/tsvwg/lresBXGfn0O4do5WjfmLsbyK3_A>
Subject: Re: [tsvwg] [iccrg] IETF104 ICCRG TCP Prague presentation
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, 04 Apr 2019 17:06:25 -0000

On 4/4/19, 11:29 AM, "Sebastian Moeller" <moeller0@gmx.de> wrote:

    Hi Greg,
    
    [SM]: I happen to believe that head-end AQM will ameliorate the need for an ingress AQM for a lot of casual users, but all those that are constantly running against capacity limits (think ADSL) typically desire a more fine-grained prioritization than a head-end AQM is going to offer, includsing restricting bandwidth to certain proiorety classes to say keep latency increas for game traffic tightly bound. I believe in that case the guarantees L4S offers are not sufficient, as the gaming case requires "guaranteed bandwidth at a certain latency level" as compared to the low_queueung latency guarantee L4S offers (which basically moves the que back into the sending end-host, which is fine, but all it does not help if I need to send @ X Hz).
    
[GW]  In an L4S world, there is nothing that prevents a user running an "ingress AQM" of their choice with whatever traffic controls they like (as long as the ECT(1) implementation lines up with the L4S definition, which is totally doable in fq_codel and CAKE).    The issue we have been discussing is where the user is running an old version of fq_codel/CAKE that hasn't been updated to the L4S version of ECT(1).  In that case, the L4S traffic would see worse queuing latency than classic TCP.


[...]
    > [GW] Alternatively, if fq_codel/CAKE were to treat ECT(1) as non-ECT (or implement the L4S style ECN) this would again not be an issue, I believe.  
    
    [SM] I believe this to be just as viable as having L4S AQMs interpret ECT(1) as pulse-modulated continuous congestion information. [...]

[GW] How?  That seems impossible to me.  What is the classifier that directs traffic to the LL queue vs Classic?

v2.23.0 | Report a Bug | By Email