From: Scott Vermillion (scott_ccie_list@it-ag.com)
Date: Mon Mar 03 2008 - 18:25:26 ARST
Yes, what you explain below applies perfectly to Option A.
Now what about Option B? ;~)
I don't claim to have proven this definitively in a lab (or I'd simply post
the results), but when I look at the outbound QoS order of operations, I see
that outbound policing is applied before LLQ (or any fancy queuing). So,
again, even in the *absence* of congestion, my vote is that Option B polices
class voice to 500k, which, as you correctly point out, is not the behavior
of Option A...
http://www.cisco.com/warp/public/105/qos_orderofop_3.html
-----Original Message-----
From: nobody@groupstudy.com [mailto:nobody@groupstudy.com] On Behalf Of
Spolidoro, Guilherme
Sent: Monday, March 03, 2008 1:11 PM
To: Biggs, Jeff (M/CIO/BIE); Sadiq Yakasai; Scott Vermillion
Cc: Gaurav Prakash; groupstudy groupstudy
Subject: RE: LLQ
Folks, the way it works is very simple:
1- If the interface isn't congest, traffic in the voice class can go as
high as it wants to (whole port speed if available).
2- If the interface is congested, its traffic will be limited to 500Kbps
and any exceeding traffic (above 500Kbps) will be discarded. That is a
huge difference from the bandwidth command (it guarantees, but doesn't
limit during congestion).
Here is a link that explains that:
http://www.cisco.com/en/US/docs/ios/12_0t/12_0t7/feature/guide/pqcbwfq.h
tml#wp5459
And here are some extracts from that link:
Syntax Description
bandwidth
Guaranteed allowed bandwidth (in kbps) for the priority traffic. Beyond
the guaranteed bandwidth, the priority traffic will be dropped in the
event of congestion to ensure that the nonpriority traffic is not
starved.
When the device is not congested, the priority class traffic is allowed
to exceed its allocated bandwidth. When the device is congested, the
priority class traffic above the allocated bandwidth is discarded.
Which is funny, because I always thought that any traffic above the
speed on the priority command (independently of the interface being
congested or not) would be dropped.
Gil
-----Original Message-----
From: Biggs, Jeff (M/CIO/BIE) [mailto:JBiggs@usaid.gov]
Sent: Monday, March 03, 2008 2:58 PM
To: Sadiq Yakasai; Scott Vermillion
Cc: Spolidoro, Guilherme; Gaurav Prakash; groupstudy groupstudy
Subject: RE: LLQ
Isn't the idea for option A to make sure voice gets the 500K in times of
congestion? So if I have a 768K VSAT connection, when the Windows AD is
chewing up my bandwidth and other web users are surfing/youtub'ing...I
want that 500K for the 25 G729 voice calls if it is needed.
Option A is already a policer, so wouldn't option B be sort of like the
"department of redundancy department"?
Jeffrey Biggs
Sr. Network Engineer
USAID
M/CIO/BIE
240-646-5003
jbiggs@usaid.gov
-----Original Message-----
From: nobody@groupstudy.com [mailto:nobody@groupstudy.com] On Behalf Of
Sadiq Yakasai
Sent: Monday, March 03, 2008 2:41 PM
To: Scott Vermillion
Cc: Spolidoro, Guilherme; Gaurav Prakash; groupstudy groupstudy
Subject: Re: LLQ
Scott,
You are absolutely right there. This is always one of those areas in
which one needs to hypothesize (if this word exists :)) i guess.
It basically comes down to the definition of congestion on the
interface.
In the second case (B), they wld definately be policing themselves
even without congestion.
So, when is the interface "congested" again? When they packets start
filling up the interface queue? If so, to what limit?
Mayb i need to check with my Odom and refresh me mind here.
This archive was generated by hypermail 2.1.4 : Tue Apr 01 2008 - 07:53:52 ART