Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Path: utzoo!mnetor!seismo!rutgers!ames!ucbcad!ucbvax!ACC.ARPA!art From: art@ACC.ARPA Newsgroups: comp.protocols.tcp-ip Subject: IP Datagram sizes Message-ID: <8705222146.AA28375@ucbvax.Berkeley.EDU> Date: Fri, 22-May-87 18:12:00 EDT Article-I.D.: ucbvax.8705222146.AA28375 Posted: Fri May 22 18:12:00 1987 Date-Received: Sat, 23-May-87 17:18:00 EDT Sender: daemon@ucbvax.BERKELEY.EDU Reply-To: Distribution: world Organization: The ARPA Internet Lines: 41 I don't recall ever seeing a suggestion such as follows, so I thought that I'd throw the idea out for comment. BACKGROUND: In the internet environment, two end hosts generally don't know what the maximum IP datagram size that can traverse the network is. The current solutions seem to be: 1) negotiate down to the minimum of the datagram limits of the directly connected networks. 2) if using a gateway, use guaranteed limit of 576. 3) use a fixed TCP segment size and don't think about it. Solution 1 can cause lots of unneeded fragmentation (i.e. host-ethernet-arpanet-ethernet-host). Solution 2 may be unnecessarily suboptimal for the path. Solution 3 may perform as either 1 or 2. PROPOSAL: Add an entry to the IP routing table which gives maximum datagram size for sending to this destination network. This entry would be initialized based on the directly attached network used to send to that destination. Add a new ICMP message type which a gateway sends back to an originating host when it fragments an IP datagram. The ICMP message would identify the destination network and specify what size it had to fragment the datagram to. The originating host would update the limits for that network in its IP routing table. The originating host should adjust its segment size (either immediately or on new TCP connection) to optimize IP datagram size. If current implementations ignore the new ICMP message, then they would continue to operate as always. Any Comments? Art Berggreen art@acc.arpa ------