LLQ understanding

[Calin C.]

Hello all,

I have an issue with theory and practice with LLQ. I understand that LLQ allow you to prioritize packets (e.g. voice) up to a certain limit (bandwidth) when available bandwidth is fully utilized. When there is enough bandwidth free, than this LLQ limit can overcome.

Let me give you an example to understand better and be able to help me with an advice.

Let's assume that I have a 4Mbit available bandwidth on a Serial line with Frame-Relay encapsulation and I apply the following configuration:

class-map voice-ef
match dscp 46

policy-map po2-s1-out
class voice-ef
  priority 423
class class-default
  bandwidth 3489

policy-map po1-s1-out
  class class-default
  shape average 3912000 39120 0
  service-policy po2-s1-out

map-class frame-relay frm-s1-out
frame-relay fragment 1600
service-policy output po1-s1-out

int s1.100
frame-relay interface-dlci 100 IETF  
  class frm-s1-out

I reserved 10% from the bandwith in LLQ and the rest goes to default class (the packets are marked correctly at network edge). The rest of the QoS is necessary because I have to shape the bandwidth and apply it in a FR interface.

Question, in this scenario, if the bandwitdh is not occupied, can voice calls overcome the 10% bandwidth (from 4Mbit aprox 423kbit). If I use the codec g711 which has about 100k / call , that mean that I can do 4 parallel calls in this 423kbit. What if I make 6,7 calls when the bandwidth if free?

My findings are that if I overcome the 423kbit, then I have packet loss and choopy voice calls. It's like LLQ is not "borrowing" bandwidth from other classes.

Thank you!

[milan.kulik]

Hi,

priority 16
configured with no options means:

Burst = 400 Bytes

As "The default burst size is calculated based on a 200-millisecond interval and the bandwidth configured for low latency queueing (LLQ)."

(So 16*1024 bps /5 = 3276,8 bits in 200ms = 409,6 Bytes in 200 ms)

See http://www.cisco.com/en/US/docs/ios/12_1t/12_1t3/feature/guide/dtcfgbst.html for details.

Now some serialisation delay maths:

If I suppose 100Mbps LAN interface, one 1400Bytes packet can come in 0,0001 s in theory.

In a case of 10Mbps LAN, it's 0,001s.

To send the same packet out of the 1544 kbps serial line would take 0,007 s.

In a case of a continuous packet flow, the serial line output buffer might become full, and the burst size can play a role.

(Don't forget LLQ was designed for voice originally, so small packets are expected by default.)

But generally, I agree the LLQ should be able to get all the bandwidth available in a case of no congestion.

As I said already, if you repeat the same test on Ethernet interfaces instead of serial one, you might be able to get the full bandwidth.

BR,

Milan

[Calin C.]

I will try to find time to repeat the tests on Ethernet line with some scenario like

PC (Iperf) - R1 - R2 - PC (Iperf)

and see how much I can go over the reserved bandwidth for LLQ. Of course I'll have no congestion on the line.

Once it's completed I will post the results here.

[d.serra]

Milan,

I think you are dead on but you math may be a bit off.  Tc is 250 ms not 200ms.  The reason is Bc is 400k and bps is 16k.  So 16000 divided by 400 is 4 meaning that there are 4 250ms time slots transmitting 400bps (Bc).  Add the 4 slots together and you get 16k bps per 1 second.

To be honest, I've read the same docs where it describes the LLQ as having some sort of CAR function but I believe there are changes to the newer code such as the 12.4 I used to create this test that allows LLQ to use excess burst (Be) though that too is speculation.

Calin, looking forward to seeing the results of you test.

Dave

[Calin C.]

Hello again,

So, I took some time to test, and indeed it seems that I was wrong assuming that LLQ cannot borrow full bandwidth.

The testing scenario is very simple

PC-SRC(IPerf) -> R1 -> R2 -> PC-DST(IPerf).

Bandwidth: 10Mbps

On R1, I have applied the following configuration:

####### Voice packet marking with EF #######################################################

access-list 101 permit udp any any range 16384 32767
access-list 101 permit udp any range 16384 32767 any
access-list 101 permit udp any any range 5060 5061
access-list 101 permit udp any range 5060 5061 any

class-map match-all VOIP
match access-group 101

policy-map ASTERISK
class VOIP
  set dscp ef

int gi0/0
service-policy input ASTERISK

######## LLQ configuration with 1Mbps reservation ########################################################

class-map voice-ef
match dscp 46

policy-map Queue-out
class voice-ef
  priority 1000
class class-default

interface gi0/1
service-policy output Queue-out

Now, some traffic

10 parallel calls, each call 100kbps that should be aprox. 1Mbps

Result: 0% packet loss

20 parallel calls, each call 100kbps that should be aprox. 1Mbps

Result: 0% packet loss

50 parallel calls, each call 100kbps that should be aprox. 1Mbps

Result: 0% packet loss

You can see a screencast of the test here: bit.ly/aIsI1B

Now I have too see why there were issues in the first test. Maybe due to frame-relay, nested policy-maps or shaping.

I will let you know if with FR everything is fine once I'll complete that test