TCP-specific issues to improve the protocol response
Written by Leonardo Balliache

There has been discussions about what kind of modification should be made to the TCP congestion control algorithm such that the protocol response could be improved.

People sometime complaint with TCP fast of response and behavior mainly because they compare it against more aggresive transport protocol like SPX or UDP.

These people forget that TCP behavior has been designed to protect Internet from a possible collapse provoked when uncontrolled flows, i.e., not having a good, largely proved, congestion avoidance control mechanism, are injected into the global network. They evaluate only the fast of response that they would like for their applications, putting aside the fact that is specifically true that Internet collapse is avoided, just because the main transport protocol is precisely, TCP.
TCP response has to be improved and people from IEFT are working on it, but, every decision has to be taken after been carefully analized, discuted and tested, and always through the publication of new standards. Vendors have to respect the standards, avoiding the release of aggresive protocols to be used over Internet, without having enough confidence in their congestion avoidance control capabilities.
IEFT has been doing an effort to design a new real-time transport protocol to replace UDP. UDP has not any kind of congestion avoidance control mechanism and is being used every day even more and more in Internet. All those real-time applications, including VoIP, video, video-conferences, multimedia and games are being used every day more frequently, and this pose a serious problem for the global network stability, because most of them run over UDP.
The new real-time protocol is called DCCP and include a carefully designed congestion avoidance control mechanism (in fact, it includes some to be selected by the application designer) to protect the network and, at the same time, give the potential users and application designers, the quality and fast of response behavior they are requesting to.
Fortunately, the IEFT working group in charge of this design, is being led by Sally Floyd, one of the people in the all world that better known the theme, and that has dedicated almost her entire all life to study and propose improving to the TCP congestion avoidance control algorithms. Then, we are, thanks to God, in good hands.
 
Some proposals issues to improve TCP behavior
These proposals (some of them) have been taken from RFC 2914, Congestion Control Principles; most of them are yet under study.
Initial window
 The TCP sender can not open a new connection by sending a large burst of data (e.g., a receiver's advertised window) all at once. The TCP sender is limited by a small initial value for the congestion window. During slow-start, the TCP sender can increase its sending rate by at most a factor of two in one roundtrip time. Slow-start ends when congestion is detected, or when the sender's congestion window is greater than the slow-start threshold ssthresh.
An issue that potentially affects global congestion control, and therefore has been explicitly addressed in the standards process, includes an increase in the value of the initial window [RFC2414,RFC2581].
Slow-start
Issues that have not been addressed in the standards process, and are generally considered not to require standardization, include such issues as the use (or non-use) of rate-based pacing, and mechanisms for ending slow-start early, before the congestion window reaches ssthresh. Such mechanisms result in slow-start behavior that is as conservative or more conservative than standard TCP.
Pure ack congestion control
An issue that potentially affects global congestion control, and therefore would be likely to be explicitly addressed in the standards process, would include a proposed addition of congestion control for the return stream of `pure acks'.
Presumed bytes in the pipe
An issue that has not been addressed in the standards process, and is generally not considered to require standardization, would be a change to the congestion window to apply as an upper bound on the number of bytes presumed to be in the pipe, instead of applying as a sliding window starting from the cumulative acknowledgement.
Retransmit timer
An issue that potentially affects global congestion control, and therefore would be likely to be explicitly addressed in the standards process, might include a modified mechanism for setting the retransmit timer that could significantly increase the number of retransmit timers that expire prematurely, when the acknowledgement has not yet arrived at the sender, but in fact no packets have been dropped. This could be of concern to the Internet standards process because retransmit timers that expire prematurely could lead to an increase in the number of packets unnecessarily transmitted on a congested link.
Duplicate acknowledgments
An issue that potentially affects global congestion control, and therefore would be likely to be explicitly addressed in the standards process, might include a proposal (if there was one) for inferring a lost packet after only one or two duplicate acknowledgements. If poorly designed, such a proposal could lead to an increase in the number of packets unnecessarily transmitted on a congested path.
Send a presumed-lost packet
An issue that has not been addressed in the standards process, and would not be expected to require standardization, would be a proposal to send a "new" or presumed-lost packet in response to a duplicate or partial acknowledgement, if allowed by the congestion window. An example of this would be sending a new packet in response to a single duplicate acknowledgement, to keep the `ack clock' going in case no further acknowledgements would have arrived. Such a proposal is an example of a beneficial change that does not involve interoperability and does not affect global congestion control, and that therefore could be implemented by vendors without requiring the intervention of the IETF standards process. (This issue has in fact been addressed in [DMKM00], which suggests that "researchers may wish to experiment with injecting new traffic into the network when duplicate acknowledgements are being received, as described in [TCPB98] and [TCPF98]."
TCP's recovery
Other aspects of TCP congestion control that have not been discussed in any of the sections above include TCP's recovery from an idle or application-limited period [HPF00].
Unresponsive flows
RFC 2309 also discussed the potential dangers to the Internet of unresponsive flows, that is, flows that don't reduce their sending rate in the presence of congestion, and describes the need for mechanisms in the network to deal with flows that are unresponsive to congestion notification. We would note that there is still a need for research, engineering, measurement, and deployment in these areas.
Because the Internet aggregates very large numbers of flows, the risk to the whole infrastructure of subverting the congestion control of a few individual flows is limited. Rather, the risk to the infrastructure would come from the widespread deployment of many end-nodes subverting end-to-end congestion control.
High performance TCP implementations
Trying with the TCP's response function it is possible to design some high performance TCP implementations, basically by changing the AIMD (Additive Increase Multiplicative Decrease) TCP parameters. Some of these new ideas are yet in draft phase. These are FastTCP, Scalable TCP, XCP, HighTCP and HighSpeed TCP. From them, I like the excelent work done by Sally Floyd with HighSpeed TCP for Large Congestion Windows. Have a look to the draft draft-ietf-tsvwg-highspeed-01.txt or newer, by the IETF's TSV Working Group.