Multipath TCP in htsim

Implementation

The implementation of multipath TCP in htsim is mainly for congestion control testing. Thus, the code does not reorder data at connection level, or simulate receive buffer issues (such as blocking).

There are several congestion control algorithms implemented, including fully coupled, linked increases and uncoupled tcp. All the cwnd operations are done using integer arithmetic to mimic a real stack.

Multipath is merely a congestion control wrapper around the traditional TCP code. The TCP code will perform traditional new reno CC by default; however, if it is added to a multipath connection, cc will be handled by the connection.

Currently, the code only supports two subflows. We haven't tested its behavior for more than two subflows.

Running tests

To start a multipath flow, just create a multipath tcp source with the desired congestion control behavior, and add TCP flows to it. All the added TCP flows will be congestion controlled by the multipath connection, but are otherwise independent (e.g. retransmissions, sequence numbers, etc).

You can use one of the main_* files to test multipath. There are three simple topologies: the multipath dumbbell (one multipath connection with two subflows, each crossing a link shared with other TCPs), shared botleneck (the multipath subflows cross the same bottleneck and compete with TCP), and resource pooling (only multipath flows). The congestion control algorithm is a command line parameters to htsim; by default UNCOUPLED congestion control is used (e.g. independent TCP). The values for the other algos are FULLY_COUPLED and COUPLED_INC (this is the Linked Increases algorithm). A version of TCP with bottleneck fairness is implemented as COUPLED_TCP.

By default, the main_* code will report once per second the rates each tcp (including multipath) sink gets. To view the mean rates, just load analysis.r and call the rates() function. To draw the rates, call draw_rates(). The loss rates of the queues are is displayed by approx_loss_rates(). There are other utility functions defined in analysis.r for multipath. Some of them require detailed tcp logging (the examples also contains this, typically for the multipath subflow).