[tsvwg] Re: NQB: WiFi e23 traversal - text proposal

[Sebastian Moeller <[e-mail]>]

Hi Gorry.

> On 24. Oct 2024, at 09:33, Gorry Fairhurst <[e-mail]> wrote:
> 
> On 24/10/2024 06:31, Sebastian Moeller wrote:
>> Hi Gorry
>> 
>> On 23 October 2024 22:43:01 CEST, Gorry Fairhurst <[e-mail]> wrote:
>> 
>>> On 23/10/2024 20:09, Black, David wrote:
>>> 
>>>>> NEW
>>>>> This conclusion is not disturbed by network support for NQB increasing the likelihood of DSCP 45 traffic traversing network boundaries without change to the DSCP, as that likelihood of increased network boundary traversal is balanced by a likelihood of NQB traffic encountering the traffic-limiting aspects of NQB support, traffic protection and shallow buffers, which limit the potential for abuse.
>>>>> END
>>>>> [SM] As you said this is based on intuition/judgement, yet this text reads as if this was a proven fact, how about leading into this section with a "We believe..." or "We argue..."
>>>>> to clearly signal the nature of this as an evaluation not based on hard and cold data.
>>>>> 
>>>> Ok, I'd write "The document authors do not expect this conclusion to be disturbed by ..." which I think is accurate.
>>>> 
>>>> Thanks, --David
>>>> 
>>> Thanks for the offer, but I don't think we need text that is a view of the documents authors. This is a WG document.
>>> 
>> [SM2] I am less concerned about scoping the "who" here veridically.* My point is, the believes about safety are not based on real empirical data, but at best on theoretical reasoning. While I consider that fact by itself as quite unfortunate and not an example of careful and cautious engineering, my point is that an ID/RFC should be explicit about what is based on data and what is not. The argument here is inherently a quantitative one, two things balance each other out, but the support does not come from measuring these quantities, so let's be explicit about that. 
>> 
>> *) Given the size of the WG I am pretty confident that not all members agree, in fact I clearly disagree.
>> 
>> 
> If David wishes to propose a definement to the text, there is still the opportunity to consider adding a sentence  soemthingf like this - but we need to determine the wording. The word "expects" or "expectation" is often used to describe something we do not know for certain.

[SM3] Yes, however uncertainty can have different causes, e.g. smaller sample size than desired or not being based on mpirical dat at all but theoretical analysis. Depending on the field either can be decent and useful (e,.g. in math often a proof is based on theoretical analysis, but e.g. in experimental astronomie peolpe trend to want to statistics based on empirical observations/data).
IMHO a RFC/ID should ve crystal clear what it deals in. I am not trying to say basing a judgment on theoretical osbervations is per se undesirable, but as a reader of an RFC I want to know which conclusions are based on data and which are not. 


> I'd suggest David's use of "likelihood" is pretty close to that.

[SM3] Well, no. In statistics we often compare likelhoods, that are based on estimates that come from empiric data, so neither "likelihood" nor "expectation" really make it clear that this assessment is not based on quantitative data analysis but on a thought experiment.
If the WG believes that such qualitative assessment of risk/harm is fine, we surely should have no reservation to actually explicitly acknowledge that in the text, no? If we believe such a qualitative assessment is not enough, we need to reasess reanalyse the data. Dressing up a qualitative engineering judgement call as fakt based assessment, helps nobody.



> Gorry
>>> Gorry
>>> 
>>> 
>>>> -----Original Message-----
>>>> From: Sebastian Moeller <[e-mail]>
>>>> Sent: Wednesday, October 23, 2024 1:25 AM
>>>> To: [e-mail]; Black, David <David.Black=[e-mail]>; tsvwg IETF list <[e-mail]>
>>>> Cc: Black, David <[e-mail]>
>>>> Subject: Re: [tsvwg] NQB: WiFi e23 traversal - text proposal
>>>> 
>>>> 
>>>> [EXTERNAL EMAIL]
>>>> 
>>>> Hi David
>>>> 
>>>> On 23 October 2024 03:21:10 CEST, "Black, David" <David.Black=[e-mail]> wrote:
>>>> 
>>>>>>> [SM] Now, NQB also offers a higher chance of e2e traversal (or NQB will have failed), here is the 64K question, from the perspective of a potential abuser, does this outway the small risk of degradation?
>>>>>>> 
>>>>> 
>>>>> 
>>>>>> That's ultimately an engineering judgement call that I think ought to be noted in the draft. I would expect that the higher likelihood of traversal is
>>>>>> accompanied by a higher likelihood of full NQB support in the traversed networks, bringing traffic protection and shallow queues into play.
>>>>>> I'll post some proposed text changes to the list in the next day or so.
>>>>>> 
>>>>> Working from the 3 paragraphs that Greg posted, I have a proposed additional sentence to add to the end of the first paragraph:
>>>>> 
>>>>> ===========================
>>>>> As stated above, the use of DSCP 45 (decimal) for NQB is not expected to create incentives for abuse by non-compliant applications in the Wi-Fi uplink direction. The fact that the NQB DSCP brings with it the potential for degradation of non-compliant applications (traffic protection and/or a shallow queue resulting in reordering and/or packet loss) plus the existence of multiple other DSCP values that don't carry the risk of degradation, and which could be readily used to obtain prioritization (AC_VI or even AC_VO), leads to the conclusion that NQB non-compliant applications that are seeking prioritization in the Wi-Fi uplink would be better off selecting one of those other DSCPs.
>>>>> NEW
>>>>> This conclusion is not disturbed by network support for NQB increasing the likelihood of DSCP 45 traffic traversing network boundaries without change to the DSCP, as that likelihood of increased network boundary traversal is balanced by a likelihood of NQB traffic encountering the traffic-limiting aspects of NQB support, traffic protection and shallow buffers, which limit the potential for abuse.
>>>>> END
>>>>> 
>>>> [SM] As you said this is based on intuition/judgement, yet this text reads as if this was a proven fakt, how about leading into this section with a "We believe..." or "We argue..." to clearly signal the nature of this as an evaluation not based on hard and cold data.
>>>> 
>>>> 
>>>>> In the case of traffic originating outside of the Wi-Fi network, the prioritization of traffic marked with the NQB DSCP via the Video Access Category (if left unchanged) could potentially erode the principle of alignment of incentives discussed in [Section 5]. In order to preserve the incentives principle for NQB, Wi-Fi systems MAY be configured such that the EDCA parameters for the Video Access Category match those of the Best Effort Access Category, which will mean AC_VI is at the same priority level as AC_BE. These changes might not be possible on all Access Points, and in any case the requirements and recommendations in [Section 4.4.1] would apply in this situation.
>>>>> 
>>>> [SM] I am still expecting an explicit description of the trade off here, that is stating that this will have clear side effects on all traffic scheduled in this modified AC_VI. This is just as necessary for a MAY as it would be for a SHOULD or even MUST. Not clearly stating the trade-off is more typical for marketing material, than for standards documents, IMHO, let's keep it that way.
>>>> 
>>>> As much as the authors may want to push/plug NQB, we should give implementors/users a clear picture of the consequences. Not puzzled anymore, that I need to spell this out explicitly, also not surprised that this will not lead to any meaningful change of the draft.
>>>> 
>>>> 
>>>>> Similarly, systems that utilize [RFC8325 [ietf.org]<https://urldefense.com/v3/__https:/www.ietf.org/archive/id/draft-ietf-tsvwg-nqb-25.html*RFC8325__;Iw!!LpKI!kEwuENwtM7AUFzztaj3PiFHXT65NvS4zhUuZQAzzfTnGpTlcXesLcE9v4Ias5OmEsjF0nCbo_L--A9LJEgs$>;] but cannot provide a separate AC_BE queue for NQB traffic, SHOULD map the recommended NQB DSCP 45 (decimal) (or the locally determined alternative) to UP_5 in the "Video" Access Category (see [Section 7.3.2]).
>>>>> 
>>>> 
>>>>> ===========================
>>>>> 
>>>>> 
>>>>> Thanks, --David
>>>>> 
>>>>> David L. Black, Sr. Distinguished Engineer, Technology & Standards
>>>>> Infrastructure Solutions Group, Dell Technologies
>>>>> mobile [phone] [e-mail]<mailto:[e-mail]>
>>>>> 
>>>>> 
>>> 
>> 
>