Review of "FairCloud: Sharing The Network In Cloud Computing"

Problem: In the current cloud computing environment. Network is currently shared in a best effort manner, unlike CPU or memory. The key difficulty of sharing network efficiently is the allocation of network for VM X also depends on other VMs that X communicate with.

Key point & trade-off: This paper proposes a set of desirable properties for allocating the network bandwidth at the VM granularity, and show that there exists a fundamental trade-off between the ability to share network according to payment and the ability to provide minimum bandwidth guarantees. It also proposes a mechanism that can select different points in the trade-off between payment proportionality and bandwidth guarantees. This mechanism is called Per Endpoint Sharing (PES). It's a mechanism for sharing cloud networks that allow one to explicitly trade between weight fidelity and guaranteed bandwidth. The main point of PES is to calculate a static weight for each source-destination pair by the following formula:

W(A, B) = W_A / N_A + W_B / N_B

where W_A is the weight VM A has annd N_A is the number of other VMs A is communicating with. Similar to B. But fundamental trade-off or problem here is this doesn't take care of the actual demand of communicating between A and another specific host. If the demand is small, it will not be able to adapt. This is also a common problem for all mechanisms that compute static weights.

Will this paper be influential in 10 years? Maybe, this paper identifies the fundamental trade-off between the ability to provide proportional network sharing based on payment and the ability to provide minimal bandwidth guarantees, it also proposes PES as a mechanism to achieve different design points in the trade-off between these conflicting requirements.

Review of "Towards Predictable Datacenter Networks"

Problem: Cloud providers usually provide storage resource and computation resource as the main metrics for charging tenants usage. Although quite simple, this misses a critical part of of computation, the intra-cloud network. As a result, cloud providers don't usually guarantee network performance. Thus bring unstable performance to tenant's applications, if they relies heavily on network. Is the problem real? Well, maybe for some cases. But some providers do provide a "dedicate lines" for tenants if they are willing to pay.

Key point & trade-off: This paper proposes extending the tenant-provider interface to explicitly account for the network. The key is provide tenants with a virtual network connecting their compute instances. Which can yield significantly better and more predictable tenant performance while reduce tenant costs by up to 74%. At the same time, the flexibility achieved by using virtual networks can makes rate enforcement, billing, etc on tenants much more easily.

Will this paper be influential in 10 years? Maybe. It proposes a good way to solve the networking quality problem in shared cloud through virtualization.

Review of "Managing Data Transfers in Computer Clusters with Orchestra"

Problem: Cluster computing applications transfer large amount of data between computation stages. And these transferring takes a lot of the job execution time. But traditional network research mainly focuses on per-flow traffic management. So this paper proposes a global management architecture and a set of algorithms that improves transfer times of common communication patterns and allow scheduling policies at the transfer level, such as prioritized transfers.

Key point & trade-off: Use a global coordination both within a transfer and across transfers in a hierarchical control structure. The top level of Orchestra is an Inter-Transfer Controller (ITC) that implements scheduling policies such as prioritizing transfers from ad-hoc queries over batch jobs. ITC manages multiples Transfer Controllers (TCs), one for each transfer in the cluster and TC is responsible for selecting a mechanism to use for their transfers. They also actively monitor and control the nodes participating in the transfer. TCs are supposed to be used when a cluster needs to do data transfer. The trade-off here is mainly the extra complexity, you have another layer above transporting, if it fails, they the communication will be aborted. Another possible trade-off is scalability, meaning, how many TCs the ITC can schedule efficiently at the same time.

Will this paper be influential in 10 years? Maybe. It provides a good solution speed up communication in clusters. As long as the complexity can be controlled elegantly and scales really well. I think it's a very good choice to go for system optimizations.

Review of "Fastpass: A Centralized “Zero-Queue” Datacenter Network"

This paper claims that an ideal DC network should provide several properties: 1) packets experience no queuing delays, 2) network has high throughput, 3) network should be able to support multiple resource allocation objectives between flows, applications and users. DC that doesn't have these properties makes it very hard to meet complex service-level objectives and application specific goals.

Key points and trade-offs: Traditional networking protocols are essentially a distributed protocols, congestion control is done at the end-points whereas path selections are done in the middle at switches. In this paper, the authors propose a centralized protocol to handle congestion and path selection. Which they call arbiter. With a centralized arbiter, they loose the scalability and fault-tolerance of the traditional approach but gained several key features such as consistently low latency, no persistent congestion and packets will never be dropped due to buffer overflow.

Will this paper be influential in 10 years? Yes, I think so. Traditional networking protocols are designed for the Internet, which can span across continents. But for networking inside a data center, many of the designs don't actually fit. This paper identifying that and proposing a centralized version – which is possible because it's networking within a data center – made a good option for considering the networking technology for building a better data center network.

Review of "Less is More: Trading a little Bandwidth for Ultra-Low Latency in the Data Center"

Problem: Traditionally network goodness and fairness are expressed in terms of bandwidth. Latency is rarely a primary concern because delivering the highest level of bandwidth essentially entails driving up latency – at the mean and especially at the tail. However, as the real-time requirement of applications becomes more and more critical, latency of networking stack also need to be taken care of.

Key points and trade-offs: This paper proposes HULL witch sacrifices a little bit of bandwidth and get drastically lower average and tail average latencies in data centers. The way it does this is it leaves a "bandwidth headroom" by using Phantom Queues that delivers signals before network links are fully utilized and queues form at switches. It also employs DCTCP to adaptively respond to congestions and to mitigate the bandwidth penalties arise from operating in a buffer-less fashion. Packet pacing is used to counter burstiness caused by Interrupt Coalescing and Large Send Offloading.

Will this paper be influential in 10 years? Maybe. Generally, it's a good improvement of the existing protocol which didn't pay too much attention on the network latency.

Review of "pFabric: Minimal Near-Optimal Datacenter Transport"

Interactive soft real-time workloads such as the ones seen in search, social networking generates a lot of small requests and responses across data centers. Theoretically these requests could be finished in 10-20 microseconds, but in TCP-based fabrics, the latency ca be as high as tens of milliseconds. The reason is these short flows gets queued by co-existing large flows caused by backup, replication, data mining, etc.

So this paper proposes pFabric under this observation. Key points of this paper is based on the opinion that flow scheduling should be decoupled from rate control. they are 1) end-hosts put a single number indicating the priority of the packet. It can be remaining size or completion deadline; 2) Switches choose packet send and drop strictly according to priority. 3) Rate control is minimal. All flows start at line rate and throttle sending rate only when they see high and persistent loss.

Will this paper be influential in 10 years? Maybe. It does provide an simple solution to the current networking stack. But it requires rewriting of the host networking stack as well as switches. The deployment cost might be too high for it to go popular. As long as the manufacturing side keeps up, this should be a great solution.

Review of "Jellyfish: Networking Data Centers Randomly"

Existing high-bandwidth network designs have rigid structure that interferes with incremental expansion, so this paper proposes Jellyfish, a high-capacity network interconnect which adopts random graph topology and yields itself naturally to incremental expansion. And this paper argues that it's also more cost-efficient than a fat-tree.

The main idea behind Jellyfish is that random graphs have higher throughput because the have lower average path length compared to fat tree. But this is only true when all data flows uniformly between servers. If a service has an application server that needs to talk to its databases constantly, this will have a very hot line between two servers while leaving other connections be very cool. With a random graph, you might not leverage this the rack level locality very well. I also think that racks and ToR switches are a good way to organize wires. With the topology suggested by a random graph. I don't know how the wires will look like, and if any issues happen how is an operator going to debug the issue and replace a line. So I don't really think Jellyfish is really a neat idea. But identifying the fact that random graph has a lower average path length is something useful, maybe in another settings when we are able to connect servers using machines.

Review of "PortLand: A Scalable Fault-Tolerant Layer 2 Data Center Network Fabric"

Existing L2 and L3 network protocols face some combination of limitations in the trends of multi-core processors, end-host virtualization, and commodities of scale are pointing to millions of virtual endpoints. This paper proposes PortLand, a scalable fault tolerant L2 routing and forwarding protocol for data center environments.

PortLand employs a logically centralized and replicated fabric manager to maintain soft state about the network configuration information such as topology, mac addresses etc. It's a user process running on a dedicated machine responsible for assisting with ARP resolution, fault tolerance and multi-casting. It may run in a separate control network or simply be a redundantly connected host int he larger topology. It doesn't require any administrator configuration such as number of switches, locations and identifiers of them etc. Since the fabric manager only keeps soft state, it doesn't require replicate to be strictly consistent. Fabric manager helps keeping the mapping of PMAC and real MAC and the corresponding IP addresses. PMAC is a virtual MAC addresses that also encodes position information in it. For example, all end points in the same pod will have the same prefix in their PMACs. Traditional ARPs suffers scalability problem because they need to broadcast over the entire network, PortLand solves this problem by again using fabric manager backed proxy-based ARP. Thus transforming the broadcasting into a unicasting. The fabric manager also helps with fault tolerant routing using a fault matrix.

Will this paper be influential in 10 years? I think so. It centralizes the control logic of a more and more complex network and provides far more features on it than traditional networks. A good way to go under the trends of huge data centers.