Using a SQL
Application on a Slow WAN Link
Imagine that Company A uses a SQL application for centralized inventory. It was
originally used only at the corporate headquarters; however, it has now become
critical to the core business, and its use has been extended to remote sites.
Unfortunately, because it was developed in a LAN environment, it does not
respond well to delays and packet loss. Assume that it needs 50 Kbps to function
adequately, and that all the remote sites are connected with 256 Kbps serial links.
In the absence of other traffic, the application functions perfectly. However, at
peak times during the day, other applications such as bulk transfers from FTP,
Telnet sessions to the corporate mainframe,Web browsing, and messaging are
periodically filling the link to capacity.With WFQ enabled, some SQL packets
may be dropped in a congestion situation because of the competing conversations.
Remember that all traffic gets its fair share of the bandwidth and its fair
share of packet drops.The drops would cause TCP retransmissions, which could
slow down the SQL application considerably. Because of the SQL application’s
interactive nature, the user’s productivity drops, and he or she comes to you
requesting an upgrade of the link speed. A circuit upgrade might sound like a
good idea if we could get the project funding. However, if we did this, we might
quickly find out that even if we doubled the circuit speed, the company’s critical
application might still not achieve the performance it requires. IP networks work
in bursts, and even the largest pipes can momentarily become saturated.
One solution would be to configure a class for the SQL application.The SQL
traffic could be classified by the TCP port number of incoming packets. By
applying a policy to the output of the serial interface allocating 50 Kbps to this
www.syngress.com
Advanced QoS for AVVID Environments • Chapter 8 241
class, we could guarantee that even during the busiest part of the day, this application
would be given the amount of bandwidth needed for good performance. In
addition, all other traffic could be configured to function under flow-based WFQ
so all conversations would have fair access to the remaining bandwidth.
In effect, we have carved out a slice of the serial bandwidth for the SQL
application but also allowed it to use more than this amount, although its use
above 50 Kbps would not be guaranteed. In addition, other applications can use
the reserved 50 Kbps when SQL is not using it. Remember, CBWFQ does not
function unless there is congestion.