Version 5 (modified by, 7 years ago) (diff)


Instructions for TCP Exercise

3.5 An Experimental Congestion Avoidance module for Linux

Source code needed (to-be changed by you):

  • Makefile
  • tcp_exp.c
    In this exercise, you will develop and evaluate a TCP congestion control module for the Linux kernel. Linux provides a pluggable interface for TCP congestion control, which allows named congestion control modules to manipulate its sending rate and reaction to congestion events. You have already used the reno and cubic modules, and in this exercise you will create one named exp.
    Linux kernel modules must be compiled against kernel source that matches the kernel into which the module will be loaded. In order to prepare your ProtoGENI host for kernel module development, follow these steps:
  1. Install the required packages with this command:
    sudo yum install kernel-devel kernel-headers
  2. Fix up the kernel version in the installed headers to match the running kernel; this can be tricky, but these steps should handle it. (a) Find your kernel sources. They are in /usr/src/kernels, in a directory that depends on the installed version. As of the time this handout was created, that directory is We will call this directory $KERNELSRC. (b) Identify your running kernel version by running uname -r. It will be something like 2.6.40-4.emulab2.fc15.i686.PAE. The first three dotted components (2.6.40, in this case) are the major, minor, and micro versions, respectively, and the remainder of the version string (-4.emulab2.fc15.i686.PAE) is the extraversion. Note the extraversion of your kernel. (c) In$KERNELSRC/Makefile,find the line beginning with EXTRAVERSION. Replace its value with the extraversion of your kernel. FIXME: Also update PATCHLEVEL = 0. (d) Update the kernel header tree to this new version by running the command:
    sudo make include/generated/utsrelease.h
    More details to handle version issues are provided at Building modules for a precompiled kernel.
    A Makefile for compiling the module and the source for a stub TCP congestion control module are included in Makefile.
    The module is named tcp exp (for experimental TCP), and the congestion control algorithm is named exp. Comments in the provided source file explain the relationship between the various functions, and more information can be found in Pluggable congestion avoidance modules.
    The compiled module (which is built with make and called tcp_exp.ko) can be inserted into the kernel using insmod. It can be removed using the command rmmod tcp_exp and reloaded with insmod if changes are required.
    Once the module is complete and loaded into the kernel, the algorithm implemented by the module can be selected in the same manner that reno and cubic were selected in previous exercises, by placing the keyword exp in /proc/sys/net/ipv4/tcp_congestion_control.

3.5.1 Algorithm Requirements
The experimental congestion control module is based on Reno, but has the following modifications:

  • It uses a Slow Start exponential factor of 3. Reno uses 2.
  • It cuts ssthresh to 3 × FlightSize/4 when entering loss recovery. Reno cuts to FlightSize/2.

3.5.2 Hints
These hints and suggestions may help you get started.

  • The existing congestion avoidance modules are a good start. See net/ipv4/tcpcong.c in the Linux source for the Linux Reno implementation.
  • The file net/ipv4/tcp_input.c is a good place to learn how the congestion avoidance modules are used and invoked.
  • RFC 5681 specifies the Reno congestion control actions in detail, and may be helpful in understanding the kernel code.
  • The Linux Cross Reference at may be useful for navigating and understanding how the code fits together.
  • If one of the hosts becomes unresponsive due to a bug in your congestion control module, you can restart the sliver to reboot it.
  • The Linux Kernel Module Programming Guide provides a good introduction to kernel module programming in general.

3.5.3 Evaluation
Once you have implemented the algorithm described above, answer the following questions:

  • 1. Question: Discuss the impact of these algorithmic changes in the context of traditional Reno congestion control.
  • 2. Question: Compare the convergence time and fairness of your algorithm with Reno and Cubic under (a) high delay (500 ms) and (2) high loss (5%) conditions. Use Jain’s fairness index, or some other quantitative measure of fairness, in your comparison.