Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Path: utzoo!mnetor!seismo!rutgers!ames!ucbcad!ucbvax!AMES-NAS.ARPA!yamo From: yamo@AMES-NAS.ARPA (Michael J. Yamasaki) Newsgroups: comp.protocols.tcp-ip Subject: Re: Re: IP Datagram sizes Message-ID: <8705261555.AA14106@ames-nas.arpa> Date: Tue, 26-May-87 11:55:33 EDT Article-I.D.: ames-nas.8705261555.AA14106 Posted: Tue May 26 11:55:33 1987 Date-Received: Thu, 28-May-87 02:11:07 EDT Sender: daemon@ucbvax.BERKELEY.EDU Distribution: world Organization: The ARPA Internet Lines: 48 Greetings. > From: Hans-Werner Braun > > What are we really talking about? Most of what we are discussing implies > the difference from 576 bytes to 1500 bytes, i.e., the maximum record > size on an Ethernet. But 1500 bytes is less then three times the 576 bytes. > In the longer run, i.e., a very few years, what we REALLY need are much > larger packets then 1500 bytes. This will become imperative with the > expected appearance of very high speed networks. I cannot help myself > thinking that a reasonable thing to do for today, supposing you want to > reach other then your local net, is to rather stick with the 576 byte > limit (a limit that is spelled out all over the place) and rather design > future networks which allow at least 20K or 40K packets on very high speed > networks which might run at multiple hundreds of megabits per second or > higher. Even if the local speeds are much lower then this, there could be i > [...] Uh, gee, I was really appreciative that this issue (IP MSS negotiation) was brought up because at this very moment I've been grappling with the problem of high speed file transfer over a NSC HYPERchannel network. In the short term I developed a simple ACK-NAK protocol so that I could transfer in 56K blocks (Why 56K is a long story. Why "blocks" instead of "packets" is that in the HYPERchannel world "packets" is not a useful term.). It just seems too boggling to tackle the issues associated with the MSS problem that we face here at NASA/Ames all at once, which would be required to use our normal vehicle for file transfer namely TCP/IP. Our MSS for the HYPERchannel network is 4K data + the HYPERchannel header. This stresses the buffer management schemes of our 4.2, 4.3 and TWG/SV versions quite well (can you say crash and burn when two many rcp's happen at once ;-). We have drivers on some of our machines (Cray 2, Amdahl 5840, SGI IRIS) which can handle greater than 4K data (up to 64K). Consequently, our local net could conceivably have quite a range of MSSs. In addition, all of our local hosts with the exception of the Cray 2 have Ethernet connections and plans are in the near term to experiment with a token ring net and FDDI as soon as... Add Vitalinks, ARPAnet, gateways... Anyway, I just wanted to say that this is not a solution in search of a problem. Selecting 576 for a gateway between ethernet and HYPERchannel is a losing proposition. Add the additional wrinkle that the host rather than the network chooses the maximum size it can accept (HYPERchannel has no theoretical upper bound on segment size although mileage may differ...). An end to end protocol for MSS negotiation seems very appropriate. -Yamo- Thanks, Art, for bringing up an important issue.