Anticipating New Network Traffic
Background.
In the last web page we described the seven steps associated with
determining network requirements.
In this page we will go into much more detail about step 5. Step 5 - Characterize New Network Traffic. In the last web page we described the basic outline associated with Step 5 in the bulleted list below.
We will break apart each of these bullets in quite a bit more detail. Broadcast Behavior. Broadcasts are used by many protocols as part of their normal operation. It should be obvious that if networks have too many broadcasts then network performance will degrade. For example, the use of broadcasts and very simple collision prevention in Ethernet is why it is so inefficient at making use of available bandwidth. All hubs and even many switches, operating at layer 2 of the OSI model, forward all broadcasts and multicasts depending on how the broadcasts/multicasts and switches are configured. The NICs at each network station pass broadcasts and relevant multicasts on to the CPU of the station. Some NICs even pass all multicasts onto the CPU of the station. Thus the CPU at a particular station can become overwhelmed when trying to deal with all of the network traffic, much less it's own operations, when trying to determine which broadcasts/multicasts are actually intended for its station. Teare states that CISCO's technical marketing group determined that
Thus, it should be clear that when you design you need to account for the broadcast behavior on the network, particularly on the broadcast behavior of the network protocol. Frame Size. Using frame sizes that are larger can have a significant impact on network performance. This is particularly true for certain sorts of network activity such as file transfers using FTP. For some protocols you can set the MTU - maximum transmission unit. But you also need to make sure if you set the MTU you do not set it to something that is too large for the particular media. If you do you will have an unusual amount of fragmentation and reassembly of the frames. When network devices need to fragment and then reassemble this involves a lot of extra operation overhead and degrades network performance. When working with IP you want use a protocol stack that supports MTU Discovery so that the software can dynamically adjust the largest frame size that will traverse the network without requiring fragmentation. You also need to make sure the technology or MTU Discovery is enabled since it is often disabled by default. The following table is taken from Teare and illustrates what we have just discussed. Though this is not the only way that frame size impacts network performance. |
|
Efficiency Depending on Frame Size |
|||
| Data Size in Bytes | Frame Size in Bytes | Overhead | Maximum Efficiency |
| 1492 | 1518 | 2.5% | 97.2% |
| 974 | 1000 | 3.8% | 96.2% |
| 474 | 500 | 7.4% | 92.6% |
| 38 (no PAD) | 64 (minimum) | 50.0% | 50.0% |
| 1 (plus 37 bytes of PAD) | 64 (minimum) | 98.7% | 1.3% |
| Windowing and Flow Control.
Some protocols, such as Novell's NetWare Core Protocol (NCP) use a "ping-pong"
protocol approach where each request generates a reply.
This is actually a relatively inefficient use of bandwidth.
It is also often possible to send things using a burst mode protocol where a station can send as much data as there is room in the receiver. This availability in the receiver is referred to as the receive window. TCP supports windowing and flow control. UDP - User Datagram Protocol does not support windowing and flow control. Remember, UDP is a connectionless protocol in that it sends data but there are no acknowledgements if it is received or retransmission if any data is lost. Error Recovery. Protocols all have their own ways of recovering after errors occur. If this is not done very effectively it can definitely impact network performance. Data link layer protocols such as Ethernet are connectionless and do not implement error recovery. Network layer protocols such as IP, IPX and AppleTalk's DDP are also connectionless and do not implement error recovery. Even some transport leyer protocols, such as UDP, are connectionless and do not implement error recovery. A connection oriented protocol establishes a connection between the sender and receiver before any data is sent. Error recovery mechanisms for these sorts of protocols vary. Connection oriented protocols exist at all OSI layers. SPX, ATM and Frame Relay are some examples of these sorts of protocols. A good TCP implementation should have adaptive retransmission where the rate of retransmission slows more when the network is more congested. In some instances you can configure retransmission and timeout timers. A protocol analyzer can/should be used to determine whether your customer's protocols implement efficient error recovery. Typical Transmission Sizes. While it is impossible to know the actual sizes of what will be transmitted across the network beforehand, you can get some rough estimates based on different information about what is going to be done on the network. For example, e-mail messages are usually considerably smaller than database accesses. Still images are considerably smaller than animations. You need to gather information about the applications that will be used and develop estimates. It is also the case that their is some inevitable overhead for operating particular data link layer and/or network layer protocols. These overheads are fairly well known and listed in the book. Finally, you also need to consider the impact of workstation initializations on the network. This can impact both well directed packets and broadcast packets which you also need to consider. |