[503] in linux-net channel archive
Re: CONFIG_INET_SNARL: What for?
daemon@ATHENA.MIT.EDU (C. Harald Koch)
Wed Jun 14 23:37:26 1995
To: shields@tembel.org (Michael Shields)
cc: Pjnesser@rocket.com (Philip J. Nesser), urlichs@smurf.noris.de,
submit-linux-dev-net@ratatosk.yggdrasil.com
In-reply-to: shields's message of "Tue, 13 Jun 1995 21:55:23 -0400".
<m0sLhfw-000DUbC@yage.tembel.org>
Date: Wed, 14 Jun 1995 10:44:14 -0400
From: "C. Harald Koch" <harald@enfm.utcc.utoronto.ca>
> You cannot tell the size of the block from the address. ifconfig knows
> the correct netmask and that's what should be used.
If you send a full-size packet packet on FDDI (with an 4352 byte MTU), and
it crosses onto an Ethernet, (with a 1500 byte MTU), Then the router must
fragment the packet into three pieces to deliver it.
This (obviously) gets worse when talking across serial links that use the
Internet standard MTU of 576 bytes.
Unecessary fragmentation is always considered bad. It increases packet loss
probability (lose any fragment, and the whole packet is bad), it means that
a gateway must generate the fragments, and the receiving host must buffer
the fragments and perform reassembly.
To quote from RFC 894 (IP datagrams over Ethernet):
Note: Datagrams on the Ethernet may be longer than the general
Internet default maximum packet size of 576 octets. Hosts connected
to an Ethernet should keep this in mind when sending datagrams to
hosts not on the same Ethernet. It may be appropriate to send
smaller datagrams to avoid unnecessary fragmentation at intermediate
gateways. Please see [4] for further information on this point.
[4] is RFC 879, "The TCP Maximum Segment Size Option and Related Topics",
However (and this is important), 576 byte packets are inefficient if
everything between you and your destination is an Ethernet or PPP link (both
with MTU 1500).
Ideally, you would want to transmit packets that are just small enough not
to be fragmented on the path between you and your destination; this value is
the "Path MTU". There is an algorithm for determining the path MTU for a
given path between two hosts; this is described in RFCs:
1191 DS J. Mogul, S. Deering, "Path MTU Discovery", 11/16/1990. (Pages=19)
1435 I S. Knowles, "IESG Advice from Experience with Path MTU Discovery",
03/17/1993. (Pages=2) (Format=.txt)
This is the current best way to handle the problem of determining the MTU to
use to send to a particular destination.
--
C. Harald Koch | University of Toronto Computing & Communications
harald@canet.ca | Network & Operations Services
+1 416 978 0992 (voice) | External Network Facilities Managment
+1 416 978 6620 (fax) | 4 Bancroft Ave., Rm 101, Toronto, ON M5S 1C1
