Roman Elizarov, December 1999
Roman_Elizarov@baylor.edu
This reports gives the result of agressive TCP implementation attempt. While it is not hard to make TCP behave absolutely wild and flood the network with the packets that effectively knock out all other competing protocols running over the network (unless some sort of fair queueing is done in the network), but that approach will drive the network to the congestion collase which is not the goal and must be avoided. It turned out that aggressive TCP, i.e. that will compete significantly better without provoking congestion collaps is not an easy thing to do. Efforts by different network specialists are undertaken to improve TCP performance in the presence of congestions. Overview of their work shows that there are few things that could be done without changing TCP too much.
The original purpose of the work was to modify Linux kernel of one of the HackNet group machines in order to make TCP aggressive. By word aggressive we mean the implementaion that is able to get more bandwidth that non-aggressive TCP implementations are able to. But we still want to get data being send and do not drive the network into congestion collapse.
That is an easy question to answer. [RFC2581] gives explicit upper bounds on how aggressive TCP implementations shall be, though it allows experimantal implementations to relax or violate some of the requiremnts. There are not many requirements to break and almost all requirements have good reasons of being imposed.
Actually, limits on TCP aggresiveness are made in an effort to prevent congestion collapse and I will futher justify this later. Let us now look at aggresiveness limits themselves.
We can still try to make window increase faster, but by increasing it faster we run into congestion faster, and again end up with smaller window. The only resonably looking solution is to eleminate as many backoffs as possible in an attempt to get highest possible window. The main source of backoffs during actual connections, as it turned out, is Fast Retransmit/Fast Recovery.
Fast restransmit is a primary source of congestion detection and it is the main mechanism that limits the growth or the windows. Though, simulations showed that over a long delay links implementation window limit can serve as a perfomance bound.
One of the main feature of TCP that limits its perfomance is an ACK clock. There is not much TCP sender can do (implying that data to send is always available) being not the part of the reaction on ACK from receiver. The only execptions are retransmit timers that actually fire rarely.
This behaviour is a great constaint on the TCP's abilty to handle data transfer in the most efficient way, and it also prevents simple hacks to make it aggresive. It seams that having internal clock which frequency is adjusted based on the feedback is superiour, and that is how most realtime transfer protocols do their job. This will allow one effiently complete with TCP connections over the network bandwidth.
The presence of any kind of fairness-enforcing gateway (like one proposed in [Lin97]) anywhere on the path renders any efforts to create aggressive TCP useless. That one reason why it is very hard to evaluate actual aggresivenes of some implementaion over the real Internet, and, unfortunataly, that is the single interesting place to run simulations over.
Small number of simulations were done using HackNet workstations as a testbed. Linux kernel was modified to write (using kprint function) different characters in different places of TCP implementation in order to study TCP behaviour during actual long-delay FTP data transfer (put) over the Internet to the remote host.