Our customers often ask about our “congestion control” feature: what exactly is congestion control, why is it needed and how does it work in the context of FileCatalyst? Not easy questions to answer without getting overly technical, but this article will attempt to give high-level answers.
Congestion Control: General Overview
On an IP network such as the internet, there are millions of data streams that must co-exist at any given time. Those streams must not conflict with one another or the internet would come to a grinding halt and all applications that require internet access would cease to function properly. The reason these connections are able to coexist is because of congestion control.
Congestion control is a mechanism that will increase or decrease the speed of data transmission based on network conditions. Network conditions are monitored during a transmission, and if congestion is detected the transmission rate is decreased; otherwise it is increased. That's the general idea. However, the way congestion is detected, as well as how much the rate is increased or decreased is where different congestion control mechanisms differ.
How is congestion detected? Data packets run through a series of routers along their path to their final destination. Each router is responsible for handling several unique data streams, and directing the packets from each stream to the proper destination. Packets arriving at the router awaiting processing are stored in queues or buffers. These queues are generally processed using a FIFO (first in first out) policy. This means simply that they are processed in the order they arrive.
These queues are limited in size. When packets cannot be processed fast enough by the router, the queue grows until it is full. At this point any new packets will be discarded, causing packet loss. In addition, when queues are full, the packets already in the queue are delayed because of the large number of packets that will be processed first. This causes an increase in the RTT (round trip time), which is the time it takes for a transmitted packet to make it to a receiver and a reply to make it back to the transmitter. Monitoring either packet loss or RTT over the duration of a file transfer are viable means of detecting congestion.
Congestion control is built into TCP, the protocol that accounts for the majority of all traffic on the internet. TCP determines that there is congestion by detecting packet loss as described above. The protocol itself will slow down a stream when a packet is lost, and speed up again when no more loss is detected. Various algorithms do exist within TCP to avoid congestion (i.e. Tahoe, Reno, Vegas, etc...) but these are outside the scope of this post.
The FileCatalyst Approach to Congestion Control
In FileCatalyst, the UDP protocol is used for data transmission instead of TCP. It therefore doesn't have congestion control at the protocol level. For that reason, FileCatalyst has application level congestion control. There are 2 modes of congestion control used in FileCatalyst, one based on RTT and one based on packet loss.
The first congestion control algorithm used is based on RTT. This works by establishing a baseline average RTT before the data starts to flow. Once the transmission begins, RTT is monitored continuously. While the RTT stays within a certain range of the baseline RTT, the speed of the transfer will be increased. Once the RTT begins to go above a certain range, the speed is decreased. How much the RTT is allowed to spike above the baseline average is controlled by the Congestion Control aggression setting FileCatalyst provides.
This type of congestion control works well on wireless or satellite links where there is packet loss from other sources besides congestion. TCP will slow down, for example, when a packet is lost due to interference or being too far from a cellular tower. When FileCatalyst is using the RTT based congestion control it ignores individual packet losses and focuses only on RTT. For these scenarios, FileCatalyst continues to maintain high speeds through the kinds of packet loss “hiccups” that would trigger decreases speeds under TCP.
There are circumstances in which this RTT based may not work properly. For example, when a router's queue is very small, the RTT may never spike when there is congestion. The RTT will remain low, and therefore FileCatalyst would continue to increase its transmission rate even when there is congestion present. For these scenarios, the only way to detect the congestion is using a packet loss approach. As outlined previously, packet loss may come from other sources besides congestion, so this mode is best used on terrestrial or land based networks where all packet loss is due to real congestion.
Loss-based congestion control mode reacts to packet loss by slowing down (just like TCP); however, FileCatalyst is not nearly as aggressive as TCP. The primary reason for using a UDP-based file transfer solution like FileCatalyst is because TCP is so aggressive in its congestion avoidance that it often ends up under-utilizing your link. The FileCatalyst loss-based congestion control algorithm was designed such that is it able to maximize link utilization while still avoiding congestion. Like the RTT-based congestion control, the loss-based mode can be tuned to be more or less aggressive. More aggressive settings allow for a higher percentage of packet loss before slowing down, while for more passive settings the opposite is true.
There is certainly a need for congestion control in any protocol that transfers data across the internet. It is built into TCP, but TCP's implementation is conservative to the point that file transfers are usually crippled as a result. UDP without congestion control is potentially just an illusion of speed, with packets being “blasted” out, lost, and re-sent. FileCatalyst's UDP-based transfer uses two different methods of congestion detection, allowing for effective management of transfer rates. This helps prevent excessive packet loss while transferring files at maximum speed.
#1 on 2012-Feb-29 Wed 02:46+-14400
#2 on 2012-Feb-28 Tue 02:46+-14400
#3 on 2012-Feb-28 Tue 02:15+-14400
#4 on 2012-Feb-28 Tue 02:56+-14400
#5 on 2012-Feb-28 Tue 02:17+-14400
#6 on 2012-Feb-28 Tue 02:06+-14400
#7 on 2012-Feb-28 Tue 02:20+-14400
#8 on 2012-Feb-28 Tue 02:23+-14400