|
Practical QOS |
|
|
|
|
TCP-specific issues to
improve the protocol response |
|
|
|
Written by Leonardo Balliache
Octuber 2.003
http://opalsoft.net/qos |
|
| 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. |
|
|
|
|
|
Practical QOS |
|
|