Re: Comparing an old flow snapshot with some packet size data

["Kent W. England" <[e-mail]>]

At 02:11 PM 8/16/96 -0400, Robert Moskowitz wrote:

>I want to know, even with HTTP 1.1, what percent of traffic benefits from
>the larger MTU?  And if you allow the larger MTU, what does it do to those
>elephants versus all of the little mice?
>
>
>Robert Moskowitz
>Chrysler Corporation
>[phone]
>
>
>
It seems there is some confusion about what clients should set the MTU to be
(no more than what can be expected to work without fragmentation) versus
what maximum MTU a backbone should support (the largest possible allowing
for buffer memory efficiency). These are quite different. If a client sets
too large an MTU, then it suffers fragmentation. If a backbone sets the MTU
too large, then all that happens is some buffer memory might be wasted. No
client applications are affected by a too large MTU on the backbone.

(Technically, a backbone doesn't have an MTU except for traffic originated
by the routers. What we are really talking about is "maximum packet size
configured into the routers" and "host MTU", respectively.)

What seems obvious to me is that 1500 bytes is a safe bet for an MTU today.
By this I mean that a host can set the MTU to 1500 bytes and it will usually
work off local subnet.

Backbones must support at least 1500 bytes and should support up to 9180.
The only difference is how the routers use memory for buffering. If each
packet is allocated the router's MTU, then there is a lot of wasted buffer
memory between 500 bytes typical and 9180. If a router vendor has a problem
with that much memory wastage, then I'd say it was up to them to allocate,
say, 1500 bytes per packet, and handle an exception for anything beyond that
MTU.

So let's see to it that the backbones can handle anything up to ATM 9180 and
try to get hosts to use path MTU discovery or their interface MTU of at
least 1500.

--Kent