QoS and available Bandwidth

Discussion in 'Cisco' started by JF Mezei, Dec 6, 2010.

  1. JF Mezei

    JF Mezei Guest

    On a 871W, I am implementing QoS.

    I have an ACL which defines the UDP ports used by the VoIP/SIP system.

    interface Dialer 1
    service-policy output voip-QoS
    ...

    class-map match-any class-voip
    description VOIP traffic QOS
    match access-group name ACLvoip
    !
    !
    policy-map voip-QoS
    class class-voip
    priority 240
    class class-default
    fair-queue

    There is a complaint when it loads that only 42kbps is available (when I
    request 240 for the class-voip)




    show queueing int Dialier 1:

    Interface Dialer1 queueing strategy: fair
    Input queue: 0/75/0/0 (size/max/drops/flushes); Total output drops: 0
    Queueing strategy: weighted fair
    Output queue: 0/1000/64/0 (size/max total/threshold/drops)
    Conversations 0/0/16 (active/max active/max total)
    Reserved Conversations 0/0 (allocated/max allocated)
    Available Bandwidth 42 kilobits/sec



    QUESTION:

    Must I tell the router the maximum speed of the link ? (if so, with what
    commands and where ?) Where does the 42kbps number come from ?

    Since this is a PPPoE link, would the definition of maximum uplink speed
    (if required) be at the IP level, PPPoE level or ethernet level ? (for
    instance, an 800kbps ADSL1 link has significant overhead when you
    factior in ATM, ethernet and PPPoE.
     
    JF Mezei, Dec 6, 2010
    #1
    1. Advertisements

  2. JF Mezei

    JF Mezei Guest

    Thanks. I ended up with 2 statements.

    bandwidth 700
    bandwidth receive 6190

    Seems it doesn't accept it in one line.

    I remember reading about bandwidth, and noting that it was just some
    "information" that didnt control actual throughput. But rereading it
    again and implementing it does seem to affect the QoS system.


    This is a 7mbps 800kbps ADSL link. I removed the ethernet, PPPoE and ATM
    overhead to get those numbers.

    This router does not have a buiolt in ADSL modem, only a 100mbps
    ethernet port to the modem, so it has no way of knowing what throughput
    the link is capable of.


    What is not clear to me is what the bandwidth includes.
    The above numbers assumes it includes only the IP header and its payload.

    The router can't know about the ATM overhead. But it would know about
    ethernet, PPPoE overheads. (but ATM represents the greatest overhead).


    Now, I get:
    router1#show queueing int dialer 1

    Interface Dialer1 queueing strategy: fair
    Input queue: 0/75/0/0 (size/max/drops/flushes); Total output drops: 0
    Queueing strategy: weighted fair
    Output queue: 0/1000/64/0 (size/max total/threshold/drops)
    Conversations 0/0/16 (active/max active/max total)
    Reserved Conversations 0/0 (allocated/max allocated)
    Available Bandwidth 527 kilobits/sec


    Out of curiosity, wouldn't QoS on the receive side also work ? If you
    stop the flow at the end of the pipe instead of at the start of it,
    wouldn't senders of non priorioty packets detect packets dropped (by my
    router) and slow down ?
     
    JF Mezei, Dec 6, 2010
    #2
    1. Advertisements

  3. JF Mezei

    alexd Guest

    Meanwhile, at the comp.dcom.sys.cisco Job Justification Hearings, JF Mezei
    chose the tried and tested strategy of:
    Even if it was built in, with a best-effort service like DSL the router
    doesn't know what bandwidth it has available either. All you can do is test
    it and plug in some numbers.
     
    alexd, Dec 6, 2010
    #3
  4. JF Mezei

    JF Mezei Guest


    But with :

    policy-map voip-QoS
    class class-voip
    priority 240
    class class-default
    fair-queue


    Shouldn't any voip traffic get priority over "class-default" for the
    first 240kbps of traffic no matter whether the line is 300kbps or 10gbps ?


    Also, if I have "bandwidth 600" in the interface,

    why does:

    router1#show queue dialer 1
    Input queue: 0/75/0/0 (size/max/drops/flushes); Total output drops: 0
    Queueing strategy: Class-based queueing
    Output queue: 0/1000/64/0 (size/max total/threshold/drops)
    Conversations 0/0/256 (active/max active/max total)
    Reserved Conversations 0/0 (allocated/max allocated)
    Available Bandwidth 210 kilobits/sec


    Show 210kbps available ?

    I could understand 600, or 600-240=360 or 240. But 210 ?



    Another question:

    OK, so I want voip to have priority of at least 240kbps. Rest is fair
    queue in the above.

    Is it possible to create a web-class (my web server's outbount traffic)
    which would not have any bandwidth garantee, but would have priority in
    the queue against the rest of the traffic ?
     
    JF Mezei, Dec 6, 2010
    #4
  5. JF Mezei

    Stephen Guest

    The golden rule with "bandwidth" statements is high enough to be
    realistic, but at or lower than the real useful data rate.

    If you have say "priority" for your VoIP traffic and other stuff in a
    WRED queue, then the WRED queue will naturally use everything
    available - spare bandwidth allocated to priority or stuff you never
    allocated or whatever.
    The Tx ring is the last buffer for packets waiting to go out on the
    wire.

    The router doesnt drop from the Tx buffer unless something goes badly
    wrong (like the line going down) - it is just a holding area to feed
    bits to the hardware.

    The assumption is that "significant buffering" is done in the QoS
    queues, and the Tx ring just trades some jitter for line use
    efficiency.
    QoS is about controlled unfairness for different sets of traffic.

    because QoS works by controlling what goes into a queue and what order
    things come out, it only has a big effect at a choke point in the
    traffic flow (although since you often dont know where that is,
    ideally QoS should be at each point through the network where
    congestion might build up)

    For a traditional user the inbound traffic dominates the flow, and the
    ADSL line on a broadband link is the biggest choke point. So the most
    effective way to control you inbound traffic is at the ISP DSLAM
    connection.

    There are devices that can handle inbound QoS in this kind of setup -
    but they manipulate the TCP window and other high level aspects of TCP
    to control upstream.
    WRED will have the effect of making flows "back off" in TCP.

    2 issues.
    1 - WRED doesnt have any effect on UDP, so if your line is heavily
    used for something like iplayer it isnt going to do much good (at
    least not directly)
    2 - you are assuming there is good correlation between outgoing TCP
    flows and incoming - unfortunately a well tuned TCP stack will see a
    big difference in useful data flow vs reverse direciton control
    traffic.

    a link to a Cisco doc about QoS good practice:
    http://www.cisco.com/en/US/docs/solutions/Enterprise/WAN_and_MAN/QoS_SRND/QoSIntro.html
     
    Stephen, Dec 7, 2010
    #5
  6. JF Mezei

    JF Mezei Guest

    I need a sanity check...

    The dialer 1 has a "bandwidth 600" and max-reserved-bandwidth 100 (since
    there is no routing protocol on some simple PPPoE link)


    Dialer 1 gets attached to a 100mbps ethernet port that leads to the
    modem which has an 800kbps ADSL uplink. (translates to about 600kbps in
    application throughput in real life).


    How does the router detect congestion ? It gets data at 100mbps from
    the lan, and is able to push it out the ethernet link to the modem at
    100mbps.

    Does the "bandwidth 600" command really tell the policy-map that any
    throughput higher than that will cause congestion ?
     
    JF Mezei, Dec 7, 2010
    #6
  7. JF Mezei

    bod43 Guest

    I last worked on this a couple of years ago
    and things may have changed but here is what I found.

    On IOS almost no QoS works as advertised or as you might
    expect. There are many many exceptions to what works
    and these exceptions are undocumented. There will be
    many fine configuration examples but it turns out that
    none of them work on your platform/interface-type/
    something-else and that what works and what doesn't
    work is not described.

    Given that I have got QoS to actually work on DSL.

    I forget all of the details but I think I can recall enough.

    1.
    QoS ONLY works outbound on an interface.

    2.
    Traffic shaping cannot be used on a dialer.

    3.
    The trick on DSL for OUTBOUND traffic is to use

    interface ATM0
    ... ! noting relevant here

    #sh run int atm0.1
    interface ATM0.1 point-to-point
    bandwidth 512
    pvc 0/38
    vbr-nrt 448 448 !<-- THIS IS CRITICAL
    Also use tx ring limit here or in ATM0 - not sure.
    Obviously use your own values.

    4.
    I don't think that tx rimg limit is meaningful on the dialer.

    5.
    You can then apply your policy on the dialer differentiating
    traffic as required.


    For inbound:-

    If you are using TCP for most of your traffic e.g. Web
    browsing then you can usefully shape that on the
    inside interface OUTBOUND. You need to leave enough
    for your critical traffic (e.g. voice). TCP detects
    bandwith limits and respects them:)))

    e.g.

    We have 2M DSL download. We choose to reserve 500k for
    voice.

    int vlan 1
    shape non voice to 1500k with policy maps

    OR

    rate limit non voice to 1500k

    Rate limiting drops exceeding traffic whereas shaping
    queues it but shaping often does not seem to actually work
    depending on the interface you are actually using.

    As I recall policy maps with shaping does work on a vlan
    int on an 877.

    Finally, MAKE SURE YOU TEST IT. iperf is likely your friend.
    Most stuff doesn't actually work.

    It looks as if using hierarchical policy maps and shaping then
    inside that applying per traffic type rules should be good
    but it doesn't actually work on a dialer up to 12.4.12T or
    thereby on an 877. As I said the vbr-nrt thing is the KEY.

    take precedence over (say) P2P or FTP / SCP uploads.
     
    bod43, Dec 8, 2010
    #7
  8. JF Mezei

    JF Mezei Guest


    That appears to be an understatememnt !

    I found an example on a cisco web page that said you hacve to use the
    shape command on a parent policy-map to define available bandwidth, and
    that policy-map then does a service-policy that calls in your real
    policy-map.


    BUT, that example applies to a ethernet interface, not to a dialer
    interface. I get a "GTS: not supported on this interface" had to lookup
    what GTS means (generic traffic shaping).

    Not supported for dialer interface ! And this router doesn't have an ATM
    interface.

    This is what I hate of IOS. There doesn't seem to be a simple list of
    what is and isn't supported on various interfaces.
    I will look into it. But it is quite easy to get a bittorrent going at
    59KB/s, and then watch it as I make a phone call and make lots of noise
    on phone. It *should* cause the BitTorrent client to lower the output rate.


    When I decided to go with Cisco, I didn't expect the above sentence to
    apply to a company that makes enterprise and even carrier grade products.

    Configuring the 2924 switch was much simpler and worked according to the
    documentation. But this 871W router is quite the challenge when you
    can't find documentation that actually applies to it.
     
    JF Mezei, Dec 8, 2010
    #8
  9. JF Mezei

    JF Mezei Guest

    BTW, can someone confirm that one has to put the class-map and
    policy-map statements ahead of the interface definitions in the startup
    config ?

    I hage mine after, and when booting the rooter, it could complain about
    the policy-map being unknown. But once booted, I was able to enter the
    service-policy command in the interface without complaint.

    Moving the class-map and policy-map statements above the interface
    command that have the service-policy command seems to have solved the
    problem. The ACLs can still be after the interface definitions, even
    those being used by the class-map statement.
     
    JF Mezei, Dec 8, 2010
    #9
  10. JF Mezei

    bod43 Guest

    Well I have never noticed any issues with command
    order.

    I just use conf t and enter the commands.
    I would not mess with external text editors and tftp say
    to try to change the order of the commands.

    Usually IOS just lets you put what you want in and
    assumes that undefined items will be defined later.
     
    bod43, Dec 8, 2010
    #10
  11. JF Mezei

    bod43 Guest

    Well everything except QoS seems to work quite well:)
    Sorry, I got it in my head that it was an 876 that you
    had.

    One trick I recall was using a loopback and PBR to force all traffic
    to the loopback and then doing QoS on the outbound from
    the loopback.

    I recall that QoS worked quite well on Ethernet interfaces.
    Is there a way for you to get rid of the dialer?

    When you use the vbr-nrt thing on the ATM it links the
    ATM and the dialer queues. The term I think cisco used
    was pushback. It allows the ATM queue to push back
    against the dialer queue and stops it from just blasting away.
    This I recall did work but still not hierarchical policy maps.

    In some cases I ended up using rate-limit to constrain
    non-critical traffic and reserving bandwidth for voice.
    I described this briefly in a prior message.
    Not ideal as rate limit drops out of spec traffic
    instead of queuing it but it did work since TCP
    copes with lot frames. Modern TCP stacks with selective
    ACK cope rather well.

    Have you tried ver 15?

    You havent mentioned hierarchical policy maps?
    They dont seem to work on all interfaces.

    Have you tried a policy map on your ethernet?
    I know it makes no sense to put an IP based
    policy on an interface without an address but
    I have seen references to the use of such maps on ATM
    interfaces. I was dubious and never got round to trying it.

    Finally - TAC?
     
    bod43, Dec 8, 2010
    #11
  12. JF Mezei

    JF Mezei Guest

    To get a non PPPoE ADSL link would tripple my monthly bill. The local
    mafia (Bell Canada) has decided that non PPPoE ADSL was a premium
    service and charges and arm and a leg for it.

    I tried this. Didn't work on the dialer interface. It appeared to do
    something on the ethernet interface which, despite handling PPPoE
    traffic from the dialer. Show QUEUE IN Fa4 would show individual TCP
    streamns and a whole bunch of information that would never show when
    applied to the dialer interface. But voIP traffic wasn't given any priority.

    Perhaps I need to revisit this approach and try various permutations to
    see if I can get it to limit non voip traffic.
    Would probably cost more than the value of the modem :)
     
    JF Mezei, Dec 8, 2010
    #12
  13. JF Mezei

    JF Mezei Guest

    Well, I think I found something which works, thanks to a
    supportforums.cisco.com posting:

    class-map match-any class-voip
    description VOIP traffic QOS
    match access-group name ACLvoip
    !
    !
    policy-map voip-QoS
    class class-voip
    priority 128
    !
    policy-map voip-parent
    class class-default
    shape average 500000
    service-policy voip-QoS

    and apply "service-policy output voip-parent" to the fast ethernet 4
    interface instead of the dialer 1 interface. The trick was to avoid
    defining a "class-default" in the child policy-map.


    the "shape average" is what tells the router what your upload/outbound
    bandwidth is. (I'll probably have to adjust this based on speed tests
    for this supposed 800kbps uplink minus ATM overhead.

    Now, I have a question:

    an 800kbps ADSL1/2 uplink gives 716kbps of real throughput once you
    remove the ATM overhead. (1696 bytes of ATM packets to transmit 1
    ethernet of 1518 bytes).

    In terms of the "shape average" command for that policy-map applied to
    the ethernet interface that carries PPPOE traffic, but which prioritises
    traffic based on IP characteristics,

    what does it apply to ?

    ethernet packet ? (1518 bytes, yields 716kbps)
    pppoe packet ? (1500 bytes, yields 707kbps
    IP packet ? (1492 bytes, yields 703kbps)
    IP payload ? (1452 bytes, yields 684kbps)

    (Remember that this router is unaware of ATM protocol and overhead
    because that is handled by the separate ADSL modem).
     
    JF Mezei, Dec 15, 2010
    #13
    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.