packet size

2 replies
6316 views

Hi,

How the packet size impact throughput .

Why do we require higher throughput when the packet size is small.

How do we identify the packet size during the poc time ?

which service will be using the smaller packet size ?

Thanks

Grave_RoseAnswer

New Member

Hey sims,

A smaller packet will pass through a device faster than a larger packet. Due to this, any device will push more smaller sized packets than larger packets in the same time frame. This is why you need higher device throughput (Packets per Second and Connections per Second) when dealing with smaller packets. The firewall (or routing device) needs to manage more connections in a smaller amount of time, thus using up more system resources.

When it comes to identifying packet size, most non-Jumbo Frame Ethernet networks will use an MTU of 1500bytes however that is the maximum and not the minimum which means that you may have packets which don't use all 1500bytes. To help identify during a PoC, I would just run normal traffic through the device since this is your traffic. If the PoC doesn't use your production traffic, you'll want to use a traffic generator. This can be a commercial appliance you buy from a reseller, customizing something like "iperf", "hping3" or "tcpreplay" or forking some of your production traffic through the PoC.

Hope this helps,

Sean (Gr@ve_Rose)

Grave_RoseAnswer

New Member

Hey sims,

A smaller packet will pass through a device faster than a larger packet. Due to this, any device will push more smaller sized packets than larger packets in the same time frame. This is why you need higher device throughput (Packets per Second and Connections per Second) when dealing with smaller packets. The firewall (or routing device) needs to manage more connections in a smaller amount of time, thus using up more system resources.

When it comes to identifying packet size, most non-Jumbo Frame Ethernet networks will use an MTU of 1500bytes however that is the maximum and not the minimum which means that you may have packets which don't use all 1500bytes. To help identify during a PoC, I would just run normal traffic through the device since this is your traffic. If the PoC doesn't use your production traffic, you'll want to use a traffic generator. This can be a commercial appliance you buy from a reseller, customizing something like "iperf", "hping3" or "tcpreplay" or forking some of your production traffic through the PoC.

Hope this helps,

Sean (Gr@ve_Rose)

ede_pfau

SuperUser

Smaller packets do traverse a device faster, sure, but the packet frame (so called "overhead") is always the same size, and adds to the amount of data to be moved. Say, TCP adds 20 bytes to the payload. If the payload is only 60 bytes you have an overhead of +1/3 = +33%. With a maximum packet payload of 1500 bytes, you have an overhead of only +1.3%.

Second effect is the time it takes to handle a session, and then route it from one interface to another. Session buildup (plus RPF and other scores) is only done on the first packet of a new session. Look at the "new sessions per second" rate in the datasheet to get an estimate of the CPU power. Smaller units, with a SoC, suffer a lot here because of limited CPU power. Session build-up rate is important if you have a lot of users with low bandwidth consumption, like with browsing (HTTP). For few users who transfer large sequential bulk data session buildup is neglectable (FTP, SMB).

That's why firewall throughput generally is measured and given in datasheets for large packets. Even FTNT specifies throughput for small, medium and large packets so that you can see whether the packet size will incluence throughput or not.

In Fortigates, offloading traffic to the NPx ASIC will make throughput (more or less) independent of packet size, or rather, the amount of time for transfer data between interfaces (see above). That is because handling each packet is not done on the CPU but piped to the ASIC very quickly. Only the real transmission of the data will count for the latency (the reciprocal throughput), which of course, even FTNT can't accelerate.

Sign up

Login with SSO

Login to the community

Login with SSO