Congestion Control in the Recursive InterNetworking Architecture (RINA)

Authors

• Peyman Teymoori¹, University of Oslo,
• Michael Welzl, University of Oslo,
• Stein Gjessing, University of Oslo,
• Eduard Grasa, i2CAT,
• Roberto Riggio, CREATE-NET,
• Kewin Rausch, CREATE-NET,
• Domenico Siracusa, CREATE-NET.

¹ Primary contact: peymant [AT] ifi.uio.no

Resources

• Link to the paper
• link to the RINASim snapshot used in the paper

Scenario description

• The goal of this demonstration is to show how RINA’s Aggregate Congestion Control (ACC) policies are used in a dumbbell network topology. In particular, we show how flows can be aggregated and controlled using one congestion controller to reduce the negative effect of competing flows for a shared bandwidth on each other.
• The simulation scenario is in the SmallNetwork3 folder in /examples.
• This scenario generates a number of measures. To name a few, congestion window size, CWND, and the output queue length at the bottleneck link. The other metrics such as end-to-end delay and transmission completion can be calculated using the round-trip time and received ACK measures, respectively.

Simulation setup

• omnetpp.ini:
  • The simulation duration is set to 1 minute.
  • The application type is set to AEStream.
  • The application processes are named Appxy where x = 1 and 2 mean the sender and receiver sides, respectively, and y = 1 .. 5 mean the node index on each side. For example, App15 is the 5th sender node.
  • The applications in the nodes are named in the same format, i.e. Stream xy.
  • The IPC addresses in the lower layer are named in the format of 0xy. 0 means the lower level/DIF, and the combination of x and y identifies each IPC address uniquely.
  • The lower DIFs are named in the format of Layer0xy. 0 means the lower level/DIF, and the combination of x and y identifies each DIF uniquely .
  • The upper DIF and IPC addresses in this DIF are named similarly.
  • Then, DIFs are configured using the config.xml file.
  • The scenario is called Aggregation.
  • In this scenario, the base RTT is set to 200 ms, and the stream applications are configured.
  • Then, the corresponding congestion controller, DTCPTxControlPolicyTCPTahoe, is set at the sender nodes, and the router is empowered with UpstreamNotifier - an RMT policy to notify senders of congestion.
  • To remove the effect of packet drop, the routers' queue size is set to a very large number, e.g. 5000 in this case.
• config.xml:
  • In this file, all the DIF config data and directory settings are defined.
  • For the sake of simplicity, directory setting are defined only for host11 and router1, and the other nodes and router use theirs, respectively.
  • At first, connections are defined with qosCube = 1, which is the only QoS Cube definition in the simulation.
  • The NeighborTable of all the nodes are defined such that nodes can route/forward packets to the right destination.

Results

• Reproducing results:
  1. Run the Aggregation scenario in OMNeT++.
  2. When it is finished, open the produced sca, vci, and vec files through an anf file.
  3. Find xx and yy in the Vectors tab to observe CWND and queue length.
  4. Plot each of them by selecting the rows, right-clicking on them, and selecting Plot.
• Result analysis:
  • The CWND plot shows the congestion controller behaves like a TCP one.
  • You can see the saw-tooth behavior.
  • The queue length plot shows how the queue is filled and emptied.