Re: [tsvwg] NQB + ECT

Greg White <g.white@CableLabs.com> Thu, 21 November 2019 08:35 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 1106312094E for <tsvwg@ietfa.amsl.com>; Thu, 21 Nov 2019 00:35:39 -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 A6fA2a46FFuc for <tsvwg@ietfa.amsl.com>; Thu, 21 Nov 2019 00:35:35 -0800 (PST)
Received: from NAM01-SN1-obe.outbound.protection.outlook.com (mail-eopbgr820121.outbound.protection.outlook.com [40.107.82.121]) (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 9A5BF120801 for <tsvwg@ietf.org>; Thu, 21 Nov 2019 00:35:35 -0800 (PST)
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=MpEmDJMow+ziRjJy4MXYcQxWdfw4turVqaXoNc7hhBUH/Ic0V8/6DV6Xgx9YhF7tCuqwF8hQngeyzXHbNBv2GDlngCJt11hzKCFnAbdlR5AIJhxj5vDJjjmwwR50h56mMliuA4Xpzh5cxxcIDVhwPeaXY26xGwF+2CXRbwcPdWw68rgUvp+364foqTywuGC1y4XsHYZRvw25jDU7EIifZtgk+LPSNfTBcaFOt06FT/TyEcXgJvknADt2E5VhxMLzupEuY24fcY9EiQsaI3bYjIzDwfdv5Hv8jLxAs3vQ8sP4lHrGrh+3kXmPBbUfseXZ0MsSdOOd6ByTlz+UvckpkA==
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=hbwj2ZYlFLvQP8OLmTPNqoNuU5pZIYo3RAy9l8fBX4w=; b=mZtspPYDMMMrQ+Dm52sXpxLWnX8zPkAmnNC0EcF7rVKKkOTLrQmnXd4lKIKgcfMnsYWP9fv4aqK/4Ftr7HtvY5oxNmUwq/q/xOr7UQo/Y888mkpD9S3tH9jrwWaJiWH356nMX0OM9nCUDFCXaeYqEuQD6fp9V+OkUWSEuQwTvSsNRUk3nXQm9kIPecEim+5h12IUjW70qxF3P61Z3BTzBwvfJ617eakw7WgtK1/Bm5XYB7LSriNhL6sfgZ/LYSBYasA/W/j6Zi7uOX+Z0vBzIHT8tBNx+QQCOuWzoNEO8TLcHIcZVs9KRp0Bt4vrereuXB8r/mEH5hUfXCT4NsDNcQ==
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=hbwj2ZYlFLvQP8OLmTPNqoNuU5pZIYo3RAy9l8fBX4w=; b=dJlpHPN+Iexo267b902yqv9A9Rhn5T2rc6GU5r9f47CW5e/mhS2Z7ig6o/5Dm5msx0EblOH8P74clTVML5Wit5tmLZwpYR99qx7xbfc5muYohk7MSO7MzizjJwHELpcDgHqSc/ZojqQaSVtOktnfzZmpL+4SczzOehZIYKIT6Ss=
Received: from SN6PR06MB4655.namprd06.prod.outlook.com (52.135.117.85) by SN6PR06MB4288.namprd06.prod.outlook.com (52.135.121.10) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2451.29; Thu, 21 Nov 2019 08:35:34 +0000
Received: from SN6PR06MB4655.namprd06.prod.outlook.com ([fe80::91c5:f29b:4501:6db5]) by SN6PR06MB4655.namprd06.prod.outlook.com ([fe80::91c5:f29b:4501:6db5%2]) with mapi id 15.20.2474.019; Thu, 21 Nov 2019 08:35:34 +0000
From: Greg White <g.white@CableLabs.com>
To: Markku Kojo <kojo@cs.helsinki.fi>
CC: "tsvwg@ietf.org" <tsvwg@ietf.org>
Thread-Topic: [tsvwg] NQB + ECT
Thread-Index: AQHVnm4oeVMrDynfT0i69RGXLJpKk6eU2lqAgADdeoA=
Date: Thu, 21 Nov 2019 08:35:33 +0000
Message-ID: <588D4ECD-8EA9-4E88-B952-954FBAEE574E@cablelabs.com>
References: <77CF80DE-3025-41AF-9182-69B11D64E0B3@cablelabs.com> <alpine.DEB.2.21.1911202215380.9015@hp8x-60.cs.helsinki.fi>
In-Reply-To: <alpine.DEB.2.21.1911202215380.9015@hp8x-60.cs.helsinki.fi>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
user-agent: Microsoft-MacOutlook/10.1c.0.190812
authentication-results: spf=none (sender IP is ) smtp.mailfrom=g.white@CableLabs.com;
x-originating-ip: [203.127.152.4]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: b4f69c34-4d42-4df5-a563-08d76e5dc6c1
x-ms-traffictypediagnostic: SN6PR06MB4288:
x-ms-exchange-purlcount: 1
x-microsoft-antispam-prvs: <SN6PR06MB428847B927AEE799E24D64A0EE4E0@SN6PR06MB4288.namprd06.prod.outlook.com>
x-ms-oob-tlc-oobclassifiers: OLM:10000;
x-forefront-prvs: 0228DDDDD7
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(376002)(346002)(136003)(396003)(366004)(39830400003)(199004)(189003)(71190400001)(25786009)(53546011)(33656002)(229853002)(14454004)(446003)(478600001)(76176011)(102836004)(76116006)(6506007)(6512007)(6306002)(66066001)(6116002)(3846002)(4326008)(6246003)(66556008)(316002)(6486002)(2616005)(7736002)(8676002)(305945005)(256004)(91956017)(296002)(11346002)(99286004)(6436002)(5660300002)(186003)(81166006)(71200400001)(81156014)(6916009)(2906002)(36756003)(64756008)(8936002)(66946007)(66476007)(58126008)(26005)(66446008)(86362001)(85282002); DIR:OUT; SFP:1102; SCL:1; SRVR:SN6PR06MB4288; 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: BCL:0;
x-microsoft-antispam-message-info: epm9DibCbx9KpZrtLv6yyaexdsBFMe0WYaeCe2zRX0JjyRILEweWgN8Z/H5GqICbE0fIA37fZIW50aZPZUMakLsngTvvNqZ3LapUCIfNPjr72n+BMX3eq3raiH+uUmMowui4QFRP63BVdqLtnWmQdAYIEn+SSLO9DAnzSzwaEipHD57bsqPu2UZSZ2hDdkM1Ix1SRbgXT141cvooTmCqsPfMfPsnJcnh74jMXQKA1NDZHrAte3lgYvU7gn33YNiVGc8iR2FLun82HybW8t0hFHGaFoMnhz5UbS1qYv8h9EvVtH/78edmSt5N+b2rIFh+ZTyphNNnZI91/D5czgJd7Otzl4I++uSFSnmocCS7coGQ2/qYLA3IAjjaij4h77baLYjTqBlA+GsqzSGrpdkIYDSXg6FZ3afghQ8hexIjqdxuqv0VY+/MFpgY892Kg9ztUuWQZjRSPUHWj+Vp7RjYwuP5u0lOKJz1d19sKaW+XM8=
x-ms-exchange-transport-forked: True
Content-Type: text/plain; charset="utf-8"
Content-ID: <9E5AEF1844CE234E86F9371AE0BC5743@namprd06.prod.outlook.com>
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-OriginatorOrg: cablelabs.com
X-MS-Exchange-CrossTenant-Network-Message-Id: b4f69c34-4d42-4df5-a563-08d76e5dc6c1
X-MS-Exchange-CrossTenant-originalarrivaltime: 21 Nov 2019 08:35:33.9839 (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: 9OzvnVRab3W4BURCsQ224IdBlj4y1Vv6DF6U7SydJX/x/loClkjRThoPmHtyweraZnPcX37Fxg8Du1BANSOwsg==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: SN6PR06MB4288
Archived-At: <https://mailarchive.ietf.org/arch/msg/tsvwg/eETn35_q_hMBAf4Duu6kKr-Ndiw>
Subject: Re: [tsvwg] NQB + ECT
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, 21 Nov 2019 08:35:39 -0000

Markku,

Unfortunately, I don't think that is true.  

While ECT(0) traffic could be classified to the LL queue via the NQB codepoint, and (assuming it passes the queue protection test) it would see CE marks driven by the classic queue AQM, it wouldn't *affect* the classic queue AQM.  

So, if such a flow were to be in a link where the classic queue remains empty, it would see no congestion signals from the LL queue.  Assuming it is a capacity-seeking flow, it would presumably then increase its sending rate until it begins to fail the queue protection test and ends up getting its packets redirected to the classic queue, where it would then begin building a queue, and thus triggering mark/drop via the classic AQM. 

-Greg



On 11/21/19, 9:33 AM, "Markku Kojo" <kojo@cs.helsinki.fi> wrote:

    Hi Greg,
    
    thanks a lot for the articulate description. So, if I understood 
    correctly, this allows for developing an alternative CC for LL Q using 
    ECT(0) as long as such a CC algo plays well with LL target and Classic 
    drop/mark?
    
    BR,
    
    /Markku
    
    On Tue, 19 Nov 2019, Greg White wrote:
    
    > Hi Markku,
    >
    > In the Low Latency DOCSIS implementation of NQB + L4S, packets that are
    > marked NQB, ECT(1) or CE get directed to the low latency queue (passing
    > through the queue protection function).
    >
    > For traffic that passes the queue protection test and remains in the
    > low latency queue, the queue performs CE marking according the ECN bits:
    > CE marked and not-ECT packets pass through, ECT(1) gets marked using the
    > L4S "Immediate AQM", ECT(0) gets marked or dropped using the mark/drop
    > probability of the classic queue AQM (but only if the queue is above
    > the min thresh of the IAQM ramp).
    >
    > For traffic that ends up in the classic queue (either because it was
    > classified there, or because it failed the queue protection test) the
    > classic AQM (PIE) performs packet drops, regardless of ECN bits.
    >
    > In other words, the NQB DSCP value is only used in the packet
    > classifier.  Once a packet enters a particular queue, the L4S Dual-Q
    > coupled AQM decisions are done based on ECN bits (ignoring DSCP).
    >
    > The IAQM pseudocode from Annex N of the DOCSIS MULPI spec
    > (https://specification-search.cablelabs.com/CM-SP-MULPIv3.1) is:
    >
    > iaqm(packet, q_byte_length) {
    >   // Derive qdelay of qL from its byte_length using qdelayCoupledL() (see Annex P)
    >   // Note: if this calc. is performed in Queue Protection, the result can be reused
    >   qdelay = qdelayCoupledL(q_byte_length + packet.size);
    >   ecn_ = read_ecn(packet);
    >   if ( ecn_ & 0x01 ) {  // L4S packet (ECT1 or CE)
    >      // Note: result from Queue Protection can be reused
    >      probNative = calcProbNative(qdelay);  //See Annex O.1
    >
    >      // Combine Native and Coupled probabilities into ECN marking probL_
    >      probL_ = max(probNative, min (qc.probCL, 1));
    >
    >      // Mark the packet as CE with likelihood probL_ using recur() from Section P.1
    >      return ( recur(probL_) ? EXIT_CE : EXIT_FWD );
    >
    >   } else {  // Non-L4S in the LL queue
    >      if ( ecn == NOT-ECT ) {
    >         return EXIT_FWD;
    >      } else {                         // ECT0
    >         // Mark with Classic drop_prob_ but at target delay of the LL queue
    >         if ( (qdelay > MINTH) && (qC.drop_prob_ > random()) ) {
    >               return EXIT_CE;  // CE-mark with probability qC.drop_prob_
    >         }
    >      }
    >   }
    > }
    >
    > Greg
    >
    >
    > On 11/19/19, 2:05 AM, "Markku Kojo" <kojo@cs.helsinki.fi> wrote:
    >
    >    Hi Greg,
    >
    >    I'm not commenting about which DSCP to select but would like to understand
    >    a somewhat related issue. I well understand that the NQB DSCP is
    >    intended for non-congestion-controlled traffic. However, what is the
    >    intended treatment if a NQB packet also has ECT(0) or ECT(1) set for some
    >    reason. The draft is quite clear what happens if the traffic turns out
    >    being QB, but how about if it does not? Does it happily get the same AQM
    >    treatment as NQB traffic with not-ECT set but also with the same ECN
    >    marking behavior as BE traffic with ECT(1) set?
    >
    >    Thanks,
    >
    >    /Markku
    >
    >
    >
    >