|
|
This chapter discusses the relative performance characteristics of each DLSw+ encapsulation method available for Frame Relay. There is also a discussion about performance differences among the various encapsulation methods and how these differences might affect the decision-making process for network design.
Figure 3-1 compares the performance attributes of each encapsulation method for Frame Relay: TCP/IP, FST, LLC2 passthrough, and LLC2 LACK.
These charts compare response times, transactions per second (Trans/sec), kbps throughput, and raw packets per second (pps) throughput. The response times are expressed in seconds using a transaction defined as 100 bytes in and 100 bytes out. Packet sizes have no bearing on transaction rates or packet throughput. It is a constant per-packet charge regardless of size. Response times and transaction rates reported are derived from the same transaction profile. The packets-per-second reported were derived from a test that sent 100-byte SNA packets as fast as possible from a PC. The kbps throughput reported was derived by simulating an SNA file transfer with 1024 maximum frame sizes. All the tests were run using a CIR of 512 kbps on a single PVC using a pair of Stratacom IPXs as Frame Relay switches.
At remote sites, router performance is rarely an issue. At remote sites the processing power required to fill up low-speed lines is minimal. The remote line, not the CPU in the router, is the bottleneck.
However, at the central site, where there is typically a concentration of multiple high-speed lines (T1 or greater) handling traffic from a large number of remote sites, router performance is an issue. A considerable amount of traffic can flow through central site routers. The processor requirement for SNA features (like DLSw) is high, so it is important to select the correct router for the function it is to perform. It is useful to know how the various encapsulation methods impact performance on the router.
In general, when considering performance, an encapsulation method will fall into one of two major categories: LACK and passthrough. There are notable performance differences between the two. The functional benefits of running LACK are well known and are covered in detail in DLSw+ Design and Implementation Guide. However, the CPU overhead to reap these benefits comes at a cost. LACK terminates two connection-oriented sessions that provide guaranteed delivery service and data sequencing: the LLC session on the LAN and the TCP/IP or LLC session on the WAN. Software overhead to maintain these two sessions is not trivial and results in higher CPU utilization.
In contrast, passthrough modes of encapsulation have only the responsibility to encapsulate the packet and send it. Passthrough modes do not incur the additional CPU overhead of maintaining sessions. The CPU requirements to perform passthrough functions are far less than LACK. In addition, these differences in processor overhead impact the latency introduced by the two encapsulation styles. LACK modes have a higher latency than passthrough modes. Passthrough modes have better response times and higher transaction rates.
The first chart in Figure 3-1 shows how response times for the various encapsulation methods compare to each other. It shows that regardless of the specific encapsulation method, LACK and passthrough display similar properties.
The first chart also highlights another important point with respect to user-perceived response times. The relative differences in response time between LACK and passthrough are significant (roughly three-fold). However, the absolute differences are only on the order of .2 seconds. This amount of time is hardly perceptible to end users. Even in the worst case scenario, with routers running at 100 percent utilization, the difference in response time between LACK and passthrough modes is inconsequential to users. Queuing delays over slow links and congestion impact user-perceived response times.
The transaction rates and packet throughputs in the second chart in Figure 3-1 further demonstrates the impact that latency has on router performance. LACK and passthrough methods once again exhibit similar behavior. Passthrough is capable of significantly greater packet rates due to smaller processing overhead for each packet.
The second chart in Figure 3-1 also shows that file transfer rates are roughly equivalent for all encapsulation methods. This is because the packets are larger in a file transfer so the packet rates are lower. Latency is a per-packet cost so the lower packet rates have a lower total impact on performance. There is also a pipelining effect at the router. While a large packet is getting clocked out of the Frame Relay serial interface, the latency incurred for processing the packet happens in tandem. File transfer rates are affected more by encapsulation overhead on the wire than by latency. This effect is shown in the test results because LLC2 LACK encapsulation has the least overhead and the highest throughput. However, the differences are small and are well within the margin of error for the test. For all practical purposes, any encapsulation method can saturate the line bandwidth (in this test saturation was 512 kbps).
From the previous discussion we can conclude that passthrough modes of operation have about three times the packet-rate capacity of their LACK counterparts. In instances where bandwidth is abundant and CPU scarce, passthrough may be a viable option. However, in most circumstances CPU and performance is not an issue. Tests have shown that a Cisco 4700 router using TCP/IP encapsulation has the capacity to handle 1600 frames per second. This roughly translates to 400 transactions per second. Excluding any batch traffic, if users initiate a single transaction every minute, then a single Cisco 4700 is capable of handing 24,000 users. Modify the modeling parameters to one transaction every two minutes and the number of users double to 48,000. At one transaction every 10 minutes (a feasible scenario), the number raises an order of magnitude to 240,000 users.
To summarize the previous discussion:
|
|