IP SLA UDP jitter - rate mismatch

Answered Question
Mar 28th, 2008

I want to check whether my WAN provider commits to 768 kbps of aggregated real time traffic (DSCP = EF)

I started 5 (five) IP SLA UDP JITTER operations on my router, each one sending 180 bytes packets paced at 10 milliseconds each. So 5*180= 900 bytes, times 100 packets per second should give me 90,000 bytes per second or 720 kbps.

To my surprise, the service provider observes that the rate of my packets is well above the rate I expected: 958 kbps:

"30 second offered rate 958000 bps"

This is a copy of one of the five operations I started on my router:

ip sla monitor 4000

type jitter dest-ipaddr 141.167.112.183 dest-port 24000 num-packets 27000 interval 10

request-data-size 152

frequency 300

tos 184

My calculation for a 180 bytes packet was based on the sum of "request-data-size" (152 bytes), 8 bytes of UDP header and 20 bytes of IP header.

¿Am I missing anything else?

Any help will be greatly appreciated.

I have this problem too.
0 votes
Correct Answer by Paolo Bevilacqua about 8 years 8 months ago

I see, traffic is measured on ATM.

A 180 bytes packet in AAL5/snap takes 5 cells, that is 5 x 48 bytes * 8 * 500 = 960 Kbps, virtually perfect match.

Note on the PVC you're actually transmitting at 1,060 Kbps including the 5 bytes per cell overhead.

If you're curious about protocol overhead:

http://sd.wareonearth.com/~phil/net/overhead/

  • 1
  • 2
  • 3
  • 4
  • 5
Overall Rating: 4.3 (4 ratings)
Loading.
Paolo Bevilacqua Fri, 03/28/2008 - 15:41

Which encapsulation is on the interface that is sla receiver? You've to include L1/L2 overhead as well.

rogelioalvez Fri, 03/28/2008 - 16:14

Hello P.bevilacqua:

The origin interface on the IP SLA sender is GEth.

The destination interface (SLA receiver, at the other side of the service provider WAN) is a loopback interface.

My client's sender router and the service provider CPE are linked by an ethernet VLAN. The service provider router has the aforementioned GE interface plus an ATM WAN interface. On the ATM WAN interface the service provider rates and polices the output (WAN bounded) packets.

Some time ago I thought that it could be necessary to include any packet overhead to the calculation, but I supposed that worst case I should have included 14 bytes of the ethernet header.

But then I thought the ethernet header should not be included because as I said before the policing is carried out in the ATM interface that looks to the service provider WAN. On this interface the ethernet header that my router includes to every IP SLA packet should be meaningless.

But even though I included the 14 bytes of the ethernet header, every packet should now be 180+14= 194 bytes. 194*100 packets per seconds times 8 bits per packet times 5 operations should give me an aggregated rate of 776000 bps, that is still well below the 958000 bps that the service provider's policer detects.

So I sill have no clue about this difference.

Please let me know if I can provide you with more information.

Best regards, Rogelio

Correct Answer
Paolo Bevilacqua Fri, 03/28/2008 - 18:46

I see, traffic is measured on ATM.

A 180 bytes packet in AAL5/snap takes 5 cells, that is 5 x 48 bytes * 8 * 500 = 960 Kbps, virtually perfect match.

Note on the PVC you're actually transmitting at 1,060 Kbps including the 5 bytes per cell overhead.

If you're curious about protocol overhead:

http://sd.wareonearth.com/~phil/net/overhead/

rogelioalvez Sat, 03/29/2008 - 06:31

Yes, it makes perfect sense!

In fact, I was puzzled because I tried the same routines on the network of another service provider, but this other WAN is based on Metro Ethernet, so I do not have this overhead and no single packet was lost.

Thank you very much for your hints. Now I have something to work with an arrive to the solution :o)

regards, Rogelio

Paolo Bevilacqua Sat, 03/29/2008 - 07:00

Since your SP appears collaborative, ask to switch to vcmux encap to save 8 bytes.

cRTP would be a bigger optimization but it requires PPP and CPU processing so that is less likely to be welcome.

Thanks for the nice rating and good luck!

rogelioalvez Sat, 03/29/2008 - 07:14

Hello P.bevilacqua:

cRTP is not possible because the ATM interface is actually the entry point to an MPLS network, and although I heard that cRTP over MPLS has already been specified (and I guess implemented on Cisco routers), this provider is a little bit behind these kind of optimizations.

Thanks a lot again, Rogelio

Paolo Bevilacqua Sat, 03/29/2008 - 07:37

Hi, in a traditional cisco router crtp would be just a link feature. It ends there on the interface and doesn't matter if there is mpls or whatever else.

But because it has interoperability issues, and can impose additional load on the router one way or another, SPs are reluctant to use it. So it's more a feature for enterprise private circuits.

One great saving bandwidth saving that you can also try, is the modern and netwok-aware codec: iLBC. It has excellent voice quality, low bitrate and copes well with jitter and packet loss. It is supported on cisco voice GWs and the latest models of phones.

Thanks again and good luck!

rogelioalvez Mon, 03/31/2008 - 08:28

Hello P.Bevilacqua:

I built a tiny lab with an IP SLA sender, an IP SLA responder, and a sniffer.

I found something strange. Even though I asked the jitter operation to pace packets at 10msec each, my sniffer shows me that 27000 packets were sent in aprox 220 seconds (I can also confirm this because I see the leds on the interface when the router starts sending and when stops it) although actually this operation should have taken 270 seconds to be executed.

I repeated this operation many times, so I am pretty sure that "something else" is going on. ¿Could it be possible that the IP SLA sender is not following the 10msec interval rule I programmed for this operation?

In other words, ¿should the router pace them strictly at 10msec as I expect or I am missing the meaning of the "interval" parameter in the jitter operation?

regards, Rogelio

Paolo Bevilacqua Mon, 03/31/2008 - 11:11

Hi, I've never practiced much with ip sla. Sure it can have bugs and I remember at least one case where it caused high cpu utilization.

Actions

This Discussion