Comparing an old flow snapshot with some packet size data
Robert Moskowitz
At 12:20 AM 8/10/96 -0400, Andrew Partan wrote:
>
>The question is, if you were designing a backbone today, what would
>you use for your hub LANs? Fddi? Or 100baseT? 100baseT is probably
>going to be a lot cheaper (it looks like there is going to be a
>*lot* of it made), but its MTU is 1500.
>
>Can you get by with this? Or do you really need to invest in LANs
>that do 4470?
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
(810) 758-8212
Robert Moskowitz
At 11:23 AM 8/21/96 -0700, Kent W. England wrote:
>
>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.
If it does it wrong, it negatively impacts on congestion (buffer full).
>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.
Thanks Kent.
John Hawkinson
> 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.
Kent, I think you're slightly confused.
Part of this is what defines "the mtu a backbone can support".
There are two ways (at least!) to look at that:
1. The minimum MTU of all the interfaces in the
backbone.
2. Various buffering considerations on all of the
equipment involved in the backbone.
Without the former, the latter seems kind of irrelevent, since path
MTU discovery will never let you go above that minimum (and rightly
so).
If you say that "backbones should support up to 9180" then you've just
disallowed most folks' DS3 interfaces and FDDI, and are mandating that
folks should all go and use ATM. I think you're well aware there are a
strong contingent of people who will not throw out their DS3 and FDDI
infrastructure for ATM :-)
I think the brunt of asp's question was really "Is it acceptable for
a backbone service provider to provide a min mtu of 1500 instead of
a min mtu of of 4352". What this really translates into is:
Is it OK for a backbone service provider to use fast ethernet
as a interconnect medium instead of FDDI.
Answers seem varied, some folks may have contractual obligations to
provide that 4k MTU, but most don't.
Is that 4k MTU worth the trade-offs? It's certainly the case that the
1.5k MTU isn't very-well exploited right now, and it's difficult to
see the 4k MTU being exploited well in the short term, though it
may be that end-users who check the "4k MTU requirement" checkbox
are actually folks who have lots of hosts with 4k MTUs on their
interfaces who exchange significant amounts of traffic with others
who have similarly-configured hosts and who implement path MTU
discovery and "all that good stuff".
--jhawk
Kent W. England
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
>(810) 758-8212
>
>
>
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
Dorian R. Kim
On Wed, 21 Aug 1996, John Hawkinson wrote:
> If you say that "backbones should support up to 9180" then you've just
> disallowed most folks' DS3 interfaces and FDDI, and are mandating that
> folks should all go and use ATM. I think you're well aware there are a
> strong contingent of people who will not throw out their DS3 and FDDI
> infrastructure for ATM :-)
Along with problematic buffering problems with certain vendor equipment for
9180 MTU.
> I think the brunt of asp's question was really "Is it acceptable for
> a backbone service provider to provide a min mtu of 1500 instead of
> a min mtu of of 4352". What this really translates into is:
>
> Is it OK for a backbone service provider to use fast ethernet
> as a interconnect medium instead of FDDI.
>
> Answers seem varied, some folks may have contractual obligations to
> provide that 4k MTU, but most don't.
>
> Is that 4k MTU worth the trade-offs? It's certainly the case that the
> 1.5k MTU isn't very-well exploited right now, and it's difficult to
> see the 4k MTU being exploited well in the short term, though it
> may be that end-users who check the "4k MTU requirement" checkbox
> are actually folks who have lots of hosts with 4k MTUs on their
> interfaces who exchange significant amounts of traffic with others
> who have similarly-configured hosts and who implement path MTU
> discovery and "all that good stuff".
It seemed to me intuitively that anything above 1500 MTU doesn't buy one much,
so I went to my routers and checked, just to be sure.
dgb>sh ip ca flow
IP packet size distribution (6502M total packets):
1-32 64 96 128 160 192 224 256 288 320 352 384 416 448 480
.002 .513 .048 .017 .025 .007 .007 .010 .014 .014 .004 .005 .005 .002 .002
512 544 576 1024 1536 2048 2560 3072 3584 4096 4608
.006 .006 .174 .000 .076 .052 .000 .000 .000 .000 .000
IP packet size distribution (6283M total packets):
1-32 64 96 128 160 192 224 256 288 320 352 384 416 448 480
.002 .515 .049 .016 .024 .007 .007 .016 .011 .013 .007 .006 .007 .002 .002
512 544 576 1024 1536 2048 2560 3072 3584 4096 4608
.005 .006 .160 .000 .081 .053 .000 .000 .000 .000 .000
dgd>sh ip ca flow
IP packet size distribution (1182M total packets):
1-32 64 96 128 160 192 224 256 288 320 352 384 416 448 480
.001 .480 .062 .015 .011 .008 .007 .012 .011 .014 .004 .009 .007 .003 .002
512 544 576 1024 1536 2048 2560 3072 3584 4096 4608
.005 .004 .136 .000 .125 .074 .000 .000 .000 .000 .000
So unless my routers aren't telling the truth, there are significant amount of
> 1500 byte packets floating in my network. I'm somewhat mystified as to where
2048 comes from, but they are there nonetheless, and in our application, it
seems to me that 4K MTU is a good thing.
-dorian