Re: Fast TCP
From: Anne & Lynn Wheeler (lynn_at_garlic.com)
Date: Sun, 22 Jun 2003 15:44:49 GMT
toro <email@example.com> writes:
> I read about the new TCP and the fact that it allows enormous data
> transfer rates by changing the error handling procedure. Since I am
> still learning the TCP/IP protocol, I was wondering whether this
> speed would help the stability of the infastructure and in which way
basically the bits can't go faster than the wire. the issues in tcp is
chaotic network with seemingly random hops between any two end points
1) protocol setup chatter
lots of tcp apps have used a windowing algorithm as an indirect
mechanism to control pacing. windowing basically is a facility for
managing end-point buffer resources, it only indirectly controls
pacing issues like packet transmit rate, packet arrival rate,
inter-packet transmit interval, etc.
one of the most common implemented algorithms is slow-start ... which
I believe was presented at '88 august ietf meeting, the same month
that a acm sigcomm proceedings had paper showing that slow-start is
non-stable in any sort of real-world environment.
one of the past discussions was that transmitting a slew of
back-to-back packets can cause overrun at intermediate router boxes.
In theory, (slow-start) windowing is to try and mitigate things like
bursts of packet transmissions from a source. The problem found in the
'88 sigcomm paper was that in real world situations, the return ACK
packets can bunch up, with a batch arriving at the source all at once.
In a windowing paradigm, receiving a batch of ACKs means that all the
associated buffers are freed up for transmission in one burst, leading
to potentially several back-to-back packets being transmitted very
quickly. This can lead to congestion, lost packets, back-off and
restarting the slow-start mechanism, gradually increasing number of
outstanding packets until the next burst of batched ACKs appears and
the cycle starts again. All of these protocol stuttering issues
contribute to the effective delivered packet rate being less than the
Rate-based pacing would explicitly measure approximate elapsed
round-trip delay and then do something like methodically adjust the
inter-packet transmission delay. This directly controls factors that
can account for congestion and intermediate node overruns and is also
insensitive to network operation peculiarities like ACK batching.
One of the comments regarding the use of windowing algorithm in the
'80s instead of direct timer control was that possibly a large number
of the 80s-era platforms lacked the timer facilities to implement
things like inter-packet transmit delay.
there was a much longer discussion on the subject in
misc. recent related threads:
http://www.garlic.com/~lynn/2003g.html#44 Rewrite TCP/IP
http://www.garlic.com/~lynn/2003g.html#45 Rewrite TCP/IP
http://www.garlic.com/~lynn/2003g.html#54 Rewrite TCP/IP
http://www.garlic.com/~lynn/2003h.html#7 Why did TCP become popular ?
http://www.garlic.com/~lynn/2003j.html#1 FAST - Shame On You Caltech!!!
http://www.garlic.com/~lynn/2003j.html#39 tunneling TCP/IP over UDP for high-latency links?
http://www.garlic.com/~lynn/2003j.html#40 tunneling TCP/IP over UDP for high-latency links?
-- Anne & Lynn Wheeler | http://www.garlic.com/~lynn/ Internet trivia 20th anv http://www.garlic.com/~lynn/rfcietff.htm