`
`PCT /US92/02995
`
`- 53 -
`
`segment Local Area Net~ork" filed on January 14, 1991
`(Attorney Docket No. 13283-NE.APP), incorporated herein
`by reference.
`In normal operation, each station in the network
`5 is monitored by a single Monitor that is located on its
`local segment. The initial determination of the Monitor
`responsible for a station is based on the results of the
`autotopology mechanism. The user may override this
`initial default if required.
`The user is informed of new stations appearing on
`any segment in the network via the alarm mechanism. As
`for other alarms, the user may select whether stations
`appearing on and disappearing from the network segment .
`generate alarms and may modify the times used in the
`15 aging algorithms. When a new node alarm occurs, the user
`must add the new alarm to the map using the SNM tools.
`In this manner, the SNM system becomes aware of the
`nodes.
`
`10
`
`2.
`
`The sequence of events following the detection of
`20 a new node is:
`the location of the node is determined
`1.
`automatically for the user.
`the Monitor generates an alarm for the
`user indicating the new node and providing
`some or all of the following information:
`mac address of node
`ip address of node
`segment that the node is believed to
`be
`
`25
`
`30
`
`located on
`Monitor to be responsible for the
`node
`the user must select the segment and add
`the node manually using the SNM editor
`
`3.
`
`SKY PE-N2P00284056
`
`Samsung - Exhibit 1022 - Page 501
`
`
`
`W092/19054
`
`PCf/US92/0l995
`
`- 54 -
`
`5
`
`.)
`
`4. The update to the SNM database will be
`detected and the file reread. The
`Workstation database is reconstructed and
`the parse control records for the Monitors
`updated if required.
`5. The Monitor responsible for the new node
`has its parse control record updated via
`SNMP set request(s).
`An internal record of new nodes is required for
`10 the autotopology. When a new node is reported by a
`Network Monitor, the Management Workstation needs to have
`the previous location information in order to know which
`Network Monitors to involve in autotopology. For
`example, two nodes with the same IP address may exist in
`15 separate segments of the network. The history makes
`possible the correlation of the addresses and it makes
`possible duplicate address detection.
`Before a new Monitor can communicate with the
`Management Workstation via SNMP it needs to be added to
`20 the SNM system files. As the SNM files are cached in the
`database, the file must be updated and the SNM system
`forced to reread it.
`Thus, on the detection of a new Monitor the
`following events need to occur in order to add the
`25 Monitor to the Workstation:
`1. The Monitor issues a trap to the
`Management Workstation software and
`requests code to be loaded from the sun
`Microsystems boot/load server.
`2. The code load fails as the Monitor is not
`known to the unix networking software at
`this time.
`3. The Workstation confirms that the new
`Monitor does not exceed the configured
`system limits (e.g. 5 Monitors per
`
`30
`
`35
`
`SKYPE-N2P00284057
`
`Samsung - Exhibit 1022 - Page 502
`
`
`
`wo 92/19054
`
`PCf/US92102995
`
`5
`
`10
`
`- 55 -
`Workstation) a~d terminates the
`initialization sequence if limits are
`exceeded. An alarm is issued to the user
`indicating the presence of the new Monitor
`and whether it can be supported.
`4 • The user adds the Monitor to the
`SNMP.HOSTS file of the SNM system, to the
`etc/hosts file of the Unix networking
`system and to the SNM map.
`5. When the files have been updated the user
`resets the Monitor using the set tool
`(described later).
`6. The Monitor again issues a trap to the
`Management Workstation software and
`requests code to be loaded from the Sun
`boottload server.
`7. The code load takes place and the Monitor
`issues a trap requesting data from the
`Management Workstation.
`8. The Monitor data is issued using SNMP set
`requests.
`Note that on receiving the set request, the SNMP proxy
`rereads in the (updated) SNMP.HOSTS file which now
`includes the new Monitor. Also note that the sHMP· hosts
`25 file need only contain the Monitors, not the entire list
`of nodes in the system.
`on completion of the set request(s) the Monitor
`9.
`run command is issued by the Workstation to bring
`the Monitor on line.
`The user is responsible for entering data into the
`SNM database manually. During operation, the Workstation
`monitors the file write date for the SNM database. When
`this is different from the last date read, the SNM
`database is reread and the Workstation database
`35 reconstructed.
`In this manner, user updates to the SNM
`
`15
`
`20
`
`30
`
`SKYPE-N2P00284058
`
`Samsung - Exhibit 1022 - Page 503
`
`
`
`wo 92/19054
`
`PCf/US92102995
`
`- 56 -
`
`database are incorporated into the Workstation database
`as quickly as possible without need for the user to take
`any action.
`When the Workstation is loaded, the database is
`5 created from the data in the SNM file system (which the
`user has possibly updated). This data is checked for
`consistency and for conformance to the limits imposed by
`the Workstation at this time and a warning is generated
`to the user if any problems are seen. If the data errors
`~0 are minor the system continues operation; if they are
`fatal the user is asked to correct them and Workstation
`operation terminates.
`The monitoring functions of the Management
`Workstation are provided as an extension to the SNM
`15 system. They consist of additional display tools (i.e.,
`summary tool, values tool, and set tool) which the user
`invokes to access the Monitor options and a Workstation
`event loq in which all alarms are recorded.
`As a result of the monitoring process, the Monitor
`20 makes a l~rge number of statistics available to the
`operator. These are available for examination via the
`Workstation tools that are provided.
`In addition, the
`Monitor statistics (or a selected subset thereof) can be
`made visible to any SNMP manager by providing it with
`25 knowledge of the extended MIB. A description of the
`statistics maintained are described elswhere.
`Network event statistics are maintained on a per
`network, per segment and per node basis. Within a node,
`statistics are maintained on a per address (as
`30 appropriate to the protocol layer - IP address, port
`number, ••• ) and per connection basis. Per network
`statistics are always derived by the Workstation from the
`per segment variables maintained by the Monitors.
`Subsets of the basic statistics are maintained on a node
`35 to node and segment to segment basis.
`
`SK YPE-N2P00284059
`
`Samsung - Exhibit 1022 - Page 504
`
`
`
`W092/19054
`
`PCf /US92/02995
`
`- 57 -
`
`If the user requests displays of segment to
`segment traffic, the Workstation calculates this data as
`follows. The inter segment traffic is derived from the
`node to node statistics for the intersecting set of
`5 nodes. Thus, if segment A has nodes 1, 2, and 3 and
`segment B has nodes 20, 21, and 22, then summing the node
`to node traffic for
`1 -> 20,21,22
`2 -> 20,21,22
`3 -> 20~21,22
`produces the required result. On-LAN/off-LAN traffic for
`segments is calculated by a simply summing node to node
`traffic for all stations on the LAN and then subtracting
`this from total segment counts.
`Alarms are reported to the user in the following
`
`10
`
`15
`
`ways:
`1.
`2.
`
`20 3.
`
`Alarms received are logged in a Workstation log.
`The node which the alarm relates to is highlighted
`on the map.
`The node status change is propagated up through
`the (map) hierarchy to support the case where the
`node is not visible on the screen. This is as
`provided by SNM.
`summary Tool
`After the user has selected an object from the map
`and invokes the display tools, the summary tool generates
`the user's initial screen at the Management Workstation.
`It presents a set of statistical data selected to give an
`overview of the operational status of the object (e.g., a
`30 selected node or segment). The Workstation polls the
`Monitor for the data required by the Summary Tool display
`screens.
`The Summary Tool displays a basic summary tool
`screen such as is shown in Fig. 18. The summary tool
`35 screen has three panels, namely, a control panel 602, a
`
`25
`
`SKYPE-N2P00284060
`
`Samsung - Exhibit 1022 - Page 505
`
`
`
`W092/19054
`
`PCT/US92/02995
`
`- 58 -
`
`values panel 604, and_a dialogs panel 606. The control
`panel includes the indicated mouse activated bottons.
`The functions of each of the buttons is. as follows. The
`file button invokes a traditional file menu. The view
`5 button invokes a view menu which allows the user to
`modify or tailor the visual protperties of the tool. The
`properties button invokes a properties menu containing
`choices for viewing and sometimes modifying the
`properties of objects. -The tools button invokes a tools
`10 menu which provides access to the other Workstation
`tools, e.g. Values Tool.
`The Update rnterval field allows the user to
`specify the frequency at which the displayed statistics
`are updated by polling the Monitor. The Update Once
`15 button enables the user to retrieve a single screen
`update. When the Update Once button is invoked not only
`is the screen updated but the update interval is
`automatically set to "none".
`The type field enables the user to specify the
`20 type of network objects on which to operate, i.e.,
`seqment or node.
`The name button invokes a pop up menu containing
`an alphabetical list of all network objects of the type
`selected and apply and reset buttons. The required name
`25 can then be selected from the (scrolling) list and it
`will be entered in the name field of the summary tool
`when the apply button is invoked. Alternatively, the
`user may enter the name directly in the summary tool name
`field.
`
`30
`
`The protocol button invokes a pop up menu which
`provides an exclusive set of protocol layers which the
`user may select. Selection of a layer copies the layer
`name into the displayed field of the summary tool when
`the apply operation is invoked. An example of a protocol
`35 selection menu is shown in Fig. 19. It displays the
`
`SKYPE-N2P00284061
`
`Samsung - Exhibit 1022 - Page 506
`
`
`
`"
`
`W092/190S4
`
`PCf/US92102995
`
`- 59 -
`
`available protocols in. the form of a protocol tree with
`multiple protocol familes. The protocol selection is two
`dimensional. That is, the user first selects the
`protocol family and then the particular layer within that
`5 family.
`
`As indicated by the protocol trees shown in Fig.
`19, the capabilities of the Monitor can be readily
`extended to handle other protocol families. The
`particular ones which are implemented depend upon the
`10 needs of the particular network environment in which the
`Monitor will operate.
`The user invokes the apply button to indicate that
`the selection process is complete and the type, name,
`protocol, etc. should be applied. This then updates the
`15 screen using the new parameter set that the user
`selected. The reset button is used to undo the
`selections and restore them to their values at the last
`apply operation.
`The set of statistics for the selected parameter
`20 set is displayed in values panel 604. The members of the
`sets differ depending upon, for example, what protocol
`was selected. Figs. 20a-q present examples of the types
`of statistical variables which are displayed for the DLL,
`IP, UDP, TCP, ICMP, NFS, and ARP/RARP protocols,
`25 respectively. The meaninq of the values display fields
`are described in Appendix I, attached hereto.
`Dialogs panel 606 contains a display of the
`connection statistics for all protocols for a selected
`node. Within the Management workstation, connection
`30 lists are maintained per node, per supported protocol.
`When connections are displayed, they are sorted on 11Last
`Seen 11 with the most current displayed first. A single
`list returned from the Monitor contains all current
`connection. For TCP, however, each connection also.
`35 contains a state and TCP connections are displayed as
`
`SKY P £-N2P00284062
`
`Samsung - Exhibit 1022 - Page 507
`
`
`
`W092/l9054
`
`PCT/US92/02995
`
`- 60 -
`
`10
`
`Past and Present based ~pon the returned state of the
`connection. For certain di~logs, such as TCP and NFS
`over UDP, there is an associated direction to the dialog,
`i.e., from the initiator (source) to the receiver (sink).
`5 For these dialogs, the direction is identified in a DIR.
`field. A sample of information that is displayed in
`dialogs panel 606 is presented in Fig. 21 for current
`connections.
`Values Tool
`The values tool provides the user with the ability
`to look at the statistical database for a network object
`in detail. When the user invokes this tool, he may
`select a basic data screen containing a rate values panel
`620, a count values panel 622 and a protocols seen panel
`15 626, as shown in Fig. 22, or he may select a traffic
`matrix screen 628, as illustrated in Fig. 23.
`In rate values and count values panels 620 and
`622, value tools presents the monitored rate and count
`statistics, respectively, for a selected protocol. The
`20 parameters which are displayed for the different
`protocols (i.e., different groups) are listed in Appendix
`II.
`In general, a data element that is being displayed
`for a node shows up in three rows, namely, a total for
`the data element, the number into the data element, and
`25 the number out of the data element. Any exceptions to
`this are identified in Appendix II. Data elements that
`are displayed for segments, are presented as totals only,
`with no distinction between RX and Tx.
`When invoked the Values Tool displays a primary
`30 screen to the user. The primary screen contains what is
`considered to be the most significant information for the
`selected object. The user can view other information for
`the object (i.e., the statistics for the other
`parameters) by scrolling down.
`
`SKY PE-N2P00284063
`
`Samsung - Exhibit 1022 - Page 508
`
`
`
`W092119054
`
`PCT/US92/02995
`
`- 61 -
`
`The displayed information for the count values and
`rate values panels 620 and 622 includes the following.
`An alarm field reports whether an alarm is currently
`active for this item. It displays as "*" if active alarm
`5 is present. A current Value/Rate field reports the
`current rate or the value of the counter used to generate
`threshold alarms for this item. This is reset following
`each threshold trigger and thus gives an idea of how
`close to an alarm threshold the variable is. A Typical
`10 Value field reports what this item could be expected to
`read in a "normal" operating situation. This field is
`filled in for those items where this is predictable and
`useful. It is maintained in the Workstation database and
`is modifiable by the user using the set tool. An
`15 Accumulated Count field reports the current accumulated
`value of the item or the current rate. A Max Value field
`reports the highest value recently seen for the item.
`This value is reset at intervals defined by a user
`adjustable parameter (default 30 minutes). This is not a
`20 rolling cycle but rather represents the highest value
`since it was reset which may be from 1 to 30 minutes ago
`(for a rest period of 30 minutes). It is used only for
`rates. A Min Value field reports the lowest value
`recently seen for the item. This operates in the same
`25 manner as Max Value field and is used only for rates.
`A Percent (%) field reports only for the following
`variables:
`off seg counts:
`100(in count 1 total off seg count)
`100(out count 1 total off seg count)
`lOO(transit count I total off seg count)
`100(local count I total off seg count)
`off seq rates
`100(transit rate 1 total off seg rate), etc.
`protocols
`
`30
`
`35
`
`SKYPE-N2P00284064
`
`Samsung - Exhibit 1022 - Page 509
`
`
`
`W092/19054
`
`PCf/US92/0l995
`
`- 62 -
`100(frame.rate this protocol J total frame
`rate)
`On the right half of the basic display, there the
`following addtional fields: a High Threshold field and a
`5 Sample period for rates field.
`Set Tool
`The set tool provides the user with the ability to
`modify the parameters controlinq the operation of the
`Monitors and the Management Workstation. These
`10 parameters affect both user interface displays and the
`actual operation of the Monitors. The parameters which
`can be operated on by the set tool can be divided into
`the following categories: alarm thresholds, monitoring
`control, segment Monitor administration, and typical
`15 values.
`
`The monitoring control variables specify the
`actions of the segment Monitors and each Monitor can have
`a distinct set of control variables (e.g., the parse
`control records that are described elsewhere). The user
`20 is able to define those nodes, segments, dialogs and
`protocols in which he is interested so as to make the
`best use of memory space available for data storage.
`This mechanism allows for load sharing, where mulitple
`Monitors on the same segment can divide up the total
`25 number of network objects which are to be monitored so
`that no duplication of effort between them takes place.
`The monitor administration variables allow the
`to modify the operation of the segment Monitor in a
`user
`more direct manner than the monitoring control variables.
`30 Using the set tool, the user can perform those operations
`such as reset, time changes etc. which are normally the
`prerogative of a system administrator.
`Note that the above descriptions of the tools
`available through the Management Workstation are not
`35 meant to imply that other choices may not be made
`
`SKY PE-N2P00284065
`
`Samsung - Exhibit 1022 - Page 510
`
`
`
`W092/19054
`
`PCf/US92/02995
`
`- 63 -
`
`regarding the particu~ar information which is displayed
`and the manner in which it is displayed.
`Adaptiyely setting Network Monitor Tbresholds:
`The Workstation sets the thresholds in the Network
`5 Monitor based upon the performance of the system as
`observed over an extended period of time. That is, the
`Workstation periodically samples the output of the
`Network Monitors and assembles a model of a normally
`functioning network. Then, the Workstation sets the
`10 thresholds in the Network Monitors based upon that model.
`If the observation period is chosen to be long enough and
`since the model represents the "average" of the network
`performance over the observation period, temporary
`undesired deviations from normal behavior are smoothed
`15 out over time and model tends to accurately reflect
`normal network behavior.
`Referring the Fig. 24, the details of the training
`procedure for adaptively setting the Network Monitor
`thresholds are as follows. To begin training, the
`20 Workstation sends a start learning command to the Network
`Monitors from which performance data is desired (step
`302). The start learning command disables the thresholds
`within the Network Monitor and causes the Network Monitor
`to periodically send data for a predefined set of network
`25 parameters to the Management Workstation.
`(Disabling the
`thresholds, however, is not necessary. One could have
`the learning mode operational in parallel with monitoring
`using existing thresholds.) The set of parameters may be
`any or all of the previously mentioned parameters for
`30 which thresholds are or may be defined.
`Throughout the learning period, the Network
`Monitor sends "snapshots" of the network's performance to
`the Workstation which, in turn, stores the data in a
`performance history database 306 (step 304). The network
`35 manager sets the length of the learning period.
`
`SKYPE-N2P00284066
`
`Samsung - Exhibit 1022 - Page 511
`
`
`
`W09l/19054
`
`PCf/US92/0l995
`
`- 64 -
`
`Typically, it should be.long enough to include the full
`range of load conditions that the network experiences so
`that a representative performance history is generated.
`It should also be long enough so that short periods of
`5 overload or faulty behavior do not distort the resulting
`averages.
`After the learning period has expired, the network
`manager, through the Management Workstation, sends a stop
`learning command to the Monitor (step 308). The Monitor
`10 ceases automatically sending further performance data
`updates to the Workstation and the Workstation processes
`the data in its performance history database (step 310).
`The processing may involve simply computing averages for
`the parameters of interest or it may involve more
`15 sophisticated statistical analysis of the data, such as
`computing means, standard deviations, maximum and minimum
`values, or using curve fitting to compute rates and other·
`pertinent parameter values.
`After the Workstation has statistically analyzed
`20 the performance data, it computes a new set of thresholds
`for the relevant performance parameters (step 312). To
`do this, it uses formulas which are appropriate to the
`particular parameter for which a threshold is being
`computed. That is, if the parameter is one for which one
`25 would expect to see wide variations in its value during
`network monitoring, then the threshold should be set high
`enough so that the normal expected variations do not
`trigger alarms. on the other hand, if the parameter is
`of a type for which only small variations are expected
`30 and larger variations indicate a problem, then the
`threshold should be set to a value that is close to the
`average observed value. Examples of formulae which may
`be used to compute thresholds are:
`Highest value seen during learning period;
`*
`
`!
`
`SKYPE-N2P00284067
`
`Samsung - Exhibit 1022 - Page 512
`
`
`
`W09Z/l9054
`
`PCf/US92/0299S.
`
`- 65 -
`
`*
`
`*
`
`*
`*
`
`*
`
`5
`
`10
`
`Highest value seen during learning period +
`10,;
`Highest value seen during learning period +
`SO%;
`Highest value seen during learning period +
`user-defined percent;
`Any value of the parameter other than zero;
`Average value seen during learning period +
`sot; and
`Average value seen during learning period +
`user-defined percent.
`As should be evident from these examples, there is a
`broad range of possibilities regarding how to compute a
`particular threshold. The choice, however, should
`15 reflect the parameter's importance in signaling serious
`network problems and its normal expected behavior (as may
`be evidenced from the performance history acquired for
`the parameter during the learning mode).
`After the thresholds are computed, the Workstation
`20 loads them into the Monitor and instructs the Monitor to
`revert to normal monitoring using the new thresholds
`(step 314).
`This procedure provides a mechanism enabling the
`network manager to adaptively reset thresholds in
`25 response to changing conditions on the network, shifting
`usage patterns and evolving network topology. As the
`network changes over time, the network manager merely
`invokes the adaptive threshold setting feature and
`updates the thresholds to reflect those changes.
`30 The Diagnostic Analyzer Module:
`The Management Workstation includes a diagnostic
`analyzer module which automatically detects and diagnoses
`the existence and cause of certain types of network
`problems. The functions of the diagnostic module may
`35 actually be distributed among the Workstation and the
`
`SKYPE-N2P00284068
`
`Samsung - Exhibit 1022 - Page 513
`
`
`
`W092119054
`
`PCI'/US9Z/02995
`
`- 66 -
`
`5
`
`In
`Network Monitors which are active on the network.
`principle, the diagnostic analyzer module includes the
`following elements for performing its fault detection and
`analysis functions.
`The Management Workstation contains a reference
`model of a normally operating network. The reference
`model is generated by observing the performance of the
`network over an extended period of time and computing
`averages of the performance statistics that were observed
`10 during the observation period. The reference model
`provides a reference against which future network
`performance can be compared so as to diagnose and analyze
`potential problems. The Network Monitor (in particular,
`the STATS module) includes alarm thresholds on a selected
`15 set of the parameters which it monitors. Some of those
`thresholds are set on parameters which tend to be
`indicative of the onset or the presence of particular
`network problems.
`During monitoring, when a Monitor threshold is
`20 exceeded, thereby ingicating a potential problem (e.g. in
`a TCP connection), the Network Monitor alerts the
`Workstation by sending an alarm. The Workstation
`notifies the user and presents the user with the option
`of either ignoring the alarm or invoking a diagnostic
`25 algorithm to analyze the problem.
`If the user invokes
`the diagnostic algorithm, the Workstation compares the
`current performance statistics to its reference model to
`analyze the problem and report its results.
`(Of course,
`this may also be handled automatically so as to not
`30 require user intervention.) The Workstation obtains the
`data on current performance of the network by retrieving
`the relevant performance statistics from all of the
`segment Network Monitors that may have information useful
`to diagnosing the problem.
`
`SKYPE-N2P00284069
`
`Samsung - Exhibit 1022 - Page 514
`
`
`
`W092/J90S4
`
`PCT/US92/02995
`
`- 67 -
`
`The details of a specific example involving poor
`TCP connection performance will now be described. This
`example refers to a typical network on which the
`diagnostic analyzer resides., such as the network
`5 illustrated in Fig. 25. It includes three segments
`labelled Sl, S2, and SJ, a router Rl connecting Sl to s2,
`a router R2 connecting 52 to SJ, and at least two nodes,
`node A on Sl which communicates with node B on S3. On
`each segment there is also a Network Monitor 324 to
`10 observe the performance of its segment in the manner
`described earlier. A Management Workstation 320 is also
`located on Sl and it includes a diagnostic analyzer
`module 322. For this example, the sympton of the network
`problem is degraded peformance of a TCP connection
`15 between Nodes A and B.
`A TCP connection problem may manifest itself in a
`number of ways, including, for example, excessively high
`numbers for any of the following:
`errors
`packets with bad sequence numbers
`packets retransmitted
`bytes retransmitted
`out of order packets
`out of order bytes
`packets after window closed
`bytes after window closed
`average and maximum round trip times
`or by an unusually low value for the current window size.
`By setting the appropriate thresholds, the Monitor is
`30 programmed to recognize any one or more of these
`symptons.
`If any one of of the thresholds is exceeded,
`the Monitor sends an alarm to the Workstation. The
`Workstation is programmed to recognize the particular
`alarm as related to an event which can be further
`35 analyzed by its diagnostic analyzer module 322. Thus,
`
`20
`
`25
`
`..
`
`SKY PE-N2P00284070
`
`Samsung - Exhibit 1022 - Page 515
`
`
`
`. wo 92/19054
`
`PCT/US92/02995
`
`- 68 -
`
`5
`
`the Workstation presents the user with the option of
`invoking its diagnostic capabilities (or automatically
`invokes the diagnostic capabilities).
`In general terms, when the diagnostic analyzer is
`invoked, it looks at the performance data that the
`segment Monitors produce for the two nodes, for the
`dialogs between them and for the links that interconnect
`them and compares that data to the reference model for
`the network.
`If a significant divergence from the
`10 reference model is identified, the diagnostic analyzer
`informs the Workstation (and the user) about the nature
`of the divergence and the likely cause of the problem.
`In conducting the comparison to "normal" network
`performance, the network circuit involved in
`15 communications between nodes A and B is decomposed into
`its individual components and diagnostic analysis is
`performed on each link individually in the effort to
`isolate the problem further.
`The overall structure of the diagnostic algorithm
`20 400 is shown in Fig. 26. When invoked for analyzing a
`possible TCP problem between nodes A and B, diagnostic
`analyzer 322 checks for a TCP problem at node A when it
`is acting as a source node (step 402). To perform this
`check, diagnostic algorithm 400 invokes a source node
`25 analyzer algorithm 450 shown in Fig. 27.
`If a problem is
`identified, the Workstation reports that there is a high
`probability that node A is causing a TCP problem when
`operating as a source node and it reports the results of
`the investigation performed by algorithm 450 (step 404).
`If node A does not appear to be experiencing a TCP
`problem when acting as a source node, diagnostic analyzer
`322 checks for evidence of a TCP problem at node B when
`it is acting as a sink node (step 406). To perform this
`check, diagnostic algorithm 400 invokes a sink node
`35 analyzer algorithm 470 shown in Fig. 28.
`If a problem is
`
`30
`
`SKYPE-N2P00284071
`
`Samsung - Exhibit 1022 - Page 516
`
`
`
`wo 92/19054
`
`PCT/US92/02995
`
`- 69 -
`
`5
`
`identified, the Workst~tion reports that there is a high
`probability that node B is causing a TCP problem when
`operating as a sink node and it reports .the results of
`the investigation performed by algorithm 470 (step 408).
`Note that source and sink nodes are concepts which
`apply to those dialogs for which a direction of the
`communication can be defined. For example, the source
`node may be the one which initiated the dialog for the
`purpose of sending data to the other node, i.e., the sink
`10 node.
`
`If node B does not appear to be experiencing a TCP
`problem when acting as a sink node, diagnostic analyzer
`322 checks for evidence of a TCP problem on the link
`between Node A and Node B (step 410). To perform this
`15 check, diagnostic algorithm 400 invokes a link analysis
`algorithm 550 shown in Fig. 29.
`If a problem is
`identified, the Workstation reports that there is a high
`probability that a TCP problem exists on the link and it
`reports the results of the investigation performed by
`20 link analysis algorithm 550. (step 412).
`If the link does not appear to be experiencing a
`TCP problem, diagnostic analyzer 322 checks for evidence
`of a TCP problem at node B when it is acting as a source
`node (step 414). To perform this check, diagnostic
`25 algorithm 400 invokes the previously mentioned source
`algorithm 450 for Node B.
`If a problem is identified,
`the Workstation reports that there is a medium
`probability that node B is causing a TCP problem when
`operating as a source node and it reports the results of
`30 the investigation performed by algorithm 450 (step 416).
`If node B does not appear to be experiencing a TCP
`problem when acting as a source node, diagnostic analyzer
`322 checks for a TCP problem at node A when it is acting
`as a sink node (step 418). To perform this check,
`35 diagnostic algorithm 400 invokes sink node analyzer
`
`SKYPE-N2P00284072
`
`Samsung - Exhibit 1022 - Page 517
`
`
`
`W09l/19054
`
`PCI'/US92/0l99S
`
`- 70 -
`
`10
`
`If a problem is identified,
`algorithm 470 for Node A.
`the Network Monitor reports that there is a medium
`probability that node A is causing a TCP problem when
`operating as a sink node and it reports the results of
`5 the investigation performed by algorithm 470 (step 420).
`Finally, if node A does not appear to be
`experiencing a TCP problem when acting as a sink node,
`diagnostic analyzer 322 reports that it was not able to
`isolate the cause of a TCP problem (step 422).
`The algorithms which are called from within the
`above-described diagnostic algorithm will now be
`described. Referring to Fig. 27, source node analyzer
`algorithm 450 checks whether a particular node is causing
`a TCP problem when operating as a source node. The
`15 strategy is as follows. To determine whether a TCP
`problem exists at this node which is the source node for
`the TCP connection, look at other connections for which
`this node is a source. If other TCP connections are
`okay, then there is probably not a problem with this
`20 node. This is an easy check with a high probability of
`being correct. If no other good connections exist, then
`look at the lower layers for possible reasons. Start at
`DLL and work up as problems at lower layers are more
`fundamental, i.e., they cause problems at higher layers
`25 whereas the reverse is not true.
`In accordance with this approach, algorithm 450
`first determines whether the node is acting as a source
`node in any other TCP connection and, if so, whether the
`other connection is okay (step 452).
`If the node is
`30 performing satisfactorily as a source node in another TCP
`connection, algorithm 450 reports that there is no
`problem at the source node and returns to diagnostic
`algorithm 400 (step 454).
`If algorithm 450 cannot
`identify any other TCP connections involving this node
`35 that are okay, it moves up through the protocol stack
`
`