ult (Ref. 3), describes four steps to correct network faults. These are: 1. Observing symptoms 2. Developing an hypothesis 3. Testing the hypothesis 4. Forming conclusions 21.4.1.1 Observing Symptoms. It should be kept in mind that often many symptoms will appear at once, usually a chain reaction. We must be able to spot the real causal culprit or we may spend hours or even days chasing effects, not the root cause. The reference article suggests these four reminders: 1. Find the range and scope of the symptoms. Does the problem affect all stations (all users)? Does it affect random users or users in a given area? We're looking for an area pattern here. 2. Are there some temporal conditions to the problem? How often does it occur per day, per hour, and SO on? Is the problem continuous or intermittent? What is its regularity? Can we set our watches by its occurrence or is it random in the tempo- ral context? 3. Have there been recent rearrangements, additions to the network, reconfigurations? 4. Software and hardware have different vintages what are called release dates. I write this on WordPerfect 7.0, but what was its release date? The question one should ask then would be, Are all items of a certain genre affected in the same way? Different release dates of a workstation may be affected differently, some release dates not at all. The problem may be peculiar to a certain release date. This is particularly true of software. Before we can move forward in the troubleshooting analysis, we must have firmly at hand the troublesome network's baseline performance. What is meant here is that we must have a clear idea of "normal" operation of the network SO that we can really qualify and quantify its anomalous operation. For example, what is the expected BER and is the value related to a time distribution? Can we express error performance in EFS (error free seconds), ES (errored seconds), and SES (severely errored seconds)? These are defined in ITU-T Rec. G.821 (Ref. 4). 2We define an event as something out-of-the-ordinary