Path: utzoo!utgpu!jarvis.csri.toronto.edu!rutgers!apple!bloom-beacon!tut.cis.ohio-state.edu!ukma!xanth!ames!killer!lll-winken!bayes.llnl.gov!casey
From: casey@bayes.llnl.gov (Casey Leedom)
Newsgroups: comp.protocols.tcp-ip
Subject: Re: PC-NFS bug (long). Was: What is Ethernet type code 8035 hex?
Keywords: PC-NFS ibmpc
Message-ID: <26194@lll-winken.LLNL.GOV>
Date: 1 Jun 89 07:16:50 GMT
References: <3001@yarra.oz.au>
Sender: usenet@lll-winken.LLNL.GOV
Reply-To: casey@lll-crg.llnl.gov.UUCP (Casey Leedom)
Organization: Lawrence Livermore National Laboratory
Lines: 28


   Chris Jankowski (chris@yarra.oz.au) describes a problem where telnet
sessions ``lock up'' for seconds at a time.  He tracked it down to a very
weird phenomena involving PC-NFS using reverse ARPs for unknown reasons
if PC-NFS was on a class A network.  Fascinating.

  One other source for lock ups that some of you should be aware of when
using PC-NFS is it's lack of silly window avoidance.  Our people have
only seen this crop up as a problem with ftp transfers, but I don't see
any reason it couldn't happen with a telnet session.

  Apparently what happens is that the PC offers a silly window (window is
less than half open).  The remote system which has silly window avoidance
decides to wait for the PC's receive buffers to clear and the PC to offer
a larger window so the remote host doesn't flood the net with a bunch of
smaller packets.  But PC-NFS doesn't update its window, so the transfer
hangs until the remote host gives up waiting for the window update.  The
remote host sends a small packet, PC-NFS sends a window update SEGSIZ/2 <
WINSIZ <= SEGSIZ.  The remote host likes the new window size and
immediately sends more data and PC-NFS sends another silly window ...
Once this pattern sets in for a given transfer, it apparently goes on
forever.

  If anyone is interested I can point them at the person locally who has
been working on this problem.  I haven't kept up with the work, so for
all I know Sun may already have a fix for this.

Casey