Who decides what a good RTT is?

I'm not sure if this is a question for thwack or the cisco support forums but here goes anyway...

Who decides what is or is not a good RTT on an IPSLA operation? For example, I just setup my first IP SLA Manager operation for DHCP, and it immediatly came back in the red. 2 seconds its the RTT. But then I got to thinking when I do a IPCONFIG /renew on our network it takes about 2 seconds and that doesnt seem so bad. Maybe its not so bad, maybe it is. How is someone to know? Should I trust the defaults? Myabe there is a series of guidelines for what RTT should be in a "normal" (whats normal) network.

I dont want to just go and set anyting that is red to green by changing the thresholds. That defeats the point of having IPSLA in my opinion. Who decides what's acceptable and by what bar do you measure?

thanks

Find more posts tagged with

caffine_buzz

ip_sla

dhcp

rtt

Accepted answers

All comments

FormerMember

You should set your thresholds based on your environment. If you get alerts, yet you have no problems, but them up.

Bahlkris

I know my enviroment rather well, one would hope so, so with things like ICMP echo's and generic TCP connects its a no brainer.

But I guess my point is did someone somewhere do a baseline of how a DHCP server(or SQL, www, etc) would perform in a perfect network to say "set the bar"? I mean if I get 2 seconds on a DHCP operation, and some other guy with a very similar network or even identical gets 1 or 3, and neither of us have problems/errors then who's network has problems?

Am I making sense? I might be rambling, had a lot of tea this morning.

-b

FormerMember

Neither of your networks would have a problem in your DHCP example. If clients would be failing to get addresses or renew successfully, your phone would be ringing and then you could go back to the data and adjust.

Even ICMP and TCP connects can mean very little, especially when they are robotic transactions that don't originate from the client.

Now as far a setting the bar from an industry perspective goes, that can be definitively set for Real Time applications like VoIP.

If you've never seen data from an "on the wire" system, I'd be willing to bet your head would spin as to why the phone isn't ringing. Mine sure did.

All of these cases, the questions they create, etc. are why I prefer performance to be base lined and warnings issued when the baseline is exceeded by a certain percentage or threshold. As the baseline increases, with no problems, it can be reset and the cycle continues. Eventually, the warning will reflect real end user pain but are meant to help you get in front of the problem before the phone rings.

Part of the problem with all of this is breaking it down to how much of the response time is made up of Network, and Application(Client and Server). It can be done, but it is not usually cheap. DHCP today in my network is averaging 15ms and a high watermark of 311ms, and all that time is spent in the application vs the network flight time. Another example is RDP for Terminal Services. On my busiest server, across all the locations using it, including VPN to work at home users, is 105ms (40ms Network, 65ms in the application). One more example from a busy SAN attached corporate file server. 23ms on the network, 47ms in the application. If you were to sort the flows by response time, you can see the problem clients dragging down the stats and see that it is not a global problem.

Bahlkris

So really I guess IPSLA in general is a case by case basis sort of thing. We arent having any DHCP issue, but maybe 2 seconds for a M$ DHCP server is normal.

I'll take your advice and baseline these operations and build my thresholds on errorless enviroments over time. Thanks for the detail