Packet Latency Thresholding
Packet latency thresholding measures elapsed time, not just processing time, in order to more accurately reflect the actual time required for the rule to process a packet. However, latency thresholding is a software-based latency implementation that does not enforce strict timing.
The trade-off for the performance and latency benefits derived from latency thresholding is that uninspected packets could contain attacks. A timer starts for each packet when decoder processing begins. Timing continues either until all processing ends for the packet or until the processing time exceeds the threshold at a timing test point.
As illustrated in the above figure, packet latency timing is tested at the following test points:
-
after the completion of all decoder and preprocessor processing and before rule processing begins
-
after processing by each rule
If the processing time exceeds the threshold at any test point, packet inspection ceases.
Tip | Total packet processing time does not include routine TCP stream or IP fragment reassembly times. |
Packet latency thresholding has no effect on events triggered by a decoder, preprocessor, or rule processing the packet. Any applicable decoder, preprocessor, or rule triggers normally until a packet is fully processed, or until packet processing ends because the latency threshold is exceeded, whichever comes first. If a drop rule detects an intrusion in an inline deployment, the drop rule triggers an event and the packet is dropped.
Note | No packets are evaluated against rules after processing for that packet ceases because of a packet latency threshold violation. A rule that would have triggered an event cannot trigger that event, and for drop rules, cannot drop the packet. |
Packet latency thresholding can improve system performance in both passive and inline deployments, and can reduce latency in inline deployments, by stopping inspection of packets that require excessive processing time. These performance benefits might occur when, for example:
-
for both passive and inline deployments, sequential inspection of a packet by multiple rules requires an excessive amount of time
-
for inline deployments, a period of poor network performance, such as when someone downloads an extremely large file, slows packet processing
In a passive deployment, stopping the processing of packets might not contribute to restoring network performance because processing simply moves to the next packet.