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

["Black, David" <[e-mail]>]

> In links that today provide a single, deep-buffered queue for best-effort Default traffic, there may or may not exist protection mechanisms
> that prevent individual application instances (or individual users) from consuming too much bandwidth, or causing too much delay, or causing
> too much packet loss to the detriment of other application instances (or other users).  These mechanisms might be good to have in place
> in certain cases, but they aren’t always necessary (and they certainly aren’t mandated by the IETF).

> NQB doesn’t change this.

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?

Thanks, --David

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


[EXTERNAL EMAIL]
David,

I think you are missing the point.

In links that today provide a single, deep-buffered queue for best-effort Default traffic, there may or may not exist protection mechanisms that prevent individual application instances (or individual users) from consuming too much bandwidth, or causing too much delay, or causing too much packet loss to the detriment of other application instances (or other users).  These mechanisms might be good to have in place in certain cases, but they aren’t always necessary (and they certainly aren’t mandated by the IETF).

NQB doesn’t change this.

-Greg



From: "Black, David" <David.Black=[e-mail]<mailto:David.Black=[e-mail]>>
Date: Wednesday, July 24, 2024 at 10:09 AM
To: Jason Livingood <[e-mail]<mailto:[e-mail]>>, "Black, David" <David.Black=[e-mail]<mailto:David.Black=[e-mail]>>, "Overcash, Michael (CCI-Atlanta)" <[e-mail]<mailto:[e-mail]>>, gwhiteCL/NQBdraft <[e-mail]<mailto:[e-mail]>>, gwhiteCL/NQBdraft <[e-mail]<mailto:[e-mail]>>
Cc: tsvwg IETF list <[e-mail]<mailto:[e-mail]>>, David Black <[e-mail]<mailto:[e-mail]>>
Subject: [tsvwg] Re: [EXTERNAL] Re: [gwhiteCL/NQBdraft] Should traffic protection be mandatory to implement? (Issue #48)

> [JL] First hop access gear would typically still have per user/device/home flow boundaries

Would it be reasonable to specify those boundaries in a bit more detail and limit usage of this PHB to equipment that enforces such boundaries?

If that were to be done, then ...

> [JL] In any case, the user/device/home cannot exceed the bandwidth they have been provisioned.

... would be a fine "abuser can only shoot itself in the foot" conclusion to most of the security concerns because the boundaries prevent damage to others.

Thanks, --David

From: Livingood, Jason <[e-mail]<mailto:[e-mail]>>
Sent: Wednesday, July 24, 2024 12:54 PM
To: Black, David <[e-mail]<mailto:[e-mail]>>; Black, David <David.Black=[e-mail]<mailto:David.Black=[e-mail]>>; Overcash, Michael (CCI-Atlanta) <[e-mail]<mailto:[e-mail]>>; gwhiteCL/NQBdraft <[e-mail]<mailto:[e-mail]>>; gwhiteCL/NQBdraft <[e-mail]<mailto:[e-mail]>>
Cc: tsvwg IETF list <[e-mail]<mailto:[e-mail]>>
Subject: Re: [tsvwg] Re: [EXTERNAL] Re: [gwhiteCL/NQBdraft] Should traffic protection be mandatory to implement? (Issue #48)


[EXTERNAL EMAIL]
> A better example would be an NQB queue in ISP access network equipment a few hops away from the subscriber where the traffic in the NQB queue is from multiple users.

[JL] First hop access gear would typically still have per user/device/home flow boundaries – for example limiting home-1 to 300 Mbps per their service tier and home-2 to 1 Gbps, home-3 to 500 Mbps, and so on. Those users cannot exceed their service plan limits and take bandwidth from other users. If they consistently have high utilization that causes congestion at the aggregation point, the capacity monitoring systems would automatically trigger a normal capacity augmentation process. The second hop, just after that access aggregator would typically have extraordinary capacity and never experience congestion unless there was something extraordinary like one or more fiber cuts in a regional network.

[JL] In any case, the user/device/home cannot exceed the bandwidth they have been provisioned. And if they do use a lot of their provisioned bandwidth, that seems fine – as it is what they have paid for.