Re: [tsvwg] NQB + ECT

Sebastian Moeller <moeller0@gmx.de> Thu, 21 November 2019 09:27 UTC

Return-Path: <moeller0@gmx.de>
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 24DAF120058 for <tsvwg@ietfa.amsl.com>; Thu, 21 Nov 2019 01:27:38 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.648
X-Spam-Level:
X-Spam-Status: No, score=-1.648 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=gmx.net
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 0Lz6ltfvJkPy for <tsvwg@ietfa.amsl.com>; Thu, 21 Nov 2019 01:27:35 -0800 (PST)
Received: from mout.gmx.net (mout.gmx.net [212.227.15.18]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B09B9120041 for <tsvwg@ietf.org>; Thu, 21 Nov 2019 01:27:34 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gmx.net; s=badeba3b8450; t=1574328446; bh=/oFzjXdq9GKpXdBP5ljuLhkyxBqft1Y1z/WlLi69Dgk=; h=X-UI-Sender-Class:Subject:From:In-Reply-To:Date:Cc:References:To; b=jUbJH5sN5Miq+HgjH4FbFrDATmHsxavLGc/k8pno3a9N1pQoMoV5ThFl0TPUJgH/6 NnoLGAuP5BSg3UDSMYlgpFWoTzRaopUXi3E34r4qevfMkp1++4+UaIYRA9p01KARsX 9k9+JvTdXr5ctI+Sw09eN/jNwEVYC6VH17+haemo=
X-UI-Sender-Class: 01bb95c1-4bf8-414a-932a-4f6e2808ef9c
Received: from [10.11.12.33] ([134.76.241.253]) by mail.gmx.com (mrgmx005 [212.227.17.190]) with ESMTPSA (Nemesis) id 1MIMfW-1ib2eQ27TY-00EQXT; Thu, 21 Nov 2019 10:27:26 +0100
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\))
From: Sebastian Moeller <moeller0@gmx.de>
In-Reply-To: <588D4ECD-8EA9-4E88-B952-954FBAEE574E@cablelabs.com>
Date: Thu, 21 Nov 2019 10:27:25 +0100
Cc: Markku Kojo <kojo@cs.helsinki.fi>, "tsvwg@ietf.org" <tsvwg@ietf.org>
Content-Transfer-Encoding: quoted-printable
Message-Id: <139B02C0-F254-4252-8C1A-5C7E48DFCC75@gmx.de>
References: <77CF80DE-3025-41AF-9182-69B11D64E0B3@cablelabs.com> <alpine.DEB.2.21.1911202215380.9015@hp8x-60.cs.helsinki.fi> <588D4ECD-8EA9-4E88-B952-954FBAEE574E@cablelabs.com>
To: Greg White <g.white@CableLabs.com>
X-Mailer: Apple Mail (2.3445.104.11)
X-Provags-ID: V03:K1:aGTsMWvXe3lMTDn5FxzV6dodm5D2/7Zt9FxA8lvRjM0L3/iyXv5 LpWYpJ+D/VW6cfSFxPm3/C5xxzmPnKQDjdT7h7xCkxUMZz+00+IIEJgE5RxbkLn0CeNVdYy NQm+wRI3T/9MAYAo0POGS4ENqZ8BNp7LiXkNcHuPjlQXSgaL+hEyR3RlF7qNkPrimvNQvYv U7M8OwhXRT11qIXgaEmuQ==
X-UI-Out-Filterresults: notjunk:1;V03:K0:JrrrtlBodN0=:4chIgNFpeElua0NO6V1S5o HtEvHU5+pDNSS28O4RW3k1pyS+621sjqSMd5e3DCt+124U+qj/IxqgiCR3JCytWHNS22vzsko t/gfPoBBr0juzUVqxCJ7d/LYQP4u3g2syt5/paSOihUwfCGxlkyhPc8n6l2b+rmwqc9jpE2FY r1Vtxeoyy0Na4qH0+rgBnbG4QvHBgjScG0YqWZBOPfO5i6Jz24IcNfn6D52ZPnPUwPV4KsQ/i FS/rn6WaSl74bRcQymN+Pc/vvaKzlD2kZMU1s+ungkOBL/dNa3JEZIL8xeigKCATDQ9rTw5Dw jLiUrlGlLftP3A9NvH9F3Kshov2z4aTM+6Xd2w/SahVCs4GRoYbBRCWVd+t0joqVnQpu+7WJo 8K1l22r/aJUHgUYFXze/arVT4FCY1qIpTrEZQbxTttnXBCUG9A/tE49F3IlMqcVvbLlMFf9Mp SQ4FqkExAo1jCW2EDiWJvdGlKQV4Q+5wMu2iZyDgumuqsSvLdqdRkDt/jIJwsSp8/1Eyl+ZjD JhetILw+nU0L9xuOakquditQSxCmkv1HCSG+0pIAkasI64Mqay09d7LdLN1RHWcUl7SmxGiXC ftS9rkkXhwQ2kw1fmmHQD42cFRXDeyZUiIhmhXrtt5HcJKFmeLf2G8MHnSr0FdeBPWgJR2jU6 HorVTe4gddJIzPCUyY1eW4M18IeAMwm7LQcS2elyEqY1VUBzujlRax2fCpK2b1m2dvlqg2qLj i/yvfmRR5ZhiRT97RQgmiaPQUoshIo/uHGKmmFe3at4/3yuRXXu0KSlewW7zNKJqhSNuPWhK/ 3Y8jgB8sikF9LGFuIH9oZlILhfOZZ8ef7QqdDEWJOop1L0mun/3f1WQhTfD41nOKwfSIPQM3L JxryYLdWioVbyzpaJy7afDYe/4fM9XHPSQjXK5+LTxiSsWPqcuG3cC9QULLHcO8UXrhDInph1 ka12w+MlmRP0wF3ekRoQrNwE/lEBCUhjjPubScVBmTXAC6+LUwSnL67as51SmyrBr4kULN66R U8EMWrLzPxS3BLJpzd3/2e2P4/PkQ/ZTHZFr6ry8SMa8Acpl1sIgXwAFHmehzDrmTHH3A5Kk8 9QqUz4hpuQKVAPANjI7AD7d1b3hX2ujB54xKFgwe4e6Ie/Gwa8nQBB3dv/pmmhUhiZZKYZwxs mcpc17YUVv1AhyGCFURaokxbgISTgRmHBX9zX7ytXa0BUFPlapY8MckFvYbbYKCPGll3QXIQ3 apSJuwC40ZDEJGnMwc7sxndOVk/iBkHkvElmKYbqfQYd7NbwKdWwfvsJIiGo=
Archived-At: <https://mailarchive.ietf.org/arch/msg/tsvwg/odh7UUWlSIucS6t_DChRec24i6M>
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 09:27:38 -0000


> On Nov 21, 2019, at 09:35, Greg White <g.white@CableLabs.com> wrote:
> 
> 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. 

	[SM] Wouldn't the following stipulation "as long as such a CC algo plays well with LL target" avoid that fate for the flow? (Surely the LL queue will also emit CE's at one point if there is zero traffic in the non-LL queue, or will it resort to drop in that case?)

Sebastian 


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