Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!seismo!gatech!hao!husc6!think!ames!sdcsvax!ucbvax!G.BBN.COM!CLYNN
From: CLYNN@G.BBN.COM
Newsgroups: comp.protocols.tcp-ip
Subject: Re: IP Datagram sizes
Message-ID: <[G.BBN.COM]22-May-87.20:11:55.CLYNN>
Date: Fri, 22-May-87 20:11:00 EDT
Article-I.D.: <[G.BBN.COM]22-May-87.20:11:55.CLYNN>
Posted: Fri May 22 20:11:00 1987
Date-Received: Sat, 23-May-87 18:05:56 EDT
Sender: daemon@ucbvax.BERKELEY.EDU
Distribution: world
Organization: The ARPA Internet
Lines: 20

Art,
	I don't think that we NEED more message types (although I have
suggested some).  We have a Very Strong Hint already in place - all we
need to do is to have the IP reassembly code notice the size of the
First fragment of a fragmented datagram and pass it up to the higher
layers.  TCP could then send the appropriate max seg size option to the
other end; the routing table could record it for use in subsequent
connections (by the time a packet is fragmented, it MAY be too late
to help the current connection, depending on the packetization
algorithm being used).
	This assumes that the IP fragmentation algorithms split a
datagram so that the size of the first fragment is determined by the
MTU (and not, for example, into n equal pieces).  Are there any
implementations which do not make the first fragment as large as possible??
	Note that this is one of the things that a system may do without
the need for cooperation from other systems.  Note also, that since
route going and coming may not be the same, the size a system finds may
not be the best one for datagrams it sends.

Charlie