Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!seismo!husc6!think!ames!sdcsvax!ucbvax!XX.LCS.MIT.EDU!Lixia
From: Lixia@XX.LCS.MIT.EDU (Lixia Zhang)
Newsgroups: comp.protocols.tcp-ip
Subject: Re: Datagram sizes
Message-ID: <12306822194.48.LIXIA@XX.LCS.MIT.EDU>
Date: Sun, 31-May-87 15:13:24 EDT
Article-I.D.: XX.12306822194.48.LIXIA
Posted: Sun May 31 15:13:24 1987
Date-Received: Tue, 2-Jun-87 02:22:11 EDT
References: <hinden@CCV.BBN.COM>
Sender: daemon@ucbvax.BERKELEY.EDU
Distribution: world
Organization: The ARPA Internet
Lines: 46

>	Isn't this fun.  No simple solutions.
I think there exist simple answers to the problem.

1.As Vint pointed out, IP fragmentation is not designed for performance
  optimization purpose.  That is probably why one faces so complicated
  tradeoffs when trying to play with the fragmentation beyond its intended
  goals.  So just avoid fragmentation if you can (or until someday when IP
  fragmentation is redesigned for regular usage).

  Considerations like TCP header or ack overhead are TCP design
  considerations.  Since TCP was designed to be "general purpose", the
  overhead with possibly small segment size should have been justified
  during design; if not, the design should have provided tunings (e.g.
  smaller header, and accumulated ack) to reduce the overhead.

  I'm not saying that TCP must achieve highest throughput indenpendently from
  the network support, but rather,
  (1)TCP design should make sure that the overhead will not cause a big
     concern even when the net does not support large TCP segment size;
  (2)higher and lower layer protocols should collaborate to whatever extent
     possible for a overall better performance, but should not misuse the
     network functions that are not designed for the purpose.
    (An analogy: relying on IP redirect is not the solution to the EGP
     extra-hop problem; EGP got to fix itself.)

2.(just for fun, I'm not suggesting this) if wanted to play with
  fragmentation for performance, there is a simple answer too.  An optimal
  decision can always be made when all the information needed for such a
  decision is available.
  By common sense, it is suggested that gateway fragmentation is costly and
  should be avoided if possible.  IF other tradeoffs must also be evaluated,
  then an ideal is to let the source host know, so that it can do the same
  computation as you did about the gain and loss with each IPgram size and
  make a right choice every time.  (There are many more other issues to
  worry than just TCP overhead: the cost of fragmentation at gateways,
  the probability and cost of fragment losses ...)

  In reality it is probably impossible/infeasible to equip hosts with all
  the complicated knowledge/information, therefore an engineering tradeoff
  is between how much knowledge to build into the host, and how much
  performance gain we get by the complication.  The answer is simple,
  the engineering is difficult.  You always have a hard time when using a
  wrong tool to fix things.

Lixia
-------