🚀 go-pugleaf

  I have been playing around with a TCP implementation trying to get
the throughput up and discovered an interesting anomaly with large
windows. The setup I have is a program which is an infinite data
source sending to the discard port (port 9) on a remote machine over
ethernet. I am merely measuring the bandwidth and occassionally reporting
that to the user -- nothing complicated.
  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?

  (BTW, I noticed that the IBM/AIX which extends a 16k window 
   has the same problem with a Sun running 4.1.2, so the problem
   is not unique to the TCP I'm futzing with...)
-- 

		Michael Thomas	(mike@gordian.com)
	"I don't think Bambi Eyes will get you that flame thrower..."  
		-- Hobbes to Calvin
		USnail: 20361 Irvine Ave Santa Ana Heights, Ca,	92707-5637
		PaBell: (714) 850-0205 (714) 850-0533 (fax)