Re: [tsvwg] WGLC: draft-ietf-tsvwg-nqb-14 - coexistence with L4S

[Sebastian Moeller <[e-mail]>]

Hi Roland,


> On Nov 2, 2022, at 16:32, Bless, Roland (TM) <[e-mail]> wrote:
> 
> Hi Rüdiger,
> 
> see below.
> 
> On 02.11.22 at 15:47 [e-mail] wrote:
>>  
>> current draft text informs about a coexistence of NQB and L4S in the same LowDelay queue. Does this include that
>> 	• NQB traffic should or could be marked by a DSCP and have ECN 1 set?
>> 	• L4S traffic should or could have ECN 1 set and be marked by NQB DSCP?
>>  
>> The current text is not clear on that issue. As all marking is to be done by application programmers and this is a standards track doc, I’m interested for the draft to be crisp and clear to that point. Include or exclude simultaneous NQB&L4S  DSCP&ECN setting?
> As far as I understand the draft, it is just an implementation detail:
> NQB packets do not need to have ECT(1) set to be put into the L4S low-latency queue.
> It is a node local mapping from the NQB DSCP(s) to the L4Slow-latency queue, i.e.,
> they just use the already existing low-latency queue.
> If I understand section 3.1 correctly, L4S flows should not be marked
> as NQB traffic since they violate the following condition:
> 
> " In contrast, Queue-Building (QB) flows include those that use TCP or QUIC, with 
> Cubic, Reno or other TCP congestion control algorithms that probe for the link 
> capacity and induce latency and loss as a result."
> 
> and especially L4S flows may also violate the (not so strict) condition of a 1Mbit/s limit.

	[SM] That is IMHO incorrect at least generally. Just because TCP allows a flow to search for the capacity limit applications can (and do) decide to send less than possible. But I guess the bigger issue is that the L4S drafts have some words to say when and when not to set ECT(1):

https://datatracker.ietf.org/doc/html/draft-ietf-tsvwg-ecn-l4s-id-29#page-14:


In order to coexist safely with other Internet traffic, a scalable
   congestion control is not allowed to tag its packets with the ECT(1)
   codepoint unless it complies with the following numbered requirements
   and recommendations: [list skipped]

So NQB flows would need a scalable congestion control to be allowed to set ECT(1)


However usage of a "scalable congestion control" is not mandatory for setting ECT(1):

As a condition for a host to send packets with the L4S identifier
   (ECT(1)), it SHOULD implement a congestion control behaviour that
   ensures that, in steady state, the average duration between induced
   ECN marks does not increase as flow rate scales up, all other factors
   being equal.  This is termed a scalable congestion control.


I would respectfully argue that that SHOULD is mighty weak...


BUT that L4S draft hasd the following ot say about NQB:

To identify packets for just the scheduling treatment, it would be
   inappropriate to use the L4S ECT(1) identifier, because such traffic
   is unresponsive to ECN marking.  Examples of relevant non-ECN
   identifiers are:

   *  address ranges of specific applications or hosts configured to be,
      or known to be, safe, e.g. hard-coded IoT devices sending low
      intensity traffic;

   *  certain low data-volume applications or protocols (e.g. ARP, DNS);

   *  specific Diffserv codepoints that indicate traffic with limited
      burstiness such as the EF (Expedited Forwarding [RFC3246]), Voice-
      Admit [RFC5865] or proposed NQB (Non-Queue-
      Building [I-D.ietf-tsvwg-nqb]) service classes or equivalent
      local-use DSCPs (see [I-D.briscoe-tsvwg-l4s-diffserv]).

It makes a ton of sense to mirror this in the NQB draft explicitly to
at least keep these two consistent.





> 
> So my interpretation of the draft is that the answer to both questions is no, i.e.,
> either NQB DSCP is set or ECT(1) is set. However, there should be a hint
> what to do in case both are set (following the L4S argument of letting DiffServ being 
> orthogonal, ECT(1) should take precedence and the DSCP should be kept nevertheless).

	[SM] The bigger issue is that L4S AQMs are not mandated to check at all whether any marked traffic actually fulfills the requirements. So honestly it matters little whether a flow uses NQB of L4S to gain access to L4S high-priority queue. Without actual policing/enforcement any requirements in RFC are reduced to "requirements".

Kind Regards
	Sebastian

P.S.: I am convinced that this draft is not (yet) ready and should not pass last call right now.



> 
> Regards,
> 
>  Roland
> 
>>  
>> Von: tsvwg <[e-mail]> Im Auftrag von Black, David
>> Gesendet: Mittwoch, 2. November 2022 04:47
>> An: tsvwg IETF list <[e-mail]>
>> Betreff: [tsvwg] WGLC: draft-ietf-tsvwg-nqb-14, closes 21 November 2022
>>  
>> This email announces a TSVWG Working Group Last Call (WGLC) on:
>>  
>> A Non-Queue-Building Per-Hop Behavior (NQB PHB) for Differentiated Services
>>                         draft-ietf-tsvwg-nqb-14
>> https://datatracker.ietf.org/doc/draft-ietf-tsvwg-nqb/
>>  
>> This draft is intended to become a Proposed Standard RFC.
>>  
>> This WGLC will run through the end of the day on Monday, November 21.
>> The WG will meet in London on Monday, November 7, while this WGLC
>> is in progress.
>>  
>> Comments should be sent to the [e-mail] list, although purely
>> editorial comments may be sent directly to the authors. Please cc: the
>> WG chairs at [e-mail]  if you would like the chairs to
>> track such editorial comments as part of the WGLC process.
>>  
>> No IPR disclosures have been submitted directly on this draft.
>>  
>> Thanks,
>> David, Gorry and Marten
>> (TSVWG Co-Chairs)