Questions about Congestion Management/QOS

Discussion in 'Cisco' started by Douw Gerber, Nov 13, 2003.

  1. Douw Gerber

    Douw Gerber Guest

    Me and a collegue of mine are having a debate about various methods of
    QOS/Congestion Management and which ones are better to use. Maybe
    someone on this group can settle the argument for us :) Hopefully one
    of the many CCIE's here.

    Here is the scenario:

    We have a customer who is connected to our POP in City A via 256k
    Leased Line and in to our POP in City B via 192k - the headoffice is
    in city A. We then connect the two offices to each other via an MPLS
    VPN. We as the provider run a frame-relay link between our two POP's
    (2MB with 512k CIR)

    The client's request was that his Terminal Services get a guarenteed
    portion of the bandwidth so what we did initially was to set up
    Content Based Wighted Fair Queing (CBWFQ) on the interfaces where they
    connect to on our POP's and service the policy in an outbound
    direction towards the customer.

    I configured it so that TS would get a CIR of 25% of the available
    bandwidth - this is because as I understand CBWFQ this means that
    Branch A would then get a CIR of 64k burstable to the full 256k if
    available and other traffic could use the TS 64k if there was no TS
    traffic. Same goes for branch B.

    Question 1 is this correct??

    Then my colleague removed this setup and applied a rate-limit on our
    side at both branches which basically was as follows

    rate-limit output list 100 (TS Traffic) 64000 16000 24000
    conform-action transmit exceed-action continue
    rate-limit output 192000 48000 72000 conform-action transmit
    exceed-action drop

    This could work I guess but with rate-limit's as I understand it you
    are shaping traffic not guarenteeing bandwidth. The above obviously
    partitions a 64K portion of bandwidth for TS but when there is no TS
    other traffic also cant utilise the available bandwidth.

    Looking at the above which one of the two are correct or alternatively
    "more correct" :)

    Then also a comment was made by him that priority-lists are old
    technology. Id this correct?? My feeling is that priority-lists work
    well when used for the right reason depending on what you would like
    to achieve.

    Any and all comments will be appreciated

    Thanks in advance
    Douw Gerber, Nov 13, 2003
    1. Advertisements

  2. Douw Gerber

    CCIE8122 Guest

    We have a customer who is connected to our POP in City A via 256k
    CBWFQ is actually "class-based weighted fair queuing" (not "content").
    Basically you are dividing up traffic types into classes, which are then
    assigned bandwidth, packet limits, weight, etc. Bandwidth assigned to
    indiv classes is guaranteed during congestion, and IIRC, flows within
    the class are WFQ'd among themselves.
    Correct. CAR is not congestion management as CBWFQ is, but is in fact
    traffic policing. You are capping the amount of BW that a particular
    traffic profile can use, regardless of whether there is congestion or not.
    Both are equally correct. It just depends upon what you want to do. If
    you are after guaranteeing a min BW for a traffic type, scenario 1 is a
    correct method (but not the only correct one-- you could also use CQ,
    which is probably preferable because it is simpler, unless you have a
    lot of classes and more complex schema). My rule of thumb is always use
    the simplest method to accomplish what you want to do.

    On the other hand, if you want to limit TS to 64k, no matter what, then
    CAR is the correct method, as your colleague suggests.
    PQ is just different. You can use PQ within CBWFQ. PQ is just a
    different queuing strategy. Whether it is old or not is a non-issue.
    If you want to guarantee that a given queue gets serviced and drained no
    matter what, you use PQ. Use with caution, however, cause PQ if
    implemented improperly can cause queue starvation which is a b****.

    But to answer your question, PQ is still very much alive and well. In
    fact, some of the "newer, sexier" QoS methods with which your colleague
    appears to be enamored, require PQ:

    LLQ is just PQ applied to the voice class of CBWFQ.

    CCIE8122, Nov 18, 2003
    1. Advertisements

  3. Douw Gerber

    Douw Gerber Guest

    Thank you very much for the insightfull reply - it has clarified things
    a lot.
    Douw Gerber, Nov 18, 2003
    1. Advertisements

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments (here). After that, you can post your question and our members will help you out.