DIFFUSE - Usage Examples

Prioritisation of FPS Game Traffic (single router)

This example shows how to use DIFFUSE to classify traffic into latency-sensitive First Person Shooter (FPS) game traffic and other traffic, and then use this information to prioritise the game traffic over the other traffic on a single firewall. Traditionally this would rely on knowing specific port numbers and IP addresses belonging to games and game servers. DIFFUSE enables us to detect certain game traffic without relying on known ports and addresses.

We assume the following network setup, where a FreeBSD router/firewall sits between a local network and the ISP's network. This is a typical setup for a home user who wants to prioritise game traffic over other traffic on the outgoing access link (which is typically the bottleneck in current ADSL/Cable access networks). The customer's router could be a small router with integrated ADSL/Cable modem or a PC-based router connected to an ADSL/Cable modem (bridge).


The following commands are used to configure DIFFUSE and IPFW/Dummynet to classify and prioritise outbound game traffic. Note that we have omitted all security-related firewall rules here.

First we setup two queues using Dummynet (assuming the total outbound capacity is 1Mbit/s). As suggested in the IPFW documentation the bandwidth of the Dummynet pipe is set to 95% of the capacity. The first queue is used for game traffic and has a much higher weight (weight 100) than the queue for other traffic (weight 10). Note that the queue configuration here serves as example; in practise different configurations could be used.

ipfw pipe 1 config bw 950kbit/s ipfw queue 1 config pipe 1 weight 10 ipfw queue 2 config pipe 1 weight 100

Next we setup DIFFUSE to classify traffic into game traffic and other traffic and queue the traffic according to its class (outgoing interface is ed0). Note that the classifier model et_vs_other.c45.diffuse was specifically built to detect the FPS game Wolfenstein: Enemy Territory (a free game based on the Quake 3 engine), but it also works for other Quake 3 based games.

ipfw mlclass myclass config algorithm c4.5 model et_vs_other.c45.diffuse class-names other,game ipfw add queue 1 ip from any to any out via ed0 if-match-class myclass:other ipfw add queue 2 ip from any to any out via ed0 if-match-class myclass:game

Prioritisation of FPS Game Traffic (multiple routers)

This example shows how to use DIFFUSE to classify traffic into latency-sensitive First Person Shooter (FPS) game traffic and other traffic, and then use this information to prioritise the game traffic over the other traffic in a network with multiple routers, such as an ISP network. For the sake of brevity we focus on a simple example network with one classifier node and two action nodes (one on a customer router and one on an ISP edge router). However, this could be a small part of a larger network.

We assume the customers' traffic is classified by one or more classifier nodes (via switch mirror ports, optical splitters etc.). Flow information and class (game or other traffic) is then passed on to the actions nodes, which label and prioritise the game traffic flows. We assume that the customers' ADSL/Cable modems/routers  also accept flow information from the classifier nodes and prioritise traffic accordingly like the ISP's routers. Since the potentially performance-intensive traffic classification is performed by the ISP's dedicated classifier nodes, the customer routers can remain simple low-end devices.


The following rules are used to configure DIFFUSE and IPFW/Dummynet to classify and prioritise game traffic. Note that the queue configuration here serves as example, in practise different configurations could be used. Also note that we do not show any other security-related firewall rules here.

The ClassifierNode observes all the traffic flowing between the customer and the ISP through a mirror port on the switch. In order to classify these packets with DIFFUSE a pseudo bridge (pseudo because it does not go anywhere) is configured on the ClassifierNode with the following commands (assuming interface em0 is connected to the switch).

ipfw bridge create ipfw epair create ipfw bridge0 addm em0 addm epair0a up ipfw bridge0 -learn em0 -learn epair0a ipfw em0 up ipfw epair0a up sysctl net.link.bridge.ipfw=1

The following commands are used to configure the ClassifierNode. The commands used to classify the traffic are similar to the commands used in the single router scenario. The difference is that now we do not queue packets locally but inform remote ActionNodes about the flows and their classes, which then queue the flows' packets.

ipfw mlclass myclass config algorithm c4.5 model et_vs_other.c45.diffuse class-names other,game ipfw export myexp config target udp://localhost min-batch 1 max-batch 20 confirm 100 ipfw export myexp ip from customer1.net:mask to any if-match-class myclass:game ipfw export myexp ip from any to customer1.net:mask if-match-class myclass:game ipfw_exp -c localhost -a sctp://router.customer1.net:5000,sctp://router.isp.net:5000 -q &

The following commands configure the ActionNode on the customer's router (assuming the total outbound capacity of the customer's router is 1Gbit/s).

ipfw pipe 1 config bw 950Mbit/s ipfw queue 1 config pipe 1 weight 10 ipfw queue 2 config pipe 1 weight 100 ipfw add 900 accept ip from any to any in via em1 ipfw add 2100 queue1 ip from any to any out via em1

Similarly, the following commands configure the ActionNode on the ISP's edge router (assuming the total outbound capacity of the ISP's edge router is 1Gbit/s).

ipfw pipe 1 config bw 950Mbit/s ipfw queue 1 config pipe 1 weight 10 ipfw queue 2 config pipe 1 weight 100 ipfw add 900 accept ip from any to any in via em0 ipfw add 2100 queue1 ip from any to any out via em0

The following command runs the collector to receive flow information and configure IPFW/Dummynet rules on each ActionNode. The collector will dynamically generate rules for game traffic flows with rule numbers between 1000 and 2000.

ipfw_col -a actions.txt -r 1000-2000 -s 5000 -q &

The file actions.txt contains a list of classes and IPFW actions. In our scenario it looks as follows. Unclassified traffic and class 0 traffic (other traffic) is queued in queue 1 and game traffic is queued in queue 2.

default queue 1 myclass:0 queue 1 myclass:1 queue 2