Obra y Servicios Públicos

Our investigation of packet-level routing in Chapter 3 focused exclusively on the FatTree topology. A logical next step would be to determine whether our results can be applied to other mutli-path topologies. We expect that some of the results can be extended to apply to other forms of the Clos network such as VL2.

One of the key unknowns that we confronted in our study is the precision with which sending rates can be controlled. This presented a significant obstacle in our evaluation of load balancing since we found that the results were very sensitive to bursty traffic.

To overcome this, we attempted to model the possible range of performance that we could expect from flow control mechanisms in real data center networks. We did this by modeling the sending rates of servers as a process that was either Poisson or periodic. The results showed that our multi-phase load balancing algorithm only pro-vides a significant improvement when the sending process is periodic. The scheduling framework can, in principle, simulate the periodic process by strictly controlling the departure times of packets at each VOQ. However, it remains to be seen whether it is practical to achieve the performance of this strict model with a real implementation.

Therefore, an important step to further this work would be to determine where a real implementation may lie on the strict/loose spectrum that we have examined.

Distributed scheduling opens up a rich problem space and the work that we have done represents one approach. The goal was to explore the concept and understand some of the trade-offs. There are many possible optimizations that were not pursued in an effort to simplify the design and evaluation. A logical next step would be to explore some of these optimizations and their tradeoffs. Additionally, our evaluation focused solely on the virtual switch abstraction. Our proxy based algorithm supports any network topology. However, more complex abstractions, such as the Virtual Oversubscribed Cluster (VOC), raise additional scaling challenges since proxies for oversubscribed links need to manage rates for many more servers. While support for such topologies needs to be further developed, one property that could be exploited is that with more servers, the relative differences between their rates decreases, partic-ularly with max-min. This means rates on these links can be scheduled over a longer scheduling interval without significantly impacting performance. Another approach might be to distribute the proxy state for such links among “local proxies”. For ex-ample, to manage rates on an oversubscribed link in the VOC abstraction, a local proxy could be assigned at each group switch to manage the rates for the servers at that switch. For local proxies to converge to the rates assigned by a single proxy, they would need to maintain complete replicas of the state managed by the other proxies.

Alternatively, we could accept an approximate solution in exchange for reduced con-trol overhead by allowing local proxies to exchange just the aggregate backlog and bandwidth requested by their servers.

The use of VOQs with changing rates means the scheduling layer presents an incon-sistent view of the network to the layers above. How precisely the scheduling layer may interact with the protocols and applications above is a question worthy of further exploration. One direction might be to examine how the scheduling layer interacts with common protocols, such as TCP, and determine whether performance can be improved by making scheduling protocol aware.

Another key question is how scheduling impacts the performance of different types of applications. Given the unknown dependency between rates assigned and the behavior of the application, the backlog scheduling problem provides one model to

help answer this question. However, it assumes the arriving backlog is effectively independent of the backlog delivered on the timescale at which scheduling occurs. At a high level, the role of the network in any distributed system is to deliver messages between the various nodes. Therefore, the performance of any data center application can only depend on the network as far as it is bottlenecked on the exchange of some message between its servers. Without making assumptions about the application, we cannot know which messages represent a bottleneck to the application at any given time. Moreover, the scheduling layer cannot even determine where the boundaries of the application layer messages are.

In-spite of these issues, it may still be possible to provide some general way to char-acterize the performance of the application in terms of the rates assigned to VOQs.

We briefly describe one possible approach, which we call message scheduling, that attempts to capture these unknowns. The essential idea is that messages can be de-fined implicitly based on the amount of backlog that arrives over some period, e.g.

one scheduling interval. Given that the scheduling layer has no way to know what messages matter most to the application, the goal would be to bound the time it takes to deliver any message. In order to do this, lets suppose that in the absence of competing traffic, it takes x units of time to deliver a given message. If it takes X units to deliver the message with a given rate schedule, the stretch for that message would be ^X_x. The precise objective would then be to produce a schedule that mini-mizes the maximum stretch over all messages. It is likely that if some algorithm could bound the maximum stretch to some value S, then the application would complete in at most S times the completion time it would have if every message were delivered in the minimum time possible. This problem could be modeled incrementally in a similar fashion to the backlog scheduling problem and it may provide an interesting alternative to complement the approach that we have taken in this work.

Appendix A

FatTree DCN Simulator

A.1 Introduction

This appendix describes our FatTree data center network simulator. This simulator was developed specifically to conduct the work presented in this thesis. However, because it was built on top of the publicly available OMNeT++ [7] and INET [4]

frameworks, some of its components may potentially benefit other researchers who are familiar with these tools. This appendix provides an overview of the simulator and also serves as the primary documentation for others that wish to incorporate parts of our simulation model into their own projects.

The simulator can be found at:

http://www.arl.wustl.edu/~mah5/dc_sim.html