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

["Black, David" <[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.`

That's an improvement, but "significantly smaller" is almost as undefined as "shallow-buffered" and the size in octets of a 10ms queue varies dramatically by egress rate.

Trying a different perspective ... A simple way to attempt abuse of an NQB queue is to point a TCP connection at the queue and set TCP loose.  If that TCP is using IW10, then drops in that initial window would be a good initial disincentive for that sort of abuse (aside: this is all but assuming that the IW10 packets are not paced, which may not be a good assumption).  Attempting some quick back of the envelope math for my 50 Mbit home service, 15kB (10 x 1.5kB typical MTU) x 8 = 120 kbits.  120k/50M = 2.4ms at a 50Mbit line rate, which is less than 10ms.  If the NQB egress rate were capped at 10% of the line rate, then 15kB takes 24ms, so a 10ms bottleneck buffer size ought to cause multiple drops which will get that TCP's attention ;-).  OTOH, if the service rate is increased to 1 Gbit (available from my ISP), then that 24ms gets divided by 20, resulting in 1.2ms for 15kB which easily fits in a 10ms buffer.

At a minimum, I hope this illustrates that a fixed time period is not a great way to size NQB queues because the link/egress rates involved vary by a number of orders of magnitude.  There's more to be done from here to get to a complete solution.

Greg – two questions (with more doubtless to come):

  *   what sort of link/egress rates were assumed in coming up with the 10ms recommendation for NQB buffer size?
  *   The 10% NQB rate cap in the above example is at best a plausible assumption (e.g., could allow for 10 microflows @ 1% rate cap each, as described in the per-microflow rate policer for traffic protection) – what would make sense?

Thanks, --David

From: Greg White <[e-mail]>
Sent: Tuesday, July 23, 2024 7:47 PM
To: Overcash, Michael (CCI-Atlanta) <michael.overcash=[e-mail]>; Black, David <David.Black=[e-mail]>; gwhiteCL/NQBdraft <[e-mail]>; gwhiteCL/NQBdraft <[e-mail]>
Cc: Black, David <[e-mail]>; tsvwg IETF list <[e-mail]>
Subject: Re: [tsvwg] Re: [EXTERNAL] Re: [gwhiteCL/NQBdraft] Should traffic protection be mandatory to implement? (Issue #48)


[EXTERNAL EMAIL]
[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.