jbn@GLACIER.STANFORD.EDU.UUCP (01/18/87)
Craig suggests that I reply to an observation about the shock load that
occurs after a retransmission has been successfully acknowledged and we are now
again sending into an empty window. The sending TCP, if equipped with
the congestion window mechanism, will send until it runs out of data to
send, the flow control window fills up, or the congestion window fills up,
whichever happens first. If we are operating in a congested situation,
ICMP Source Quench messages should have been coming in, and we should have
a small congestion window, so the amount of data sent after a successful
retransmission acknowledge should be relatively small, perhaps as little as
one packet.
All this, though, presumes that ICMP Source Quench packets are in fact
being received. This opens up a fruitful area of study. It would be
worthwhile to record the size of the congestion window and some ICMP
reciept statistics whenever a retransmit occurs. If a TCP is encountering
heavy packet losses but is not receiving Source Quench messages, and we
have no reason to suspect heavy packet loss in the transmission system,
then some overloaded gateway is not generating Source Quench messages
when it should. It should be easy to check this out.
Given that the usual cause of retransmissions is congestion, not
error, it might be worthwhile treating a retransmission timeout as
a congestion indication and shrinking the congestion window as if
a Source Quench had been received. Give this idea some thought, people.
It would probably help in some situations but may have unexpected side
effects.
It's good that people are instrumenting their transport protocols.
Most of my insights into network behavior were made possible by a
heavily instrumented TCP implementation.
John Nagle