Differentiated Services QOS

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

  1. :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.

    I have heard of that kind of billing before, as some of the large
    providers with presences hereabouts use it.

    Hereabouts, the entry level fibre is usually a "3 Mbit/s burstable"
    line on a 10 Mbit/s base. The signalling capacity of the pipe is 10 Mbit/s,
    but that pipe feeds in, along with a bunch of other such pipes, into
    a common router, the WAN link of which is more than N times 3 Mbit/s
    but less than N times 10 Mbit/s. You can thus burst above 3 Mbit/s,
    but when you start -sustaining- above 3 Mbit/s, you are eating away
    at the WAN bandwidth shared by all of the customers, so you have to
    pay more. They could bill at your peak for the month, but they know
    that peaks are very short lived and don't draw down on the shared
    bandwidth appreciably, so they instead bill by a smoothed function
    of what you actually use by taking the 95 percentile rate.
     
    Walter Roberson, Jan 27, 2005
    #21
    1. Advertisements

  2. bsudbury

    bsudbury Guest

    I think I may have found a way to do it with the Linux Advanced Routing
    project.

    http://opalsoft.net/qos/DS-211.htm - shows docs on the policing part of
    the project.

    In this, it seems that I could set an initial class that matches all
    traffic and sets a policer at 10Mbps, but after this 10Mbps has been
    hit, it does not drop the traffic, but instead pass it on to the next
    rule.

    The next rule would then match only bronze traffic, and would be set to
    a limit of 1Mbps and set to drop any bronze in excess of that.

    Any other traffic (ie. Gold traffic should drop through)

    Any traffic that is less than 10Mbps should match the first rule and
    just be delivered and not reach the second rule.

    Does anyone have any experience with this in Linux? Is this how it
    would work?

    Is there a similar way to do this in any cisco products?
     
    bsudbury, Jan 27, 2005
    #22
    1. Advertisements

  3. bsudbury

    bsudbury Guest

    I am having post cognitive dissonance in relation to my previous post.

    I think that it could lead to a situation where we could end up with
    5Mbps of Bronze trafic while gold is running at 10Mbps.

    It could be that only half of the gold traffic was recognised by the
    first rule while all of the bronze traffic was recognised by the first
    rule and all of the traffic that exceeds the first rule is gold. In
    that case, we wouldn't be acheiving the desired outcome.
     
    bsudbury, Jan 27, 2005
    #23
  4. bsudbury

    bsudbury Guest

    If I could combine the rules I mentioned above with a queue that
    ensured that gold packets would be the first packets to match the rules
    leaving bronze packets behind them so they would be the first packets
    to exceed the rules.

    Maybe I need an ingress queue doing the prioritisation and an egress
    queue doing the policing. Then I am not doping my policing as close as
    possible to the edge.
     
    bsudbury, Jan 27, 2005
    #24
  5. bsudbury

    Ben Guest

    I did some asking around and a few people know about 95th percentile
    billing although it is normally based on a recurring 5 minute AVERAGE
    not momentary bit rate. This makes a bit more sense :)
    I think this requirement is the problem. You want to change the
    behaviour in one class based on the behaviour of another.
    IOS can do this kind of reactive behaviour, but it's in the CBWFQ
    algorhitm itself, and not configurable as such.

    My solution above is probably the simplest approximation, although if
    the 3550 cannot do CBWFQ it's a moot point.

    Another idea that comes to mind (although I haven't had the time to
    think it through fully) is to introduce another class altogether.

    This would actually be Bronze-1Mbcap as opposed to Bronze-10Mbcap.
    For this to work you would need to classify the traffic on ingress to
    your edge device and apply a qos marking (e.g. ip precedence) which
    would transit the switch's internals.
    On engress, you would do the appropriate policing based on the qos
    marking. The trick here is of course to get the classification policy to
    work correctly.
     
    Ben, Jan 27, 2005
    #25
  6. bsudbury

    Ben Guest

    We are thinking along the same lines - see my post above.
     
    Ben, Jan 27, 2005
    #26
    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.