Method to display information representing network traffic on a computer display monitor

[0002] 1. Field of the Invention

[0003] The present invention relates generally to tools for network performance and protocol analysis, and more specifically to a user interface and method for visually displaying information about packet traces in a network environment, using thread diagrams.

[0004] 2. Description of Background Art

[0005] Conventional network protocol analysis tools, such as Sniffer Basic by Network Associates, Inc. (www.nai.com), evaluate network performance with respect to the transfer of individual packets across network connections. For example, packet transfer times can be measured and aggregated into a performance metric. Such analysis is generally able to provide detailed information regarding a network protocol at the packet level.

[0006] However, in many situations, analysis of application-level behavior is desired. For example, one may wish to analyze the behavior of an application such as a web browser, which makes use of a network protocol, in order to determine whether the performance of the application is satisfactory, and to diagnose problems in application-level behavior.

[0007] Application-level behavior can be extracted from packet-level analysis by pruning a protocol analyzer trace to determine the application level information that is of interest. Information relevant to a particular transaction or communication must be extracted and synthesized from the packet-level data. Such a technique is time-consuming and often yields inaccurate results.

[0008] In addition, such a technique fails to provide any easy-to-use graphical user interface for viewing application-level protocol analysis data. Thus, the technique fails to provide the viewer of the output with the necessary information, presented in a coherent manner, for diagnosing and solving network protocol deficiencies and problems.

[0009] What is needed is a method and user interface for displaying network performance and protocol analysis results in a coherent and visually understandable manner. What is further needed is a method and user interface for accurately providing application-level protocol analysis without requiring time-consuming analysis of packet-level trace information.

[0010] The present invention overcomes the limitations of conventional network analyzer software products by providing a user interface and computer-implemented method that employs graphical techniques to enable the user to quickly identify performance problems in network traffic and application behavior, including parallelism faults, timing gaps, and the like.

[0011] The user interface of the present invention operates as part of a network analyzer software product coupled to a network having a plurality of nodes. The nodes transmit packets of data between them, which packets are monitored by the network analyzer. The user interface comprises a time axis listing a plurality of times. These times may be listed in any useful time format, whether absolute or relative time (with respect to some arbitrary starting time). The user interface further includes a plurality of thread names listed along a second axis that is perpendicular to the time axis. Each thread name is associated with a thread, which includes at least one sequence of packets transmitted between two or more nodes and forming a discrete transaction between the nodes. The present invention determines which packets belong in a particular thread by analyzing the stream of packets and making a protocol-specific determination of the packets that should be grouped together.

[0012] In general, a transaction consists of an application-level communication between two nodes. Thus, a request by one node for a file stored at a second node, and the subsequent delivery of the requested file, can be considered a single transaction, and can therefore be represented as a single thread. More specifically, in the Hypertext Transfer Protocol (HTTP), a GET request by a client browser and the delivery of the requested web page together form a single thread, even though there are at least two discrete sequences of packets. The sequence of packets that makes up a thread need not be contiguous, as a single node may participate in several different threads at the same time. For example, a server node may be serving numerous different client nodes at the same time, and thus have a distinct thread occurring with each of the clients, with the packets being serially transmitted and received by the server node belonging to these many different threads.

[0013] The plurality of thread names are listed according to a sequence of threads between the nodes of the network. Each thread name is further associated with a thread graphic in the user interface. Each thread graphic begins at the time of a first packet in the associated thread and extends parallel to the time axis to the time of a last packet in the associated thread. The thread graphic thus shows the overall duration of the associated thread, along with its starting and ending times. A thread graphic may be color-coded with respect to various quantitative measures, such as its total size, average packet size, number of packets, number of bytes, and so forth, or qualitative aspects, such as protocol type. Color-coding, or other distinctive visual features, may also be provided for other relevant quantitative values or qualitative characteristics of the thread.

[0014] Since several thread names are listed, and each one has its associated thread graphic showing its duration and its beginning and end, the user can readily see when one thread ends or begins with respect to any other thread. This makes it very simple to identify parallelism faults, where multiple different threads are occurring concurrently between the same two nodes, or gaps between the end of one thread and the beginning of another (indicating a loss of optimum bandwidth utilization). These types of problems degrade network or application performance, and their diagnosis can be vital to improving application operation.

[0015] In addition, the user interface of the present invention makes clear the interdependence among different parts of a networked application, and facilitates thread grouping in an interactive, dynamic manner. The user is also able to quickly narrow down an area of interest by zooming.

[0016] The present invention thus facilitates analysis of packet-level operational characteristics in a packet trace that groups packets in coherent, application-level structure.

[0017] A method in accordance with the present invention includes receiving a plurality of packets on networks, identifying in the packets a plurality of threads between pairs of nodes on the network, displaying a time axis including a plurality of times, listing the names of the threads in perpendicular to the time axis, and then for each thread name, displaying a thread graphic beginning, with respect to the time axis, at a time of a first packet in the sequence of packets of the thread, and ending at the time of a last packet in the sequence of packets. The method may also implement thread grouping as specified by the user.

[0018] FIG. 1 is a diagram of a network to be analyzed in connection with the present invention.

[0019] FIG. 2 is a screen shot of a visual thread diagram according to the present invention.

[0020] FIG. 3 is a screen shot of a zoomed visual thread diagram.

[0021] FIG. 4 is a screen shot of a visual thread diagram showing pop-up information.

[0022] FIG. 5 is a screen shot of a visual thread diagram showing a view of a thread group.

[0023] FIG. 6 is a screen shot of a visual thread diagram showing selecting and sorting operations.

[0024] FIG. 7 is a block diagram of the software architecture of one embodiment of the present invention.

[0025] FIG. 8 is a flow diagram showing a method of determining which packets belong in a particular thread.

[0026] Referring now to FIG. 1, there is shown a network 100 to be analyzed in connection with the present invention. Network 100 contains a number of interconnected nodes 102, which may be servers, clients, routers, and other networked components. The topology shown in FIG. 1 is merely exemplary; network connections may be arranged according to any other scheme, depending on the configuration and requirements of the particular network. Connections among nodes 102 are established by well-known protocols such as Transfer Control Protocol/Internet Protocol (TCP/IP) along conventional physical connection media such as an Ethernet, T1, or T3 line. Analyzer 101 is a device, typically implemented as software on a conventional computer connected to network 100, for measuring performance characteristics, such as timing, of the network and its connections.

[0027] The present invention is described herein in terms of a user interface and computer-implemented method for presenting information obtained by analyzer 101 in measuring network characteristics. As such, it is presented as a software application running on a conventional computer, such as that represented by analyzer 101. Such computer is for example, a conventional computer with a Pentium II microprocessor, random access memory (RAM), input and output devices, and storage. It runs an operating system, such as Windows 95 from Microsoft Corporation. The user interface of the invention may be presented on a conventional display device such as a cathode ray tube (CRT), as is known in the art. The user may interact with the user interface of the invention using a conventional pointing device such as a trackball or mouse, and a keyboard, if desired.

[0028] Referring now to FIG. 2, there is shown a screen shot of a visual thread diagram 200 according to one embodiment of the present invention. As with all screen shots described herein, the diagram 200 presented in FIG. 2 can be displayed on a display screen of a computer for analyzing the performance of network 100. The user can interact with the various components displaying in the screen shot by using a pointing device to manipulate an on-screen cursor (not shown).

[0029] Visual thread diagram 200 presents information in terms of threads, with each thread representing a series of packet transfers. Information describing threads is shown in a manner that allows the user to explore the length of time, or duration, of a thread, the content of the thread, the start and stop times of the thread, and the network resources involved in processing the thread.

[0030] A thread is defined as some collection of individual packets that relate to a particular transaction or other application-level event. The present invention determines which packets belong in a particular thread by analyzing the stream of packets and making a protocol-specific determination of the packets that should be grouped together.

[0031] Referring now to FIG. 8, there is shown an example of a method for performing this analysis. A first packet is selected 801 and decoded 802. The system then determines 803 whether the selected packet can be grouped into an existing thread. This test is protocol-specific, and is generally based on the particular types of packets associated with the application being analyzed. For example, in the HTTP protocol, there are two particular types of packets that will not be grouped into an existing thread because they indicate the beginning of a new thread: 1) the first packet in a new TCP connection; or 2) a packet that contains a GET or POST command. Depending on the particular protocol being used, different rules and conditions apply in implementing the test of 803.

[0032] If the packet can be grouped into an existing thread, the packet is assigned 804 to that thread. If not, a new thread is created 805 and the packet is assigned 806 to it. The system then determines 807 whether there are any additional packets to be analyzed. If so, it selects 808 another packet and returns to 802. If not, the algorithm ends 809.

[0033] Alternatively, other ways of determining or defining threads can be used. In an alternative embodiment, a specific programming language for writing protocol decodes and thread recognition can be made available, so as to provide greater configurability in this regard.

[0034] Each thread has a number of characteristics, including for example: a name; a start time, which can be expressed either in absolute terms or in relative terms (with respect to the beginning of the appropriate packet trace); a duration; a source and destination node; average packet size; number of packets; number of bytes; and the like. Visual thread diagram 200 provides a graphical display of some or all of these characteristics in a manner that is recognizable and understood by the user. Thread names are automatically generated based on the nature of the underlying network operation represented by the thread; however, the user can rename threads if desired, by simply double-clicking on the cell containing the name and typing a new name. In one embodiment, a pop-up menu is provided, which allows selection from a list of names.

[0035] Visual thread diagram 200 contains two panes 201 and 208. Within each pane, scroll bars 209 provide navigation controls in a conventional manner. The vertical scroll bar 209 controls vertical scrolling for both panes 201 and 208, so that each element in pane 201 remains in alignment with the corresponding element in pane 208. The center line between the two panes 201 and 208 can be moved left or right by the user, using an on-screen cursor (not shown), to resize panes 201 and 208 as desired.

[0036] Pane 201 shows a table listing a number of threads 202 in a columnar format. For each thread 202, various types of information are provided, including any or all of the items listed previously. In one embodiment, the specific types of information shown in pane 201 can be configured by the user. In the example of FIG. 2, sixteen threads 202 (numbered 2 through 17) are shown in pane 201, and for each thread 202 the name of the thread, and an associated server, are displayed.

[0037] Pane 208 contains a visual representation of threads 202, known as a “Gantt chart”. Gantt charts are described for example in “Microsoft Project 98: Step by Step”, Microsoft Press, November 1997. An example of a computer-implemented instantiation of a Gantt chart can be found in Microsoft Project 98, from Microsoft Corporation. In the present invention, a horizontal bar 205 is shown for each thread 202 displayed in pane 201. Each bar 205 is positioned so that it is aligned with the corresponding thread 202 information in pane 201. The start and end position of each bar 205 is representative of the starting and ending time for the corresponding thread 202, with reference to time axis 212. Thus, the width of each bar 205 represents the duration of the thread.

[0038] In one embodiment, the user can define groups of threads. Threads belonging to a particular group are shown below the group title, and indented with respect to the group title. For example, FIG. 2 shows group title 210, labeled “All threads”, which represents an aggregate of threads 202 listed below it. A bar 213 for the thread group is shown in pane 208, with visual characteristics representative of the relevant information for the group as a whole. The user can expand or collapse such groups of threads by manipulating icons 211 as desired, so as to selectively view a higher-level representation of network activity in both panes 201 and 208. The collapsing and expanding operations are performed by activating a small icon 211 in a manner that is familiar to Windows 95 users for collapsing and expanding hierarchical displays. The user can also reorganize thread groups as desired, by dragging rows representing threads 202 or thread groups from a position within (subordinate to) one group to a position within another group. Groups within groups can also be created. Moving a thread group automatically causes all its subsidiary items to move along with it.

[0039] In one embodiment, bars 205 are color-coded to show average packet size for each thread, keyed to legend 203. Other types of information can also be displayed using color-coding, as will be recognized by one skilled in the art.

[0040] As stated above, scroll bars 209 operate in both panes 201 and 208 of the diagram 200. The user can manipulate the vertical scroll bars 209 to change the display of both panes 201 and 208 in a coordinated manner, with each bar 205 remaining in alignment with the corresponding entry in the table of pane 201. Thus, the user can relate the information in the table of pane 201 with the graphical view of pane 208.

[0041] The default root of the hierarchy displayed in pane 201 is the “All Threads” group 210. Initially, in one embodiment, threads 202 are sorted within any particular group by start time, from top to bottom. Thus, within a group, the earliest thread is shown at the top and the latest is shown at the bottom. In other embodiments, a different sort order may be used. The user can specify a desired sort order by double-clicking on any column heading. For example, if the user double-clicks on the “Server” column heading, the display of threads is re-ordered to be in alphabetical order by server name. If a group contains both groups and threads, its child groups appear first, followed by its child threads. Other methods for specifying a sort order can also be employed, as will be recognized by one skilled in the art.

[0042] The information presented in diagram 200 is derived from measurements of network performance. Such measurements, including statistics concerning packet transfers, data rates, and the like, are obtained by methods that are well known in the art of network performance assessment. Many existing network environments provide log files from which such measurements can be extracted for use in the present invention.

[0043] Referring now to FIG. 5, there is shown an example of diagram 200 employing a more complex grouping structure. Group 210 (labeled “All threads”) includes all items listed in pane 201. Group 501 (labeled “Group 1”) includes items listed underneath the group's title and indented with respect to the title. Group 502 (labeled “Group 2”) includes three threads. Note that Group 501 includes Group 502, as well as a number of other threads.

[0044] The user defines a thread group by selecting one or more items (including threads and/or groups) using an on-screen cursor, and activating a “Group” command from a pop-up menu or keyboard command. A new group is created containing the selected items. A temporary name (such as “Unnamed”) is assigned to the group, subject to replacement by the user. The group is placed in the same location in the hierarchy of groups as were the individual items contained in the group. If some of the items of the group are themselves groups, the new thread group is placed in the hierarchy as a child of the parent of one those groups.

[0045] Quantitative information shown in the table of pane 201, describing byte and frame count and the like, is provided for groups. This information represents an aggregate for all items contained within the group. Depending on the nature of the particular data element, the aggregate may represent a minimum, maximum, average, sum, or some other computation based on the values for individual threads within the group. In some cases, a value is shown if there is only one value among all the threads in the group, and the word “Multiple” is shown if there is more than one (for example, if all the threads have the same protocol, the name of the protocol is displayed, but if more than one protocol is present within the group, the word “Multiple” is displayed). The information is dynamically updated whenever the group structure is reorganized by the user.

[0046] The grouping structure is also reflected in pane 208 of FIG. 5. Bar 503 shows, in a graphical form, thread information for Group 501 as a whole. Bar 504 shows thread information for Group 502 as a whole. In this way, the user can see visual representations of thread groups, in any organizational scheme desired.

[0047] Thread groups can be ungrouped. The thread group is removed and all items contained therein become children of the original thread group's parent.

[0048] Thread groups can be renamed by the user if desired, by double-clicking on the name of the group and typing a new name. As described above for thread names, a pop-up menu may also be provided.

[0049] Referring now to FIG. 7, there is shown a block diagram of the software architecture that is used to generate visual thread diagram 200 according to one embodiment of the present invention. Analyzer 101 employs software which performs thread analysis 702 on a source of packets such as packet database 701. This thread analysis 702 creates a thread collection 703 with characteristics that form the base information for visual thread diagram 200. Thread collection 703 stores information describing thread name, source and destination nodes, packets, bytes, start times, durations, and the like.

[0050] Thread analysis 702 includes performing conventional protocol decoding techniques, and then examining individual packets to determine which packets constitute a thread, as defined in relation to a specific application being analyzed. For each application, threads are defined as some significant application-level type of event that occurs in the course of the application. For example, in the World Wide Web environment, the signification application-level type of event could be considered the execution of a GET command.

[0051] Thread analysis 702 further includes recording information about any subsequent packets belonging to the identified thread. This is done for each source/destination node pair seen in the packet trace obtained from packet database 701.

[0052] A number of graphics routines and processes 705-709 are employed to generate diagram 200 from thread collection 703. The current state of the screen display is stored in 704, and this information is also used by the graphics routines. Pop-up manager 705 controls display of pop-up information as described below in connection with FIG. 4. Draw tabular information module 706 performs the graphics functions involved in generating the table in pane 201 of the display. Draw threads module 707 performs the graphics functions involved in drawing bars 205 representing threads. Draw axis module 708 performs the graphics functions involved in drawing the time axis 212. Zoom and scroll handler 709 implements the interactive zooming and scrolling functions. Many of these graphics routines utilize standard graphics application programming interfaces (APIs) 710 as may be provided with the native operating system, such as Windows 95.

[0053] Referring again to FIG. 2, in one embodiment, the user is able to zoom in on selected portions of diagram 200. This is done by drawing a rectangle 206 using an on-screen cursor, to define a zoom area 204 including some portion of pane 208. The user then activates a command (such as releasing a mouse button) and the area defined by the left and right borders of rectangle 206 is expanded to fill pane 208. In one embodiment, this zooming operation does not affect the vertical axis, so that bars 207 would still appear in the zoomed display even though they lie outside the rectangle 206.

[0054] Referring now to FIG. 3, there is shown a screen shot of visual thread diagram 200 after the zooming operation has been completed. Pane 201 is unchanged, but pane 208 has been updated to reflect the zooming operation. Specifically, time axis 212 now shows a range of time specified by the rectangle 206 drawn by the user in FIG. 2. Bars 205 and 213 are updated in accordance with the new time axis 212. In this embodiment, the vertical organization of diagram 200 remains unchanged, so that the same number of threads is shown as in FIG. 2, and the rows of pane 201 and bars of pane 208 retain the same vertical height as in FIG. 2.

[0055] By providing the zooming feature illustrated in FIGS. 2 and 3, the present invention allows the user to focus on particular ranges of time that are of interest, and to see more detailed graphical representations of selected portions of diagram 200.

[0056] Referring now to FIG. 4, there is shown a screen shot of visual thread diagram 200 with pop-up information 401 for a thread. In one embodiment, such pop-up information 401 appears when the user positions an on-screen cursor (not shown) over a bar 205 in pane 208 for a specified length of time. In another embodiment, pop-up information 401 appears when the user positions the cursor over a thread 202 in pane 201. Pop-up information 401 includes detailed information describing the corresponding thread, including for example the name of the thread, start time, duration, number of bytes, number of packets, and average packet size. In one embodiment, the user may configure the system to specify what kind of information is displayed as pop-up information 401.

[0057] The pop-up feature described and illustrated in FIG. 4 allows a user to obtain detailed information for any thread in a quick and easy manner, even if such information is not currently displayed in pane 201. This is particularly useful if pane 201 is implemented as a resizable window pane, so that in certain configurations of the window pane, the user may not be able to see the entire description of a particular thread in pane 201.

[0058] Referring now to FIG. 6, there is shown an example of selecting and sorting operations. When a thread 602 is selected by the user in the table of pane 201 (using an on-screen cursor), it is highlighted using a black border. The corresponding bar 603 in pane 208 is also highlighted. In one embodiment, the user can select bar 603 using the cursor, and the corresponding thread 602 in the pane 201 is highlighted. In addition, FIG. 6 shows an alternative sort order, wherein the user has double-clicked on the header of the Bytes column 605, so that the threads are now sorted by number of bytes. Byte values 604 confirm this order. Similarly, the user could double-click on the header of the Name column 601 to see threads sorted by name. Other mechanisms for changing the sort order for the table of pane 201 may also be provided.

[0059] From the above description, it will be apparent that the invention disclosed herein provides a novel and advantageous user interface and method for visually displaying information about packet traces in a network environment, using thread diagrams. The foregoing discussion discloses and describes merely exemplary methods and embodiments of the present invention. As will be understood by those familiar with the art, the invention may be embodied in other specific forms without departing from the spirit or essential characteristics thereof. Accordingly, the disclosure of the present invention is intended to be illustrative, but not limiting, of the scope of the invention, which is set forth in the following claims.