From: msi@ESD.3Com.COM (Mark Isfeld)
Newsgroups: comp.sys.mac.comm
Subject: Re: VersaTerm SLIP Problems receiving data
Keywords: SLIP VersaTerm transferring
Date: 12 Jan 93 19:04:25 GMT

gweil@ibeam.intel.com (Garry Weil) writes:

>I have been having transferring problems, SLOW!, using VersaTerm FTP.
>Small files transfer fast, under 20K, but larger files are very slow.
>What I see watching my modem's LEDs is that there are bursts cycles
>where FTP is receiving data, 10-20k, then the Send and Receive LEDs
>go dark for 30 seconds upto minutes. A 200k file takes 20 to 30 
>minutes to receive. To make this situation more interesting, I just
>noticed that FTP sends FLY. The Send LED is almost always on!

>I have noticed this same problem using Fetch or trying to use a News
>reader, Nuntius or NewsWatcher.

>My configuration:
>1. Mac SE
>2. System 7 with tune-up installed
>3. Zoom 14.4k modem with compression and correction
>4. Hardware handshaking modem cable
>5. VersaTerm SLIP
>6. MacTCP 1.1.1
>7. Connected to an Annex terminal server running SLIP
>8. MTU=1006
>9. Sun4 FTP & NNTP server

>Is there any 'debug' thing I can do to help narrow down this problem?
>What about a different MTU value? Modem configuration?

I had a very similar problem.  I strongly recomend setting the re-transmit
filter to 0 to disable it.  

Background:
Versaterm SLIP has a re-transmit timer that attempts to limit MACTCP's
tendency to re-transmit too soon when dealing with a slow link like
a SLIP modem link.  Essentially when MacTcp is transmitting data, it
will re-send the same data too soon, since the acknowledge did not come
as soon as it expected (latencies over a SLIP modem compression line
are quite long, even if the packets are small).  So Versaterm Slip provides
a "patch" that deletes any identical transmit packets that appear within 
a particular window of time.  This process works quite well for 
"uploading" data from your MAC to another system.  It achieves nearly full
line rate transmitions.

The problem is that in some configurations, Versaterm SLIP appears to have
a bug.  When data is being recieved, and none is being sent, MacTcp is
only transmitting Acknowledges.  Versaterm Slip appears to delete the 
second and subsequent acknowledges, as though they were duplicate 
re-transmitions (indeed they have the same Sequence numbers since no
data is being transmitted, Versaterm should also check the Ack field which
is changing).  

So the sequence goes something like this.

REcieve     Transmit
------      --------
Packet 1
packet 2       ACK1
packet 3        ***  Ack2 should appear here but does not
packet 4        ***  Ack3 should appear here but does not
packet 5        ***  Ack4 should appear here but does not
                ***  Ack5 should appear here but does not

About this time the Sending devices window closes, and there is a pause 
(typically 30 seconds). Then the sending device starts re-sending the 
data that appears to be lost.

REcieve     Transmit
------      --------
Packet 2
packet 3       Ack5 In response to packet 2 MacTcp sends the current Ack
               which is Ack 5
packet 6
packet 7
and so on.


If You set the Re-transmit timer to 0 You will observe

REcieve     Transmit
------      --------
Packet 1
packet 2       ACK1
packet 3       ACK3
packet 4       ACK4
and so on.
And the recieve rate will approach that of the serial line.

I suspect (this is really wild speculation) that things work fine for
many people because the re-transmit timer is smaller than the total
time to send a window's worth of data.  The sequence may look like this

REcieve     Transmit
------      --------
Packet 1
Packet 2        ACK1
Packet 3        *** ACK2 is not sent
Packet 4        *** ACK3 is not sent
Packet 5        *** ACK4 is not sent
Packet 6        ACK5 is sent because the re-transmit timer has expired
                and a Packet was recieved, stimulating MacTcp to send
                a current ACKnowledgement, and versaterm Slip lets it 
                through!
Packet 7        *** ACK6 is not sent
and so on.

Now for more knowledgeable TCP people, Yes, Sequence number and ACK fields
are byte quantities and go up by much more than one at a time.  Also I may
be using slightly incorrect terminology when refferring to Sequence and ACK
fields.

I found this out doing a line anaylzer trace of the 
serial line.  I called Synergy software, and they talked to the author, 
whose response was

"the re-transmit problem  will be fixed in Future Versions of MacTcp.  
Just turn off the re-transmit timer if it is causing problems"

So that is what I do.  The recieve rate goes way up, although the transmit
rate goes down (MacTcp is now sending duplicate data across the line).
Since I do almost all receives, this works fine for me.

So If I am correct (I have strong evidence of the above in my config,
but zero evidence anywhere else), Whether Versaterm Slip works well for
you with the re-transmit timer depends on a complicated relationship of
a) The transmit window of the sending device
b) the MTU size
c) The transmition rate
d) the latencies involved because of compression time, modem latency, 
   slip server delays and so on.
e) the re-transmit timer in Versaterm Slip.
f) Others??

ANOTHER POSSIBILITY.....

Now there is a second possible problem that I also ran into with
similar symptoms.  
Background:
The Terminal server running SLIP must buffer
as many packets as the sending device will send in one window.  This is
because the sender on the LAN will assume network speeds and send
the full window almost imediately.  If the Slip server 
does not hold the entire window of data, and send it as possible on the
line, then one or more packets will be lost and the sender will
have to time out and re-send the data.  This results in the timeout you
are noticing on the LED's.  

Now there are two things
encouraging designers to set the buffer space small.  One is reduction
in memory usage in the terminal server, and the other has to do with
re-transmit problems.  If the sender on the Ethernet(or whatever lan)
is re-transmitting too soon, then performance will actually be better
if the SLIP server throws away most of those extra re-transmissions.
A limited queue depth is one way to do this.  Another way to look at it
is that data sitting in SLIP server memory is aging and becomes useless
after too long.  Sending it then just uses up line bandwidth.

This is the reason that SLIP server implementations may only allow
4-8 packets to be buffered in their transmit queue.  This may not be 
adequate.  The case I ran
into is that the packet queue size was sufficient for the sending device,
but overflowed whenever too many broadcast packets were recieved, or if
a second TCP connection was started.  The solution was to 
A) turn off Broadcast traffic on the SLIP line
B) find out how to configure the SLIP server to hold more packets, 
so there is no packet loss.  

If the TCP devices on the network are respecting Slow start(Sun's do), then
things should work with a reasonable queue size.  I had to set my queue
size to 16 packets, and I turned off broadcast packets since they have
no utility on the Mac.   However, I was using a 3Com terminal server, not
an Annex, so I have no idea what annex allows/supports.

Good Luck, it can Work!!!


--
-------------------------------------------------------------------------
| Mark Isfeld   
| Mark_Isfeld@3Com.com                     
| 408-764-5167