Differentiated Services QOS

Discussion in 'Cisco' started by bsudbury, Jan 23, 2005.

  1. bsudbury

    bsudbury Guest

    Hi There,

    We are colocated in a datacenter where we are charged for traffic on a
    95th percentile basis. ie. Our interface transmit and receive rates are
    sampled every five minutes and at the end of the month the top 5% of
    figures are discarded, we are then charged for the highest figure in
    the remaining lot.

    We have a situation where we would like to create two classes of
    traffic which we will call gold and bronze. The idea is that gold class
    would continue to burst to meet demand while bronze has a base amount
    of bandwidth available to it but can expand during off peak times. So,
    we might define a peak time as when gold traffic is at or above 10Mbps.
    And we might define the minimum traffic for bronze traffic as 1Mbps.

    In this case the amount of bandwidth available to bronze traffic should
    be defined by the following.

    GoldPeak = 10Mbps
    BronzeMinimum = 1Mbps
    GoldCurrent = The current gold bandwidth

    So at any point in time:

    If GoldPeak > GoldCurrent

    BronzeBandwidth = GoldPeak - GoldCurrent + BronzeMinimum

    Otherwise

    BronzeBandwidth = BronzeMinimum

    My current solution for this involves using snmp to check the current
    bandwidth level and then changing the aggregate policer throttle for
    Bronzetraffic (defined by ACL) using tftp and snmp.

    This should work, but suffers from the fact that the throttle is only
    defined periodically. What I would really like is something more
    realtime.

    I figured that there may be some way to do this within the qos settings
    without needing an external program or system. I am using a cisco 3550
    to do this.

    Any assistance (directions to examples of similar configs, pointers,
    howto's) would be greatly appreciated.

    Regards,


    Ben Sudbury
     
    bsudbury, Jan 23, 2005
    #1
    1. Advertisements

  2. :We are colocated in a datacenter where we are charged for traffic on a
    :95th percentile basis.

    :The idea is that gold class
    :would continue to burst to meet demand while bronze has a base amount
    :eek:f bandwidth available to it but can expand during off peak times.

    :If GoldPeak > GoldCurrent
    :BronzeBandwidth = GoldPeak - GoldCurrent + BronzeMinimum
    :Otherwise
    :BronzeBandwidth = BronzeMinimum

    Seems a bit complicated.

    Would it perhaps work out to define the 'gold' traffic into
    the high priority "deliver first" queue, and to define the 'bronze'
    through a best-efforts policer with a cap?
    I guess it depends on the behaviour you want in the extreme caes.
    Your algorithm has these implications that it would be good to
    explicitly confirm you want:

    - if 'gold' is currently using (say) 50 Mbit/s then you want gold
    customers to continue unthrottled, but meanwhile bronze should still
    receive a minimum of 1 Mbit/s ?

    - if there is no present gold traffic at all, bronze will be allowed
    up to 11 Mbit/s ?

    - bronze traffic will never be permitted past 11 Mbit/s, even if there
    is no gold traffic and even if the 95%th percentile because of the
    bursting gold is up around (say) 50 Mbit/s ? That is, that even when you
    know that your gold customers have peaked above N Mbit/s for more than
    37 hours so far this month, you would limit the bronze to 11 Mbit/s
    even though allowing them to go all the way up to the 95%th
    percentile would not increase your costs?
     
    Walter Roberson, Jan 24, 2005
    #2
    1. Advertisements

  3. bsudbury

    Ken Johnson Guest

    Have you examined Cisco Class-Based Waighted Fair Queueing and the
    "bandwidth" command? Sounds like it will do what you want.
     
    Ken Johnson, Jan 24, 2005
    #3
  4. :Have you examined Cisco Class-Based Waighted Fair Queueing and the
    :"bandwidth" command? Sounds like it will do what you want.

    I haven't looked at Class-Based WFQ yet, but I think there may be
    a difference between what it can do and what the OP asked for.
    The OP's algorithm provides for open-ended bandwidth access for
    'gold' customers -- if most gold customers only use (say) 3 Mbit/s
    but one of them wants to run at 100 Mbit/s flat out for a week solid
    [e.g., to a different box at the same colo] then the OP's algorithm
    would permit that access. And yet in the meantime, the 'bronze'
    customers should still be allocated 1 Mbit/s minimum no matter how much
    the 'gold' customers are usng.

    WFQ is, as best I understand, useful for the case in which there is an
    upper limit on the bandwidth and prioritization must be done within
    that bandwidth.

    This triggers in my mind the question, "But suppose that link was
    expensive: you wouldn't want traffic to be filling it more than
    necessary to pass the high priority traffic." I haven't looked at WFQ
    enough to know if it can take differing port costs into account [other
    than on a traffic-ratio basis -- load balancing over unequal cost
    links]. This hypothetical requirement does, though, remind me of
    the overview descriptions of what MPLS is useful for.
     
    Walter Roberson, Jan 24, 2005
    #4
  5. bsudbury

    bsudbury Guest

    :Seems a bit complicated.

    I agree, but it seems that you get the idea of what we want to do. If
    the algorithm that I have outlined is not exactly what happens that is
    not a problem, the main idea is to deliver this bronze traffic at a
    fixed cost but for it to have the benefit of our off-peak periods.

    :Would it perhaps work out to define the 'gold' traffic into
    :the high priority "deliver first" queue, and to define the 'bronze'
    :through a best-efforts policer with a cap?
    :I guess it depends on the behaviour you want in the extreme caes.
    :Your algorithm has these implications that it would be good to
    :explicitly confirm you want:

    I am not sure, my experience with this type of thing is limited to a
    few experiments in a test environment, How would this method "know" if
    we were over GoldPeak?

    :- if 'gold' is currently using (say) 50 Mbit/s then you want gold
    :customers to continue unthrottled, but meanwhile bronze should still
    :receive a minimum of 1 Mbit/s ?

    That is correct.

    :- if there is no present gold traffic at all, bronze will be allowed
    :up to 11 Mbit/s ?

    That is correct.

    :- bronze traffic will never be permitted past 11 Mbit/s, even if there
    :is no gold traffic and even if the 95%th percentile because of the
    :bursting gold is up around (say) 50 Mbit/s ? That is, that even when
    you
    :know that your gold customers have peaked above N Mbit/s for more than
    :37 hours so far this month, you would limit the bronze to 11 Mbit/s
    :even though allowing them to go all the way up to the 95%th
    :percentile would not increase your costs?

    In an ideal scenario, bronze traffic would be adjusted upwards in this
    scenario to the point where it would not increase costs, but I could
    implement this with an external monitor periodically changing the level
    of GoldPeak.

    My experience is very linited, so please humour me but I was thinking
    something like applying a policer on bronze traffic that sets the
    precedence on traffic over 1Mbps so that it is in a low priority queue,
    but then I can't really work out what will happen with that traffic if
    gold traffic is sitting at 2mbps sustained. It seems to me that the
    bronze traffic in excess of 1mbps would just not get through. I guess
    in this scenario, I can't work out how to tell the switch what the
    level of gold peak is.

    Maybe I have it back to front, maybe I set a policer on gold traffic at
    10Mbps and any traffic over 10mbps goes into a high priority queue
    while bronze traffic over 1mbps is set with another policer to go into
    a low priority queue, but somehow I think this may deliver the gold
    traffic that is over 10mbps at a priority to the regular gold traffic
    which could cause all sorts of problems.

    as you can see, I am somewhat confused by this, but it does seem that
    there would be a way to do this.
     
    bsudbury, Jan 24, 2005
    #5
  6. Hello, !
    You wrote on 24 Jan 2005 14:45:11 -0800:

    One of the solutions would be to shape bronze traffic to 11 Mbps and also set
    bandwidth statement of 1 Mbit to give it a minimum guarantee. You can leave gold
    traffic for class-default. In case of congestion bronze traffic will get 1 Mbps
    only, and if there is no congestion it will go all the way to 11 Mbps. Gold
    traffic will be able to use the whole pipe minus 1 Mbps.

    With best regards,
    Andrey.
     
    Andrey Tarasov, Jan 25, 2005
    #6
  7. bsudbury

    bsudbury Guest

    Hi Andrey,

    That sounds good, I just need some more clarification on what you are
    suggesting.

    When you say shape bronze traffic to 11 Mbps, which technology /
    algorithms are you suggesting I use?

    If you can tell me the Cisco terminology for what you are suggesting, I
    can then have a look further in their documentation to work out what to
    do.

    Best Regards

    Ben.
     
    bsudbury, Jan 25, 2005
    #7
  8. Hello, !
    You wrote on 24 Jan 2005 20:53:49 -0800:

    b> Hi Andrey,

    b> That sounds good, I just need some more clarification on what you
    b> are suggesting.

    b> When you say shape bronze traffic to 11 Mbps, which technology /
    b> algorithms are you suggesting I use?

    b> If you can tell me the Cisco terminology for what you are
    b> suggesting, I can then have a look further in their documentation
    b> to work out what to do.

    It's Class-Based Weighted Fair Queueing.

    http://www.cisco.com/en/US/products...on_guide_chapter09186a00800b75a9.html#1001203

    Config will look something like

    class-map Bronze
    match xxx

    policy-map QoS
    class Bronze
    bandwidth 1000
    shape average 11000000
    class class-default
    fair-queue

    With best regards,
    Andrey.
     
    Andrey Tarasov, Jan 25, 2005
    #8
  9. bsudbury

    bsudbury Guest

    I just had a look into shaping, and it appears that it is not available
    on the Cisco 3550.

    But wouldn't it be the same if I set it to police traffic at 11Mbps and
    used the bandwidth command to guarantee 1mbps?

    Would this really work? What if gold and bronze traffic both wanted to
    run at 10 Mbps, wouldn't this kind of config allow that?

    Regards,

    Ben
     
    bsudbury, Jan 25, 2005
    #9
  10. Hello, !
    You wrote on 24 Jan 2005 22:15:02 -0800:

    b> I just had a look into shaping, and it appears that it is not
    b> available on the Cisco 3550.

    Oops! I missed that part.

    b> But wouldn't it be the same if I set it to police traffic at
    b> 11Mbps and used the bandwidth command to guarantee 1mbps?

    I don't think there is bandwidth command on 3550 platform. There is 4 transmit
    queues and it's possible to put specific traffic into single queue and use
    Weighted Round Robin (WRR) mechanism to allocate guaranteed bandwidth. On the
    other hand I don't think you will need it. Policing for bronze traffic should be
    enough.

    b> Would this really work? What if gold and bronze traffic both
    b> wanted to run at 10 Mbps, wouldn't this kind of config allow that?

    Since you only police bronze traffic gold class will use the rest of the
    bandwidth, up to interface speed.

    With best regards,
    Andrey.
     
    Andrey Tarasov, Jan 25, 2005
    #10
  11. bsudbury

    bsudbury Guest

    Hi Andrey,

    :I don't think there is bandwidth command on 3550 platform

    It seems that there is the bandwidth command on the 3550, but I haven't
    actually tried it to see if it works.

    :Since you only police bronze traffic gold class will use the rest of
    the
    :bandwidth, up to interface speed.

    So, with this config, what would happen if gold traffic was at 22mbps,
    wouldn't bronze traffic still be allowed to continue right up to 11mbps
    also?

    Just to repeat the desired behaviour:

    :GoldPeak = 10Mbps
    :BronzeMinimum = 1Mbps
    :GoldCurrent = The current gold bandwidth

    :So at any point in time:

    :If GoldPeak > GoldCurrent

    :BronzeBandwidth = GoldPeak - GoldCurrent + BronzeMinimum

    :Otherwise

    :BronzeBandwidth = BronzeMinimum

    So, in the desired scenario, if gold traffic was at 22mbps, bronze
    should be at 1mbps.

    If gold was at 5mbps, bronze should be at 6mbps.

    Do you think that this would be the result of the commands that you
    have suggested? Are you able to explain why in both the 22mbps case and
    the 5mbps case?
     
    bsudbury, Jan 25, 2005
    #11
  12. Hello, !
    You wrote on 25 Jan 2005 03:42:48 -0800:

    b> :I don't think there is bandwidth command on 3550 platform

    b> It seems that there is the bandwidth command on the 3550, but I
    b> haven't actually tried it to see if it works.

    b> :Since you only police bronze traffic gold class will use the rest
    b> of the
    b> :bandwidth, up to interface speed.

    b> So, with this config, what would happen if gold traffic was at
    b> 22mbps, wouldn't bronze traffic still be allowed to continue right
    b> up to 11mbps also?

    b> Just to repeat the desired behaviour:

    b> :GoldPeak = 10Mbps
    b> :BronzeMinimum = 1Mbps
    b> :GoldCurrent = The current gold bandwidth

    b> :So at any point in time:

    b> :If GoldPeak > GoldCurrent

    b> :BronzeBandwidth = GoldPeak - GoldCurrent + BronzeMinimum

    b> :Otherwise

    b> :BronzeBandwidth = BronzeMinimum

    b> So, in the desired scenario, if gold traffic was at 22mbps, bronze
    b> should be at 1mbps.

    b> If gold was at 5mbps, bronze should be at 6mbps.

    b> Do you think that this would be the result of the commands that
    b> you have suggested? Are you able to explain why in both the 22mbps
    b> case and the 5mbps case?

    Somehow I've thought that GoldPeak is equal to interface speed. If this is not
    the case I'm afraid 3550 is not suitable for the job. You will need parent QoS
    policy with shaper set to GoldPeak+BronzeMinimum to cap _all_ traffic. Than
    inside of nested policy you will have class for Bronze traffic with 1Mb
    bandwidth and one for Gold with 10Mb. With no congestion each class will be able
    to go all the way to GoldPeak+BronzeMinimum and if there is a congestion each
    one will get whatever guaranteed by bandwidth statement.

    With best regards,
    Andrey.
     
    Andrey Tarasov, Jan 25, 2005
    #12
  13. bsudbury

    bsudbury Guest

    Hi Andrey,

    It seems to me that if I set a shaper to cap _all_traffic to
    GoldPeak+BronzeMinimum, then I would limit gold to being able to use
    10Mbps, when really I don't want to limit gold at all, I only want to
    limit bronze traffic.

    If only I could get the policer or shaper to have two triggers, 1 when
    bronze traffic is over 1Mbps and the other when gold traffic is over
    10Mbps.

    Does anyone have any other suggestions?

    regards,

    Ben
     
    bsudbury, Jan 25, 2005
    #13
  14. Hello, !
    You wrote on 25 Jan 2005 13:18:54 -0800:

    b> Hi Andrey,

    b> It seems to me that if I set a shaper to cap _all_traffic to
    b> GoldPeak+BronzeMinimum, then I would limit gold to being able to
    b> use 10Mbps, when really I don't want to limit gold at all, I only
    b> want to limit bronze traffic.

    b> If only I could get the policer or shaper to have two triggers, 1
    b> when bronze traffic is over 1Mbps and the other when gold traffic
    b> is over 10Mbps.

    There is no Cisco built-in solution for this to best of my knowledge. Two rate
    policer is available on some platforms but I don't see how it's going to help.

    With best regards,
    Andrey.
     
    Andrey Tarasov, Jan 26, 2005
    #14
  15. bsudbury

    bsudbury Guest

    Thanks Andrey,

    I will have to stick with the original plan of updating the policer
    periodically through an external application.

    At least now I won't be up at nights thinking "There must be a way!"
    Regards,


    Ben
     
    bsudbury, Jan 26, 2005
    #15
  16. bsudbury

    Ben Guest

    I still a little confused as to your requirements. Can you separate
    these entirely from any supposed solutions and restate them? Then, if
    there is a solution I am sure I can find it for you :)
    cheers,
    Ben
     
    Ben, Jan 26, 2005
    #16
  17. :I still a little confused as to your requirements. Can you separate
    :these entirely from any supposed solutions and restate them?

    I'm not the original poster, but this is what the original poster has
    asked for:

    - Two classes of users
    - One class is not to be artificially limited as to bandwidth. This
    class will be billed according to actual usage.
    - The second class will pay flat rate.
    - The second class is to be limited to no more than 11 Mbit/s.
    - Any usage by the first class of users is to reduce the available
    bandwidth to the second class of users, except that the second class
    should always get a minimum of 1 Mbit/s.

    To phrase things a completely different way: under the constraint
    that the one class of users is to always be entitled to a minimum
    of 1 Mbit/s [between all of them], and that the bandwidth of the other
    class of users is not to be restricted, the bandwidth allocated to the
    limited users should be such that usage by the limited class does not
    push the total bandwidth beyond the 95%'th percentile for the month:
    bandwidth for the limited class is to be limited so as to not trigger
    a rate increase [unless such is necessary in order to meet the
    1 Mbit/s minimum guarantee.]
     
    Walter Roberson, Jan 26, 2005
    #17
  18. bsudbury

    Ben Guest

    I think the part that is hard to understand about this is why the below
    is a requirement?
    I can't understand what you are trying to acheive with this. Either
    there is still some false assumptions inherent in the argument or there
    are some strange billing practices going on...

    My approach to this would be to first state very simply the actual
    requirements - do not confuse these with your possible solutions

    1) Bronze get's a minimum of 1Mbs
    2) Gold does not get capped and so has a minimum gauarantee of someting
    close to your access speed (which you have not specified)
    3) I can't glean the 3rd requirement from this discussion, as it relates
    to how your provider bills you. I have never heard of a provider billing
    based on 'sampled rates' (his seems quite odd to me) Normally you
    purchase an access link at a particular rate and have free reign up to
    that speed. Or you are billed based on actual bits served in a
    particular timeframe. I am unsure why a provider would find it desirable
    to bill on a momentary rate sampled only once every five minutes.

    Anyhow, in case I have misunderstood, can you please re-explain what
    access link you have and how you are billed?



    The solution:

    Ignoring reqiurement number 3 for now, I will assume you have a 100Mbs
    access link and want to allow the Gold class to have up to 95% of that.

    interface fasteth 0
    max-reserved-bandwidth 95
    service-policy output WHATEVER

    policy-map WHATEVER
    class Bronze
    bandwidth percent 1
    police 11000000
    class Gold
    bandwidth percent 94

    bandwidth represents a minimum guarantee that CBWFQ will provide. Note
    the relative priority of each class is inherent in the ratio between the
    two bandwidth values, i.e. 94:1

    To summarise the policy, Bronze can have up to 11Mbs but only provided
    Gold is not using more than 84Mbs.

    In practice:

    If Bronze wants 10Mbs and Gold wants 50Mbs, no problem
    If Bronze wants 11Mbs and Gold wants 1Mb, no problem
    If Bronze wants 12Mbs, and Gold wants 20Mbs, Bronze gets 11Mbs

    More complex:

    If Bronze wants 12Mbs, and Gold wants 90Mbs, Bronze only gets 5Mbs (plus
    a fraction of the unreserved 5Mbs)
    If Bronze wants 2Mbs and Gold wants 97Mbs, this is probably ok since we
    have an unreserved 5Mbs leftover - although at one time Gold is only
    *guaranteed* to get 94Mbs


    Is this what you are trying to achieve? (please ignore the fact that
    this configuration is not possible on a 3550 for now!)

    cheers,

    Ben
     
    Ben, Jan 27, 2005
    #18
  19. bsudbury

    bsudbury Guest

    I am the original poster and I agree that what Walter has outlined is
    what we are looking for.

    I will reiterate with some extreme case examples.

    Note: We are on a 100Mbps link.

    In Walter's post, The first class of traffic we will call Gold and the
    second class of traffic we will call Bronze.

    So, the following equation should define the rates at all times.

    GoldPeak = 10Mbps
    BronzeMinimum = 1Mbps
    GoldCurrent = The current gold bandwidth

    So at any point in time:

    If GoldPeak > GoldCurrent

    BronzeBandwidth = GoldPeak - GoldCurrent + BronzeMinimum

    Otherwise

    BronzeBandwidth = BronzeMinimum

    Remembering that we don't want to shape gold bandwidth at all, it
    should burst out to the maximum size of the pipe less the 1Mbps used by
    bronze.

    So, in the case where There is no Gold traffic at all, bronze would use
    up 11 Mbps.

    In the case where Gold was using 5Mbps, bronze will ber permitted up to
    6Mbps.

    If Gold was using 10 Mbps, bronze would be permitted only 1Mbps.

    The ultimate goal is that we don't allow the bronze traffic to push our
    95th percentile figure more than 1Mbps beyond what it would be with
    Gold traffic alone.
     
    bsudbury, Jan 27, 2005
    #19
  20. bsudbury

    bsudbury Guest

    Hi Ben,

    First of all, let me explain how and why we are billed on a 95th
    percentile basis.

    How:

    Our interface transmit and receive rates are sampled once every five
    minutes and at the end of the month the top 5% of figures are
    discarded, we are then charged for the highest figure in the remaining
    lot.

    Why:

    We have the advantage of being able to burst our link for peak loads
    but we are being charged for a figure that is closer to what we
    regularly use on the link. Rememeber this is in a co-location
    datacenter where there are a number of other customers using the total
    available bandwidth. From the datacenter's point of view, they can
    allow us to burst once in a while because the capacity is such that it
    can handle bursts form several customers but not all at once. From our
    point of view we get to burst 5-10Mbps over what we are being billed
    for. Of course, we pay more per Mbps for this type of data but it seems
    to work well.

    To try to simplify the requirements:

    1) Bronze get's a minimum of 1Mbs
    2) Gold does not get capped and so has a minimum guarantee of 99Mbps
    3) If the Sum of Bronze and Gold is greater than our 95th pct level
    Bronze must be restricted to 1MBps even though the link is not
    congested.

    I hope that clarifies it.

    Regards,

    Ben.
     
    bsudbury, Jan 27, 2005
    #20
    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.