[j-nsp] SRX CoS Bandwidth

[Andrew Jones]

It’s covered in the Enterprise switching and routing book, but essentially the SRX works on a priority based scheduler instead of a weight based scheduler, where it will max out a higher priority queue before serving a lower priority one even if you have a transmit-rate configured. You can sort of get around it by setting all your queues to be the same priority, or putting in a rate limit on the higher priority queue so it can’t use all of the available bandwidth.

From: tim.hunt at bt.com<mailto:tim.hunt at bt.com>
Sent: ‎Tuesday‎, ‎January‎ ‎28‎, ‎2014 ‎3‎:‎15‎ ‎AM
To: juniper-nsp at puck.nether.net<mailto:juniper-nsp at puck.nether.net>

Hi,

Can anybody explain the QoS operation of a SRX when a higher priority queue is in negative credit and a lower priority queue is in positive credit yet has traffic to transmit?

The documentation suggests:
"Transmission Scheduling
The packets in a queue are transmitted based on their transmission priority, transmit
rate, and the available bandwidth.
By default, each queue can exceed the assigned bandwidth if additional bandwidth is
available from other queues. When a forwarding class does not fully use the allocated
transmission bandwidth, the remaining bandwidth can be used by other forwarding
classes if they receive a larger amount of offered load than the bandwidth allocated."

Yet we have observed starvation of lower priority queues in preference to higher (not strict-high). This appears to be at odds with say the MX or J-series routers mode of operation.

Thanks for your help,

Tim.

_______________________________________________
juniper-nsp mailing list juniper-nsp at puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp