Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!seismo!rutgers!ames!ucbcad!ucbvax!apolling.UUCP!geof
From: geof@apolling.UUCP (Geof Cooper)
Newsgroups: comp.protocols.tcp-ip
Subject: Re: IP Datagram sizes
Message-ID: <8705281737.AA00159@apolling.imagen.uucp>
Date: Thu, 28-May-87 13:37:20 EDT
Article-I.D.: apolling.8705281737.AA00159
Posted: Thu May 28 13:37:20 1987
Date-Received: Sat, 30-May-87 09:37:43 EDT
Sender: daemon@ucbvax.BERKELEY.EDU
Reply-To: imagen!geof@decwrl.DEC.COM
Distribution: world
Organization: The ARPA Internet
Lines: 22


 >      In other words, negotiate a value that is too large rather than too
 >      small, and use as large a value as gets through without fragmenting
 >      (without exceeding the negotiated value of course). Such a scheme is
 >      also compatible with what is currently implemented. Old TCP
 >      implementations will negotiate small MSS's. 

Ummm, the sending TCP doesn't know that the packets are being fragmented.
The receiving TCP does.  As John Wobus states, you have to treat the
different directions differently.

If a TCP-level solution is really the way of choice (I don't believe it
is) then just allow the MSS option to exist on ANY packet.  Beyond the
first packet the interpretation is that it is an advisory value, relating
to fragmentation.  I think this is the smallest change to the TCP spec
to make things work.  It also should work fine with all existing
implementations, since the MSS option should just be ignored past the
first packet (there is probably some implementation out there who sends
mail to the system maintainer of the other system, flaming at him to
fix his TCP....).

- Geof