# Avg. Packet Size - Again?

Most of the data and studies I have found on this topic are a bit out of date.

I would be interested in find out what the average packet size people are seeing on their backbones is at this point and time? Also for those in the DC space what is average packet size you are seeing for web farm traffic (outbound)? Yes I know there are 1000's of answers and different possibilities in setups so please no, "this is a dumb question". I am well aware of all the variables involved in this. I am just looking for some data points that come from a wide degree of sources.

Is this data even something that you track and if so why?

Thanks!
Sean

This is all from netflow. The results are from two different routers.

IP packet size distribution (43046M total packets):
1-32 64 96 128 160 192 224 256 288 320 352 384 416 448
480
.000 .382 .077 .043 .022 .012 .011 .006 .007 .004 .004 .005 .003 .003
.003

512 544 576 1024 1536 2048 2560 3072 3584 4096 4608
.005 .002 .007 .021 .375 .000 .000 .000 .000 .000 .000

IP packet size distribution (54192M total packets):
1-32 64 96 128 160 192 224 256 288 320 352 384 416 448
480
.001 .418 .052 .034 .017 .008 .045 .006 .010 .004 .003 .005 .003 .004
.005

512 544 576 1024 1536 2048 2560 3072 3584 4096 4608
.013 .003 .011 .036 .311 .000 .000 .000 .000 .000 .000

I predict that if you graph it, there's a ton of packets that are right
around the MTU of the network. almost equal number of tiny packets carrying
the ACK's of the mobygrams, and then a small noise level of "everything else".

Our network also shows peaks at the ethernet MTU (our MTU is higher than that)
and the DNS packet size.

Our network also shows peaks at the ethernet MTU (our MTU is higher
than that) and the DNS packet size.

so who has been tracking packet size distributions for some years and
has published or could provide data?

randy

As Valdis stated earlier:

I predict that if you graph it, there's a ton of packets that are right
around the MTU of the network. almost equal number of tiny packets carrying
the ACK's of the mobygrams, and then a small noise level of "everything else".

That's pretty much the case for the last decade. Way back when the "net" had more telnet and "terminal based things" the numbers were skewed to the left, but you can hardly say "Hello World" in HTTP/HTML/XML/CSS/Ajax/Javascript these days in under a megabyte

Sample from our border:

UTC-Edge#sho ip cache flow
IP packet size distribution (1566M total packets):
1-32 64 96 128 160 192 224 256 288 320 352 384 416 448 480
.000 .412 .120 .022 .010 .003 .004 .002 .002 .001 .001 .003 .001 .001 .001

512 544 576 1024 1536 2048 2560 3072 3584 4096 4608
.005 .001 .003 .027 .371 .000 .000 .000 .000 .000 .000

versus our core:

UTC-Core#sho ip cache flow
IP packet size distribution (22714M total packets):
1-32 64 96 128 160 192 224 256 288 320 352 384 416 448 480
.000 .453 .073 .022 .011 .052 .069 .045 .011 .005 .009 .013 .020 .007 .001

512 544 576 1024 1536 2048 2560 3072 3584 4096 4608
.001 .001 .001 .009 .188 .000 .000 .000 .000 .000 .000

But those are fairly stock IPv4, no jumbos, plain-jane ethernet numbers.

Jeff

CAIDA has been doing a lot of that, at least in the past. Last I asked them, which was quite a while back, they said that O(35%) of traffic in their samples was at the path MTU (which included 576 bytes for historical reasons), O(40%) was about the size of a TCP SYN or ACK, for reasons that are apparent if you think about common TCP implementations, and sizes were scattered more or less uniformly in between - last packet in a burst or transaction exchanges. From the numbers that Valdis posted the other day, it sounds like the logic remains about the same but the relevance of "576" has largely gone away.

This is about what I would expect but as others haev noted does not
include jumbos.

This says that the majority of packets are session control and
open/close sequences on the one side and big, fat, WRED eligible data
packets on the other side.

This is consistant with the trends of youtube, "high resolution" video
streams, mp3 type traffic, and web pages that just can't seem to
understand that a 150k jpeg looks just as good on an index as a 2 meg
jpeg.

I don't think these figures are likely to change signifcantly in the
near future until we start seeing jumbo frames available from user to
server, not simply somewhere inbetween.

It might be interesting to see what of the other sizes are the final
packet in a data transfer before close vs other types of data.

-Wayne

Here is the output from one of our "high volume" webservices router.

IP packet size distribution (58785M total packets):
1-32 64 96 128 160 192 224 256 288 320 352 384 416 448 480
.000 .007 .000 .000 .000 .000 .000 .000 .000 .000 .000 .000 .000 .000 .000

512 544 576 1024 1536 2048 2560 3072 3584 4096 4608
.000 .000 .003 .001 .986 .000 .000 .000 .000 .000 .000

And here from a core router

IP packet size distribution (73734M total packets):
1-32 64 96 128 160 192 224 256 288 320 352 384 416 448 480
.015 .563 .124 .031 .019 .016 .010 .006 .004 .004 .003 .005 .003 .003 .003

512 544 576 1024 1536 2048 2560 3072 3584 4096 4608
.002 .003 .004 .017 .155 .000 .000 .000 .000 .000 .000

most recent update on this question, with
just a couple of data points:
http://www.caida.org/research/traffic-analysis/pkt_size_distribution/graphs.xml
(so, yes the peak has moved up to 1500.)

note there are more tiny packets in our recent ipv6 data,
but that could just be someone's ping experiment,
it's too small a sample (76k pkts)

k

CAIDA has been doing a lot of that, at least in the past. Last I asked
them, which was quite a while back, they said that O(35%) of traffic
in their samples was at the path MTU (which included 576 bytes for
historical reasons), O(40%) was about the size of a TCP SYN or ACK,
for reasons that are apparent if you think about common TCP
implementations, and sizes were scattered more or less uniformly in
between - last packet in a burst or transaction exchanges. From the
numbers that Valdis posted the other day, it sounds like the logic
remains about the same but the relevance of "576" has largely gone away.