lynch@theory.tn.cornell.edu (Tim Lynch) (10/25/90)
Hello, Well, here's a new one for me. We've recently set up some Sun and DEC machines in our library. Everything seems to work fine except for ftp going from one of our machines to a remote machine. That is, if we try to move a file from a local machine to a remote machine, the transfer goes so slowly as to usually timeout. Moving a file in the other direction works fine. By remote, I mean a machine off campus. We've set up machines on the net before, so I believe we've got all the basics correct: - We've checked our netmask, broadcast mask - We've checked to make sure the default route is correct - Trailers are off. Any ideas? I've not seen anything like this before and am really stumped. I can provide more information, but am hoping this is a problem others might have experienced and would know the answer off the top of their head. Tim Lynch, Mann Library
goud@sicsun.epfl.ch (Mireille Goud) (02/07/91)
I have a problem with ftp :
I noticed that the packets size depends on the address of the hosts :
- If the 2 hosts are on the same network (same B class
address) the size of the packets is negociated between the 2 hosts.
- If the 2 hosts are not on the same network (they don't have
the same class address) the size of the packets is 512 bytes.
1. Is this a ftp problem or a tcp problem ?
2. Is there a solution to have big packets (4K bytes on fddi) even if
the 2 hosts are not on the same network ?
Thanks.
Mireille
----------------------------------------------------------------------
Mireille Goud
SIC EPFL
Switzerland INET : goud@sic.epfl.chbarmar@think.com (Barry Margolin) (02/10/91)
In article <1991Feb6.184300@sicsun.epfl.ch> goud@sicsun.epfl.ch (Mireille Goud) writes: > - If the 2 hosts are on the same network (same B class >address) the size of the packets is negociated between the 2 hosts. > - If the 2 hosts are not on the same network (they don't have >the same class address) the size of the packets is 512 bytes. >1. Is this a ftp problem or a tcp problem ? It's a problem/feature of many TCP implementations. The reason it is done is that the goal is to prevent fragmentation of datagrams. Hosts on the same network can agree to base the max segment size (MSS) on the maximum packet size (called the MTU -- Max Transmission Unit) of the network. If they are on different networks, though, they don't know what the smallest MTU is of all the intervening networks, except that all networks in a TCP/IP internet are required to support at least 512-byte packets (actually, I think the number is something like 568, to allow 512-byte TCP segments plus IP and TCP headers). >2. Is there a solution to have big packets (4K bytes on fddi) even if >the 2 hosts are not on the same network ? There is work going on to develop "path MTU discovery" mechanisms. Also, some TCP implementations use a larger MSS for subnet that are part of the same subnetted network than for outside networks (on the assumption that local area media are faster than wide area media, so the consequences of greater retransmission due to loss of a fragment are less severe). -- Barry Margolin, Thinking Machines Corp. barmar@think.com {uunet,harvard}!think!barmar
almquist@JESSICA.STANFORD.EDU ("Philip Almquist") (02/12/91)
Barry, > It's a problem/feature of many TCP implementations. The reason it is done > is that the goal is to prevent fragmentation of datagrams. Hosts on the > same network can agree to base the max segment size (MSS) on the maximum > packet size (called the MTU -- Max Transmission Unit) of the network. If > they are on different networks, though, they don't know what the smallest > MTU is of all the intervening networks, correct so far, but > except that all networks in a > TCP/IP internet are required to support at least 512-byte packets > (actually, I think the number is something like 568, to allow 512-byte TCP > segments plus IP and TCP headers). 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). Thus, it is technically a protocol error to send a datagram larger than 576 to any host unless the sending host knows (perhaps because of a TCP maximum segment size negotiation or an agreement between the system managers) that the receiving host can accept larger datagrams. 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. It is recommended (but, surprisingly, not required) that a host be able to receive (and reassemble if necessary) a datagram at least as large as the MTU of its connected network (RFC 1122 page 56). Because most hosts follow this recommendation, it usually works to send MTU-sized datagrams to other hosts on the same (sub)net. However, as described above, there are no guarantees. The default TCP maximum segment size is 536 (not 512) octets, for the reasons you gave (to allow 40 octets for IP and TCP headers - RFC 1122 page 85). Finally, a minor nit: the standards talk about octets rather than bytes. Octets are eight bit quantities. Bytes are also eight bit quantities on most most modern computers, but computer architecture is beyond the scope of the TCP/IP standards. Philip
vjs@rhyolite.wpd.sgi.com (Vernon Schryver) (02/12/91)
In article <1991Feb9.190400.6078@Think.COM>, barmar@think.com (Barry Margolin) writes: > .... Also, > some TCP implementations use a larger MSS for subnet that are part of the > same subnetted network than for outside networks (on the assumption that > local area media are faster than wide area media, so the consequences of > greater retransmission due to loss of a fragment are less severe). Some might fear worse consequences of IP fragementation in such an environment, because the routers are likely to be general purpose systems which just happen to have additional ethernet interfaces, and may not have an abundance of buffering. The justification I've heard most often for such switches is that the MTU in the local internet is at least as large as the MTU on local ethernet, 1500 bytes. In such a case, 1500 causes no more fragmentation than 576. I have seen large commerical, production networks where using 1500 instead of the approved 576 improved FTP performance 3X. The default configuration on an IRIS is "allsubnetsarelocal=true". Do you guys consider this Evil, Wrong, and Grounds for Belittling Remarks? Vernon Schryver, Silicon Graphics, vjs@sgi.com
barmar@THINK.COM (Barry Margolin) (02/12/91)
Date: Mon, 11 Feb 91 11:26:29 -0800
From: "Philip Almquist" <almquist@jessica.stanford.edu>
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.
Thanks for the correction. However, it's reasonably safe to assume that
most media have an MTU of at least 512. I can't think of any that
don't, and I would be surprised if anyone invented a new medium with a
smaller MTU (the current direction is generally towards larger packet
sizes).
Finally, a minor nit: the standards talk about octets rather than bytes.
Octets are eight bit quantities. Bytes are also eight bit quantities on
most most modern computers, but computer architecture is beyond the
scope of the TCP/IP standards.
I know that, and I debated using "octet" in my message. I chose to use
terminology consistent with the question. It's rarely necessary to make
this fine distinction outside standards documents (people on systems
with non-8-bit-bytes generally know how to translate to their own frame
of reference).
barmaralmquist@JESSICA.STANFORD.EDU ("Philip Almquist") (02/12/91)
Barry, > However, it's reasonably safe to assume that > most media have an MTU of at least 512. I can't think of any that > don't, and I would be surprised if anyone invented a new medium with a > smaller MTU (the current direction is generally towards larger packet > sizes). SATNET had an MTU of somewhere around 250, if I recall correctly, but I'm pretty sure it's now defunct. I also seem to recall that Van uses a similar MTU over his compressed SLIP dialup line (since he doesn't preempt an FTP data packet that is being transmitted when a Telnet packet is queued for transmission, he wants to ensure that the FTP data packet is short enough that its transmission can be completed without noticeably delaying the transmission of the Telnet packet). I don't know what sorts of MTUs are used for packet radio, but they may be pretty small for similar reasons. ATM networks will also use very small packets, but I guess the expectation is that they will do Link Layer fragmentation to present the appearance of a reasonably large MTU to the Network Layer. In general, I agree that the trend is for new kinds of networks to have much larger MTUs. >> Finally, a minor nit: the standards talk about octets rather than bytes. > I know that, and I debated using "octet" in my message. I chose to use > terminology consistent with the question. It's rarely necessary to make > this fine distinction outside standards documents... Like I said, it was a minor nit, and I almost omitted it. You should probably chalk it up to fond memories of the days when I worked on computers which have a far more flexible concept of what a "byte" is. Philip
cpw@SNOW-WHITE.LANL.GOV (C. Philip Wood) (02/12/91)
Vernon, >The default configuration on an IRIS is "allsubnetsarelocal=true". >Do you guys consider this Evil, Wrong, and Grounds for Belittling Remarks? No, but some subnets are more equal than others. :^) Phil
nelson@sun.soe.clarkson.edu (Russ Nelson) (02/13/91)
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 <nelson@clutx.clarkson.edu> 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.mogul@wrl.dec.com (Jeffrey Mogul) (02/13/91)
In article <19910211212243.8.BARMAR@OCCAM.THINK.COM> barmar@THINK.COM (Barry Margolin) writes: > From: "Philip Almquist" <almquist@jessica.stanford.edu> > > 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. > >Thanks for the correction. However, it's reasonably safe to assume that >most media have an MTU of at least 512. I can't think of any that >don't, and I would be surprised if anyone invented a new medium with a >smaller MTU (the current direction is generally towards larger packet >sizes). RFC1191 ("Path MTU Discovery Protocol") lists all the MTUs I could track down when I was writing it. Several networks have MTU == 508, and in RFC1144, Van Jacobson points out that on low-speed links (like telephone lines) the use of too large an MTU may increase the delays encountered to the point where they become unpleasant. To quote: From the discussion in sec. 2, it seems desirable to limit the maximum packet size (MTU) on any line where there might be interactive traffic and multiple active connections (to maintain good interactive response between the different connections competing for the line). The obvious question is `how much does this hurt throughput?' It doesn't. However, when Chris Kent invented the old "use 576 if non-local" rule, he was attempting to avoid fragmentation-induced communication failure without unduly reducing throughput. 576 is a compromise; it is essentially an arbitrary number that was chosen because it seemed less arbitrary than any other choice. Until you can rely on PMTU Discovery, the 576-rule works pretty well, but it does not guarantee non-fragmentation. -Jeff
raj@hpindwa.cup.hp.com (Rick Jones) (02/20/91)
A bit of drift, but which routers support MINMTU (RFC 1191) at this point?... rick jones
mogul@wrl.dec.com (Jeffrey Mogul) (02/23/91)
In article <36540022@hpindwa.cup.hp.com> raj@hpindwa.cup.hp.com (Rick Jones) writes: >A bit of drift, but which routers support MINMTU (RFC 1191) at this >point?... I don't know of any routers which support the new form of ICMP message defined in RFC1191, but it is important to understand that the protocol was designed to work with any router that conforms to existing standards (for IP and ICMP). You just get faster results when the routers implement RFC1191. For 4.3BSD-based routers: I did a pilot implementation while writing the RFC, and I can provide the necessary changes. To be sure: if any router vendor does implement RFC1191, I probably wouldn't know about it. -Jeff