Tuning PCs for Optimum DSL Performance

March 12, 2001 -- You receive an order for DSL service. You go through the service order process for a copper pair from your incumbent, test the line, visit the customer, install the modem, configure TCP/IP settings on the customer's PC, check that service is "up and billable" and leave a seemingly happy customer to experience the world wide without wait.

Shortly thereafter, your help desk receives a complaint from the customer: "My DSL is TOO slow. You promised me X kilobits per second and I don't get nearly that." Your helpdesk staff can suggest that the customer is confusing kilobytes with kilobits as they download files using Internet Explorer, claim the line is in service and "looks fine"-this is more "helpless" than "helpdesk", and it won't earn customer loyalty.

Wouldn't it be nice if you could reduce calls to Customer Support about performance? Some simple tuning advice-and ways to include tuning in your service offering-may turn a nagging headache into a golden opportunity to grow customer confidence and loyalty.

TCP Receive Window and Performance
TCP (Transmission Control Protocol) is used to provide reliable delivery for applications like HTTP (Web) and e-mail through a mechanism called positive acknowledgement with retransmission. In simple terms, your PC's TCP will return a very small response packet to acknowledge that an error-free packet has been received.

After years of studying reliable transmission protocols, we've come to understand that sending a separate acknowledgement for each successfully delivered packet is very inefficient in high speeds and high delay networks. And you can quickly appreciate that a PC in say, New York City, can easily compose and transmit many packets before the first packet transmitted might arrive at a destination in San Jose. So your PC's TCP offers what is called a receive window-- the number of bytes of application data your PC can receive before sending an acknowledgement. The purpose of the receive window is to help keep the TCP connection as full as possible, to derive the best performance (throughput).

Your receive window should be bigger than what is called the bandwidth-product delay-the bit rate of your connection multiplied by the (average) delay you'd expect to experience when accessing services via the Internet. For example, a 768 Kbps DSL downstream service with an average 200 millisecond delay has a bandwidth-delay product of 153,600 bits or 19,200 bytes. Increasing the receive window on a PC with this DSL service to at least 19,200 bytes should improve throughput.

The receive window size on most PCs is never changed from its default value. In a few cases, this window actually may have been set smaller by residential customers who have downloaded a program designed to improve web surfing over low-speed modems. Let's look at an example. The default receive window size on my lame old Windows 95 PC is 8192 bytes. Using this window size on my ADSL connection, and testing my throughput at DSL Reports, downstream throughput averaged over 10 tests was 404 Kbps. My results are consistent with the bandwidth-product formula shown above: 8192 octets divided by an estimated 160-200 millisecond average latency is 327-410 Kbps. In my case, the small receive window size not only hampers my performance, but caps it on established high delay connections.

Using the receive window size of 64240 bytes specified in the import file I downloaded from DSL Reports, my average downstream throughput after 10 more tests jumped to 622 Kbps. That's a pretty astonishing 54 percent improvement. Yes, the test environment admittedly has many variables, but so does real-world use of the Internet.

Adjusting the receive window size on a PC's TCP can measurably improve performance. To adjust the window properly, obtain a good estimate of the average delay. A simple way to estimate the average delay is to use ping. Nearly every PC has a command line ping.exe, and there is an abundant collection of shareware Internet tools that support it (at Core Competence, we use a homegrown shareware utility, NetHelper). The simplest method of obtaining internet delay is to visit a web site like Internet Weather, which continuously calculates the average Internet latency. Armed with this latency figure, you or your customer can tune receive window appropriately.

Don't let the customer be confused by or argue the fact that his PC is connected to your DSL modem using Ethernet LAN. While a small receive window size is fine for 10 Mbps LAN traffic, it's the Internet traffic you're trying to optimize in the typical residential broadband access situation. The larger receive window won't noticeably hinder intra-LAN performance between a residential customer's PC and his DSL modem.

Packet Size Matters (a little)
The receive window is often discussed in terms of packets. This is slightly imprecise, but the important matter is that TCP always tries to fill IP packets with maximum transport unit (MTU) size number of bytes. MTU is the largest possible amount of data you can send over a network connection without having to break it into pieces or fragment it. Fragmentation is Evil for several reasons. First, it uses valuable router and switch resources in the Internet, which must break packets into smaller packets before sending them along towards their destination. Upon receipt, destinations must reassemble these fragments. Since this is not the usual processing path, some equipment may process fragmented packets more slowly than complete (unfragmented) packets.

The effect of an excessively large MTU is fragmentation; a too-small MTU will generate more packet header overhead for a given stream of application data, which reduces your effective payload. While MTU is not as critical to TCP performance in DSL networks as receive window size, it's useful to know that MTU ought to be set to (but not exceed) the largest packet size that can traverse the Internet (1500 bytes). Historically, an MTU size of 576 bytes has been used in dialup networking. If your customer was a former dialup user who tuned TCP receive window for dialup, it's possible he's set his MTU to this value. Since he's now accessing the Internet via an Ethernet link to a DSL modem, check to see that his MTU is suitably large for the Ethernet and DSL link. In many cases, the Ethernet default MTU of 1500 bytes is sufficient.

Unfortunately, choosing the correct MTU isn't always simple. IPsec VPN users must typically use a slightly smaller MTU to accommodate the extra headers required for security. Customers whose DSL equipment uses PPP over Ethernet must also accommodate the extra 8 bytes of PPP header in the Ethernet frame. As the DSL provider, you should be able to provide the customer with an accurate and sufficiently large MTU for good performance.

How You Support TCP Tuning Matters (a lot)
Tuning a PC's TCP requires changes to the Windows Registry. There's a high intimidation factor associated with any Registry change, and service providers are justifiably loathe to get involved in such changes. There are several ways to circumvent direct registry editing, however, and you should consider these:

1. Direct your experienced customers (small business network administrators and power users) to the Tweaks pages at DSL Reports. They can download registry changes appropriate for every Windows version (except ME). The imports are written so that they only require a double-click to install, and the instructions are likely to be sufficient for this class of customer. You might also suggest that your customers try a $15.00 shareware called TweakDUN from Patterson Design Systems and InfiniSource. This application can set the TCP receive window and MTU, and can also dynamically determine the optimum MTU. You may wish to check if a service provider discount is available and provide the software as a courtesy and valuable added service to your customers. [By the way, there is a Macintosh equivalent to TweakDUN, see IPNetTuner.]
2. Post the Windows Registry changes specific to each Windows OS at your web site. This is in my opinion the least desirable way to go about TCP tuning, but it's here for completeness sake. If you take this path, you may actually increase support calls…
3. Make the changes yourself, when you install DSL for a customer.

How deeply involved you get in helping your customers with TCP tuning is your call. Depending on how hands-free you wish to remain from Registry involvement, one of these solutions should work for you. You should create a Web page explaining whichever of these processes you choose, or send a standardized e-mail to customers about TCP tuning. If you are taking the "hands-off, information only" approach, point your customers to the resources I've identified. Include suitable disclaimers and emphasize the importance of saving (exporting) the working registry before changing registry settings, and call specific attention to the descriptions of how to restore the backed up copy should a PC fail to operate correctly following the mandatory restart.

If you really want to keep customers happy, consider making the changes yourself, at installation time. If you are already teaching field craftspeople how to configure TCP/IP settings, install NICs for customers, and configure DSL modems for service, consider whether teaching them to export a customer's PC registry, copy the appropriate registry import files from their laptops to the customer's desktop, then import the TCP tuning changes is that much more invasive. Then weigh this against the prospect of fewer "disgruntled over service" calls to Customer Support.

David Piscitello is president of Core Competence, Inc., a network consulting firm and founder of the Internet Security Conference.