Funciones de la superintendencia financiera de colombia

To ascertain how effective SOS is at increasing TCP throughput on high speed networks and to better determine the limiting factors of an SOS agent, SOS was deployed over a 10Gbps link connecting Clemson University in Clemson, SC to the University of Utah in Salt Lake City, Utah. The link was a VLAN-stitched, layer 2 link within the AL2S network with a 10Gbps end-to-end link. Each machine described below was equipped with a Myricom 10Gbps Ethernet card with TCP segment

Figure 5.3.2: SOS on AL2S

offloading enabled (default configuration) and with the maximum possible IP MTU of 8976 bytes. The transmit queue length of the network cards on the SOS agents were also configured to be 1000. And lastly, on the agent machines only, the TCP buffer, send, and receive queue lengths were configured to be more suitable for large delay bandwidth product networks [87].

As shown in Figure 5.3.2, the file server was hosted at Clemson, while the client that downloads the large files was hosted at Utah. An SOS agent was also deployed at each location. Ubuntu 14.10 64-bit was installed on the Clemson server and the Clemson agent, while CentOS 6.7 64-bit was installed on both the Utah client and SOS agent. The Clemson server and SOS agent were equipped with Intel Core i5 2400 processors and 4GB and 8GB of RAM, respectively. The Utah client and SOS agent were each equipped with two (per machine) Intel Xeon E5620 processors and 24GB of RAM.

On the Utah agent, since there were 16 available CPU cores, the network card interrupts were distributed evenly across 13 of these cores, the agent application itself was assigned to a single core, and all other OS processes were assigned to the last two cores such that all cores were being utilized and the system load was efficiently distributed. Likewise, on the Clemson agent, since there were 4 available CPU cores, the network card interrupts were assigned to one, the agent application processes were assigned to another, and OS processes were assigned to the other two.

installation of iperf for network throughput tests.

At the Clemson end of the network, the server and the SOS agent were directly connected via their 10Gbps Myricom network cards to an OpenFlow-enabled Dell S4810 network switch using a 10Gbps SFP network cable. The same physical configuration was mirrored in Utah with another OpenFlow-enabled Dell S4810 switch directly connected to the client and the second SOS agent. The S4810 at Clemson and the S4810 at Utah were connected through a layer 2 link traversing AL2S. VLAN translation was performed within this link, causing Clemson to be on one VLAN, while Utah resided on another. This required modifying the default MAC learning algorithm of the SOS Floodlight OpenFlow controller.

A series of tests were conducted running an iperf server at the Utah server and running an iperf client at the Clemson client. This resulted in a flow of data from Clemson to Utah. (By default, iperf tests transfer data from the client to the server – emulating a file upload.) These tests were designed to better gauge the impact SOS parameters have on performance. Specifically, the number of TCP sockets to use between the agents and the number of bytes to send/receive at a given time on a given TCP socket were of interest. A third parameter – the TCP socket receive queue lengths – was set to a constant length of 5, since this parameter has no impact on throughput performance but simply serves as a “safety” in the case of significant packet loss.

Figure 5.3.3 demonstrates the impact the number of parallel sockets and the buffer size used on the agents can have on a data transfer. Without SOS, the data transfer rate between the Clemson client and the Utah server was an average of 130Mbps. With SOS, the maximum average data transfer rate achieved was 5.08Gbps, which was conducted with 60,000 byte buffer sizes and 7,000 parallel TCP connections on the agent machines at both Clemson and Utah. It was noted that the Clemson agent CPU utilization was quite high in the mid-90% range during the tests resulting in the greatest throughput. This is an indication that the agent was becoming the bottleneck. The scalability of SOS can be leveraged to overcome such situations where a single agent is unable to keep up with the desired network throughput.

For the tests in this section, the Clemson client and Utah server were not modified in any way to increase performance. The default TCP algorithm of TCP-cubic [40] was used on each machine, and the Linux default TCP windowing parameters were used. On the other hand, the agents were configured to use h-TCP [42] – designed for high speed and long distance networks – and with increased TCP windowing parameters according to [87].

Figure 5.3.3: SOS agent number of parallel sockets and send/receive data chunk size parameter sweeps