Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!uunet!husc6!hao!ames!ucbcad!ucbvax!SCARECROW.WAISMAN.WISC.EDU!ORCHARD/BRUC
From: ORCHARD/BRUC@SCARECROW.WAISMAN.WISC.EDU (Bruce Orchard)
Newsgroups: comp.protocols.tcp-ip
Subject: TCP maximum segment size determination
Message-ID: <2.716@scarecrow.waisman.wisc.edu>
Date: Thu, 5-Nov-87 22:31:54 EST
Article-I.D.: scarecro.2.716
Posted: Thu Nov  5 22:31:54 1987
Date-Received: Thu, 12-Nov-87 06:36:16 EST
Sender: usenet@ucbvax.BERKELEY.EDU
Organization: The ARPA Internet
Lines: 51

Consider a TCP connection passing through 3 networks: An Ethernet,
the ARPANET, and another Ethernet.  There are gateways between
each Ethernet and the ARPANET.  At connection time, each host must
choose a maximum segment size for the TCP segments it transmits.
The selection algorithm is generally to take the minimum of the
maximum size allowed by the receiver (given in the TCP maximum
segment size option), the maximum size allowed by the network the
host is connected to (in this case, an Ethernet), and the maximum
the transmitting host can handle.  Allowing integral multiples of
the local network maximum would be reasonable too.  All this has
to allow enough space for headers.

Now the maximum size allowed by an Ethernet is 1500 bytes, but the
maximum allowed by the ARPANET is 1007 bytes.  If a maximum
segment size greater than 1007 is picked by the transmitting end,
the gateway going into the ARPANET will fragment the message.  A
segment of 1500 bytes would get split into one of about 1000 bytes
and another of about 500 bytes.  One particularly poor choice I
have seen used is a maximum segment size of 1024 bytes.  Since the
1024 bytes excludes headers, this results in one fragment of 1007
bytes and another 77 bytes.

The real problem is that the transmitting end has no knowledge of
the limits of networks it is not connected to.  Therefore, I
propose adding a new option to the IP header.  This option would
give the minimum of the maximum transmission units of any network
that handled the packet.  The originating end would set it to a
large value.  Each node that transmitted the packet would compare
the value given in the option to the maximum transmission unit of
the outgoing network.  If the network value were less, the value
in the option would be reduced to the network value.

This IP header option would be used by TCP on the packet that
includes the TCP maximum segment size option.  The receiving TCP
would consider both the maximum allowed by its peer TCP (in the
TCP option) and the maximum allowed by any network along the way.
It would probably take the lessor of the two.

One limitation of this proposal is that all packets of a TCP
connection do not necessarily pass through the same networks.
Actually, given the way the networks are connected, all packets
usually go through the same networks.  Also, if one packet takes a
different route from an earlier packet, the second route could be
on the same kind of network (for example, two parallel Ethernets).
Regardless, the consequence of a poor choice is reduced
throughput, not failure.

Bruce Orchard
University of Wisconsin-Madison

P.S.  Is the MTU of SATNET really 256 bytes, as given in IEN 192?