bof@vieta.math.uni-sb.de (Patrick Schaaf) (06/10/91)
Hi Netlanders!
I'm rather new to the internals of TCP but willing to learn.
In my environment here I encounter a problem I cannot completely
understand, and I hope for some hints (or even solutions).
The environment:
Two Ethernets connected through a very slow (9600bps) PSN X.25 link,
with a Sun 3/80 running sunlink x25manager on our side and a Cisco
on the other.
My machine: A DOS PC running a derivate of the BSD4.3 TCP/IP (indirectly
connected to our ether via a 1MB D-Link Lan, but this shouldn't matter).
Remote machine: Another Sun 3/80 (btw, both Suns mentioned are 4.0.3EXP)
The problem:
I rlogin from my machine to the Sun on the distant Ethernet. I run
some applications (e.g. nn) producing one screenful of data at a time.
After some time and some amount of data (screens) transferred, output
stops somewhere. It then normally takes about 10 seconds to continue.
I attribute this to multiple retransmissions stuck "in" the X.25 link
causing several retransmits and the retransmission timer going up due
to Karn's algorithm.
What I don't understand is this: Once in a while, the transmission seems
to stop completely (doesn't continue for minutes). Watching the X.25
packet counts (vcstat on our Sun) shows that some packets are going out
from here but no reaction comes in. When I then open a second connection
to the same machine through the same link (originating from another
PC on the same net), IT WORKS, at rather normal (low) speed (until I
burst again).
NB: Normally I (my connections) am the only one using that particular
X.25 link (which is a permanent SVC), but it might be that the full stop
occurs at some time when somebody else just did something.
The Questions:
- Is it possible for Sun's TCP implementation to explode retransmission
timeouts to minutes' frequency?
- Is it possible to make TCP work better (smoother) in such an extreme
environment, and if, how (explanations based on the 4.3BSD code would
be best).
- Is there a possibility to monitor the RTT estimates on the distant
Sun? I would be very interested to study the delays.
- Did I forget to ask something relevant?
Thank you in advance for your help
Patrick
--
Patrick Schaaf, SysAdm at the Math Dept., University of Saarbruecken, Germany,
aka bof@math.uni-sb.de
All relevant signature standards ignored...eckert@immd4.informatik.uni-erlangen.de (Toerless Eckert) (06/10/91)
From article <bof.676539524@vieta.math.uni-sb.de>, by bof@vieta.math.uni-sb.de (Patrick Schaaf): [...] > The Questions: > > - Is it possible for Sun's TCP implementation to explode retransmission > timeouts to minutes' frequency? From my experience: yes, though other TCP (notably 4.2bsd) are even worse and have the problem of coming to a full stop completely. > - Is it possible to make TCP work better (smoother) in such an extreme > environment, and if, how (explanations based on the 4.3BSD code would > be best). I've never tried to fiddle around in the kernel for this purpose. My simple solution was alway to use X28/X29 instead of telnet for those slow X.25 based connections (for ftp it really doesn't matter how fast it is). > - Is there a possibility to monitor the RTT estimates on the distant > Sun? I would be very interested to study the delays. Use 'ping -s' > - Did I forget to ask something relevant? If the PC is DOS based, the TCP/IP may not really be 4.3 derived and may have problems with reassembling fragmented IP frames. This leads to the effect that TCP connections hang absolutely even though more IP traffic over the same SVC is still floating. Don't use x25manager, use x25mgr which comes with SunNet X.25 7.0. Try to fiddle with the MTU on both the cisco and the sun side, use the same value on both ends. (RFC877 specifies 576 as a minimum, but for faster interactive performance you may prefer 128). Use the maximum available X.25 packet size for the link. Use window size 7 if negotiatable. Best question: ask for a faster link. The sun can handle up to 64kbps if it's a sun4 (over the cpu ports). (This is not the general purpose answer for overloaded or misworking circuits, but for 9600 IP/X.25 links it is). Hope that helps a little --- Toerless.Eckert@informatik.uni-erlangen.de /C=de/A=dbp/P=uni-erlangen/OU=informatik/S=Eckert/G=Toerless bandwidth - the final frontier.