Path: utzoo!attcan!uunet!decwrl!ucbvax!VAX.FTP.COM!jbvb
From: jbvb@VAX.FTP.COM (James B. Van Bokkelen)
Newsgroups: comp.protocols.tcp-ip
Subject: Re: telnet and pc's
Message-ID: <9007091356.AA28226@vax.ftp.com>
Date: 9 Jul 90 13:56:30 GMT
Sender: daemon@ucbvax.BERKELEY.EDU
Reply-To: jbvb@vax.ftp.com
Organization: The Internet
Lines: 30

Two points:

1. The "retransmit increases steadily toward a limit, even when data
is eventually getting acknowleged" is a TCP bug that at least a
couple of "Van Jacobsen" TCPs can be provoked into demonstrating.
With the two I'm familiar with (SunOS 4.0.1, Ultrix 3.0) it normally
has to do with which ahead-of-sequence segment the receiver drops
first if buffers are tight (earliest sequence vs. latest).  In my
opinion, it would be worth the effort to fix it in the workstation.

2. Read the TCP section of RFC 1122 - it has somewhat to say about
the use of Nagle's algorithm to collect data into larger segments.
The gateway vendors (and the regional networks) won't be awfully
happy about bursts of back-to-back 64-byte packets.  Even if the
traffic is time sensitive, like X, a larger packet every 10ms
would suffice.

I can't really blame PC-NFS in this case - my TCP probably wouldn't do
much better under that kind of abuse.  A receiving TCP is rather limited
in what it can do to prevent overrun, or sender retransmit escalation.

To answer your original question, I hope the Sun Unix TCP isn't
looking at the 3Com manufacturer code in the destination Ethernet
address and slowing down (this would fail through routers, or if they
were talking to software which sets its own Ethernet address).  I
think what you're seeing is mostly the effect of code which attempts
to send as much data as possible in each segment...

James B. VanBokkelen		26 Princess St., Wakefield, MA  01880
FTP Software Inc.		voice: (617) 246-0900  fax: (617) 246-0901