2.1 FCM

2.1.1 Design Philosophy

The architecture of FCM is fixed by client requirements into the modules described below, hence no alternative architectures were considered. In understanding the functionality of FCM however, it is useful to note that FCM is naturally event driven; the functions which provide the interface for each module are event handlers for external events (e.g. a packet being received or sent).

2.1.2 Implementation Language

In keeping with Linux kernel conventions, the FCM modules will all be written in the C programming language, which produces efficient compiled code. This also avoids any possible issues with interfacing between languages, since all existing kernel code is written in C.

2.1.3 Design Overview

FCM is composed of three modules: two of these are the Router and Receiver modules as described in the SRS. These two modules interact only through the modifications made to incoming packets by the module on the Router. The Router module does not require any Receivers to be present, however the extra functionality provided by the Receiver module will only work as expected when a Router module is present on a network link.

The third module, the queue size logging module creates a log of the queue size and $p(q)$ (see section 10 for definitions) at a time interval specified by the user. This takes place on the same host as the Router module, since these data values are only both available there, but the Router module does not depend on the logging module. The majority of logging however was designed into SAM (see section 2.2 for details) to minimise the load of the FCM modules when installed, and also because these logging features are better integrated into SAM along with analysis and graphing tools.

Figure 1: The decomposition of FCM into Router, Receiver and Queue size logging modules

The Router and Receiver modules are both implemented as Linux kernel modules, to be loaded into a 2.4.18 kernel. They will require no modifications to the existing kernel source code, however the kernel must have support compiled in for QoS and Packet Filtering.

2.1.4 Router Module

The Router module will be implemented using the ``QoS'' (Quality of Service) architecture that is included with the 2.4.18 Linux kernel source code. This implementation was chosen because it provides exactly the interface needed for the Router part of the algorithm. This interface is that of a queue, with corresponding enqueue and dequeue operations.

The following options must be compiled into the kernel for the module to work:

• In the Networking Options, ``QoS and/or fair queueing'' must be compiled into the kernel.

The module is implemented as a queueing discipline module, and as such must provide the ability to queue packets before finally being dequeued when the network is free to send them. The module is being implemented in this way because to know the size of the queue without modifying the existing kernel source code requires managing the queue ourselves. It also provides the ability to easily modify a packet as it leaves the Router, by simply modifying the packet when it is dequeued.

An alternative implementation would use the Netfilter architecture used for the Receiver module, however this would be overly complicated, due to the interface which expects packets to be returned immediately. Thus the queue length would have to be determined based on the kernel's queue, which would be more difficult. The problem with the QoS implementation is that additional user space commands must be run after the loading of the module. However this was deemed to be acceptable, as only the Router needs this to be performed, and the administrator of the Router is expected to be capable of running these commands.

2.1.5 Receiver Module

The Receiver module will be implemented using the ``Netfilter'' architecture provided by the 2.4.18 Linux kernel. This system allows modules, such as ours, to be inserted such that all packets entering and leaving the host are passed through the module to be accepted, rejected or modified.

The Netfilter architecture allows the functionality required to be implemented in either kernel space, as a kernel module, or in user space, using the libipq library. It was decided to implement it as a kernel module for maximum speed, and also because it simplifies installation, as it becomes just another module to load. Being a kernel module does introduce additional complications, with the most notable being the requirement to be re-entrant. This means it must allow for the possibility of being called more than once at any given time. While not a problem on machines with only one processor, on multiprocessor machines the chance for multiple packets passing through the module at any given time becomes a possibility. As such, all data being modified must be protected from corruption (through the use of locks on variables) from other running instances of the module.

An alternative to the Netfilter architecture would be to implement a queueing discipline using the QoS architecture used by the Router. However this would require extra commands to be run by the user after loading of the module, and not all users may be familiar with this. It would also be necessary to maintain two queues, one to see incoming packets and one to modify outgoing packets. Again, this is added complexity which would be placed upon the user. The Netfilter solution overcomes this without presenting any additional problems.

The Receiver module implements two separate components of the FCM functionality:

• Recording of incoming $p(q)$ information from the Router
• Modifying outgoing packets to reflect the modified TCP window calculation.

2.1.6 Queue size logging module

The queue size logging module is responsible for reading the current queue size and $p(q)$ from the interface provided by the Router module, and writing it, along with a timestamp, to a file.