Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!usc!wuarchive!uunet!mcsun!unido!sbsvax!vieta!bof
From: bof@vieta.math.uni-sb.de (Patrick Schaaf)
Newsgroups: comp.protocols.tcp-ip
Subject: Ether-X25-Ether, strange(?) delays
Keywords: X.25 Karn retransmits slow
Message-ID: <bof.676539524@vieta.math.uni-sb.de>
Date: 10 Jun 91 07:38:44 GMT
Sender: news@sbsvax.cs.uni-sb.de
Lines: 59

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...