In this section we provide some more information about the various modules that make up the server nodes. All of these modules are found in the src/node direc-tory. With the exception of the server folder (described below), the structure of this directory reflects the various layers of the network stack of servers.
A.3.1 Server
Sever nodes are compound modules that implement the Server interface defined by Server.ned. The Server interface is simple. Only one parameter must be specified,
Figure A.1: The compound module representing a server.
the address, it interfaces with the network through the port gate. The ServerBase module defines the structure of the server node and is shown in Figure A.1.
A.3.2 Control module
Allows exchanging messages between modules without affecting the simulation. As opposed to keeping a memory reference or using the direct connection, the motivation behind the use of a separate control module was two fold. First, messages can be addressed to specific modules in other servers using their names. Delivery details handled automatically making it easier to exchange information. Second, it preserves the ability of the model to be distributed.
A.3.3 Application Layer
While there were several application level modules that we developed, we primarily used one which we describe here.
Message Application
The message application is designed to send fake data representing generic application-layer messages. We used the message application to generate many of the traffic pat-terns that we used in this dissertation. These messages are read in from a script file.
The message application at each of the server nodes in the simulation read through the script to determine the messages that they have to send to other servers.
An example of the message script format is shown below:
# Example script file 2012-04-13 16:53:12
# The message script format is:
# <source>;<destination>;<messageNum>;<startTime>;<messageSize>;<messageRate>
0 ; 1 ; 1 ; 0 s ; 512 KiB ; 100 Mbps
0 ; 1 ; 2 ; 500 ms ; 3.2 MiB ; 3 Mbps + 100 kbps
1 ; 2 ; 1 ; 1.5 s ; 1 GiB ; 0 bps
Each message has a source and a destination identifying the sending and receiv-ing server respectively. The messageSize indicates the number of application-level bytes in the message. The startTime indicates when the sending server should begin sending the message. Once the startTime is reached, the sending server will begin sending the message by generating UDP packets whose size is determined by the MessageApplication’s payloadSize parameter. The actual packets produced by the application are therefore larger than the payloadSize. If the messageRate parameter has a non-zero value, then the packets will be produced at intervals to match the specified rate. Note that this rate is in terms of the raw Ethernet sending rate and does account for the protocol overheads. If no messageRate is specified (i.e., the value is 0 bps) then the maxSendRate parameter determines when the next packet will be sent. The messsageNum field is optional and is simply intended to make it easier to
differentiate between different messages between the same pair of servers. The Mes-sageApplication automatically handles unit conversion and mathematical expressions by leveraging the parser that OMNeT++ uses to process ini files.
The MessageApplication can also instantiate a “ScriptGenerator” class. The Script-Generator class is used to generate script files for different traffic patterns according to the “scriptGenType” parameter. When this feature is used, only the first server (with address 0) generates the script file during the first stage of module initialization.
The rest of the servers simply read the script file during the second stage of module initialization.
A.3.4 Transport Layer
This folder contains modules to support a simplified UDP protocol and several mod-ules to interface with INET’s TCP models. The UDP module is called SimpleUDP and simply handles encapsulation and decapsulation of DCN UDPPackets.
A.3.5 Network Layer
The purpose of the network layer is simply to multiplex and demultiplex traffic for the transport layer modules. Currently, there is only one type of network layer which is called VirtualIP. While fairly simple, it does have to interact with the InetTCP-Wrapper class to decapuslate and encpauslate TCP packets when TCP is used.
A.3.6 Scheduling Layer
The scheduling layer is one of the more complex layers. As shown in Figure A.2, the scheduling layer is a compound modules that contains several simple modules. The demultiplexer module (“demux”) accepts traffic arriving from the network layer. The multiplexer module (“mux”) forwards traffic down to the next lower layer in the stack.
The multiplexer is also responsible for notifying the controller when a packet arrives for a destination for which there is currently no VOQ. Traffic can also enter into the
Figure A.2: The compound module representing the scheduling layer.
scheduling layer via the controller module which filters out scheduling packets and delivers them to the SchedulingAlgorithm module (shown simply as “algorithm”).
We provide two different scheduling algorithm modules. The first can be found in the
“proxy” subfolder and corresponds to the proxy algorithm described in section 4.3.
The other module is called “schedFromeFile” which is found in the subfolder of the same name. This module allows rates to be read in and set from a rate schedule script.
The format of the rate schedule script mirrors the format of the backlog scheduling script described in section 5.6.1. The primary purpose of this module is to provide a way to test the scheduling framework in the simulator.
A.3.7 Resequencing Layer
The resequencingLayer folder contains the implementation of our hybrid resequencing approach described in section 3.4. While we implemented only one approach to rese-quencing, the Resequencer.ned file defines an interface for reseqeuencers that other all resequencers must implement. The HybridResequencer module is a compound mod-ule that implements the Resequencer interface and represents our hybrid resequencer
approach. The HybridResequencer dynamically allocates ResequencerBuffer modules when a packet arrives from a sender for which there is currently no buffer. The mod-ules are removed according to a timeout. The HybridResequencer module also adds sequence numbers to outgoing packets and demultiplexes incoming packets into the appropriate ReseqeuncerBuffer instance. The ResequencerBuffer modules actually handle all of the complexity of queueing and releasing packets based on sequence numbers and timestamps.
A.3.8 Link Layer
The LinkLayer compound module contains several types of submodules. First, it contains the ServerPortQueue module which is an extension of OMNeT++’s Queue container and it buffers packets as they are sent into the network. The rxMeter and txMeter are submodules that can optionally be enabled to measure and produce statistics for the incoming and outgoing server bandwidth respectively. The Load-Balancer.ned file contains all of the various approaches to load balancing described in chapter 3. Finally, path modules are dynamically allocated to represent each of the paths that the server can send to. The path modules are simply used to collect statistics about the number of bytes each server places on each path.
List of load balancers
• ECMP: Equal Cost Multi-Path load balancer randomly hashes flows to paths based on their source and destination address.
• VLB: Valiant Load Balancing randomly assigns each packet to a path.
• RR/P-RR: Round Robin & permutation round robin load balancers described in section 3.2.2.
• SRR/P-SRR: Surplus Round Robin load balancer described in section 3.2.2.
• SD/D-SD: Sorted-Deficit load balancer described in section 3.2.2.
• TP/P-TP: Two-Phase load balancer described in section 3.2.3.
• MP/P-MP: Multi-Phase load balancer described in section 3.2.3.