Re: [tsvwg] draft-ietf-tsvwg-nqb-15.txt vs the cake AQM

[Sebastian Moeller <[e-mail]>]

Hi Dave,


> On Mar 14, 2023, at 15:01, Dave Taht <[e-mail]> wrote:
> 
> I have been sitting on the cake related patches for this for years
> now, and it is my hope to get support for NQB into the next linux
> release, regardless of whether it gets through last call at this time,
> unless the selected codepoint number changes. (?)
> 
> Cake (please see the man page here:
> https://man7.org/linux/man-pages/man8/tc-cake.8.html ) supports
> multiple diffserv models.
> 
> besteffort is exactly that, besteffort, and will not gain NQB support.
> 
> The diffserv3 interpretation is the default, and given that flow
> queuing handles most of the NQB-like problems naturally, and  Voice
> (CS7, CS6, EF, VA, TOS4) is all that is handled there today, I am
> thinking of *not* elevating NQB into that class is the right thing.
> 
> NQB fits nicely into the diffserv4 model in the video class, so I will
> put it there. since covid we tend to use the diffserv4 model a lot to
> manage videoconferencing better.

	Are you sure? Video gets up to 50% of shaper capacity at elevated priority.. this is not doing the required enforcement to keep NQB rate low...



> As for the CS0-CS7 precedence model inc cake, we have declared that
> obsolete in the code, and wherever NQB falls into it, great. And the
> diffserv8, I don´t know.
> 
> Anyway, does that work for everyone?

	Not for me, as you know I prefer to treat NQB like CS0 for all classes.

> 
> Part II of this would be a discussion of the various wash modes, but
> merely getting the right byte into the right lookup tables after all
> this discussion, would be nice.

	Wash is only a single mode and should stay so, remapping all DSCPs cake used to steer packets to priority tins to CS0 to not leak/reveal any of the internal details upstream. Users wanting to expose NQB to the world, simply do not configure wash or use nowash...
	I am not sure whether you are thinking in that direction at al or whether I am just "paranoid" but washing most DSCPs but retain NQB would IMHO a disservice to cake's users. If you believe such a functionality is needed, it should be configurable which DSCPs to retain and most importantly it should not be called wash to avoid confusion with the current behavior, please.

Regards
	Sebastian

P.S.: The bigger issue is that NQB's design goal is a shallow buffered queue where the side effects of that shallow buffers is hoped to discipline the NQB users not to try to game the system. While I generally believe this not to work, this is not what cake is going to offer, NQB flows will really only be bound by the capacity share. And e.g. a single NQB flow n diffserv4 (with no other non-BestEffort traffic, will be able to hog >= 50% of the total link capacity. That seems problematic... (this is also true for other DSCPs mapping into these priority tiers, but these are rarely exercised by applications without active user intervention in the first place).