9.1 FCM

The following are a set of use cases designed to show how FCM interacts with both the user and the kernel on the machine on which one of its modules is installed.

Figure 31: Shows the actors and use cases for the Router module of FCM

Figure 32: Shows the actors and use cases for the Receiver module of FCM

Figure 33: Shows the actors and use cases for the Logger module of FCM

9.1.1 Installing Router FCM

Description:

This scenario describes the loading of the Router FCM module onto a Router.

Trigger:

The user decides to install the Router FCM module.

SRS References:

3.1.1.4, 3.1.1.5, 3.1.1.7

1. The user runs insmod to install sch_qsize.o, specifying the output rate $\mu$, but choosing not to specify values for $b$ and $q_{\rm min}$.

2. The kernel loads the module with the user-specified values, and runs the function specified using the module_init() macro.

3. The module registers with the register_qdisc() function.

9.1.2 Sending $p(q)$

Description:

This scenario describes the sending of $p(q)$ by the Router FCM module. It has already been loaded as in the previous scenario.

Trigger:

The rqueue_dequeue() function is called by the kernel, requesting the next packet to be sent.

SRS References:

3.1.1.1, 3.1.1.2, 3.1.1.3

1. The current queue length and hence $p(q)$ is calculated, ignoring the packet about to be removed (the packet which has been in the queue the longest).
2. Router FCM checks that the packet is a valid TCP/IP packet as specified by reference [7], including the extensions in reference [3].
3. The packet is a valid TCP packet, so it is modified to include $p(q)$.
4. The packet is removed from the queue and returned to the kernel.

9.1.3 Removing Router FCM

Description:

This scenario describes the removal of the Router FCM module from the kernel. This stops packets from having $p(q)$ added to them, causing any Receiver FCM Module depending on $p(q)$ from this Router to revert to the existing kernel window sizing algorithm.

Trigger:

The user decides to remove the Router FCM module.

SRS References:

3.1.1.7

1. A user runs rmmod sch_qsize.
2. The function specified in the module_exit() macro is called by the kernel.
3. The Router FCM calls unregister_qdisc().

9.1.4 Installing Receiver FCM

Description:

This scenario describes the loading of the Receiver FCM into the kernel.

Trigger:

The user decides to install the Receiver FCM module.

SRS References:

3.1.2.4, 3.1.2.6

1. The user runs insmod with rami_receiver.o as its only argument, and does not choose to specify values for $\tau$, $\alpha$ or PS_THRESH.
2. The kernel loads the module and runs the function specified using the module_init() macro.
3. The module registers itself with the Netfilter architecture to receive all packets passing through the system.

9.1.5 Receiving $p(q)$

Description:

This scenario describes the reception of a packet containing $p(q)$ from a Router.

Trigger:

A function of the Receiver module is called by the kernel, and a packet given.

SRS References:

3.1.2.2, 3.1.2.3

1. The Receiver module inspects the packet and determines that it contains the Router $p(q)$.
2. The internal record of the Router $p(q)$ is updated based on $p(q)$ in the packet received.
3. The packet is returned to the kernel unchanged.

9.1.6 Sending a TCP Packet with Modified Window

Description:

This scenario describes the sending of a TCP packet by the Receiver module so that the TCP window is modified.

Trigger:

The kernel calls modify_window() in the Receiver module and passes it a packet.

SRS References:

3.1.2.1, 3.1.2.5

1. The Receiver FCM inspects the packet and determines that it originated on the current host.
2. The TCP window is calculated using the Client's algorithm.
3. The existing TCP window field of the packet's header is updated with the new window size as calculated if it is less than the existing window size field.
4. The packet's checksum is recalculated to ensure that the modified packet is a valid TCP packet.
5. The packet is returned to the kernel, noting that it's been modified.

9.1.7 Removing Receiver FCM

Description:

This scenario describes the removal of the Receiver FCM from the kernel. This stops new packets sent from this host from having their TCP window field modified.

Trigger:

The user decides to remove the Receiver FCM module.

SRS References:

3.1.2.6

1. A user runs rmmod rami_receiver.
2. The function specified in the module_exit() macro is called by the kernel.
3. The module deregisters itself from the netfilter architecture. It no longer receives packets from the kernel.
4. The module is unloaded from memory.

9.1.8 Creating a log of Router statistics

Description:

This scenario describes the logging of data provided by the Router module of FCM. This data gives the value of $p(q)$ and the number of packets modified, as well as other useful information.

Trigger:

The user runs rami-logger.

SRS References:

3.1.1.6

1. A user runs rami-logger -interval 10 -duration 60 output.nlog.
2. The command line arguments are parsed using the getopts library, by the rami-logger module.
3. It is checked that both an interval and duration were given for logging, if not the program would quit.
4. The file given as an argument, in this case output.nlog, is opened for writing as the output file, by calling openoutput().
5. The file exported in /proc by the Router module is loaded for input by openinfofile().
6. The fields in the input file are parsed by calling findfields().
7. The input file is closed by calling closeinputfile().
8. The header line for the output file is written by writeheader().
9. A signal handler is set up for the SIGALRM signal, to call dump_fields().
10. A timer is set to create the SIGALRM signal at the interval request by the user.
11. rami-logger sits in a loop, pausing until the duration is over. Meanwhile, dump_fields() is called at regular intervals. The following occurs:
    • The input file is opened by calling openinfofile().
    • The line of data is read from the input file.
    • The data is written to the output file by calling writedata().
    • The input file is closed.
12. When the duration of logging is over, the output file is closed by calling closeoutput().
13. The program exits.