🚀 go-pugleaf

In article <1993Jan21.233655.29402@gordian.com> mike@gordian.com (Michael A. Thomas) writes:
>
>  What I have found is that with large windows (say 16kb) the sending
>TCP stops sending at about 4k and waits for the receiving TCP to
>send an ACK. The receiving TCP, however is using a defered acking
>scheme which tries to delay sending ACK until a larger window is
>consolidated into one packet. The metric it is using is 1/2 the
>buffer size, and the delayed ack period is on the order of 100ms.
>  I can understand why a sending TCP might be leary of sending *so*
>much data without hearing an ack, but my question is what algorithm
>is the sending TCP using to determine how much data it will send
>before going into this quiesent state? Is there an appropriate
>RFC which I should read which describes this situation? Is the
>behavior of the sending TCP correct?

	Sounds like the sender's computing a congestion window
around 4K. See, say, Steven's _Internetworking with TCP/IP_ or
probably rfc793 somewhere or other. Steven's has a good exposition.

	The point is that TCP makes a guess at a good sending
window size based on latency of packets, and uses the minimum
of that window size and the remote's advertisement as the real
window. This is used to avoid congestion. It might even be that
the delayed ACK cause the sender to compute an artificially
small congestion window (4K seems small to me).

	One must keep in mind that TCP is polite. If the goal is
to hammer your media to death, TCP is the wrong protocol. Not, by
the way, to suggest that this is your goal.

	Andrew

>		Michael Thomas	(mike@gordian.com)