Author: Neftaly Malatjie

While this is an excellent approach for building networks, the layered approach falls short in cooperative error reporting. Applications generally must work independently of the network environment, and lower layers of the network do not generally report meaningful errors to upper layer applications. The result is that lower layer network problems can cause upper layer application problems without giving any information about why the errors are occurring.

Applications do not have sophisticated methods for identifying and correcting network related errors. Because specific problems are not identified for the application by the network, no corrective action can be taken. This results in confusion and frustration for consumers, who must then call support professionals to help solve their application problems.

Support professionals must then embark on one of two strategies, depending on accessibility of the machine. One, spend time teaching the consumer command line utilities such as PING, Telnet, and others (frequently used by phone support) or Two, ask the user to allow the support professional to work at the machine while the consumer/user does something else during the troubleshooting process (frequently used by onsite support).

In both cases, fixing network related problems in a timely fashion requires methodical troubleshooting techniques. The first critical step is gathering information about the consumer’s machine. The second critical step is identifying what works and what doesn’t. Many of the tools and techniques used in this process only frustrate a consumer who is not interested in the command line tools and interfaces that are necessary to solve the problem. On the other hand, support professionals generally prefer command line utilities for their speed and batch capabilities.

Question How does the support professional gather the required information unobtrusively and solve the actual problem in a timely fashion, assuring a satisfactory customer experience?

The answer is the new suite of Network Diagnostics Tools. For consumers, there are new graphical HTML–based and windows based tools that are simple to click and use, and for administrators, there are still command line tools for batch execution and scripts. This new suite of tools is effective for both the consumer and the administrator.

Regardless of which Network Diagnostics tool is run, the support professional and consumer will find useful information or the immediate resolution to a problem. These tools help eliminate the necessity for consumers to ever have to use a command line utility, while also providing command line tools for the administrator, making the troubleshooting experience easier for everyone.

Diagnosing network related problems can consume a considerable amount of time and lead to frustration for consumers not trained as network experts. Network problems can be the result of a wide range of issues, from minimal disruptions in service to simple configuration problems of the operating system. In order to tackle network problems, the computer industry leans heavily toward a layered network approach, known as the ISO/OSI (International Organization for Standardization Open System Interconnection) model. Another model used is the standard TCP/IP model, also a layered network approach. The layers of both models are shown below in Figure 1. The stratification of the network allows a programmer to focus on a layer within a model, without having to understand the layers above or below.

Figure 3: The transmission overhead against packet size for message length 1000.

We define the transmission overhead to be the number of bits, communicated for a message, that do not represent the data bits of the message. In particular, packet headers and acknowledge packets determine the transmission overhead. Most forms of serial communication use encoding, e.g., adding stop bits, to ensure that the receiving side correctly interprets the serial bit stream. DS links use an encoding scheme that extends each byte, 8 bits, to a 10 bit token. The transmission overhead is therefore at least 20 %.

Figure 2 shows the format of data and acknowledgement packets that we use for the DSNIC protocol. It shows that, apart from the DS link routing header, three characters are used for protocol specific information, independent of the payload size. Together with the acknowledgement scheme, this allows us to calculate the transmission overhead for different packet sizes. Figure 3 shows the transmission overhead against packet size, or, more precisely, against payload size, for sending a 1000 byte message. The packet size strongly influences the required number of packets and packet headers, and thereby the transmission overhead.

Figure 4: The maximum network throughput versus packet size.

Figure 4 shows the influence of the packet size on the maximum network throughput for a 512 end-node Clos network under random traffic. This graph shows an optimal network throughput for packet size 28. For packets smaller than 28, the network throughput drops due to the domination of the transmission overhead. For packets larger than the optimum, the network throughput becomes worse due to network congestion.

The header of each packet needs to be processed by the DSNIC. This processing requires time. Using a small packet size, such as the optimal 28, requires a lot of processing to achieve full bandwidth communication. To keep this processing from becoming the system’s bottleneck, we choose not to fix the packet size, but to make it adaptable so that its influence on the performance of the DSNIC can be investigated. We only support powers of two for the packet size to accommodate the implementation.

A network is congested when one or more network components must discard packets due to lack of buffer space. Given the above architecture, it is possible to see how network congestion can occur. A source of data flow on the network cannot reserve bandwidth across the network to its data’s destination. It, therefore, is unable to determine what rate of data flow can be sustained between it and the destination.

If a source transmits data at a rate too high to be sustained between it and the destination, one or more routers will begin to queue the packets in their buffers. If the queueing continues, the buffers will become full and packets from the source will be discarded, causing data loss. If the source is attempting to guarantee transmission reliability, retransmission of data and increased transmission time between the source and the destination is the result. Figure 2 from [Jain & Ramakrishnan 88] demonstrates the problem of congestion.

As the load (rate of data transmitted) through the network increases, the throughput (rate of data reaching the destination) increases linearly. However, as the load reaches the network’s capacity, the buffers in the routers begin to fill. This increases the response time (time for data to traverse the network between source and destination) and lowers the throughput.

Once the routers’ buffers begin to overflow, packet loss occurs. Increases in load beyond this point increase the probability of packet loss. Under extreme load, response time approaches infinity and the throughput approaches zero; this is the point of congestion collapse. This point is known as the cliff due to the extreme drop in throughput. Figure 2 also shows a plot of power, defined as the ratio of throughput to response time. The power peaks at the knee of the figure.

The credit value of this unit standard is calculated assuming a person has the prior knowledge and skills to:

• Demonstrate an understanding of issues affecting the management of a local area computer network (LAN).