On the essential nature of the "512 byte 25 rule" heuristic

[tangent]

It's common advice on this forum when translating MirokTik's official test results to reality to use the number from the "512 byte" column, on the "25 IP filter rules" row. I've had a revelation: I now believe I know why that bogus-seeming heuristic so often works.

The first key realization is that these devices are more often bottlenecked by packets-per-second limitations, not actually by bandwidth. If we look at the 25-filter row for the Hex S 2025, we find 117.8 kpps for full-size Ethernet packets, 121.6 kpps for 512-byte packets, and 117 kpps for 64-byte packets. Those differences are down in the noise; it's as close to constant as matters.

Next, let us observe that this is a 6-port device, allowing three bidirectional paths in simultaneous use. The block diagram for this device tells us the efficient combinations are something like sfp1 to ether1 + ether2 to ether3 + ether4 to ether5, but other combinations would give equivalent results.

Finally, let us observe that 1518 ÷ 512 ≈ 3.

Yes, it's that simple: this heuristic is a roundabout method for dividing packets-per-second by three to match the max count of full-width streams. It works because the bulk of consumer-grade MT routers are six-ish port devices, and the problem most often comes up in this class of devices. That's it.

Yes, there is plenty of room to quibble. "What of the RB4011?" you say. "It has ten copper ports! Doesn't that mean there are five paths?" Not really; those ports are split across two switch chips, so it's effectively a 5-port device for the purposes of this discussion. The "divide by 3" heuristic still gets you into the ballpark.

"And the RB5009?" Now we have eight copper ports under one switch chip, giving 4 independent bidirectional paths. The thing is, dividing by 3 remains a better heuristic than taking the all-ports test as a plausible target value in real-world use.

Doubtless this breaks down for MT's bigger routers, but then, you don't as often see this heuristic given for those routers. They're meant for professional users who don't tend to raise the question of why they aren't getting the all-ports result over a single connection in the first place.

[jaclaz]

@tangent

bogus-seeming heuristic

I use to compare it with the way to see if socks are the right size by wrapping one of them around your closed fist, it just (roughly) works.

But in the case of the Mikrotik 512 bytes/25 firewall rules, it is good to know (loosely) why it works .

The difference between five and six is in this case is of little relevance [1], but some Mikrotik devices have 4 ports (hap lite, hap ax lite) and some others only 2 (map, wap ax, cap ax) .

Now if I compare the map with a hap lite, they both run at 650 MHz, and have a very similar processor, QCA9531 vs. QCA9533, and the test results are similar enough (192.5 vs. 220.8) so either the rule of thumb doesn't apply to them or there must be something else. (4 is still near enough to 5 or 6, but 2 is much less).

[1] In other cases, it might be VERY relevant, I love math explained by Clint Eastwood, on the difference between 6 and 5 :

"Did he fire six shots or only five?" Well to tell you the truth in all this excitement I kinda lost track myself. But being this is a . 44 Magnum, the most powerful handgun in the world and would blow your head clean off, you've gotta ask yourself one question: "Do I feel lucky?" Well, do ya, punk?

[tangent]

@jaclaz

I love math explained by Clint Eastwood

Long before it was a web browser, it was a major motion picture starring the man himself, in which we learn that all it takes to pilot the high-tech router is to learn to think in Latvian.

But I may have mangled the plot somewhat.

[lurker888]

I always just put this down to simply the fact that packets are actually closest to the 512 byte size.

E.g. The simple IMIX (https://en.wikipedia.org/wiki/Internet_Mix) traffic profile, after adding in the ethernet headers, comes to 354 byte packets.

My absolutely ad-hoc statistics for roughly 3TB of traffic comes to 438 bytes. If I modify my calculation to assume max mtu for the largest bucket of packets, it's 502 bytes.

So, for me at least, it's not such a surprise that this statistic is the most realistic.

As to the argument about the number of ports: before the integrated switch chip/port extender concept came along, it was fairly common to see routers with 3 ports. (I'm looking at the PCEngines ALIX devices, or the original Ubnt EdgeRouter Lite, etc.) Additional ports beyond this are usually not strictly needed, but in many cases provide convenience, and while I often often don't use more than 2-4 ports, in lots of situations it comes in very handy. Also, given that MT's devices come in a fixed configuration, the interface types are not individually selectable like with line cards, which I honestly don't really miss.

[tangent]

@lurker888

packets are actually closest to the 512 byte size.

On average, in real-world workloads, perhaps, but this heuristic is commonly used to explain the behavior of speed tests, which use max-sized packets to get the best results possible.

[lurker888]

But again, those speed tests are often done using half-duplex tcp. (Even on bidirectional tests.)

[BartoszP]

I checked my stats for 3 months (last reboot) from my router acting as a PPPoE client to ISP and routing traffic to my other routers. All of them have public IPs. Main router used for home office work + mobiles, VPNs to service my clients, streaming etc., typical SOHO mixed usage. Some other devices are test routers but they generate very small traffic. Lucky me: MTU for PPPoE is 1492. Ethernet interfaces set to maximum values.

Packet size split for circa 1.7TiB in / 93GiB out