[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

IP-TCP ... incomplete implementation



   Date: Thu, 21 Jul 88 09:48 EDT
   From: Crawley@alderaan.scrc.symbolics.com (Eric S. Crawley)

       Date: Wed, 20 Jul 88 22:56 EDT
       From: cjl@WHEATIES.AI.MIT.EDU (Chris Lindblad)

	   Date: Wed, 20 Jul 88 19:05 EDT
	   From: buff@upenn.warminster.cis.upenn.edu (Richard Billington)

	   It appears that the version of IP-TCP we have loaded here doesn't handle IP
	   fragmentation. We need a fix for this immediately. We are trying to get NFS to
	   work, and our central UNIX file server sends a datagram containing all of the
	   information in /etc/exports (which is considerable) in reponse to the RPC
	   request mntproc-1-export. The resulting datagram is larger than an ethernet
	   packet and is hence fragmented, and the Symbolics drops it on the floor. We
	   don't believe that IP fragmentation is an optional portion of the IP protocol
	   specification.

       Symbolics IP-TCP does do reassembly.  It just has a maximum packet size of an
       ethernet packet, 1500 bytes.  It will reassemble any fragments as long as the
       resulting packet is 1500 bytes or less.  I believe this is allowed by the IP
       protocol specification.

   The IP protocol specification says that an implementation must be able
   to reassemble packets of at least 576 or so bytes.  So, we are way above
   the "minimum maximum transmission unit size".  Actually, we can
   fragment and reassemble packets of up to 1920 bytes, the size of a
   packet buffer (based on the size of 2 pages of memory minus some header
   information).

       I agree that it should also do fragmentation and handle IP packets of up to 16
       kilobytes, but in terms of the IP specification, this is optional.

   I also agree that we should do fragmentation and reassembly of larger IP
   packets and it has been on my queue for some time.  Since this is an
   optional item and can usually be worked around, other things have taken
   higher priority.


I have wanted this for a long time also.  Dealing with much larger packet
sizes should really boost NFS performance.  As more and more users are
using NFS this will probably become more important.

--Dan