Re: [tsvwg] NQB + ECT

Greg White <g.white@CableLabs.com> Tue, 19 November 2019 00:13 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 6936312099E for <tsvwg@ietfa.amsl.com>; Mon, 18 Nov 2019 16:13:32 -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 nGCWR9U662ft for <tsvwg@ietfa.amsl.com>; Mon, 18 Nov 2019 16:13:27 -0800 (PST)
Received: from NAM01-SN1-obe.outbound.protection.outlook.com (mail-eopbgr820101.outbound.protection.outlook.com [40.107.82.101]) (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 38F2112012A for <tsvwg@ietf.org>; Mon, 18 Nov 2019 16:13:27 -0800 (PST)
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=PGZZXju874KivtlYNtH038RgZzW5d9ZLqgg46IGu/2J4dljhq1pHJe02hGpYsqd6VM5369DBlVTMqsnZjr641XGfWrdh5apsHOP5RKDEow7apxZ12cgZXZbiRXPkXIyfC3sOlg+5CzZoMcK0ZP53e+oKcQUyIki8HJJhCzBYF2/mOCDR8qSos7Tw1l0KM3VX3Gc9+p29dPYDbFqGVeiJo12HCLGPWrGGGmbfHxJetjV9ZbuMJ40egM7ac+cwAChxYxb5wtRIJPgkbigaQN8aj2VS/qdjXMy+ve1L2OMRYyJVBRgbn8GadrzJDzF7+JzLlPZHGOhf0M1o54X5X6ewyA==
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=Ine2x9r/JR2qL+UxgK4ogHxGNuzQdSqRfn/yXT0aWD8=; b=UENQIyX4KU/9Gv3bgGIr9r/jSYZfFmfgghH6C08Pzgsofz+a85r/P/SxyrPbYudEu1+df7IVe7ClUoSXhFYiUUrIEc3d7l19PdcsvkkhuYmSc8zMDn/5lyvXTNDNsXbZvxaIPajQurOPUSpQZAAPL02YzeyHreIV+jkVX3w2oeaQ0MhGjKVEajY8fNwoWLDZxWd74AEWFf1Wx1j5RO59f/dRF8JuG/Gi/z/uOHnRY8Cquxdhl3Vje+yhxdKwJ5+dPPNt+M/KuYxFqOetpPK2lJ4v6zMiicqfa8cJp06XNf1uXz91ZhU+wnOfJNglfq0t6/LnQ8D+U7WX2SPv+O5KEw==
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=Ine2x9r/JR2qL+UxgK4ogHxGNuzQdSqRfn/yXT0aWD8=; b=G0Wa8hXukHlGtbOVFNdNbuAIGt60H1POGCD161aKVefTeT0WXo8bS1eMmnm3lFzuqq1Tp+pu2Im5B8rImmbrvX2HtonlisGB48HVgxZnGGJwfQNcySI5gfulNam35KSsNxiVaBVZUEZNl0KYQ3h0evWXfgTnr7oRhyBnU2LKe68=
Received: from SN6PR06MB4655.namprd06.prod.outlook.com (52.135.117.85) by SN6PR06MB6448.namprd06.prod.outlook.com (20.178.6.219) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2451.30; Tue, 19 Nov 2019 00:13:25 +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.2451.029; Tue, 19 Nov 2019 00:13:24 +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: AQHVnm4oeVMrDynfT0i69RGXLJpKkw==
Date: Tue, 19 Nov 2019 00:13:24 +0000
Message-ID: <77CF80DE-3025-41AF-9182-69B11D64E0B3@cablelabs.com>
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: 38abbe42-0e81-4eb7-7e5f-08d76c854b53
x-ms-traffictypediagnostic: SN6PR06MB6448:
x-microsoft-antispam-prvs: <SN6PR06MB64486D5C1367D65B82DA3559EE4C0@SN6PR06MB6448.namprd06.prod.outlook.com>
x-ms-oob-tlc-oobclassifiers: OLM:9508;
x-forefront-prvs: 022649CC2C
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(346002)(376002)(136003)(366004)(39850400004)(396003)(199004)(189003)(6512007)(8676002)(25786009)(6436002)(6916009)(66556008)(36756003)(6246003)(7736002)(14454004)(71200400001)(71190400001)(99286004)(229853002)(58126008)(66066001)(305945005)(81166006)(33656002)(256004)(5660300002)(66946007)(66446008)(66476007)(186003)(8936002)(76116006)(91956017)(26005)(3846002)(6306002)(81156014)(2616005)(64756008)(486006)(476003)(6116002)(6486002)(4326008)(316002)(296002)(86362001)(2906002)(102836004)(478600001)(6506007)(85282002); DIR:OUT; SFP:1102; SCL:1; SRVR:SN6PR06MB6448; 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: Ov0RAeztWS+EdXRPfnbrsaXzcAJkCUjSxmBmkhe1It/K4Xf2A3nBCJhDLRdmC45TjKsDm8TEljVfw8jGrVXqh4IpCSSjxeXJSNlFDQ1tNl2i7f0uFWmMIIdXm5sOM+4HPtyL/XOTKMXIwCWvz46TS9bAXhg7BiwBQfOhAJvQWUChNCJ2Zn5TcWHvMtE36TTBrVjk+HygU+apGyaCGTKCECOhaHBl7TR/AmQM2gimZ0+7HzmumKyFew0q4lac0qDRLuWAnhrBaiT9vVOUyBxO6D1FPJtVQMgJc9Y+BbRctIgbv9aI701Vwq2IeTJW2juGr6dPF2RjVFBYqkyCY79n/+ga7yBY51/eB/azubGygL4nS/45XpRilBG8hFWO/xCxWJc9KJwbbUlOjtFu+2tid1OQPBpDZIM343XBNhk0xjP4gLKeQjzCJpjDGciaWQng
x-ms-exchange-transport-forked: True
Content-Type: text/plain; charset="utf-8"
Content-ID: <8220A2A82B05284BA3FC4F22F0FDD240@namprd06.prod.outlook.com>
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-OriginatorOrg: cablelabs.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 38abbe42-0e81-4eb7-7e5f-08d76c854b53
X-MS-Exchange-CrossTenant-originalarrivaltime: 19 Nov 2019 00:13:24.4948 (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: ND1Lek7cjn90x0eOBXIKARgahSXtrzFw41toWk3O5X/6D4w6whqWtSKNr14I3XpB5GXyP5cmjVBK9L5TLYWmvw==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: SN6PR06MB6448
Archived-At: <https://mailarchive.ietf.org/arch/msg/tsvwg/_xWwuh0CB7oZYgFbo2G8riPSHfs>
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: Tue, 19 Nov 2019 00:13:33 -0000

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