BUDDENBERGRA@A.ISI.EDU.UUCP (05/27/87)
The discussion seems close to an observation I've run across. Packet size and datagram size have historically been a function of buffer size, since that was the bottleneck. It seems that the controlling factor in packet size is noise. Shorter packets are more noise resistant, all other controlling parameters constant. Rex Buddenberg -------
CERF@A.ISI.EDU.UUCP (05/28/87)
Rex, the noise argument, while true in some absolute sense, has some interesting new twists owing to new transmission media and methods. Fiber and coax LANs are quite low in noise and can support very large packets while achieving quite satisfactory error rates. Forward error correction schemes are more feasible now than ever owing to higher speed and larger memory VLSI chips. As a result, the absolute packet asize at which noise becomes a problem is considerably larger, FOR SOME NETWORKS, than used to be the case. Vint
leiner@riacs.EDU (05/29/87)
Vint, Right. Presumably, each network would be designed to use a maximum packet size appropriate to its technology. The right maximum on an end to end basis is sort of the minimum of those across the multiple networks in the path. Right? Barry ----------
hinden@CCV.BBN.COM.UUCP (05/30/87)
I am not sure that it is always the best strategy to avoid IP fragmentation. There are some cases where it might provide better service. I think that in cases of networks where the MTU are large and not too divergent, avoiding fragmentation by using the minimum MTU is good. A good example is a 1500 byte Ethernet connected to the 1006 byte Arpanet. Using 1006 MTU for the TCP segments probably provides the best service. In the case where one network has a large MTU and the other network has a small MTU it may be better to send one large packet over the first network and have it fragmented. For example, suppose you had 10,000 bytes of data to send using TCP from an Arpanet host to a host on the other side of Satnet (256 MTU). If you assumed an MTU for the connection of 256 it would require 47 datagrams (each w/ 20 bytes IP header, 20 bytes TCP header, 216 bytes of data) to send the data. If you use an MTU of 1006, it would require 11 datagrams (each w/ 20 IP, 20 TCP, 996 data) over the Arpanet and 55 fragments (11 * 5) over Satnet (first with 20 IP, 20 TCP, 216 data, next three with 20 IP, 236 data, last with 20 IP, 72 data). I would think that using the 1006 MTU would provide better service. It reduces the number of datagrams into the Arpanet by a factor of four and adds 8 datagrams into Satnet. Assuming the worst case TCP, it would eliminate 36 TCP ACK's on the return trip. If you take the more complicated case of Ethernet to Arpanet to Satnet, then it is, of course, more complicated. Using 1006 for an MTU would reduce the number of datagrams that the Ethernet-Arpanet gateway would have to send into the Arpanet. This gateway is probably the biggest bottleneck in the path (10M bps in, 50K bps out). Using an MTU of 256 probably causes this gateway to block or drop lots of packets. Using an MTU of 1500 gives one the worst of both worlds. Isn't this fun. No simple solutions. Bob
leiner@riacs.EDU.UUCP (05/30/87)
I stand corrected. Thanks. Barry ----------
CERF@A.ISI.EDU (05/31/87)
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
Lixia@XX.LCS.MIT.EDU (Lixia Zhang) (05/31/87)
> 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
-------