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

[Greg White <[e-mail]>]

[From David:]
> I understand the overall intent, and I'm fine with that as a high-level goal/direction. The problem is that in the -24 version of the draft, "shallow-buffered" is an all-but-undefined term. …. The detailed requirements for sufficiently shallow buffers that realize that non-performance guarantee need to be specified and mandated, e.g., in Section 5.1 of the draft.

Ok, I think this is solvable.  Here is a proposal:
`The NQB queue MUST have a buffer size that is significantly smaller than the buffer provided for Default traffic. It is RECOMMENDED to configure an NQB buffer size less than or equal to 10 ms at the shared NQB/Default egress rate.`


[From David:]
> Proceeding in this direction ... if traffic protection is not mandatory to implement, then the draft will need to restrict NQB implementation and usage (using "MUST" and "MUST NOT" or equivalent RFC 2119 keywords) to network environments that have "other ways to address malicious sources."

[From Michael:]
> I also don’t think it is necessary or helpful to try to solve for malicious actors here. Any malicious actor can fill up queues and crowd out other traffic simply by sending high rate UDP. Shallow buffers are not uniquely vulnerable here. On the contrary, there is no buffer so large that a malicious actor cannot easily fill it.

I agree with Michael’s viewpoint.  Similar to my previous argument, the IETF doesn't restrict implementations of the Default PHB to only being deployed in network environments that have "other ways to address malicious sources." What would be the rationale to do so here?  It is IMO definitely ok to include guidance to network operators saying that NQB implementations that lack traffic protection are as vulnerable to malicious traffic as other queues, and so the operator should follow existing best practices to protect their NQB queues from malice.