Re: [tsvwg] NQB + ECT

Markku Kojo <kojo@cs.helsinki.fi> Thu, 21 November 2019 01:33 UTC

Return-Path: <kojo@cs.helsinki.fi>
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 230D1120900 for <tsvwg@ietfa.amsl.com>; Wed, 20 Nov 2019 17:33:12 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.3
X-Spam-Level:
X-Spam-Status: No, score=-4.3 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_MED=-2.3, 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=cs.helsinki.fi
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 LagTBfRO4oUx for <tsvwg@ietfa.amsl.com>; Wed, 20 Nov 2019 17:33:09 -0800 (PST)
Received: from script.cs.helsinki.fi (script.cs.helsinki.fi [128.214.11.1]) (using TLSv1.2 with cipher AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1E02A120894 for <tsvwg@ietf.org>; Wed, 20 Nov 2019 17:33:08 -0800 (PST)
X-DKIM: Courier DKIM Filter v0.50+pk-2017-10-25 mail.cs.helsinki.fi Thu, 21 Nov 2019 03:33:04 +0200
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cs.helsinki.fi; h=date:from:to:cc:subject:in-reply-to:message-id:references :mime-version:content-type:content-id; s=dkim20130528; bh=Ui1/iY 9ZQh+mJrqDhxG4roMoZSvvqsr0GfJQY6KVjxA=; b=ZFW6VRnsWLkJb0RVsd86r2 8vZFD140Slj/fAGNHNQslSgf9c07WJf/AEbuBEbOeU6EaXNqdryGRhn46cu5Mug+ XfwmufpJTAA4Z+vheGW7KW6THlmaAzwIczX4lSQR48lDt0nuYBQrwANiCPyT2bsq TcA67edV9U4C4Y4D5XCJ8=
Received: from dhcp-9fb6.meeting.ietf.org (dhcp-9fb6.meeting.ietf.org [31.133.159.182]) (AUTH: PLAIN kojo, TLS: TLSv1/SSLv3,256bits,AES256-GCM-SHA384) by mail.cs.helsinki.fi with ESMTPSA; Thu, 21 Nov 2019 03:33:02 +0200 id 00000000005A0146.000000005DD5E94F.00000C02
Date: Thu, 21 Nov 2019 03:32:59 +0200 (EET)
From: Markku Kojo <kojo@cs.helsinki.fi>
To: Greg White <g.white@cablelabs.com>
cc: "tsvwg@ietf.org" <tsvwg@ietf.org>
In-Reply-To: <77CF80DE-3025-41AF-9182-69B11D64E0B3@cablelabs.com>
Message-ID: <alpine.DEB.2.21.1911202215380.9015@hp8x-60.cs.helsinki.fi>
References: <77CF80DE-3025-41AF-9182-69B11D64E0B3@cablelabs.com>
User-Agent: Alpine 2.21 (DEB 202 2017-01-01)
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="=_script-3371-1574299984-0001-2"
Content-ID: <alpine.DEB.2.21.1911210331570.9015@hp8x-60.cs.helsinki.fi>
Archived-At: <https://mailarchive.ietf.org/arch/msg/tsvwg/p8PkDrrI4pQrgVRuQB6pkjBbGow>
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 01:33:12 -0000

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
>
>
>
>