Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!uunet!spool.mu.edu!sdd.hp.com!usc!julius.cs.uiuc.edu!rpi!clarkson!grape.ecs.clarkson.edu!nelson From: nelson@sun.soe.clarkson.edu (Russ Nelson) Newsgroups: comp.protocols.tcp-ip Subject: Re: problem with ftp Message-ID: Date: 12 Feb 91 21:52:28 GMT References: <1991Feb9.190400.6078@Think.COM> <9102111926.AA09697@jessica.stanford.edu> Sender: @grape.ecs.clarkson.edu Reply-To: nelson@clutx.clarkson.edu (aka NELSON@CLUTX.BITNET) Organization: Clarkson University, Potsdam NY Lines: 24 In-Reply-To: almquist@JESSICA.STANFORD.EDU's message of 11 Feb 91 19:26:29 GMT In article <9102111926.AA09697@jessica.stanford.edu> almquist@JESSICA.STANFORD.EDU ("Philip Almquist") writes: IP networks are required to support 68 octet packets without network layer (IP) fragmentation (RFC 791 page 25). The Internet folklore that says that this number is 576 is erroneous. Every IP host must be able to receive (and reassemble if necessary) 576 octet datagrams (RFC 791 page 25). Historically (and arguably still today) it has been unwise to send larger datagrams to hosts on distant networks (even when the remote host was prepared to receive larger datagrams), since larger datagrams increase the likelihood that intermediate networks will perform fragmentation, causing degraded performance. Or worse. A few years ago a user at a certain unnamed milnet host was unable to FTP to a PC under my purview running KA9Q. I had set the PC's MTU to 1024. When I set the MTU down to 576, he had no troubles. Hopefully his software has been fixed by now, but I'll take the hit in efficiency rather than spend time answering questions. -- --russ I'm proud to be a humble Quaker. It's better to get mugged than to live a life of fear -- Freeman Dyson I joined the League for Programming Freedom, and I hope you'll join too.