Packet Trimming Pro's and Con's

Because this topic of packet trimming comes up very often, and there has been some misinformation surrounding it, I wanted to take a minute to get you all on the same page.  Specifically, what do I gain,  and what do I lose if a customer trims packets?

The answer to this depends greatly on which product is doing the trimming: GigaStor vs another device.

The only positive thing about trimming upstream is selective trimming. Some devices can do things like, trim HTTPS to 100 bytes, but don’t trim RTP packets, as an example.

* Depends on trimmed data length. If trimmed too small, typically less than 100 bytes, you may lose transaction data. This is especially true if there are a large number of encapsulations before the data.

** Some application database strings, and URLS, can be very long. To get a complete database or URL string, you may need 150 to 200 bytes (or more).

*** Do not truncate packets at an upstream device in order to increase the number of packets into GigaStor. If the GigaStor isn't capable of monitoring the data at its full packet length,  then trimming will not fix that issue.

Example 1:  Customer wants to monitor 10Gb of traffic but can only afford a 16T, so he truncated all the packets to 100 bytes and now the GigaStor is receiving less than 4Gbps.

Example 2:  Customer has a packet broker that is saturated and sending full length packets will cause the packet broker to drop packets. Customer wants to trim packets at the packet broker, so it can send all its data down the 10Gb link to his 96T.

In general,  it requires basically the same amount of processing for a full packet as it does a small packet.  There is over head processing required for every packet regardless of size.  More larger packets means less overall processing required.  Lots of small packets, means more overall processing.  Too much proceeding and you lose packets.

If there are no performance issues at full bytes, and they are not increasing the number of packets,  trimming should ok. If you need to trim with an upstream device, it is suggested to use >200 byte packet trimming if possible.

Decreasing packet size will not allow for more data to be sent to GigaStor. Customers who want to trim packets may do so; however, the ingest rate of the GigaStor must be based off the original untrimmed size, not the trimmed size. If the customer wanted to trim to it should not go lower than what was tested for Tolly to maintain the WTD speeds.

Decreasing packet size while maintaining the same ingest rate will negatively impact max performance. While there aren’t any official tests, by the time you get to 64-byte packets, you can have a >60% impact to max performance. So, a 40Gb WTD GigaStor would have a minimum impact of 24Gbps. This is due to the overhead required to write each packet to disk. Again, this isn’t official.

This is why we rate at max WTD with the smallest average packet size as stated by Tolly, hence the suggestion if you are going to trim, then trim no smaller than what Tolly provided.

Examples:

Customer had 100Gbps of data. Customer wanted to trim packets down to 100 bytes each.

This cut the traffic rate from 100Gbps to 30Gbps. However the GigaStor was not able to write 30Gbps down to disk because we were processing packets for 100Gbps.

Processing a 100byte packet takes as long as it does to process a 1500 byte packet. Therefore, we are unable to process more packets than what could have come into the box at full packet length.