Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!seismo!rutgers!ames!sdcsvax!ucbvax!A.ISI.EDU!CERF
From: CERF@A.ISI.EDU
Newsgroups: comp.protocols.tcp-ip
Subject: Re: Datagram sizes
Message-ID: <[A.ISI.EDU]31-May-87.07:38:54.CERF>
Date: Sun, 31-May-87 07:38:00 EDT
Article-I.D.: <[A.ISI.EDU]31-May-87.07:38:54.CERF>
Posted: Sun May 31 07:38:00 1987
Date-Received: Tue, 2-Jun-87 01:42:43 EDT
References: <hinden@CCV.BBN.COM>
Sender: daemon@ucbvax.BERKELEY.EDU
Distribution: world
Organization: The ARPA Internet
Lines: 31

Bob,

thanks for a very helpful summary. By this time it should be apparent
that fragmentation at the IP level is not and never was intended to do
more than provide flexibility to deal with systems having different
maximum packet sizes without the source having to know what path the
datagrams were taking. 

Such "blind" flexibility has a performance cost - and was intended 
mostly to deal with the case that the "system" was not or could not
be engineered ahead of time for performance and consistency.

Now that we are focusing, properly, on performance, it seems clear
that the source needs to know (find out? be told?) more about
internet conditions, at least on the paths its datagrams are taking.
similarly, the source needs to be able to assert more precisely
what its requirements are to aid the gateway routing system in choosing
paths.

I hope everyone who is working on and thinking about this problem will
continue to consider the tradeoff between performance and ability to
cope with the unexpected (so important for crisis management). Our
objective should be to learn how to engineer for high performance without
losing our ability to deal with the case where we have only ad hoc
connectivity and no control over paths taken.

If there are folks out in Internetland with markedly different opinions
on these points, I'm very interested to hear them and to understand the
line of reasoning which leads to other conc ( ( PhyPhyPsiz