[tsvwg] Re: [EXTERNAL] Re: [gwhiteCL/NQBdraft] Should traffic protection be mandatory to implement? (Issue #48)

[Sebastian Moeller <[e-mail]>]

Hi Greg,


> On 25. Jul 2024, at 19:28, Greg White <g.white=[e-mail]> wrote:
> 
> DB wrote:
> > If NQB is effectively an alternate name for Default, then why does the draft contain extensive discussion of and strong assertions about the absence of incentives to mismark Default QB traffic as NQB?
>  Precisely *because* of that property. Since there is no priority elevation

[SM] Respectfully, "citation needed". I really want to see your system that effectively prioritises one class of traffic over another that is not elevating the priority of the prioritised class over the non-prioritised class. This is by the by, a question to the whole WG, what operational theory about how NQB delivers lower latency over QB do you have that make Greg's claim above true in your views?

> or reserved bandwidth, but only a shallow-buffered queue and otherwise Default treatment, there isn’t an incentive for applications that need a deep buffer

[SM] But no application really needs a big buffer per se, but some applications might appreciate getting a larger capacity share... hence me harping on an attacker that paces its packets and is application limited to below the priority queue's capacity share. 

> to try to get anything “special” by picking the wrong codepoint.

[SM] But then NQB will do nothing... really you need priority scheduling of the shallow queue over the deep queue, otherwise the shallow queue will just produce more drops without any latency advantage. And it is the latency advantage that you are trying to sell here. As I explained in the past even the naive approach "giving the NQB queue 50% priority" as that sounds fair is flawed (I agree that this will make sharing between classes fair); as long as NQB traffic share is below 50% each NQB packet will get faster service than a QB packet, which results in NQB packets having priority over QB packets.
	And since the priority is priority is priority (there is no distinction between latency priority and throughput priority, that is not how packet scheduling works in a work conserving scheduler) NQB will require an attractive priority queue that invites abuse. Or NQB will not work at all, please pick one of the alternatives



>   Also, to be clear, the draft (particularly with the recent proposed changes*) talks about minimizing incentives , rather than making strong assertions about their absence.  
>  * https://github.com/gwhiteCL/NQBdraft/issues/46#issuecomment-2246620922

[SM] This is IMHO still arguable, you can not deliver on NQB's promises without some sort of prioritisation. So what IMHO you need to do is put in effective policing against abuse, as the underlaying design is inviting abuse.


> * https://github.com/gwhiteCL/NQBdraft/issues/47#issuecomment-2251030531

[SM] Respectfully, this is not a formal proof, this is more a set of talking points. 

Sebastian



>  -Greg