IETF Logo Mail Archive

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

Greg White <g.white@CableLabs.com> Thu, 04 April 2019 15:37 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 ACAAD120645 for <tsvwg@ietfa.amsl.com>; Thu, 4 Apr 2019 08:37:07 -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 bgFl24pLbvmN for <tsvwg@ietfa.amsl.com>; Thu, 4 Apr 2019 08:37:05 -0700 (PDT)
Received: from NAM02-CY1-obe.outbound.protection.outlook.com (mail-eopbgr760134.outbound.protection.outlook.com [40.107.76.134]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2C2E112064A for <tsvwg@ietf.org>; Thu, 4 Apr 2019 08:37:05 -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=IjQEgpijuwnBNI8y/3jWXSa9t1sbjoZ5MgRNvyMB/W4=; b=G9E4XEYxsBbOnxD1oA0dIFnBWXPARXK9a5LYQiO5i6Kh/Ywrm2EKbL3gkFYhJ9tbbRgTdyYR0iErMfBi8EQC/VP+c0RvrE+psoJgwRLZjCOgvgQxeeyVfvkhjfmwdvD4QcbebQ/xuT234sqgot4Y5uDkilSsQ8aaKmGATtFYKw8=
Received: from SN6PR06MB4655.namprd06.prod.outlook.com (52.135.117.85) by SN6PR06MB4736.namprd06.prod.outlook.com (52.135.117.146) 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 15:37:02 +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 15:37:02 +0000
From: Greg White <g.white@CableLabs.com>
To: Jonathan Morton <chromatix99@gmail.com>
CC: Bob Briscoe <in@bobbriscoe.net>, "iccrg@irtf.org" <iccrg@irtf.org>, Sebastian Moeller <moeller0@gmx.de>, tsvwg IETF list <tsvwg@ietf.org>
Thread-Topic: [iccrg] [tsvwg] IETF104 ICCRG TCP Prague presentation
Thread-Index: AQHU6ksFATQlV6AwuEyVhJCWJn+a66YrJhqA////44CAAKshgIAABXQAgABeGYA=
Date: Thu, 04 Apr 2019 15:37:02 +0000
Message-ID: <817A985F-2974-4755-B294-8CEEBFCAC744@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> <2491A216-4522-4942-BDEB-301D61CC5D03@gmail.com> <FD7FA874-3413-4F62-81CB-0F68B9038CC7@cablelabs.com> <B0F75E09-9264-4AC0-BF35-F084CC6213FC@gmail.com>
In-Reply-To: <B0F75E09-9264-4AC0-BF35-F084CC6213FC@gmail.com>
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: [77.76.75.108]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: ca302598-9ea2-42e0-b902-08d6b913625c
x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600139)(711020)(4605104)(2017052603328)(7193020); SRVR:SN6PR06MB4736;
x-ms-traffictypediagnostic: SN6PR06MB4736:
x-microsoft-antispam-prvs: <SN6PR06MB4736E70FC56B0509646CD5BFEE500@SN6PR06MB4736.namprd06.prod.outlook.com>
x-forefront-prvs: 0997523C40
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(346002)(366004)(376002)(136003)(39850400004)(396003)(189003)(199004)(1411001)(82746002)(53936002)(6116002)(97736004)(8936002)(229853002)(102836004)(25786009)(6916009)(186003)(6506007)(86362001)(53546011)(5660300002)(71200400001)(8676002)(106356001)(478600001)(105586002)(93886005)(14454004)(81156014)(33656002)(36756003)(81166006)(76176011)(99286004)(71190400001)(68736007)(26005)(6246003)(446003)(7736002)(476003)(305945005)(2906002)(3846002)(66066001)(11346002)(256004)(316002)(486006)(83716004)(58126008)(54906003)(6512007)(6486002)(4326008)(2616005)(6436002)(85282002); DIR:OUT; SFP:1102; SCL:1; SRVR:SN6PR06MB4736; H:SN6PR06MB4655.namprd06.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A: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: WLDHTtNDS9Tqpg4KyzJ0k0rM6xoW3IPWDD29zqC80Cpi95btzoJ1HWCsWGMxgRs3s1hvQZIUoP45Znq3NYnmgychfcpJ9ONl97esEgGe236+zXCHw4nVvVKVNCmbTDCjjriKb9v0vG8b6fEzuJJciMytw/hIj9ztmytdFJcNyPCPRtamtc3kZbnpgwbnwIJomWJy9419mOkWwhn9lFweoDSZeHQLFbldAhxjW9khTtqaBasJQUrSJNZglsO2R8yotKvvd1/le7igif2EmsUqBZtdVMVkybvco80/++q63oGxm+sYZXzLrNRjxLpTl0VarwqdENDwWR5mpB/Y/SkYehh8DZUly0JVlRQfkwGRbQsexVRO99JNO+YtnPFvCA7B5D2wp+FKh3wydIQCu7clWahSiPCt87iulcPonSFWJFY=
Content-Type: text/plain; charset="utf-8"
Content-ID: <64B65CC8C0DF554A8763BBF04F4E283E@namprd06.prod.outlook.com>
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-OriginatorOrg: cablelabs.com
X-MS-Exchange-CrossTenant-Network-Message-Id: ca302598-9ea2-42e0-b902-08d6b913625c
X-MS-Exchange-CrossTenant-originalarrivaltime: 04 Apr 2019 15:37:02.3753 (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: SN6PR06MB4736
Archived-At: <https://mailarchive.ietf.org/arch/msg/tsvwg/EOtuqhiUfVDo8VQA57T3LRuLACw>
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 15:37:13 -0000

On 4/4/19, 12:00 PM, "Jonathan Morton" <chromatix99@gmail.com> wrote:

    > On 4 Apr, 2019, at 12:40 pm, Greg White <g.white@CableLabs.com> wrote:
    > 
    > I don't doubt that the SCE signaling method could be used in a variant of DCTCP, but the *huge* downside is that it can only work on bottleneck links that are able (or willing) to support FQ, which will be precious few.
    
    Let me stop you right there.  You are remembering a discussion we had at least two weeks ago, based on an early concept of SCE which has since been superseded.
    
    We have running code which converges rapidly to fairly sharing the link between two SCE flows, with only a single-queue SCE-aware AQM.  That is, we used the "besteffort" and "flowblind" modes of Cake, which disable its Diffserv and flow-isolation capabilities, specifically to test that aspect of our work.  Since our prototype SCE response is DCTCP-like, that result should not be a surprise to you.
    
    We *also* believe we have a solution for fairly sharing a single queue between SCE and non-SCE flows.  We haven't implemented and tested it yet, however.  Work continues.
    

[GW] Fairly sharing the link wasn't the concern that I was alluding to by saying that SCE only works with FQ.  My presumption was that this would be possible.   My concern is that the SCE sender gets *zero* benefit from supporting SCE signaling unless the bottleneck link is an FQ link.   In my view the IETF should not consider burning the last code point for such a limited purpose.  The L4S definition provides *value* (i.e. ultra-low latency) when the bottleneck is either FQ or DualQ.

v2.23.0 | Report a Bug | By Email