IETF Logo Mail Archive

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

Greg White <g.white@CableLabs.com> Thu, 04 April 2019 17:29 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 A2F701201CC for <tsvwg@ietfa.amsl.com>; Thu, 4 Apr 2019 10:29:32 -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 uZBWV1mF5tCy for <tsvwg@ietfa.amsl.com>; Thu, 4 Apr 2019 10:29:30 -0700 (PDT)
Received: from NAM05-DM3-obe.outbound.protection.outlook.com (mail-eopbgr730095.outbound.protection.outlook.com [40.107.73.95]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 276F31204D7 for <tsvwg@ietf.org>; Thu, 4 Apr 2019 10:29:17 -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=x0PdqJMrNbGiFP/5m+zkuU4etXzblhbV0meDtD+3gaE=; b=Qlfo0/oW07+Oj1PQPkRnouAYxCWynE5yeLos6p35d5/G55fSwZ3zX1gX3pygSuXmmqV7AVouYyLut3ZybnnehwQC5DtsSz/rKZRGgYCPt+nmiTTgCXdPMIJvEiyU2EKBAxIlaVlWSj/TOUez3vc3keVSTEvISBsBB3eF/cmFE5g=
Received: from SN6PR06MB4655.namprd06.prod.outlook.com (52.135.117.85) by SN6PR06MB6383.namprd06.prod.outlook.com (20.177.254.150) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1771.13; Thu, 4 Apr 2019 17:29:14 +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:29:14 +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////44CAAKshgIAABXQAgABeGYD///D9gIAALlQA
Date: Thu, 04 Apr 2019 17:29:13 +0000
Message-ID: <8008B232-8E76-4E2B-8DEE-5C6A5391D0B1@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> <817A985F-2974-4755-B294-8CEEBFCAC744@cablelabs.com> <019569E3-9D93-41B9-8D0A-D1E3501D9B3D@gmail.com>
In-Reply-To: <019569E3-9D93-41B9-8D0A-D1E3501D9B3D@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: [176.12.107.132]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: d86c31f3-875b-4734-16ba-08d6b9230ea5
x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(5600139)(711020)(4605104)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(2017052603328)(7193020); SRVR:SN6PR06MB6383;
x-ms-traffictypediagnostic: SN6PR06MB6383:
x-microsoft-antispam-prvs: <SN6PR06MB6383E843399F12B44E513BD1EE500@SN6PR06MB6383.namprd06.prod.outlook.com>
x-forefront-prvs: 0997523C40
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(39850400004)(136003)(346002)(396003)(376002)(366004)(189003)(199004)(6486002)(71200400001)(4326008)(5660300002)(71190400001)(8936002)(82746002)(1411001)(256004)(6436002)(99286004)(4744005)(305945005)(7736002)(97736004)(229853002)(6246003)(14454004)(478600001)(25786009)(33656002)(86362001)(66066001)(83716004)(93886005)(316002)(476003)(53936002)(2906002)(11346002)(81166006)(8676002)(6512007)(6916009)(58126008)(54906003)(68736007)(446003)(3846002)(6116002)(105586002)(53546011)(186003)(106356001)(102836004)(26005)(36756003)(6506007)(486006)(2616005)(76176011)(81156014)(85282002); DIR:OUT; SFP:1102; SCL:1; SRVR:SN6PR06MB6383; 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: LMO/AhG2tH+EWbHwEzLVOiMO+ix37b+rSMH53O0YYDkKmV4+6+JR70iKIMpTFObThux6L8bYCibX1J5KG6C3D79HTHG3O/phgDHXHgvUCukoN93hpaiv/73IMhRBVOyRAzAQvuMcA88PPdzo7youw9Omt/PHX7ZTKcJsBags8GtuxUsxpDQzZ52oD2wnMtpFhmHOtcyhehCinNzapDdzENlnlJwzu1frcTxcSXGOxw8Itk9c22LoWryhqyxn+VeuZm+/RgTEE+2Yr3RxvPqkVqhp2s6Vg+6atTSNctoubaguDz74y718OrVPCk8Jz8mamsPdweXHLMDXEmWxvgp0yfFNLPqqgZxVG3ynsUrQ/BtEQJH2U6RZhxpcE8v79RA3VQ4eHTNyOXSQBbuTIL0sI/QdY+AeO+146aJtEJY9g8s=
Content-Type: text/plain; charset="utf-8"
Content-ID: <24E658553D52CF45B296E8DF9ED1532E@namprd06.prod.outlook.com>
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-OriginatorOrg: cablelabs.com
X-MS-Exchange-CrossTenant-Network-Message-Id: d86c31f3-875b-4734-16ba-08d6b9230ea5
X-MS-Exchange-CrossTenant-originalarrivaltime: 04 Apr 2019 17:29:13.9277 (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: SN6PR06MB6383
Archived-At: <https://mailarchive.ietf.org/arch/msg/tsvwg/GKmPnI7Zly7Y9LMuimxqOWzG9Y4>
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:29:33 -0000

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

    > On 4 Apr, 2019, at 6:37 pm, Greg White <g.white@CableLabs.com> wrote:
    > 
    > My concern is that the SCE sender gets *zero* benefit from supporting SCE signaling unless the bottleneck link is an FQ link.
    
    Our early results suggest otherwise.  However, I would like to flesh them out before further detailed discussion.
    
 I will be interested to see how this is possible.  When an SCE sender and a non-ECT sender share a single queue, the non-ECT sender will be driving the queue delay to the classic AQM target, and the SCE sender will experience the same queue delay as the non-ECT sender.   I've not been able to imagine a dual queue implementation that can identify SCE senders so that they can achieve reliable ultra-low delay (unless you are suggesting that SCE senders are all required to mark their traffic with a particular DSCP).

v2.23.0 | Report a Bug | By Email