Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Path: utzoo!mnetor!uunet!husc6!hao!ames!ucbcad!zen!ucbvax!AI.AI.MIT.EDU!PAP4 From: PAP4@AI.AI.MIT.EDU ("Philip A. Prindeville") Newsgroups: comp.protocols.tcp-ip Subject: Re: TCP maximum segment size determination Message-ID: <283529.871110.PAP4@AI.AI.MIT.EDU> Date: Tue, 10-Nov-87 23:52:11 EST Article-I.D.: AI.283529.871110.PAP4 Posted: Tue Nov 10 23:52:11 1987 Date-Received: Wed, 18-Nov-87 03:58:34 EST Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 34 My apologies if someone has already thought of this, but mail to my site is being delayed by up to 5 days, and seems to arrive in random order. But, here goes anyway: Date: Thu, 05 Nov 87 21:31:54 CST From: Bruce Orchard Subject: TCP maximum segment size determination [ ... ] 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. [ ... ] 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. What about the required overhead for gateways and routers to have to further inspect each packet? It could be optimized so that only TCP packets are inspected, but still, that would seem to add to the burden of possibly compute-bound gateways... P.S. Is the MTU of SATNET really 256 bytes, as given in IEN 192? Could be worse, could be the 128 byte MTU of most X.75 implementations... -Philip