Abusos de mercado

The design of the SOS architecture is founded on the agent-based framework. As shown in Figure 5.2.7, the SOS agents themselves implement framework agents and software forwarding devices, while the Floodlight controller implements the controller plugin through the SOS module.

5.2.6.1 Agent Discovery

A primary design goal of SOS is to make it highly and easily deployable with a large variety of supported network topologies. Given that SDN is still an emerging technology, unless an organization replaces their entire network with an SDN, it is unreasonable to expect an entirely SDN-enabled network on which SOS can operate. Thus, emphasis is placed in making SOS interoperable with

Figure 5.2.7: The influence of the agent-based framework in the design of the SOS architecture

traditional network forwarding devices in the data plane.

When an SOS agent is deployed, the controller needs to know about the agent, how to address it, and where it is located in the network topology. Naturally, there are two options: (1) implement an agent discovery protocol or (2) explicitly register the agents with the controller. An agent discovery protocol can be implemented by processing OpenFlow packet-in messages sent to the controller by OpenFlow switches in the SDN in which the agent is installed. The use of LLDP by the agents with custom TLVs is a possibility, but it will not propagate to the nearest OpenFlow switch if there is a non-SDN between the agent and the nearest OpenFlow switch. Likewise, other broadcast and multicast techniques are also not guaranteed to propagate through a non-SDN. Since the addition of an agent is a deliberate task, it is reasonable to require the agent be explicitly added to the controller, which was a design decision made for SOS.

5.2.6.2 TCP Connection Selection

In a similar manner, when designing SOS, a decision needs to be made on how to choose which TCP connections to enhance. Assuming operation in a busy network, there are likely to be many TCP connections in use. Some of these will be short lived, such as loading small web pages. Others might not operate at a very high or consistent bitrate, such as SSH or TELNET. Since SOS is designed to improve the performance of large data transfers over long links, filtering out TCP connections that do not meet these criteria is a requirement in order to not oversubscribe the SOS infrastructure with TCP connections it was not intended to benefit. As such, SOS requires explicit

whitelisting of the client and server IPs, as well as the server TCP port. Because of this, it is also assumed this server port only serves or receives data that meets these criteria. It is understandable that this latter assumption might not hold true for all cases. Under such circumstances, the SOS controller’s packet-in processing logic can be readily extended to perform deeper packet inspection into application headers. For example, HTTP headers could be inspected to select whitelist specific files or paths.

5.2.6.3 Agent Proximity and OpenFlow Switch Deployment

Although SOS can provide transparent performance improvement for end users, it must be deployed correctly in order for maximum performance to be achieved and for the TCP connection to be handled correctly. It is assumed that for each whitelisted TCP connection, network administrators have deployed an SOS agent nearby the client and another SOS agent nearby the server. Furthermore, it is assumed that there is an OpenFlow switch in the path between the client and server at each side of the long distance link to perform the flow operations required.

5.2.6.4 Layer 3 Operation

Lastly, although the SOS architecture supports layer 3 networks between the SOS agents and between the clients, servers, and nearby SOS agents, the SOS controller discussed in this dissertation does not currently support layer 3 routing and path-finding. The implementation of these features is not necessary to deploy SOS and to discuss general architecture, scalability, and performance, which is the focus of this part of this dissertation. Future work is planned to integrate layer 3 routing support into the Floodlight controller, a necessary prerequisite for the SOS module.

5.2.6.5 Multi-Agent Use

Since SOS is designed around the TCP windowing problem and only applies to TCP (and similarly windowed and reliable protocols), a single client cannot utilize multiple local agents simultaneously for a single TCP connection. By design of TCP, the client can only relay data to/from a single machine over a single TCP connection. However, a client can increase throughput beyond what a single SOS agent can provide and up to the link capacity by utilizing other proven throughput enhancing methods, such as parallel TCP, on top of an SOS deployment. However, it is important to note a fundamental requirement for the layering of SOS with other throughput enhancing solutions.

The complementary TCP throughput improvement technologies must not modify the transport or lower layers in the OSI model [86] if they are to be used in conjunction with SOS. Because SOS operates on standard TCP connections, such modifications to the protocol stack on the client and/or server might not transparently pass through the SOS middleware. As such, either SOS might not be able to operate on the TCP connection, or the complementary TCP throughput enhancing technology might have limited or no impact on throughput achieved.