Subject: Re: [tsvwg] NQB + ECT

From: Greg White <[email-masked]>
Date: Tue, 19 Nov 2019 00:13:24 +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" <[email-masked]> 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

---

From: Markku Kojo <[email-masked]>
Date: Thu, 21 Nov 2019 03:32:59 +0200 (EET)

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

---

From: Greg White <[email-masked]>
Date: Thu, 21 Nov 2019 08:35:33 +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" <[email-masked]> wrote:

    Hi Greg,

    BR,
    
    /Markku

---

From: Sebastian Moeller <[email-masked]>
Date: Thu, 21 Nov 2019 10:27:25 +0100

> On Nov 21, 2019, at 09:35, Greg White <[email-masked]> wrote:
> 
> Markku,
> 

	[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