Holdoff is working fine, but it's difficult to demonstrate its function in situations where it's not required.
Holdoff just disables the trigger for the set amount of time - and it won't affect the trigger frequency counter (which just tells an average frequency of the gated input signal on the trigger channel).
Holdoff is normally not set to the burst (packet) length, but slightly less than the time interval of the gap between packets and is intended to get a stable trigger on the first trigger condition within a packet. Unstable triggering usually happens when packets with multiple valid trigger conditions are arriving at a high repetition rate and there is not much space in between them.
If for example you have a packet every 4ms and your packet is 2.42ms long, then you could set the Holdoff just below the timespan of the gap between packets, which would be 4 - 2.42ms = 1.58ms. In this example, 1.57ms Holdoff should work to get a stable trigger.
Btw, seeing the packet rate is easiest done taking advantage of the deep memory. Just increase the timebase until you capture two packets instead of just one. You can then use cursors to measure the time period from packet to packet. If you need it very accurate, you can use zoom to fine-position the cursors.
If the repetition rate of the packets is very low, so that you need to increase the timebase to several seconds per division, you might need to engage peak detect acquisition mode in order to capture the pulses of the packet reliably. In that case, precision of the cursor measurement will be low correspondingly, but for slow actions like this great accuracy is usually not required and you don't need Holdoff in such situations for sure.