The first thing to do is define 'overloaded'. If I am doing a file transfer once a day
and it saturates the WAN for 15 minutes is that overloaded? If I double the data rate
and only saturate it for 7.5 minutes is that overloaded? If so, then network overload
is driven by the ability of the host(s) to saturate the link, which is probably not a
good definition. I have actually recommended cutting bandwidth in this situation to
save costs. I didn't care if it took an hour.
When you are talking about interactive traffic, DEC (remember them) used to say
anything over 80 msec round trip was too slow for efficient use by humans. That was
the response time goal of LAT, their patented protocol. If you use that standard,
satellite links are out as are most WAN connections. That is why LAT is only for Local
Area Transport (LAT) of async data.
In the current day of TCP/IP I would suggest that the definition is something like,
'When measured round trip times exceed the historical average by more than 20%, the
intervening links are overloaded.' For a product, I would allow the percentage to be
defined by the customer. You could also use average per time of day with time slots of
x minutes.
You also have to be aware of lost packets. You don't want a bad cable to cause you to
take corrective action, or do you? Again, it is really something you need to define.
Packet loss may be caused by congestion and so you might want to include it somehow.
Your tool could be host resident and wrap the TCP layer to conduct measurements. You
could also see if you can pull the RTT times from the kernel. You could also 'sniff'
the network and construct the information by analyzing the traffic. In any event you
would need to build the history information and then apply your tests.
My one recommendation would be to start with something easy and test it. Complicate
things as you need to for your purposes but don't lose track of whatever your goal is
with this project. I remember early in my career being asked to fix a CPU load
calculator that took 100% of the CPU. It was beautiful code but overly complicated and
useless.
Mark
-------Original Message-------
From: swin <[EMAIL PROTECTED]>
Sent: 03/08/03 01:53 AM
To: [EMAIL PROTECTED], [EMAIL PROTECTED]
Subject: RE: Any good method to check network overload?
>
> You all misunderstood me! what I want isn't a tool to check network
flow or just want to have it report.
I'm doing a research to find a good model to judge if network
is overload automaticlly,it may be a good algorithm but not a tool.no
matter to use ntop or mrtg, it just give a statistic of network flow,
this is not hard to achive.but my problem is how to judge network
overload in real-time and offer a countermeasure ,but not a monitor tool.
David give a suggestion to check time delay in pinging,but I think this
is not reliable.as we known ,we can get the data in realtime just like
intop can do,but with this data how can we say at certain time the network
is overloaded ,what we need is a benchmark to decide if it is overloaded,
but what should this benchmark be and how to get this benchmark are the
problems.
I don't know if I have explain it clearly,but I do holp get suggestions
of it form others.
Swin. Wang.
>
----
Mark Reardon
Reardon Information Security Corporation
156 Blue Sky Drive
Marietta, GA 30068
(770) 565-0544
(404) 444-0041 cell
