Network Anomaly Diagnosis Analysis methodology March 23 rd, 2006

List of anomalies 1.route change 2.network congestion traffic burst and sustained load for long time 3. outage 4.host problems

Alternative-I use of k-means clustering algorithm on parameters like –history mean+-history sd. –trigger mean+-trigger sd –time stamp –trigger_buffer_length (time) Assumption: –RTT calculations show different behavior for route change, network congestion, outage [1][2] [1] Polly Huang, Anja Feldmann, Walter Willinger “A non-intrusive, wavelet- based approach to detecting network performance problems” [2] Todd Hansen, Jose Otero, Tony McGregor, Hans-Werner Brau, “Active Measurement Data Analysis Techniques.”

Alternative-I We need to check our dataset shows such behavior. Complete manual inspection of data will reveal the fact.

Alternative-II (route change) Let the time of alert is T. We define two thresholds X and Y. Now we have to find out that in a time period (T-X hours ) to (T+Y) was there one or more route change(s) or not. If there is a route change, at this time we say the event is because this. Later we may check for other causes as well.

Alternative-II (network congestion) We have data from node X to Y and vice versa, in most of the cases. Say, we have an alert for source X to destination Y at given time T. We must check that does any alert exit in similar time frame in opposite direction i.e., src Y to src X. Argument: it can be a host problem

Alternative-II (network congestion) Solution: a) If X is the monitoring node and Y is the monitored node, then which other nodes monitored by X share maximum path with Y. b) after getting these nodes, to find out whether those nodes experienced any alert during that period or not. c) if other nodes are also experiencing alert in the similar time frame than most probably it is because of congestion. Argument: what about if the congestion is in that part which is not shared by any other node?

Alternative-II (Outages) This may be fairly simple. when an alert occurs, we will have to find out in raw data that do we have significant gap between data (e.g., 3 hrs) at that time or not. If that gap exists it is an outage.

Alternative-II (Host problem) With current data set, maximum we can do is to say if there is no other anomaly then it is a host problem. In future work when host level monitoring tools are running on monitoring/monitored nodes we can say what kind of host problem it is.