Notable Replies

  1. Hi Hamood,

    Glad to hear it was useful!


  2. Abhishek,
    I would recommend you check out Rene’s lesson on QoS Classification. In this lesson, you will discover that there are all kinds of tools at your disposal to be able to identify, classify, and mark traffic for QoS treatment throughout your network. It is rarely the case, for the reasons you brought up, that a simplistic approach of using just IP addresses is used.

    As for your second question, you are essentially asking about what QoS is meant to do as a whole (so there isn’t a quick, easy answer). The key to getting QoS working properly relies on the network engineer doing a few critical things before actually configuring anything:

    1. Work with your business units to learn network expectations, and what applications are important to them
    2. Determine a kind of SLA from the business units to gauge how they want their applications to perform under heavy load
    3. Perform an “inventory” of what kind of traffic is present on your network, as well as the patterns of the traffic. For example, does it spike at certain times of the day? How do these spike times line up with how the rest of the business is using the network?

    After you have answered questions like these, then the actual QoS work begins. In a nutshell, you need to identify and mark important kinds of traffic as close to the source as possible. Once the traffic is marked, you can configure the devices on your network to treat this traffic in a way that is consistent with the expectations you learned from your meetings with the business units.

    As in example in your case, you could use NBAR or a combination of IPs and ports to classify the Skype traffic. You would have this traffic assigned a high priority marking (like DSCP EF, for example for voice data), then configure queuing (perhaps LLQ) to ensure this traffic is processed quickly under load.

    As you can see, QoS is a complicated topic–it will take a lot of reading and study on your part to master it!

  3. awesome, it clears now. Thanks for your crystal clear approach of explanation.

    I am eagerly waiting for L2VPN related topics (vpls etc…) :slight_smile:

  4. The text below has also to be corrected.

    _> The first 3 bits are used to define the class and the next 3 bits are used to define the drop probability. Here are all the possible values that we can use:_

    Only 2 bits are used for drop probability, the 6th bit is ignored.

  5. Hello Maodo

    According to RFC2474 it speaks about the DS field:

       Implementors should note that the DSCP field is six bits wide.  DS-
       compliant nodes MUST select PHBs by matching against the entire 6-bit
       DSCP field, e.g., by treating the value of the field as a table index
       which is used to select a particular packet handling mechanism which
       has been implemented in that device.  The value of the CU field MUST
       be ignored by PHB selection.  

    It says that the entire 6-bit field must be used. The bits in question are bits 0 to 5 (a total of six bits). Bits 6 and 7, also known as the CU bits, are currently unused. Could this be the “6th bit” that you mention should be ignored?

    Even in RFC791 (IP Header Structure) which precedes the above RFC, the then called Type of Service or ToS field used all six bits as can be seen from the link.

    I hope this has been helpful!


Continue the discussion

36 more replies!