Experimental Testbed Description: The testbed consists of 2 machines: the client and the server. The client machine has GK installed as a test kernel module: tstgk and can be used to enqueue outgoing packets with the appropriate tc commands. The error free working of the GK setup commands is seen here.
The required working of commands specifying bandwidths in percentages of the interface capacity, is seen here.
Iperf tests were conducted on Gatekeeper to test its throughput and also compare it with the default qdisc in place i.e pfifofast to
see how much performance price is paid to use Gatekeeper's priority queue algorithm. The results are shown in the table below:
| Iperf Test | BW (in Gb/s) |
|---|---|
| Standalone GK | 1.2755 |
| GK + HTB (Rate: 5%; Ceil :5%) | 1.283 |
| pfifofast (default qdisc) | 1.347 |
Stress tests were also conducted using the ostinato tool. The results of which is explained: For this stress test, the link between
client and server was saturated with a specific priority and then higher priority packets were sent out every so often, and it was
verified that none of the high priority packets were dropped, but that many of the low priority packets have seen to be dropped by GK.
The tool used to saturate the link with the low priority packets was ostinato, and scapy was used to send out the high priority packets.
I’ll explain the screenshots here, In 1.png the pkts of length 60 are the low priority pkts (DSCP: 0x20) and the pkts of length 64 are
the high priority pkts (DSCP: 0xe0). In 4.png you see the total frames sent out from ostinato (to GK) and the rate at which they’re sent
out, the terminal screen on the right is the scapy script which was run to send out the high priority pkts (simultaneously whist the low
priority pkts from ostinato were also being sent to GK). In 2 and 3, we see the number of low and high priority pkts which reached the
other end (gk-server). Here, we see that a large number of low priority pkts have been dropped but the number of high priority pkts that
reached the server is 1000. And In 5.png we see that the scary script sent out 1000 pkts, all of which have reached the other end. So none
of the high priority packets have been dropped by GK, which verifies its functionality.