Re: [tsvwg] L4S vs SCE (Evolvability)

Greg White <g.white@CableLabs.com> Tue, 07 January 2020 00:09 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 5C9BF120110; Mon, 6 Jan 2020 16:09:41 -0800 (PST)
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 s16meJ11qjq5; Mon, 6 Jan 2020 16:09:39 -0800 (PST)
Received: from NAM10-MW2-obe.outbound.protection.outlook.com (mail-mw2nam10on2104.outbound.protection.outlook.com [40.107.94.104]) (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 4C1B91200CE; Mon, 6 Jan 2020 16:09:39 -0800 (PST)
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=aBEb3Fu8iUcN8uGPrcOPmuvMmek6XwggzIrsrSbZl9eSyqCTosCu3/yX3gajSAWQjfk6NxwQb3v0MjYcUBJz5WlMOsyiz7EfSWc4DTZN2q7lVNxISDqV7jsLcnSQYwy6zK8yNMDplmFmrurSf8mB7YVnDIsOQ9qdStGZGjOEPvNQ1a2J4g6M/YbY8zNajNJ6vesqs3RPPdYQo7mkgMowW0c4rQi/ZqLwx0ketgoxbYR8IObgk0537HLeyOTxxLHOYoOId2VCWyY3VYzXaIJNi42yUW4ThOqk4ZGAUjUBM3ww/8kFojJmc0iKqG1HFKl+4mADG045XTmHK4YhpmsZIw==
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=OM9ZYbkqkQp8MlkDo7UB0jB5VgaQa3ylg9+Gh2fcdSs=; b=J2dbwRkmccQotDIvda7CkZ9o9USxE7KDp4jzYuAVx+KBjho2FOPdGwMoudAVE2OD/yHhM0x2T8v8V8pX6rauKYyyZTTodwMbTLkqK7syiycfHF8RC0h7H95v0GFqL9EbLIoUO4OR5hDtZ1uq2q0AUeULq4/apmD32t434kF6E7AcK4Y06AU9aH4yEEa7/DMQWpkSeBE92FJGuixkSETYjLg6nqOBiXGgOSnTzinKzU9fKr9jcjjRyWq6HhL/uPuHsy2+tTcoWw4rmYN9kSG2KdFBh+U9hYKensc7YQDNBr5Xyz8IIZ5v0whfXCE9qzYxsHNmt042vWN8DId1DiGcMQ==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=cablelabs.com; dmarc=pass action=none header.from=cablelabs.com; dkim=pass header.d=cablelabs.com; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cablelabs.com; s=selector2; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=OM9ZYbkqkQp8MlkDo7UB0jB5VgaQa3ylg9+Gh2fcdSs=; b=MYAgIJqxjXdZLIyZiKWi05HBAomHZnefa2i7VUILn222aNBlF9sj44tQtzyZ1cT79W9GoTowkqx1JvsIDeoGXpMOtH4vLQd37Gfw7obVUQ6z3q1Tg5ZLjGTx7RYcMvNf+mO4In+GYs7W3CBrw7/rPDIZfmTXaM/YnU9GkUJIyEI=
Received: from SN6PR06MB4655.namprd06.prod.outlook.com (52.135.115.88) by SN6PR06MB4253.namprd06.prod.outlook.com (52.135.122.80) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2602.15; Tue, 7 Jan 2020 00:09:36 +0000
Received: from SN6PR06MB4655.namprd06.prod.outlook.com ([fe80::81b8:405c:df9d:6c35]) by SN6PR06MB4655.namprd06.prod.outlook.com ([fe80::81b8:405c:df9d:6c35%5]) with mapi id 15.20.2602.015; Tue, 7 Jan 2020 00:09:35 +0000
From: Greg White <g.white@CableLabs.com>
To: "Black, David" <David.Black@dell.com>, Bob Briscoe <ietf@bobbriscoe.net>
CC: "tsvwg@ietf.org" <tsvwg@ietf.org>, "tsvwg-chairs@ietf.org" <tsvwg-chairs@ietf.org>
Thread-Topic: [tsvwg] L4S vs SCE (Evolvability)
Thread-Index: AQHVwC+mH7O5uJBW8E26wWCyHEHI+afWdvOAgAhtEYA=
Date: Tue, 7 Jan 2020 00:09:35 +0000
Message-ID: <E9113606-E4A0-45B8-B6ED-EF7643C68EEC@cablelabs.com>
References: <HE1PR07MB44250F3C4E6A744DDCC3DAFCC24C0@HE1PR07MB4425.eurprd07.prod.outlook.com> <ad7b763e-b3dd-36cf-a9c5-7de99476babb@mti-systems.com> <12ED7632-5E3E-4EB9-B65E-8A8324067C9A@akamai.com> <5DD4BB25.3060700@erg.abdn.ac.uk> <5658232C-07D5-4C89-B16A-58A928332FC6@gmx.de> <HE1PR07MB4425D989D4A266C73331FFA5C24F0@HE1PR07MB4425.eurprd07.prod.outlook.com> <CAJU8_nUK5cZLFE-0UBzf0a7T0hC7C+CpCsUy_+ZU_p4oxW9BmQ@mail.gmail.com> <HE1PR07MB442560D0715BC921AB9B7FE3C24F0@HE1PR07MB4425.eurprd07.prod.outlook.com> <AM4PR07MB345968E8C665304DFBD5B11FB94F0@AM4PR07MB3459.eurprd07.prod.outlook.com> <228d061d-f25e-b350-4a6e-2aea827a590c@kit.edu> <e5a7ed0e-90cb-10a9-c55f-0ba8d2144ecd@bobbriscoe.net> <1ed5e25f-d105-8866-99fb-5fce181bbbbe@kit.edu> <5d36ceb0-d03f-6fee-c7ea-e803fbfa606f@bobbriscoe.net> <151fd71f-bdc5-a140-104f-e924a2b7dc16@kit.edu> <1943e190-a4c7-bafb-3c4d-5aaedfb55bd6@bobbriscoe.net> <MN2PR19MB404595E43875C2DD459A5C9283210@MN2PR19MB4045.namprd19.prod.outlook.com>
In-Reply-To: <MN2PR19MB404595E43875C2DD459A5C9283210@MN2PR19MB4045.namprd19.prod.outlook.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
msip_labels: MSIP_Label_17cb76b2-10b8-4fe1-93d4-2202842406cd_Enabled=True; MSIP_Label_17cb76b2-10b8-4fe1-93d4-2202842406cd_SiteId=945c199a-83a2-4e80-9f8c-5a91be5752dd; MSIP_Label_17cb76b2-10b8-4fe1-93d4-2202842406cd_Owner=david.black@emc.com; MSIP_Label_17cb76b2-10b8-4fe1-93d4-2202842406cd_SetDate=2020-01-01T23:31:57.6382640Z; MSIP_Label_17cb76b2-10b8-4fe1-93d4-2202842406cd_Name=External Public; MSIP_Label_17cb76b2-10b8-4fe1-93d4-2202842406cd_Application=Microsoft Azure Information Protection; MSIP_Label_17cb76b2-10b8-4fe1-93d4-2202842406cd_Extended_MSFT_Method=Manual; aiplabel=External Public
user-agent: Microsoft-MacOutlook/10.1c.0.190812
authentication-results: spf=none (sender IP is ) smtp.mailfrom=g.white@CableLabs.com;
x-originating-ip: [2620:0:2b10:22:c04f:94cc:9038:3542]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: 30d33536-272f-46f5-6442-08d79305e137
x-ms-traffictypediagnostic: SN6PR06MB4253:
x-microsoft-antispam-prvs: <SN6PR06MB4253A67479718007FC18BB83EE3F0@SN6PR06MB4253.namprd06.prod.outlook.com>
x-ms-oob-tlc-oobclassifiers: OLM:10000;
x-forefront-prvs: 027578BB13
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(376002)(346002)(39840400004)(136003)(366004)(396003)(189003)(199004)(4326008)(8936002)(478600001)(54906003)(33656002)(81166006)(110136005)(81156014)(8676002)(316002)(71200400001)(2616005)(6512007)(91956017)(66446008)(66556008)(64756008)(66476007)(66946007)(76116006)(6486002)(86362001)(186003)(2906002)(5660300002)(6506007)(36756003)(85282002); DIR:OUT; SFP:1102; SCL:1; SRVR:SN6PR06MB4253; 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: BCL:0;
x-microsoft-antispam-message-info: F/Iws1ICUj6U/ngG1ca50jcEzCQnZkTFnVysV0g0cfBkVKAjXdZ8TCI8dEnHgZAK4HwJgXFUaU15vShkclNxUxpthYz9JWWUk7jVCG9//zqGMDfqKvV49vjOGT4hPLm8Z183AkWHFKNzyEBNFTYxeum5QmLZ8Juw5AwazkSW7ASxkhIVV1/0J+doQDFnvLzrhA9JMGLApvBJiSrKHQ5Y0lxvcP4mpCUoLS0E9lZ6txjQoeVliKGlaNF7e0fNhfyvLBErjUBbbEKJQhcPCGypV93Wnzhwp4YtC/C+nrhVppUbOE1A6g9PdkdIsCN7A+S6e3F09Ln1jwfTcLC6fFS1XwodxE6iPIwV8/pIEDr0MuViNLn26dqQSGt1Xc8hZKfnaQ37qK2/Sxb4drBZFWX4dkq9L+pUS6rfFifDSmIacARqdKtbPjjgm6T+YysKGrcV12+UjBvAGHm0VhxzT6thYOtB1BEYZsowEko+oZjUI5zT2WHh3An8skkxIUmCzqpA
x-ms-exchange-transport-forked: True
Content-Type: text/plain; charset="utf-8"
Content-ID: <50F4AF0998CB1D45A369CB23AFEA5CCD@namprd06.prod.outlook.com>
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-OriginatorOrg: cablelabs.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 30d33536-272f-46f5-6442-08d79305e137
X-MS-Exchange-CrossTenant-originalarrivaltime: 07 Jan 2020 00:09:35.6609 (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-CrossTenant-userprincipalname: SFL1fXse0QxaG1rz6VFj2px9Re/fL+KCxkEtiWM4qat1EidvCZf/U+0a+sMRzv4wL94gG6FRX0+DIkyc97YlvA==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: SN6PR06MB4253
Archived-At: <https://mailarchive.ietf.org/arch/msg/tsvwg/QEoVFcfbwin-XwRMs-hOLMD7S4w>
Subject: Re: [tsvwg] L4S vs SCE (Evolvability)
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: Tue, 07 Jan 2020 00:09:41 -0000

David,
See [GW] below.
Greg

On 1/1/20, 4:33 PM, "tsvwg on behalf of Black, David" <tsvwg-bounces@ietf.org on behalf of David.Black@dell.com> wrote:

    Bob,
    (posting as an individual)
    
    The assertion that SCE traffic will "starve" is just plain wrong in the following ...
    
    > > The SCE markings can be used independently whether you have multiple
    > > queues or just a single queue.
    > [BB] This seems to be the opposite of reality. Perhaps you've used the
    > word 'can' because you think it might be possible. But there's good
    > reason to doubt that. As follows...
    > 
    > Packets from non-SCE and from SCE senders are indistinguishable by just
    > looking at them. So, if there's a single queue, they have to be mixed
    > together in it {Note 1}. But a single queue can only have one length.
    > Any transports that don't understand SCE drive the single queue to a
    > deeper operating point (defined by CE or drop).
    
    The reasoning appears to be sound up to this point, but the next sentence does not follow from the above:
    
    > This overruns the SCE
    > operating point, and causes SCE marking to approach 100% {Note 2}. Then
    > those transports that do understand SCE will starve.
    
    Actually, it causes both SCE and non-SCE senders to operate at that "deeper operating point (defined by CE or drop)" because SCE traffic has an RFC-3168-like response to CE marks, and the usual reaction to drops.  The result is a deeper queue than would have resulted in the absence of non-SCE traffic, but the result is definitely *not* starvation.

[GW] Is that true?  Setting aside Bob's "Note 2" implementation, it seems your statement would only be true if the SCE sender had /no/ cwnd response to SCE-marks (i.e. ECT(1)) at all (which I guess would make it a non-SCE sender). I know the SCE congestion controller is still under development, but I seem to remember Jonathan indicating that it would aim to reduce its congestion window until the SCE-mark rate was 50% (don't quote me on that being the precise behavior currently).   If the non-SCE senders continue to drive the SCE-mark rate to 100% in order to experience occasional CE-marks, then the SCE senders would continue to reduce their congestion window on every RTT.   I suppose one way to (somewhat) get the behavior you are describing would be for an SCE sender to, upon receiving a single CE-mark, revert to an RFC3168 compliant mode and stop responding to SCE-marks.  I don’t believe that is the behavior today.

    
    Thanks, --David