U.S. patent application number 13/546291 was filed with the patent office on 2012-11-01 for monitoring network performance to identify sources of network performance degradation.
This patent application is currently assigned to Microsoft Corporation. Invention is credited to Michael Bishop, Tin Qian, Aravind Ramarathinam.
Application Number | 20120278485 13/546291 |
Document ID | / |
Family ID | 41014027 |
Filed Date | 2012-11-01 |
United States Patent
Application |
20120278485 |
Kind Code |
A1 |
Qian; Tin ; et al. |
November 1, 2012 |
MONITORING NETWORK PERFORMANCE TO IDENTIFY SOURCES OF NETWORK
PERFORMANCE DEGRADATION
Abstract
A method of measuring, for communication paths between a
networked computer and at least one other networked computer
connected via a network performance, network information to detect
network performance degradation and diagnose source(s) of the
performance degradation. The diagnosis may be performed by a
progressive elimination of possible sources. Network performance
degradation may be attributed to problems at a local network or the
Internet. The problem sources on the Internet may comprise, for
example, an internet server provider (ISP) or a single remote
server in communication with the networked computer. A network
performance baseline established and maintained for each path may
be employed in diagnosing the network performance degradation.
Inventors: |
Qian; Tin; (Bellevue,
WA) ; Ramarathinam; Aravind; (Redmond, WA) ;
Bishop; Michael; (Redmond, WA) |
Assignee: |
Microsoft Corporation
Redmond
WA
|
Family ID: |
41014027 |
Appl. No.: |
13/546291 |
Filed: |
July 11, 2012 |
Related U.S. Patent Documents
|
|
|
|
|
|
Application
Number |
Filing Date |
Patent Number |
|
|
13183545 |
Jul 15, 2011 |
8244862 |
|
|
13546291 |
|
|
|
|
12072936 |
Feb 29, 2008 |
7991881 |
|
|
13183545 |
|
|
|
|
Current U.S.
Class: |
709/224 |
Current CPC
Class: |
H04L 43/16 20130101;
H04L 43/0876 20130101; H04L 43/00 20130101; H04L 43/0864 20130101;
H04L 43/0882 20130101; H04L 43/087 20130101; H04L 43/022 20130101;
H04L 41/14 20130101 |
Class at
Publication: |
709/224 |
International
Class: |
G06F 15/173 20060101
G06F015/173 |
Claims
1. A method comprising: establishing, by a computing device, a
network performance baseline for a communication path of a network
between the computing device and another computing device;
collecting network performance data regard ng the communication
path over a time interval; and updating the established network
performance baseline based on the collected network performance
data unless it is determined that the network is underutilized or
congested.
2. The method of claim 1 further comprising determining that the
network is underutilized;
3. The method of claim 2 wherein the determining that the network
is underutilized is based on communications on the communication
path consumed a bandwidth within a range of an estimated
bandwidth.
4. The method of claim 3 wherein the determining comprises
determining whether a sender congestion window has a size exceeding
a threshold percentage of a value representing a product of the
estimated bandwidth and an estimated round trip delay on the
communication path.
5. The method of claim 1 further comprising determining that the
network is congested.
6. The method of claim 5 wherein the determining that the network
is congested is based on communications on the communication path
consumed a bandwidth within a range of an estimated throughput.
7. The method of claim 6 wherein the determining is based on a
bandwidth metric increasing and a mean bandwidth value
decreasing.
8. At least one computer storage device storing computer-executable
instructions that, when executed by a computing device, cause the
computing device to perform a method comprising: establishing a
network performance baseline for a communication path of a network
between the computing device and another computing device;
collecting network performance data regarding the communication
path over a time interval; and updating the established network
performance baseline based on the collected network performance
data unless it is determined that the network is underutilized or
congested.
9. The at least one computer storage device of claim 8, the method
further comprising determining that the network is
underutilized;
10. The at least one computer storage device of claim 9 wherein the
determining that the network is underutilized is based on
communications on the communication path consumed a bandwidth
within a range of an estimated bandwidth.
11. The at least one computer storage device of claim 10 wherein
the determining comprises determining whether a sender congestion
window has a size exceeding a threshold percentage of a value
representing a product of the estimated bandwidth and an estimated
round trip delay on the communication path.
12. The at least one computer storage device of claim 8, the method
further comprising determining that the network is congested.
13. The at least one computer storage device of claim 12 wherein
the determining that the network is congested is based on
communications on the communication path consumed a bandwidth
within a range of an estimated throughput.
14. The at least one computer storage device of claim 13 where n
the determining is based on a bandwidth metric increasing and a
mean bandwidth value decreasing.
15. A system comprising: a computing device configured for
establishing a network performance baseline for a communication
path of a network between the computing device and another
computing device; the computing device further configured for
collecting network performance data regarding the communication
path over a time interval; and the computing device further
configured for updating the established network performance
baseline based on the collected network performance data unless it
is determined that the network is underutilized or congested.
16. The system of claim 15, the computing device further configured
for determining that the network is underutilized;
17. The system of claim 16 wherein the determining that the network
is underutilized is based on communications on the communication
path consumed a bandwidth within a range of an estimated
bandwidth.
18. The system of claim 17 wherein the determining comprises
determining whether a sender congestion window has a size exceeding
a threshold percentage of a value represent ng a product of the
estimated bandwidth and an estimated round trip delay on the
communication path.
19. The system of claim 15, the computing device further configured
for determining that the network is congested.
20. The system of claim 19 wherein the determining that the network
is congested is based on communications on the communication path
consumed a bandwidth within a range of an estimated throughput.
Description
RELATED APPLICATION
[0001] This application is a continuation of U.S. application Ser.
No. 13/183,545, filed Jul. 15, 2011, that is a continuation of U.S.
application Ser. No. 12/072,936, filed Feb. 29, 2008, which is
incorporated herein by reference in its entirety.
BACKGROUND
[0002] Computing devices may communicate with other computing
devices via connections over networks for a variety of reasons. For
example, a user of a computing device may wish to obtain data from
a server to perform computations or obtain audio or video content.
In other instances, a user may wish to engage in an interactive
application with a user of another computer or a program executing
on a server or other device accessible over the network. The
quality of service provided by the network can have a significant
impact on the user's experience.
[0003] Tools to measure network performance are known. For example,
network engineers frequently use traffic simulators and other types
of test equipment to assess performance of a network or individual
components within the network. Such tools can simulate network
traffic generated by large numbers of users to test the network
behavior under many operating conditions. Traffic analyzers are
also known and may be used to perform test functions by detecting
and analyzing messages being conveyed by a network. These powerful
tools may also be programmed to perform other test-related
functions.
[0004] Less powerful tools that run on an individual computer are
also known. Tools such as a network "Ping" can be used to test
connections. Additionally, many computers equipped for network
communication also include components that perform limited
performance monitoring as part of implementing certain network
protocols or adapting network protocols for specific operating
conditions. For example, some wireless protocols allow
communication at different data rates. Computers communicating
according to these protocols may detect and adapt to network
conditions by changing the data rate in use.
SUMMARY OF INVENTION
[0005] To manage devices communicating over networks, network
performance may be monitored. Network performance depends on
various factors and fluctuates over time. When the network
performance is below an expected performance, it may not be
straightforward to identify a particular source of a problem.
[0006] In some embodiments, a method is provided to detect network
performance degradation by a networked computer connected to a wide
area network through a local network. The source(s) of the
performance degradation may be diagnosed by a method of a
progressive elimination. Thus, a number of possible source(s) of
the detected performance degradation may be progressively narrowed
down. Initially, it may be determined whether cross-traffic on a
local network or one or more networked computers on a wide area
network (e.g., the Internet) are sources of the performance
degradation. If sources such as a Layer 3 connection problem, a
Layer 2 problem or LAN cross-traffic are ruled out as sources of
network performance problems, it may then be determined whether an
internet server provider (ISP) or a single remote server in
communication with the networked computer over the Internet are
sources of the network performance degradation.
[0007] A network performance baseline established and maintained
for connections between the networked computer and other devices on
the wide area network may be used in determining whether the
network performance is below the expected performance. The
information collected as part of the baseline may also be used in
distinguishing between degradation caused by an ISP or a particular
remote server.
[0008] In some embodiments, the network performance information may
be used to determine whether a connection between the networked
computer and any other device on a network is suitable for
interactive network applications such as, for example, remote
desktop, games applications and other suitable applications.
[0009] The foregoing is a non-limiting summary of the invention,
which is defined by the attached claims.
BRIEF DESCRIPTION OF DRAWINGS
[0010] The accompanying drawings are not intended to be drawn to
scale. In the drawings, each identical or nearly identical
component that is illustrated in various figures is represented by
a like numeral. For purposes of clarity, not every component may be
labeled in every drawing. In the drawings:
[0011] FIG. 1 is a sketch of an example of a network environment in
which some embodiments of the invention may be implemented;
[0012] FIG. 2 is a block diagram of a system within a computer,
according to some embodiments of the invention;
[0013] FIG. 3 is a sketch of an example of a data structure for a
network performance baseline, according to an embodiment of the
invention;
[0014] FIG. 4 is a flowchart of a method of using a network
performance baseline according to some embodiments of the
invention;
[0015] FIG. 5 is a flowchart of constructing a network performance
baseline according to some embodiments of the invention;
[0016] FIG. 6 is a flowchart of a method of determining whether a
network supports interactive applications according to some
embodiments of the invention; and
[0017] FIG. 7 is a flowchart of a method of detecting network
performance degradation and diagnosing source(s) of the performance
degradation according to some embodiment of the invention.
DETAILED DESCRIPTION
[0018] The inventors have appreciated that network performance for
connections between computers communicating over a network can be
monitored by utilizing network performance parameters. The network
performance parameters may be measured to determine a current
status of the network. The inventors have also appreciated that
network performance parameters may be used to establish and
maintain a network performance baseline. The baseline may be
maintained for each communication path between a networked computer
and any other device on the network. The communication path may be
a TCP/IP connection. The baseline may be maintained by updating the
network performance parameters calculated from information obtained
from the network during time intervals. In some embodiments of the
invention, a moving average technique using asymmetric weighting
factors may be employed to update some of the parameters. This
approach allows maintaining the baseline within a desired
range.
[0019] The inventors have further appreciated that the network
performance may be affected by various factors. A bandwidth metric
computed as a window size of the TCP/IP connection scaled based on
RTT of the connection may be sampled during the time intervals.
When the network performance is below some expected performance,
for example, when the amount of traffic on the network is low
and/or congestion is detected on the network, network performance
parameters obtained for the path during such periods may corrupt
the baseline and may therefore not be used to update the
baseline.
[0020] The inventors have further appreciated that network
performance information may be used to detect network performance
degradation and diagnose source(s) of the performance degradation.
The diagnosis may be performed using a method that can be referred
to as a progressive elimination. Thus, a number of possible
source.(s) of the detected performance degradation may be
progressively narrowed down. The sources may be, for example,
network cross traffic on a local network or one or more networked
computers on a wide area network (e.g., the Internet). The latter
sources may comprise, for example, an internet server provider
(ISP) or a single remote server in communication with the networked
computer.
[0021] FIG. 1 illustrates an environment 100 comprising networked
computers in which some embodiments of the invention may be
implemented. A plurality of computers may communicate aver a wide
area network (WAN) and over a local area network (LAN). Computers
may be connected to the WAN over the LAN. As shown in this example,
a networked computer 102 communicates to other networked computers,
104, 106, and 108 via connections 114 through a network 112.
Connections 114 are established over a WAN 112 which may be any
suitable network such as, for example, the Internet, and computers
104, 106, and 108 may be servers implementing web sites or other
services available over the Internet.
[0022] Some embodiments of the invention employ network performance
parameters obtained from active connections. However, the aspects
of the invention described herein are not limited in any respect by
the manner in which the computer 102 communicates with computers
104, 106, and 108, and in which computers 104, 106, and 108
communicate with each other (if at all).
[0023] As shown in FIG. 1, computer 102 may communicate with a
computer 110 via a connection 118 aver a LAN 116. Connection 118
may be either a wireless or wired connection. For example, in some
embodiments, connection 118 may be a wireless LAN using the IEEE
802.11 set of standards. In other embodiments, connection 118 may
be a wired LAN using the IEEE 802.3 set of standards. Computers
102, 104, 106, 108, and 110 may be personal computers,
workstations, servers, server clusters, mainframe computers, or any
other computer systems. Although not shown in FIG. 1, it should be
appreciated that connections between computers 102, 104, 106, 108,
and 110 and between these computers and other computers that may be
present on networks 112 and 116 are not limited to those shown in
FIG. 1. For example, computer 110 may communicate with any of the
computers 104, 106, and 108 over WAN 112. Computers 102, 104, 106,
108, and 110 may include one or more components of any type, as
discussed in more detail below. In some embodiments, computers 102,
104, 106, 108, and 110 may deploy a Microsoft.RTM. Windows.RTM.
operating system. For example, the computers may deploy the
Microsoft.RTM. Windows.RTM. Vista.TM. operating system.
[0024] Embodiments of the invention will be described below as
implemented within computer 102. However, it should be appreciated
that embodiments of the invention are not limited in this respect,
and any suitable computer (e.g., any of the computers shown in FIG.
1).
[0025] In the embodiment illustrated, a network performance
baseline may he computed using network performance values
accessible to a single computer. In some embodiments, those values
are obtained from processing parameter values measured or generated
by networking hardware or software that may otherwise be present in
a networked computer.
[0026] Network parameters, such as a delay parameter, may be
alternatively or additionally generate or use performance
information as described. For example, in embodiments where
networks are Internet Protocol (IP) based network environments, a
TCP/IP stack may track round trip time (RTT) of packets sent based
on data obtained from a network interface card connected to the
network. TCP/IP stack module 208 may be a component of the
operating system or computer 200 as is known in the art or
implemented in any other suitable way.
[0027] FIG. 2 is a block diagram illustrating a conceptual example
of components that may be included in a system 200 in which some
embodiments of the invention may be implemented. Components shown
in this example may be hardware components or may be
computer-executable instructions or computer data structures
located, for example, in computer 102 (e.g., in a non-volatile
memory) or in any other suitable computer and its components. It
should be appreciated that FIG. 2 illustrates components of system
200 by way of example only and that system 200 may include any
other suitable components. Moreover, each of the illustrated
components may be combined with other component(s) and may comprise
one or more sub-components.
[0028] In the example illustrated, a network health monitor module
202 comprises components in which some embodiments of the invention
are implemented. In the example illustrated, health monitor module
202 is implemented as computer-executable instructions within an
operating system for computer 200. Health monitor module 202
includes a bandwidth monitor 204 that performs calculations of the
network performance parameters as described in more detail below.
Bandwidth monitor 204 may poll a TCP/IP stack module 208 at certain
time intervals. In some embodiments, a five second time interval is
used. Bandwidth monitor 204 may obtain information from TCP/IP
stack module 208 via TCP/IP stack interface 207. However, it should
be appreciated that embodiments of the invention are not limited in
this respect and, in some embodiments, TCP/IP stack module 208 may
provide the information directly to bandwidth monitor module 204 or
via any other suitable component(s).
[0029] The TCP/IP stack may provide information relating to
bandwidth on all active communication paths (i.e., TCP
connections). Bandwidth monitor 204 may store information for one
or more of these connections. In embodiments in which bandwidth
monitor 204 stores information on less than all connections, the
connections for which information is stored may be selected in any
suitable way. For example, information may be stored for the most
active connections, the most recently used connections or some
other subset of the connections identified in any suitable way.
[0030] TCP/IP stack module 208 communicates with a network
interface controller (NIC) 210 which may be a NIC as known in the
art or any other suitable NIC providing an interface to a network
212 (e.g., a wireless or wired network). As is known in the art,
TCP connection may be characterized by a window that is typically
maintained by each device sending data over a network. The sender
window specifies the amount of data (e.g., defined in a number of
bytes) that a sender can send at one time before pausing to listen
for an acknowledgement from a receiver. A device implementing the
TCP/IP protocol may adjust the sender window size (referred to
hereinafter as a sender congestion window size) during the TCP
connection. Using known algorithms, the device may increase its
congestion window size to improve efficiency by sending more data
at once. However, if the window size becomes too large (e.g.,
greater than current available network bandwidth), the sender may
not receive proper acknowledgement packets due to congestion or
other sources of packet losses. In response, the device may reduce
the congestion window (e.g., divide its size by half).
[0031] The window size can be used to derive an estimation of the
bandwidth on a TCP connection. Ideally, as is known in the art, the
congestion window size will converge on a value that holds the
amount of data that the network can transmit during the interval in
which a network transmission propagates from the sender to the
receiver and an acknowledgment message propagates back. Thus, in
some embodiments, a bandwidth sample may be estimated as the
congestion window size scaled by the RTT or based on the RTT. For
example, the congestion window size may be scaled by bandwidth
delay product which may be defined as the product of capacity
(e.g., defined in bits or bytes per second) of the connection and
its RTT (e.g., defined in seconds).
[0032] In a network, the actual performance experienced at any
device connected to the network may depend on many factors,
including the amount of data transmitted by that device or other
devices connected to the network. Accordingly, a single sample of a
network performance parameter may not be an adequate representation
of the network performance. In some embodiments of the invention,
bandwidth monitor 204 maintains a "baseline" representing network
performance over a relatively long period of time. The baseline may
be computed based on multiple samples taken over an interval. As
described in greater detail below, bandwidth monitor 204 may
compute the baseline using performance parameters available to it
through TCP/IP stack interface 207. Bandwidth monitor 204 may
update the baseline as new performance parameter samples are
available. Bandwidth monitor 204 may store the baseline in any
suitable way.
[0033] When computing the baseline, bandwidth monitor 204 may take
into account variations in network performance parameters. These
variations may be reflected in any suitable way. In the example
illustrated, bandwidth monitor 204 accounts for variations by
aggregating individual measurements. In the example illustrated,
individual measurements are aggregated in two ways. First, sample
values may be collected over a sample window. The sample window may
have a duration of approximately one minute, but any suitable
duration may be used. Secondly, bandwidth monitor 204 combines
network performance parameter measurements taken in multiple
successive windows when computing the baseline. In the embodiment
illustrated, the values in multiple successive measurement windows
may be combined using a moving average.
[0034] As a specific example, bandwidth monitor 204 may compute for
each window parameters such as a mean bandwidth, a maximum
bandwidth, a minimum bandwidth, a round trip time (RTT) and a
variation in the round trip time. In each window, these values may
be determined from multiple samples. As a specific example, a
window size of one minute may be based on 12 consecutive samples
spaced five seconds apart. At each five-second sample interval, the
system may determine for each connection a window size and round
trip time experienced on that connection. The mean bandwidth sample
for any window may be the average of the 12 bandwidth samples
obtained during that window. The maximum bandwidth sample for any
window may be the maximum of the 12 bandwidth samples taken during
that window. The minimum bandwidth sample may he the minimum of
those 12 values. Similarly, the round trip time may he based on the
average of the samples in that window. The variance on the round
trip time may be computed as the variance of the 12 samples. These
samples taken on a per-window basis may be combined to form a
baseline as described in more detail below. For example, the
baseline may contain a mean bandwidth, which may be computed by
averaging bandwidth samples obtained in successive windows.
Bandwidth monitor 204 may update the mean bandwidth value in the
base line as each window passes and a new mean bandwidth sample
value is available for the window. The baseline may also contain a
value representing maximum bandwidth over multiple windows which
may likewise he updated as each window passes and a new maximum
value is available for that window. Values for minimum bandwidth
over multiple windows may similarly be combined and form a part of
the baseline which is updated as each window passes. Averages for
the round trip time and variances in the round trip time may
similarly be computed using measurements of those parameters
obtained during each window.
[0035] In the example illustrated in FIG. 2, a baseline storage
module 206 stores baseline information. Baseline storage module 206
may store such parameters as an average bandwidth maximum
(Max.sub.avg), average bandwidth minimum (Min.sub.avg), mean
bandwidth (Mean), mean RTT (RTT.sub.ave), RTT variance
(RTT.sub.Var) and other suitable parameters. It should be
appreciated that the RTT.sub.ave parameter may be used to calculate
smoothed RTT (SRTT). The value of each bandwidth sample may be
determined as described above (i.e., it may be scaled based on the
RTT). Bandwidth samples collected over a time interval may be
averaged. Extreme values of the bandwidth such as the average
bandwidth minimum and average bandwidth maximum may be obtained by
averaging minimum and maximum values of the bandwidth,
respectively, detected over the time interval. In some embodiments
of the invention, the window comprises one minute and twelve
samples are collected during this interval (i.e., one sample every
5 seconds). However, it should be appreciated that embodiments of
the invention are not limited in this respect and any suitable
number of samples and a time interval may be substituted.
[0036] FIG. 3 is a sketch of an example of a network performance
baseline data structure 300 according to an embodiment of the
invention. The baseline may be stored, for example, in baseline
storage 206. As discussed above, in some embodiments, the baseline
may be established and maintained for each destination 302 (shown
in FIG. 3 by way of example only as A, B and C), i.e., for each
device on a network communicating with the networked computer. For
TCP/IP, destinations may be identified based on the destination end
points established for connections. Accordingly, each destination
may represent communications over more than one connection.
However, the specific mechanism by which destinations are
identified is not critical to the invention. Thus, for each
destination, the mean bandwidth (Mean Bandwidth) 304, average
bandwidth maximum (Max.sub.avg Bandwidth) 306, average bandwidth
minimum (Min.sub.avg Bandwidth) 308, mean RTT (RTT.sub.ave) 310 and
RTT variance (RTT.sub.Var) 314 may be stored in fields of the
baseline data structure 300. It should be appreciated that the
order in which network performance baseline parameters are
maintained in the baseline may be any suitable order. In addition,
in some embodiments, one or more of the shown network performance
baseline parameters may be not calculated and stored as part of the
baseline. Furthermore, the baseline may include any other suitable
network performance baseline parameters, as shown by a field
314.
[0037] It should be appreciated that resources of system 200 may be
limited. Consequently, information for a limited number of paths
may be maintained. For example, in some embodiments, information
for 32 paths may be maintained. Therefore, in some embodiments, it
may be determined which paths of the currently used TCP paths may
be considered relevant and should remain being used for measuring
network performance parameters and maintaining the baseline and
which may be discarded. For this purpose, certain path usage
characteristics may be obtained and evaluated for each path
information on which is being obtained for maintaining the
baseline. For example, amount of usage of the path (e.g., the time
the path is used for trans data as compared to the total time that
all other paths are used for transmitting data), last usage time of
the path (e.g., relative age of the path as compared to the total
age of all other paths) and reliability of path data (e.g., "peaked
in" percentage described below and a spread of the path bandwidth
defined as Max.sub.avg-Min.sub.avg) may be evaluated. Other
suitable path usage characteristics may be substituted as well.
Thus, in some embodiments, baseline storage module 206 may store
baseline information on the paths that have been selected as being
relevant as described above.
[0038] In some embodiments of the invention, the network
performance information may be obtained for connections (e.g., TCP
paths) between a networked computer and other devices on a network.
The network performance information may be averaged. This
information may then be used to detect network performance
degradation and diagnose sources of the degradation. A network
performance baseline that may be established and maintained as
discussed in detail below may be used in the diagnostics
process.
[0039] Thus, in some embodiments of the invention, network
performance information may be obtained by a networked computer
(e.g., computer 102) connected to a WAN (e.g., WAN 112) through a
local network (e.g., LAN 116). The performance information also may
be obtained from other networked computers that are in
communication with the networked computer on the LAN computer 110)
and from networked computers that are in communication with the
networked computer on the WAN computers 104-108). The obtained
information may then be used to detect network performance and
identify source(s) of the degradation. The sources may be, for
example, network cross-traffic on the LAN or one or more networked
computers on the WAN. The WAN sources may comprise, for example, an
ISP or a single remote server.
[0040] In FIG. 2, network health monitor module 202 comprises
diagnostics module 216 communicating with baseline storage module
206 and TCP/IP stack interface 207. Diagnostics module 216 may
obtain network performance information provided by the TCP/IP
network stack via TCP/IP stack interface 207. The information may
then be compared with the network performance baseline information
stored in baseline storage module 206.
[0041] In some embodiments, the network performance information may
be used to determine whether the TCP path is suitable for
interactive network applications such as, for example, remote
desktop, network game applications and other suitable applications.
Thus, network health monitor module 202 comprises an interactive
support component 214 that determines whether the network supports
the interactive application. This determination may be made in
response to a request to initiate an interactive application
generated by a user, an application component or in any other
suitable way. Interactive support component 214 may obtain network
performance information from baseline storage module 206 on a
particular path to be used by the interactive application and
determine whether that path can support network traffic to provide
an acceptable user experience. It should be appreciated however
that embodiments of the invention are not limited in this respect
and the information may also be obtained either directly from the
TCP/IP stack 208 or from the stack via the TCP/IP stack interface
207.
[0042] System 200 may include a user interface 218 that may display
network performance information in any suitable way. For example,
user interface 218 may comprise icons 220 used to display
information on current connections (e.g., TCP connections), a
status of network performance degradation detection, diagnostics of
the network performance degradation and other suitable information.
In embodiments of the invention deploying the Microsoft.RTM.
Windows.RTM. Vista.TM. operating system, such icon as, for example,
a "Network Health Monitor Connectivity Tray," "Troubleshoot Network
Performance," and "MonitoringMode" icons may be provided. A user
may click on the icons to enable respective actions. Various menus
may be provided as well. For example, clicking on the
"MonitoringMode" icon may initiate a process of monitoring the
connection(s) to a remote destination (which may also be specified)
or to multiple remote destinations. The monitoring may be performed
automatically for a specified or default time interval. In some
embodiments, monitoring may be performed automatically until a user
takes an action to stop the process.
[0043] As discussed above, some embodiments of the invention
provide a method of establishing and maintaining a network
performance baseline for a communication path between a networked
computer and at least one other networked computer connected via a
network. In some embodiments, network performance information for
the communication path may be obtained and compared to the network
performance baseline. Other analyses of the network performance
information may be performed as well. For example, thresholds may
be employed, for comparison with network performance parameters
obtained from the network performance information. Deviation of the
network performance parameters from the baseline may indicate
network performance degradation. If the network performance
degradation is detected, source(s) of the degradation may be
identified. Also, the thresholds may be used to assist in
identifying the sources of the network performance degradation.
Furthermore, the network performance information may be used to
determine whether the network supports interactive
applications.
[0044] FIG. 4 illustrates an example of a process 400 of assessing
performance of a network to detect network performance degradation
and determine whether the network is suitable for interactive
applications according to some embodiments of the invention. The
process may start in block 401 where the network performance
baseline may be established and maintained as discussed in more
detail below. The process may then continue to block 402 where
current network performance information may be obtained.
[0045] It should be appreciated that the network performance
information may be processed to obtain network performance
parameters. For example, for each window in the connection (e.g., a
one-minute window), Max.sub.avg bandwidth, M.sub.avg bandwidth,
Mean bandwidth, RTT.sub.ave and RTT.sub.Var may be calculated.
[0046] The network performance information may include other
information such as, for example, IP traffic counters that define a
number of bytes received and a number of bytes sent by a networked
computer on a local network. The counters may be obtained, for
example, at one-minute intervals.
[0047] Any suitable method may he used to collect the network
performance information. For example, it may be obtained from the
network performance baseline stored in baseline storage module 206.
The information may also be obtained either directly from the
TCP/IP stack or from the stack via an interface (e.g., TCP/IP stack
interface 207). Furthermore, the information may be obtained from
any other suitable entities, including from a similar stack of
another computer on LAN 116 (FIG.1).
[0048] In block 404, the network performance parameters may be
compared to the network performance baseline. For example,
Max.sub.avg bandwidth, Min.sub.avg bandwidth, Mean bandwidth,
RTT.sub.ave and RTT.sub.Var calculated for the last window may be
compared to the respective parameters maintained as part of the
baseline. It should be appreciated that embodiments of the
invention are not limited in this respect and the network
performance information may be assessed using any other suitable
method. For example, thresholds may be employed to determine
regions of acceptable values of network performance parameters.
[0049] In decision block 406, it may be determined whether the
assessed network performance deviates from the baseline. It should
be appreciated that the deviation may define as any suitable
difference between the assessed and expected network performance.
If no deviation is detected, the process may return to block 402 to
continue sampling network performance. In some embodiments, the
process may branch to block 408 where it is determined whether the
network is suitable for interactive application. Interactive
applications may require a bandwidth to support a data rate
sufficiently fast to provide interactive response to users. The
suitability analysis is discussed in more detail below in
connection with FIG. 6. The process may then end.
[0050] If it has been determined in decision block 406 that the
network performance deviates from the established baseline, the
process may go to decision block 410 where it is determined whether
the identified deviation indicates that there is a problem on the
network. The problem may comprise any network performance
degradation that may occur on the network. If it is determined that
no network performance degradation has been detected, the process
returns to block 402 to continue sampling network performance.
[0051] If network performance degradation has been detected in
block 410, the process continues to block 412 to localize the
problem, i.e., to identify source(s) of the network performance
degradation. The performance degradation may be associated, for
example, with cross-traffic on a local network, performance issues
pertained to a remote server on a WAN, or problem(s) with an ISP
that may affect network performance of multiple computers on the
WAN. It should be appreciated that embodiments of the invention are
not limited in this respect and any other suitable sources of
network performance degradation may be identified. The process may
then end.
[0052] As discussed above, in some embodiments of the invention, a
network performance baseline is established and maintained for a
communication path between a networked computer and at least one
other networked computer connected via a network. To maintain the
baseline, the network performance parameters may be measured and
updated for the communication path.
[0053] As described above, the network performance parameters may
include an estimated network bandwidth computed as a ratio of a
congestion window size to round trip time. The inventors have
appreciated that this approach to estimating bandwidth is most
accurate when computer 200 is generating data at a rate that is
relatively close to the bandwidth that may be supported by the
network. To increase the accuracy of the baseline, the baseline may
be updated for a path using only values obtained during time
intervals when data transmitted on that communication path consumes
a bandwidth approximately equal to its estimated bandwidth of the
path. FIG. 5 demonstrates an example of the method of monitoring
the network performance by maintain the baseline according to some
embodiments of the invention.
[0054] A process 500 illustrated in FIG. 5 may start at any
suitable time. It may be initiated automatically (e.g., when a
networked computer establishes a connection with another computer
on the network) or by a user performing an action. For example, the
action may be taken via any suitable icon among icons 220 provided
by the user interface 218 shown in FIG. 2. In the example
illustrated, the network performance is monitored for one
communication path (e.g., a TCP connection) between the networked
computer and another device connected to the networked computer on
a network. However, the process of FIG. 5 may be performed for any
number of paths.
[0055] Process 500 may be executed using a sample of data obtained
from TCP/IP stack 208 (FIG. 2).
[0056] In block 502, it may be determined whether the communication
path is active. This determination may be made in any suitable way.
For example, a network interface may maintain timers for a network
connection, one of which may track time since the last successful
communication with an endpoint. If this timer has a value less than
a polling interval at which network performance data samples are
collected, the path may be deemed active. However, any suitable
mechanism to determine whether a path is active may be used.
[0057] If it is determined that the path in not active, the process
may branch to block 504 where some network performance parameters
of the path, referred to herein by way of example as path usage
parameters, may be updated. For example, the RTT.sub.ave and
RTT.sub.Var parameters may be updated. RTT.sub.ave and RTT.sub.Var
may be stored as part of a network performance baseline maintained
for the path. In addition, a duration of usage of the communication
pa(h, amount of usage of the path, a duration of time elapsed since
a last usage of the least one path may be updated as well. These
parameters may be stored in any other suitable component(s) of the
networked computer. The paths that are not active are not
considered further for monitoring network performance and the
process may then end.
[0058] If it is determined in block 502 that the communication path
is active, the process may branch to block 506 where network
performance data may be collected for one window time interval. The
window time interval may be of any suitable duration of time. For
example, in some embodiments, a one-minute window is used. The
window may comprise, for example, twelve samples of the network
performance data. The network performance data may include RTT
measurements or other delay parameters for the communication path.
The parameters may be provided by the TCP/IP stack when it is
polled by a bandwidth monitoring module (e.g., bandwidth monitor
204) which may poll the TCP/IP stack at certain time intervals. In
some embodiments, bandwidth monitor 204 polls the stack every five
seconds.
[0059] In decision block 508, it may be determined whether the
network is underutilized. This comprises determining whether,
during the time interval, communications on the path consumed a
bandwidth within a range of an estimated bandwidth. Such conditions
may occur when a "peaked in" flag is set for the path. The "peaked
in" flag may be broadly defined as an indication of a connection
condition when there are more data to send over a connection than
the connection allows. It should be appreciated that the "peaked
in" flag may be set in a data structure representing the path in
suitable software component(s) and provides only an example of an
indication that the amount of the traffic transferred over the path
is acceptable and that the networked computer sends data at a rate
that within the range of the estimated bandwidth. It should also be
appreciated that other flags may be set and values considered in
the data structure representing with the path.
[0060] In some embodiments, the "peaked in" flag is set when during
an interval, transmissions on the path consumed a bandwidth that
exceeds a threshold percentage of the estimated bandwidth of the
path. The threshold percentage may be any suitable value determined
using any suitable method. Further, determining whether the
communications on the path consumed the bandwidth within the range
of the estimated bandwidth may comprise determining whether a
sender congestion window has a size exceeding a threshold
percentage of a value representing a product of the estimated
bandwidth and an estimated round trip delay on the path. The sender
congestion window may be set by the TCP/IP stack or by any other
suitable component. This threshold percentage may be, for example,
75%.
[0061] If it is determined, in decision block 508, that the
communications on the path consumed the bandwidth below the
estimated bandwidth which may indicate that the network is
underutilized, the process may return to block 502 where another
path may be considered or the process may repeat on the same path
during a later sample. However, as illustrated, when the network is
underutilized while a sample was being collected, that sample is
not used to compute an update to the baseline.
[0062] If it is determined, in decision block 508, that the
communications on the path consumed the bandwidth within the range
of the estimated bandwidth which may indicate that the network is
not underutilized, the process may continue to block 510 where
network performance parameters may be calculated for the last time
interval window. The parameters may comprise, for example,
Max.sub.avg bandwidth, Min.sub.avg bandwidth, Mean bandwidth,
RTT.sub.ave and RTT.sub.Var and other suitable parameters. The
parameters may be calculated from bandwidth samples collected
during the last time interval window, which, in some embodiments,
equals one minute.
[0063] In some embodiments of the invention, the network
performance parameters, which may also be referred to as network
performance baseline parameters, calculated for the path during a
time interval at which congestion is detected may not be used for
updating the network performance baseline. The network performance
parameters obtained during congestion may corrupt the baseline.
[0064] The network performance parameters calculated in block 510
may be used to determine if there is congestion on the network, in
block 512. Congestion may be determined using any suitable method.
For example, it may be determined whether the communications on the
path consumed the bandwidth within a range of the estimated
bandwidth, or the throughput. RTT may increase during congestion.
Further, it may be determined whether variations of network
performance parameters (e.g., the bandwidth) of the path during the
last time interval window exceeded a threshold. During congestion,
variance of the bandwidth metric increases and the mean bandwidth
value decreases due to increased number of fluctuation. In some
embodiments, the following conditions may indicate congestion on
the network: (Max.sub.avg-Min.sub.avg>=Mean/2) or
(Min.sub.window/Max.sub.window<=0.5). The Min.sub.window and
Max.sub.window parameters define the minimum and maximum values of
the bandwidth during the last time interval window, respectively.
If congestion is detected, the process may return to block 502
where another path may be considered. If the congestion detection
performed at block 512 has indicated that no congestion has been
detected, the process may continue to block 514 where the network
performance baseline is updated using the network performance
parameters calculated for the last time interval window.
[0065] The network performance baseline for the communication path
may be updated by maintaining moving averages which may be updated
for each window Max.sub.avg and Min.sub.avg bandwidth parameters,
which may be referred to as extreme values of a bandwidth metric,
may be updated using an asymmetric moving average. Updating the
moving average of these parameters comprises computing a weighed
combination of the Max.sub.avg and Min.sub.avg bandwidth parameters
computed during the last time interval window (Max.sub.avg(Last
Window) and Min.sub.avg(Last Window)) and the moving average of the
Max.sub.avg and Min.sub.avg bandwidth parameters computed in a
prior interval, respectively. Factors used for weighing the
combination may be selected based on the extreme value during the
last time interval window relative to the moving average computed
in the prior interval. A greater weight may be given to a sample in
which the value of the extreme parameter is beyond the prior
computed extreme.
[0066] If Max.sub.avg<Max.sub.avg(Last Window), then
Max.sub.avg(Last Window)will be weighted more heavily.
[0067] Then a moving average of the Max.sub.avg bandwidth may he
calculated:
Max.sub.avg=F.sub.1.times.Max.sub.ave+F.sub.2.times.Max.sub.ave(LastWind-
ow). Eq. (1)
[0068] When Max.sub.avg<Max.sub.avg(Last Window), Max.sub.avg is
expanding. Factors F.sub.1 and F.sub.2 ("forgetting factors") may
be defined as, for example, 7/8 and 1/8, respectively:
Max.sub.avg=7/8.times.Max.sub.ave+1/8.times.Max.sub.ave(Last
Window). Eq. (2)
[0069] Conversely, if Max.sub.avg>Max.sub.avg(Last Window),
Max.sub.avg is contracting. To prevent one sample from having a
greater impact on what is intended to he an extreme value,
Max.sub.avg(Last Window) may be given less weight Factors F.sub.1
and F.sub.2 may take values of, for example, 99/100 and 1/100,
respectively:
Max.sub.avg= 99/100.times.Max.sub.ave+ 1/100.times.Max.sub.ave(Last
Window). Eq. (3)
[0070] Eq. (1), (2) and (3) apply only after a moving average has
been established. Initially, for a predetermined number of time
interval windows, the Max.sub.avg(Last Window) may be used to
update the baseline: Max.sub.avg=Max.sub.avg(Last Window) if
Max.sub.avg(Last Window) is larger. In some embodiments, the
predetermined number may be 100.
[0071] A similar asymmetrical moving average may be applied at the
other extreme for Min.sub.avg. Initially, if
Min.sub.avg>Min.sub.avg(Last Window), then, for a predetermined
number of time interval windows, the Min.sub.avg(Last Window) may
be used to update the baseline: Min.sub.avg=Min.sub.avg(Last
Window). In some embodiments, the predetermined number may be
100.
[0072] Then a moving average of the Min.sub.avg bandwidth may be
calculated:
Min.sub.avg=F.sub.1.times.Min.sub.ave+F.sub.2.times.Min.sub.ave(LastWind-
ow). Eq. (4)
[0073] When Min.sub.avg>Min.sub.avg(Last Window), Min.sub.avg is
expanding. Factors F.sub.1 and F.sub.2 may be defined as, for
example, 7/8 and 1/8, respectively:
Min.sub.avg=7/8.times.Min.sub.ave+1/8.times.Min.sub.ave(LastWindow).
Eq. (5)
[0074] If Min.sub.avg<Min.sub.avg(Last Window), Min.sub.avg is
contracting. Factors F.sub.1 and F.sub.2 may take values of, for
example, 99/100 and 1/100, respectively:
Min.sub.avg= 99/100.times.Min.sub.ave+
1/100.times.Min.sub.ave(LastWindow). Eq. (6)
[0075] Utilizing asymmetric weighing factors network performance
baseline parameters that represent extremes may, in sonic,
embodiments, be used to present a more accurate baseline. It should
be appreciated that any suitable factors F.sub.1 and F.sub.2 may be
selected. The factors may be selected automatically, set by a user
or selected in any other suitable manner.
[0076] Other baseline parameters may be updated similarly, though
in the illustrated embodiment, a symmetric moving average may be
used. To update the bandwidth mean. Mean, for a predetermined
number of time interval windows (e.g., 100), a linear average may
be used:
Mean = NumPreviousSamples .times. Mean + Mean ( LastWindow )
NumPreviousSamples + 1 . Eq . ( 7 ) ##EQU00001##
[0077] Then, a moving average may be used:
Mean=F.sub.1.times.Mean+F.sub.2.times.Mean(LastWindow). Eq. (8)
[0078] It should be appreciated that any suitable factors F.sub.1
and F.sub.2 may be selected. For example, the factors may be set as
49/50 and 1/50, respectively. The factors may be selected
automatically, set by a user or selected in any other suitable
manner. Number of previous samples, or time interval windows, may
be selected to reflect a time period over which measurements are
likely to reflect current conditions, or in any other suitable
way.
[0079] In some embodiments, to update the Max.sub.avg bandwidth of
the baseline, it may be first determined whether a percent of a
difference between Max.sub.avg and Max.sub.avg(Last Window) is less
than a threshold (e.g., 10%). If this is the case, the Max.sub.avg
may be updated in the same manner as the bandwidth mean. Similarly,
if percent difference between Min.sub.avg and Min.sub.avg(Last
Window) is less than a threshold (e.g., 10%), then the update
algorithm for Min.sub.avg may be similar to that fir updating the
bandwidth mean.
[0080] Updating RTT.sub.ave and RTT.sub.Var may be performed in a
manner similar to updating the bandwidth mean. Therefore, a linear
average may be obtained for a predetermined number of time interval
windows (e.g., 100) and a moving average may be calculated for the
next time interval windows. It should be appreciated that any other
suitable parameters may be stored and maintained as part of the
network performance baseline. For example, SRTT may be stored and
updated in a manner similar to updating the RTT.sub.ave and
RTT.sub.Var parameters. It should be appreciated that time interval
windows may be of any suitable duration of time.
[0081] It should be appreciated that updating the network
performance baseline as described above is given by way of example
only as other suitable methods may be substituted. After the
baseline is updated using network performance parameters calculated
for the last time interval window (given that no congestion has
been detected), in block 514, the process may return to block 502
to analyze another path between the networked computer and other
device on the network or to update the same path in a later
window.
[0082] As discussed above, network performance information may be
used to determine whether the network supports interactive
applications. A network with a low traffic delay may support
interactive applications. FIG. 6 illustrates an example of a
process 600 of determining whether a network supports interactive
applications according to some embodiments of the invention.
Process 600 may be performed by any device on a network (e.g.,
computer 102) using any suitable component(s). In some embodiments,
interactive support component 214 shown in FIG. 2 may be
employed.
[0083] Process 600 may be initiated at any suitable time. By way of
example only, in FIG. 6, the process is shown to start at block 602
("sample performance") where the network performance information is
being obtained. The information may be sampled at suitable time
intervals. Any suitable method, including the methods described
above, may be used to collect the network performance information.
For example, it may be obtained from the network performance
baseline stored in baseline storage module 206. The information may
also be obtained either directly from the TCP/IP stack or from the
stack via an interface (e.g., TCP/IP stack interface 207).
[0084] In decision block 604, it may be determined whether a
request to initiate an interactive application that interacts with
the device has been received. If it has been determined in decision
block 604 that no request to initiate an interactive application
has been received, the process may return to block 602 to continue
sampling network performance.
[0085] If the request has been received, the process branches to
decision block 606 where it may be determined whether the network
supports the interactive application. In the example illustrated.,
the network supports interactive application when SRTT parameter is
lower than 200 ms (milliseconds). SRTT may be calculated using any
suitable method, such as filtering a data stream reflecting
successive samples of RTT. It should be appreciated that
embodiments of the invention are not limited in this respect and
any suitable threshold may be substituted.
[0086] In some embodiments, when the SRTT parameter is lower than
200 ms, it may be further determined whether RTT for a last sample
is lower than 200 ms. If the answer is affirmative, it may be
inferred that the network supports interactive applications. The
network still supports applications if SRTT is lower than 200 ms
and RTT for the last sample is greater than 200 ms. However, such
conditions may indicate that there is a transient problem on the
network.
[0087] If, in decision block 606, it has been determined that the
network supports interactive applications, the process goes to
block 610 to run an interactive application. The process may then
end. Otherwise, if it has been determined that the network does not
support interactive applications, the interactive application may
be not permitted to run and disabled, in block 608. The process may
then end. It should be appreciated that process 600 is shown to end
at either block 608 or 610 by way of example only. Other
implementations of the process may be substituted. For example, the
process may continue to monitor for subsequent requests to initiate
an interactive application.
[0088] As discussed above, network performance information for
communication paths between a networked computer and other devices
on a network may be obtained. The networked computer may be
connected to other networked devices on a WAN via a LAN. The
information may be assessed to determine whether the network is
experiencing network performance degradation. Source(s) of the
performance degradation may then be localized. The diagnosis may be
performed using a method that can be referred to as a progressive
elimination. Thus, a number of possible source(s) of the detected
performance degradation may be progressively narrowed down. The
sources may be, for example, network cross traffic on the LAN or
one or more networked computers on the WAN. An ISP or a single
remote server may be possible sources of network performance
degradation.
[0089] Thus, in some embodiments, a networked computer may obtain
network performance information on connections between the
networked computer and other devices on the network. This may
include tracking average network performance information during an
interval of time. The average network performance information may
include a network performance baseline that may be established and
maintained for each communication path (e.g., a TCP connection)
between the networked computer and other networked devices. The
network performance information for the communication path may be
obtained and compared to the network performance baseline. Also,
thresholds may be employed for comparison with network performance
parameters obtained from the network performance information.
Deviation of the network performance parameters from the baseline
may indicate network performance degradation. If the network
performance degradation is detected, source(s) of the degradation
may be identified. Also, the thresholds may be used to assist in
identifying the sources of the network performance degradation.
[0090] FIG. 7 is a flowchart of a method 700 of detecting network
performance degradation and diagnosing source(s) of the performance
degradation according to some embodiment of the invention.
[0091] The process may start at block 702 where the network
performance baseline may be established and maintained as discussed
above. It should be appreciated that block 702 is shown as the
first block of the process by way of example only, to illustrate
that, in embodiments of the invention, the network performance
baseline may be employed to monitor network performance.
[0092] In block 704, it may be determined whether there has been
active traffic on the network during a last time interval. Though
in the example illustrated, the time interval is one minute, it
should be appreciated that other suitable time intervals may he
substituted. If it is determined that there has not been active
traffic on the network during a last time interval, the process may
go to block 706 where a layer 3 performance analysis may be
finished.
[0093] If the process reaches termination point 706, the source of
the degradation may be deemed to have been caused by components
within the computing device managing layer 3 interconnect
functions. For example, this state may indicate that the computer
is improperly configured for accessing the network. However, any
suitable layer 3 diagnostics may be used to diagnose any number of
layer 3 connection problems. Regardless of the specific mechanism
by which layer 3 connection problems are detected, if no such
problems are detected, process 700 proceeds to perform tests that
may detect other types of problems.
[0094] If it is determined that there has been active traffic on
the network during :lust time interval, the process may branch to
block 708 Where network communication information may be obtained
from at least one other networked computer on the LAN. The network
communication information may be, for example, RTT, the bandwidth
metric computer as described above, IP traffic counters and other
suitable information which may be obtained using any suitable
method. For example, in embodiments of the invention here a
Microsoft.RTM. Windows.RTM. operating system is deployed, a Link
Layer Topology Discovery (LLTD) protocol operating over both wired
(e.g., using the IEEE 802.3 standard protocol) and wireless (e.g.,
using the IEEE 802.11 standard protocol) media may be used. The
LLTD protocol provides a discovery service, LLTD Quick Discovery,
which may be used to enumerate all LLTD-capable devices in
communication with the networked device on the LAN. The LLTD Quick
Discovery may query each of the devices for its IP traffic counters
information. The counters comprise a number of bytes received and a
number of bytes sent. The counters may be sampled, for example, at
one-second intervals. Previously obtained counters may be
maintained for a time interval. In some embodiments, the interval
comprises at least 3 seconds.
[0095] In block 710, it may be determined whether the network
performance degradation can be attributed to cross traffic as a
source of the problem. Cross-traffic may be detected from counters
with high values or in any other suitable way. The cross-traffic
analysis may be used to determine if the performance problem is
caused by concurrent network traffic in the local network (e.g., a
subnet) sharing the network infrastructure. In some embodiments,
the cross-traffic detection may include using LLTD Quick Discovery.
The performance degradation may be caused by network cross traffic
when the network communication information indicates that traffic
on the local network is above a threshold. It should be appreciated
that embodiments of the invention are not limited in this respect
and any suitable threshold may be used. If it has been determined
that the cross-traffic is the source of the network performance
degradation, the process may end in block 712.
[0096] If it has not been determined that the cross-traffic is the
source of the network performance degradation, the process may go
to block 714 where it may be determined whether the network
performance degradation can be attributed to a layer 2 dynamic
problem as a source of the performance degradation. The layer 2
dynamic problem may be a media-specific dynamic problem (e.g., a
problem associated with Wi-Fi interference, low signal strength and
other problems). Tests to detect layer 2 problems are known, and
processing at block 714 may entail any one or more known tests for
layer 2 dynamic problems. However, any suitable tests, whether now
known or after developed, may be employed at block 714.
[0097] In some embodiments, if the networked computer is wireless,
then in addition to the above, if any other wireless device on a
network has a throughput (e.g., the total number of bytes sent and
bytes received) that exceeds a threshold, a cross-traffic network
congestion may be identified. The threshold may be defined as 0.5
Mbps (mega bytes per second). It should be appreciated that
embodiments of the invention are not limited in this respect and
other suitable thresholds may be substituted. Such problems may
exist because the communication media is shared among the wireless
devices and even if only one device is using the media for a longer
time than other devices, this device may eventually pull the
throughput of the networked device. If it has been determined that
the layer 2 dynamic problem is the source of the network
performance degradation, the process may end in block 716.
[0098] If it has been determined that the layer 2 dynamic problem
is not the source of the network performance degradation, the
process may go to block 718 where it may be determined whether more
than one communication path between the networked computer and at
least one another networked device has been recently active.
[0099] If no paths were active or only one path has been recently
active, insufficient information may be available to distinguish
between the various sources of network degradation. Accordingly,
process 700 may branch from 718 to termination point 730. If
process 700 reaches termination point 730, the source of the
network degradation may be identified as having been caused by a
server, the ISP. Alternatively, at termination point 730, the
source of the degradation may he deemed to be cross-traffic on the
local network that was not detected at block 710.
[0100] If it has been determined that more than one communication
path has been recently active, the process may go to block 720
where it may be determined whether the network performance
degradation can be attributed to a problem at an ISP. Average
network performance information on the paths may be compared to the
respective baselines for the paths. If the comparison indicates
that network performance is below the baseline for more than one
path of the paths per a device in communication with the networked
device, it may be determined that an ISP is a source of the
performance degradation. Also, an ISP may be identified as a source
of the performance degradation if congestion is detected on all of
the paths that have been recently active using the method described
above. It should be appreciated that embodiments of the invention
are not limited in this respect and other suitable ways of
determining that an ISP may be a source of the performance
degradation may be substituted. If it has been determined that an
ISP is a source of the performance degradation, the process may end
in block 722.
[0101] If it has been determined that a source of the performance
degradation is not an ISP, the process may branch to block 724
where it may be determined whether the degree of confidence with
which a remote may be deemed the source of the network performance
degradation. A remote server communicating with the networked
computer over the paths that have been recently active may be
identified as a source of the network performance degradation if
the network performance is below the baseline for one path of the
paths between the networked computer and the remote server and/or
if congestion is detected on one path. Further, for the remote
server to be identified as a source of the network performance
degradation, network performance on other paths is above the
baseline for those paths and no signs of congestion are detected
for those paths. If this is the case, the diagnostics process may
end at block 726. In other situations, for example, if other paths
has been active for an amount of time below a threshold (i.e., the
paths may be considered not sufficiently recent which may be
determined using any suitable method) or baselines for the paths
are determined to be broad (e.g., when
Max.sub.ave-Min.sub.ave>Mean), it may be determined that the
remote server is a possible source of the network performance
degradation, in block 728.
[0102] Having thus described several aspects of at least one
embodiment of this invention, it is to be appreciated that various
alterations, modifications, and improvements will readily occur to
those skilled in the art.
[0103] Such alterations, modifications, and improvements are
intended to be part of this disclosure, and are intended to be
within the spirit and scope of the invention. Accordingly, the
foregoing description and drawings are by way of example only.
[0104] The above-described embodiments of the present invention can
be implemented in any of numerous ways. For example, the
embodiments may be implemented using hardware, software or a
combination thereof. When implemented in software, the software
code can be executed on any suitable processor or collection of
processors, whether provided in a single computer or distributed
among multiple computers.
[0105] Further, it should be appreciated that a computer may be
embodied in any of a number of forms, such as a rack-mounted
computer, a desktop computer, a laptop computer, or a tablet
computer. Additionally, a computer may be embedded in a device not
generally regarded as a computer but with suitable processing
capabilities, including a Personal Digital Assistant (PDA), a smart
phone or any other suitable portable or fixed electronic
device.
[0106] Also, a computer may have one or more input and output
devices. These devices can be used, among other things, to present
a user interface. Examples of output devices that can be used to
provide a user interface include printers or display screens for
visual presentation of output and speakers or other sound
generating devices for audible presentation of output. Examples of
input devices that can be used for a user interface include
keyboards, and pointing devices, such as mice, touch pads, and
digitizing tablets. As another example, a computer may receive
input information through speech recognition or in other audible
format.
[0107] Such computers may be interconnected by one or more networks
in any suitable form, including as a local area network or a wide
area network, such as an enterprise network or the Internet. Such
networks may be based on any suitable technology and may operate
according to any suitable protocol and may include wireless
networks, wired networks or fiber optic networks.
[0108] Also, the various methods or processes outlined herein may
be coded as software that is executable on one or more processors
that employ any one of a variety of operating systems or platforms.
Additionally, such software may be written using any of a number of
suitable programming languages and/or conventional programming or
scripting tools, and also may be compiled as executable machine
language code or intermediate code that is executed on a framework
or virtual machine.
[0109] In this respect, the invention may be embodied as a computer
readable medium (or multiple computer readable media) (e.g., a
computer memory, one or more floppy discs, compact discs, optical
discs, magnetic tapes, flash memories, circuit configurations in
Field Programmable Gate Arrays or other semiconductor devices,
etc.) encoded with one or more programs that when executed on one
or more computers or other processors, perform methods that
implement the various embodiments of the invention discussed above.
The computer readable medium or media can be transportable, such
that the program or programs stored thereon can be loaded onto one
or more different computers or other processors to implement
various aspects of the present invention as discussed above.
[0110] The terms "program" or "software" are used herein in a
generic sense to refer to any type of computer code or set of
computer-executable instructions that can be employed to program a
computer or other processor to implement various aspects of the
present invention as discussed above. Additionally, it should be
appreciated that according to one aspect of this embodiment, one or
more computer programs that when executed perform methods of the
present invention need not reside on a single computer or
processor, but may be distributed in a modular fashion amongst a
number of different computers or processors to implement various
aspects of the present invention.
[0111] Computer-executable instructions may be in many forms, such
as program modules, executed by one or more computers or other
devices. Generally, program modules include routines, programs,
objects, components, data structures, etc. that perform particular
tasks or implement particular abstract data types. Typically the
functionality of the program modules may be combined or distributed
as desired in various embodiments.
[0112] Also, data structures may be stored in computer-readable
media in any suitable form. For simplicity of illustration, data
structures may be shown to have fields that are related through
location in the data structure. Such relationships may likewise be
achieved by assigning storage for the fields with locations in a
computer-readable medium that conveys relationship between the
fields. However, any suitable mechanism may be used to establish a
relationship between information in fields of a data structure,
including through the use of pointers, tags or other mechanisms
that establish relationship between data elements.
[0113] Various aspects of the present invention may be used alone,
in combination, or in a variety of arrangements not specifically
discussed in the embodiments described in the foregoing and is
therefore not limited in its application to the details and
arrangement of components set forth in the foregoing description or
illustrated in the drawings. For example, aspects described in one
embodiment may be combined in any manner with aspects described in
other embodiments.
[0114] Also, the invention may be embodied as a method, of which an
example has been provided. The acts performed as part of the method
may be ordered in any suitable way. Accordingly, embodiments may be
constructed in which acts are performed in an order different than
illustrated, which may include performing some acts simultaneously,
even though shown as sequential acts in illustrative
embodiments,
[0115] Use of ordinal terms such as "first," "second," "third,"
etc., in the claims to modify a claim element does `not by itself
connote any priority, precedence, or order of one claim element
over another or the temporal order in which acts of a method are
performed, but are used merely as labels to distinguish one claim
element having a certain name from another element having a same
name (but for use of the ordinal term) to distinguish the claim
elements.
[0116] Also, the phraseology and terminology used herein is for the
purpose of description and should not be regarded as limiting. The
use of "including," "comprising," or "having," "containing,"
"involving," and variations thereof herein, is meant to encompass
the items listed thereafter and equivalents thereof as well as
additional items.
* * * * *