Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!rice!uupsi!nstn.ns.ca!bonnie.concordia.ca!ccu.umanitoba.ca!herald.usask.ca!zaphod!derrick
From: derrick@zaphod.UUCP (Derrick Nagy)
Newsgroups: comp.protocols.tcp-ip
Subject: TCP flow control query
Message-ID: <4238@zaphod.UUCP>
Date: 10 May 91 20:22:11 GMT
Distribution: na
Organization: Develcon Electronics Ltd., Saskatoon, SK, Canada
Lines: 30


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