1

I have looked over the book "End-to-End QoS Network Design" by Tim Szigeti et al. and RFC4594. The RFC proposes 14 Service class:

enter image description here

I have a switch with simple QoS features. It has 14 egress queues on each port and you can only configure weights in weighted round robin scheduler for these queues. No bandwidth allocation and RSVP are available. Is there any standard or suggestion or usual way of setting these weights? I couldn't find any weight suggestion for these queues over the internet. (My switch has 8 egress queues on each port actually but, there are no standard weights for the 8-queue model either. If I reached weights for the 14-queue model, it's not difficult to remap them into the 8-queue model and recalculating weights)

Update: Thanks @Marc'netztier'Luethi for his comment, it seems there are 12 service classes in the RFC 4954.

Improve this question
8
  • 1
    What's the scale of the weights?
    – Zac67 ♦
    Jun 1, 2019 at 11:02
  • 1
    odd DSCP values (See 3rd column from screenshot) ? That's a novum. The Last bit of DSCP's six binary digits was zero, wherever I encountered it so far - I wonder how they came up with odd values, then. Also see en.wikipedia.org/wiki/… . Plus: RFC 4954 (tools.ietf.org/html/rfc4594) ended up with 12 classes. 14 was probably during the draft phase.
    – Marc 'netztier' Luethi
    Jun 1, 2019 at 14:36
  • 1
    What you are asking really depends on the traffic profile of your network, and what you want to achieve. QoS is very custom configured for each business. For example our business collected a lot of data on actual traffic flows and calculated how to achieve what we wanted. If you have a lot of small packets, e.g. VoIP, then you need to understand that there will be a lot of protocol overhead compared to larger data packets. If there were a one (or even few) size fits all, then the profile(s) would just be built in. It takes a lot of work to get QoS right.
    – Ron Maupin ♦
    Jun 1, 2019 at 14:49
  • 1
    That is because QoS is very custom. Most people use EF as the lowest latency, but some will use it as the highest-latency, most frequently dropped. You need to determine what percentage of your traffic should be treated the best, what that threatment should be, and should you police beyond your determination. There is nothing to which you can refer that says, "this is the way it should be." There is a lot of research to do before you implement QoS.
    – Ron Maupin ♦
    Jun 2, 2019 at 4:34
  • 2
    Also, based on experience, more than half a dozen classes are overkill. You probably want: LLC (real-time traffic like VoIP and video), control traffic (routing protocols, VoIP control, etc.), custom business traffic, default (most traffic), and low priority traffic (bulk traffic like server backups or other traffic that can monopolize the links).
    – Ron Maupin ♦
    Jun 2, 2019 at 4:38

1 Answer 1

Reset to default
5

14 egress queues seems a bit excessive - most devices I dealt with use 3, 4 (most common), or up to 8 queues. I'd just use four which simplifies things:

  1. critical traffic (very low-bandwidth, critical control traffic like OSPF, RIP)
  2. real-time applications (low bandwidth traffic like VoIP)
  3. normal applications (everything not in 1,2 or 4)
  4. low-priority (backup, software distribution)

Since bandwidth requirements are somewhat reciprocal to the desired priorities, simple round-robin with equal scheduling would nearly do the job, only low-priority needs some weighing down. With a linear round-robin weight of 1-127, I'd use 32:32:32:8.

More exact queueing and weighing requires you to know your network flows and their respective importance. This in turn may require a deep insight into the application layer as well. Generally, before fighting with QoS fine tuning for a lengthy period of time you should consider scaling up the network.

Improve this answer
4
  • OK! Straightforward approach! Thanks. But another question: How do you classify something like backup or software distribution traffic? Do these services appley specific DSCP value to their packets or network equipment does this?
    – A.A
    Jun 2, 2019 at 11:41
  • 1
    I helped to conceive, deploy and proof a similar concept for a financial institution with multiple divisions (stock exchange, findata collector/disseminator, card transaction processing, inter bank transaction services, trade clearing etc). We ended up calling the classes VOICE, CONTROL, BUSINESS and BULK. Every division's CIO was happy to see their traffic treated as BUSINESS, while being protected from BULK. What we never actually told anyone: Everything (there were 100s of applications) not VOICE, CONTROL, BULK got DSCP 0 and ran in the default queues of the various devices. :-)
    – Marc 'netztier' Luethi
    Jun 2, 2019 at 12:05
  • 2
    Mapping everything into just 4 classes/queues has one advantage: If the goal is to have QoS end-to-end, some lower-end platforms (as commonly seen as access switches) only have 4 hardware queues. With a 4 classes/queues model, you can avoid too much of device specific queue mapping acrobacy.
    – Marc 'netztier' Luethi
    Jun 2, 2019 at 12:09
  • 2
    @A.A That's actually a whole new question... You can't take any DSCP values for granted unless you've verified them. On the switches, you can usually map priority classes based on source/destination VLAN, source/destination transport-layer ports, or source/destination IP addresses.
    – Zac67 ♦
    Jun 2, 2019 at 14:23

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

Not the answer you're looking for? Browse other questions tagged or ask your own question.