derrick@zaphod.UUCP (Derrick Nagy) (05/11/91)
I have a very fundamental question. We had a tcp package that exhibited what I believe to be a variety of SWS. So we changed it. The new version of the package seems to have problems, too, however. The symptoms can be seen, for example, when we try to list a file (via a TELNET interface). The data will intermittently pause for a few seconds on one of the hosts (pausing host), and will pause and stay paused until a character is entered on the receiving terminal on another host (stalling host). The problems seem to lie at the TCP level when the receiving end advertises a zero window. It does not appear to turn flow control on again on its own initiative. The pausing host will send a datagram with one byte of garbage data as a probe after a few seconds, to which the receiving end responds with an ACK with the current window size (usually wide open). The stalling host only sends ACKs, and the receiving end never responds to them. Questions: are the ACKs from the stalling host probes? Are they valid probes? What criteria should the receiving end use to advertise when its window opens? We have read all of the TCP RFC's that we can find, and a couple of texts besides (eg. Comer's), and cannot find anything that specifies the proper means of flowing on data again. -- |\/\/| Derrick Nagy, Mgr., Software Engineering, Develcon Electronics _|\ | | /|_ Ltd., 856-51 St. E, Saskatoon, SK. Canada, S7K 5C7 >_ DEVELCON _< "Innovative High-Performance Internetworking Systems" >________< derrick@zaphod.uucp | Ph: (306) 931-1388 | Fax: (306) 931-1386
solensky@animal.clearpoint.com (Frank T. Solensky) (05/13/91)
In article <4238@zaphod.UUCP> derrick@zaphod.UUCP (Derrick Nagy) writes:
...
The problems seem to lie at the TCP level when the receiving end advertises
a zero window. It does not appear to turn flow control on again on its own
initiative. The pausing host will send a datagram with one byte of
garbage data as a probe after a few seconds, to which the receiving end
responds with an ACK with the current window size (usually wide open). The
stalling host only sends ACKs, and the receiving end never responds to them.
Questions: are the ACKs from the stalling host probes? Are they valid
probes?
The ACK from the stalling [client] host is in response to the zero-window probe
sent by the pausing [server] host. The ACK in the packet isn't as important as
the window size that the packet contains -- this is what allows the pausing
host to resume sending data.
What criteria should the receiving end use to advertise when its window
opens?
When the stalling host's receive window changes from zero to non-zero, it should
be sending out an ACK at that time, rather than waiting for the zero-window
probe from the pausing host.
--
-- Frank Solensky / Clearpoint Research Corp.
Red Sox magic number: 132jbvb@FTP.COM (James B. Van Bokkelen) (05/15/91)
.... The pausing host will send a datagram with one byte of garbage
data as a probe after a few seconds, to which the receiving end
responds with an ACK with the current window size ....
The ACK from the stalling [client] host is in response to the zero-window
probe sent by the pausing [server] host....
If in fact the single byte of data is garbage, then the sequence number MUST
be SND.UNA - 1, and the segment is a "keepalive". A real zero-window-probe
is sent with SND.UNA (not SND.NXT, or you may wedge if someone shrinks the
window on you) as the sequence number and a real data byte.
When the stalling host's receive window changes from zero to non-zero, it
should be sending out an ACK at that time, rather than waiting for the
zero-window probe from the pausing host.
This is true, but it doesn't excuse you from implementing zero-window-probe
logic. The single ACK might get lost in transit, and if this happens, the
TCP connection necessarily stays stalled until the sender probes.
James B. VanBokkelen 26 Princess St., Wakefield, MA 01880
FTP Software Inc. voice: (617) 246-0900 fax: (617) 246-0901