cFos Traffic Shaping and other Internet tuning methods

What tuning methods are there?

Registry-Tweaks

An entire line of so-called “registry-tweak” programs has sprung up based on the assumption that changing various Internet protocol parameters may boost data-transfer speed. In essence, what such programs do is simply change the values of certain parameters rather than have the user edit the corresponding registry entries manually. Typically, the following parameters are thus adjusted:

• MTU/MSS:
  Transmission of each packet entails a certain packet overhead, which is always the same – regardless of what size the transmitted packet may be. Thus, sending out packets that are as large as possible would seem to be one probable way to cut back on overall overhead. For instance, a TCP/IP packet sent via DSL/PPPoE has an overhead of 48 bytes (i.e., almost 10 percent for a 500-byte packet). If no value for Maximum Transfer/Transmission Unit (MTU) is specified in the registry, TCP will determine packet size itself through a process called “Path MTU Discovery.” It will do so in such a manner that packets sent will always be of the largest size that can still be handled by all intervening transmission nodes. For DSL/PPPoE, maximum MTU is 1,492 bytes, which corresponds to an overhead of approximately 3 percent. This value really doesn’t need to be set, since Windows already maximizes it through Path MTU Discovery. MSS usually equals MTU-40.
• TcpWindowSize:
  This parameter controls the maximum number of bytes the remote TCP may send before an acknowledgment must be received. Lacking such acknowledgment, the sender is forced to wait, thus resulting in dramatic drops in transfer rate. Unless the user specifies otherwise, Windows determines the value for this parameter based on packet size (12 * MSS). The greater the latency, the larger the TcpWindowSize needs to be to avoid having the sender wait. Thus, assuming a connection speed of 1,024 kbit/s and 150ms of ping time to server, TcpWindowSize must at least be 2,000 bytes. Should further delays occur, even that wouldn’t suffice anymore. This is why a lot of tuning programs tend to jack TcpWindowSize up inordinately. The problem is that while running an upload, the upload competes with acknowledgments for available bandwidth, meaning the transfer rate will plummet nevertheless. Furthermore, huge TcpWindowSize does also increase latency, which can quickly turn VoIP or online gaming into an exercise in frustration. For instance, at a TcpWindowSize of 64k or higher, latency will rise to more than 400ms, which is absolutely unacceptable for VoIP.
• TTL:
  This value indicates how often any given packet may be passed on from node to node until it reaches its destination. Changing this value has no appreciable effect whatsoever on transfer speed. Can you spell “placebo software?”

Traffic Shaping

So, in a nutshell, some registry tweaks may sometimes yield greater speed (though often at the cost of significantly higher latency).

Traffic Shaping is then the next logical step in improving data-transfer speed without sacrificing performance elsewhere. It works by sorting data packets according to importance prior to sending them, thereby ensuring all time-critical data are being sent out first. TCP acknowledgments, for example, are highly prioritized so that they are always received in time, which means download data can be transmitted without interruption.

However, the more data are transmitted simultaneously, the more data congestion will likely occur. Therefore, effective Traffic Shaping should ensure not too much data are being sent simultaneously, as this also tends to affect ping times and VoIP speech quality. The more protocols Traffic Shaping can distinguish, the more responsively a system will perform while multiple applications are being run on it at the same time. For instance, Traffic Shaping can be used to accelerate surfing speed by having the corresponding DNS requests prioritized. FTP command, Telnet, SSH and similar protocols can also be prioritized in this fashion.

Since Traffic Shaping boosts transfer rates by reducing latency, it does yield higher speed irrespective of how much bandwidth may be available. This is especially valuable seeing how latency problems during simultaneous use of multiple Internet connections cannot be compensated for by additional bandwidth.

ACK filtering

During each download, acknowledgments take up about 5 percent of the available download bandwidth in upstream direction. The problem here is that upstream bandwidth is much lower than downstream bandwidth for ADSL and broadband cable. This also means there may not be enough upload bandwidth left to achieve full download speed, not to mention that it is always desirable to have some upstream bandwidth available for other uses. For this reason, ACK filtering reduces the size of acknowledgment packets as much as possible without decreasing download rates. In this manner, the bandwidth needed for handling acknowledgments can often be cut in half.

Data compression

It is always nice to be able to compress user and/or protocol data. For Web servers, so-called “GZIP compression” lends itself particularly well to this. With it, the text on Web pages can be compressed to about half the original size prior to transmission. Leading Web browsers like the Internet Explorer or Mozilla Firefox do support GZIP compression. The Web server is also smart enough to send uncompressed data instead when dealing with old browsers that do not support GZIP. Therefore, there is to our knowledge no drawback to using GZIP. Unfortunately, it can only be activated by a Web server’s administrator.

Modems and ISDN make use of V.42bis and Stac data compression, respectively. Both reduce the amount of text data transmitted between dial-in node and modem or ISDN board by roughly one half. Thus, these compression methods could conceivably double transfer speed in both direction for types of data (like text) that can be compressed well. But because image files account for most of the data servers must transmit for today’s Web sites, our experience has generally been that this kind of compression makes very little difference. The same is true if a server is sending data already compressed in GZIP format.

In contrast, VJ compression (also known as IP-header compression) does not minimize the size of user data but only that of protocol data. Assuming a standard narrowband packet size of 576 bytes, this can effectively cut TCP/IP header size from 40 to 3 bytes, resulting in a reduction of packet overhead from approximately 7 to 0.5 percent. While this is of great interest for low-speed modem and ISDN connections, it is very rarely if ever used for broadband connections. DSL and cable providers would much rather sell their clients more bandwidth.

Download accelerator

Many servers permit downloads at no more than a predefined maximum download rate. The idea behind most download accelerators is to circumvent this by downloading a file in several segments at the same time through multiple connections to the same server. This does indeed often lead to higher download rates.

Web accelerator

The ability to use cell phones for wireless (yet typically very slow) Internet access has dramatically increased the demand for having Web-page data compressed prior to transmission. Such precompression might also be useful for modem or ISDN connections. Providers of Web accelerator software maintain their own servers with broadband connections to the Internet. These are needed to first load the desired data, compress it, and then send it through the bottleneck of the modem, ISDN or radio-network connection.

But due to the large image files involved, the gain thus yielded by conventional compression methods can only be marginal at best. This is why more and more Web accelerators have begun to manipulate image data as well. To make some headway there, images are usually reduced in color depth and resolution. Given the small size of their displays, this poses little if any problem with respect to cell phones. But on desktop computers it may well result in a clearly discernible loss in quality for desktop applications.

Installation of the respective browser add-on is required for using the services of a Web accelerator – as is in most cases payment of a monthly fee or surcharge. Using web accelerators does yield little appreciable gain in speed on broadband connections. Countervailing this is a possible increase in latency, since the Web accelerator is interposed between server and client.

Faster Connection

Switching to a rate plan that gives you higher connection speed is still the safest way to improve bandwidth and thus achieve better data transmission rates. This as such won´t improve ping times though. And neither will it prevent downloads from slowing dramatically, even stalling altogether, when data is being uploaded at the same time. That’s why it is ideal to combine any bandwidth upgrade with Traffic Shaping technology.