How must the queue sizes be designed to ensure that an application functions correctly?

Default queue configurations use generic drop thresholds and weights not tuned for specific application latency requirements, and they do not inherently compensate for serialization delay, making them unsuitable for latency-sensitive deployments.

Requiring each individual per-hop queuing delay to be less than or equal to the full application budget is technically incorrect because it is the cumulative sum of all per-hop delays - not each individual delay - that must fit within the budget.

Applications such as voice and video have a fixed maximum tolerable end-to-end delay (for example, 150 ms one-way for voice). The correct design approach is to sum the queuing delay contributed by every device in the chain together with the serialization delay on each link, and verify that this aggregate does not exceed the application's requirement. Designing per-hop budgets that keep the total within the allowed limit ensures the application functions correctly across the entire network path.

Requiring identical queuing delay on every device in the chain is neither necessary nor practical - devices have different speeds, queue depths, and traffic loads, and only the aggregate end-to-end total must satisfy the application's delay requirement.