Re: [tsvwg] NQB + ECT

[Sebastian Moeller <[e-mail]>]

> On Nov 21, 2019, at 09:35, Greg White <[e-mail]> 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" <[e-mail]> 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" <[e-mail]> 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
>> 
>> 
>> 
>> 
> 
>