A Policy-aware Switching Layer for Data Centers

The main idea of this paper is to provide a policy layer that does not mandate placing the middleboxes in sequence on the physical network paths. PLayer uses policies that propagate to the switches, which then route packets through middleboxes before delivering them to their destination.

This is a very nice idea that tries to alleviate the complexity of configuring middleboxes, ensures correctness, network flexibility and efficient resource usage. The authors also discuss why minimizing the changes required for adopting PLayer is crucial. It is true that the success of any new technique is tightly coupled to the amount of changes it requires for deployment.

It was nice that the authors also thought about security issues related to PLayer. They discuss how policy violations can take place during policy churn and how these can be solved.

I really liked reading the paper because it gave detailed explanation about the limitations of current techniques and explained PLayer very nicely with all relevant details listed. I would recommend keeping this paper in the class.

Improving MapReduce Performance in Heterogeneous Environments

The authors in this paper propose a new scheduling algorithm LATE that improves performance in heterogeneous environments. The paper is very interesting to read and is well written. Hadoop scheduler makes assumptions like homogeneous environment, tasks progress at constant time, no cost in launching speculative tasks, equal weight to all functions in a reduce task etc. These assumptions degrade performance.

Pros:

• Thinks about heterogeneous environments.
• Execution of speculative tasks is estimated from the time left to finish the task.
• I liked that authors discuss how their time left estimation technique may fail in certain scenarios.
• I really enjoyed reading the paper. It was very nicely written.
• This solves a problem in the data parallel applications that are being used in the industry and are getting adopted by more and more companies.
  

Thoughts:

• The authors suggest that different methods can be used to estimate the time left for a task. Currently, they estimate it as (1- ProgressScore)/ProgressRate. Is there a way to store history of tasks to gather statistics and then use that for estimating the time taken by a task?
• Has there been future work in the area of finding more sophisticated methods for estimating finish times.

A Delay-Tolerant Network Architecture for Challenged Internets

This paper proposes an architecture that uses overlays for achieving interoperability between diverse networks. The motivation behind building this architecture is to address problems with the TCP/IP model with respect to challenged networks. Some of these problems are network partitioning, high latencies and unexpected data transfer delays.

The architecture includes regions and gateways. Gateways are responsible for storing messages to provide reliable delivery. For routing messages they use a naming scheme that uses name tuples. Name tuples are of the form {Region, entity} where region names are unique. Convergence layers add features like reliability, and message boundaries.

Pros:

• Provides in-network storage and retransmissions in challenged networks
• The prototype implementation convinces the practicality of the architecture to a certain extent.

Cons:

• Existing application may need to be changed in adoption of the architecture
• Necessary to evaluate the overhead of using messages instead of packets
• Does it break the end-to-end model?
  

An Architecture for Internet Data Transfer

The authors in this paper propose DOT architecture that separates content negotiation from data transfer. The main idea is to provide a transfer service that can be used by applications for bulk point-to-point transfer. The advantages of providing a transfer service include:

• re-use available transfer service
• ease in adopting new transfer techniques

Instead of iterating how the authors design DOT I would list my views about the paper. I do not have any specific negative points to the proposed scheme. The main motivation is to provide a general data transfer service that anybody can use without spending time re-implementing the same service. It is good to provide general implementations that anybody can use but along with such implementations comes a drawback. The disadvantage is to be unable to add optimizations specific to the application that is using the transfer service.

X-Trace: A Pervasive Network Tracing Framework

X-trace is a tool built to ease the process of diagnosing complex tasks like web requests and DNS resolution. The main concept involves inserting X-trace metadata into a network task by a client. Metadata involves a task identifier that uniquely identifies the task. When a node sees X-Trace metadata it generates a report which is used for reconstructing the datapath. Task tree construction is performed offline by the user. The user collects reports and uses the information to build a request tree and diagnose the path traced by the request.

The main motivation for this work is to ease the method of diagnosing complex systems that have an interplay of multiple applications and protocols. I feel that with the rapid evolution of the Internet and multiple application running over it, it is really required to build better mechanisms for debugging. X-trace aids in automating the process of debugging rather than collecting reports and then manually trying to assemble them.

Even though X-trace shows to be really helpful, first thing that concerned me was related to its adoption. Success of X-trace relies on the easiness of modifying current applications and protocols. Partial deployment of X-trace can limit the view a user may get while diagnosing the problem. I was happy that the authors were aware about these issues and have discussed them in the paper. I would recommend keeping this paper in the syllabus.

Internet Indirection Infrastructure

The authors in this paper propose an overlay based scheme to provide services like multicast, anycast and mobility. The main idea of the paper involves sending a packet with an identifier and the receivers set triggers for receiving packets associated with an identifier.

I liked this scheme because it is neat and simple. The sender has to communicate with the intermediary and not with all the interested receivers of the packet. This aids in decoupling the act of sending from receiving.

This scheme relies heavily on the performance of the overlay. The overlay used should be: Robust, Scalable, Efficient and Stable. The authors choose Chord and say that it satisfies all the requirements.

I really like the concept for its simplicity but few things that concern me are:
1. What happens when a chord node goes down? This involves copying the triggers registered with the failed node to another node. This requires a robust replication and that will make the system more complicated.
2. Efficiency of this system is less because we have introduced indirection.
3. How is revocation of triggers handled neatly?

Middleboxes No Longer Considered Harmful

This paper discusses how middle-boxes such as NAT and firewalls violate the two principles of the Internet architecture:

1. Unique identifier for each Internet entity.
2. Packets processed by their respective owners.

The authors say that even though the middle-boxes break the rules but they are required for important reasons. Few reasons being security and performance improvement through caching as well as load balancing. The paper then proposes an architecture to include the functionality of middle-boxes without breaking the principles.

The architecture called Delegation Oriented Architecture proposes the following things:

1. Globally unique ID in flat namespace which is carried by the packets
   
2. Sender and Receiver can define the intermediaries that should process the packet.
   

Without going into the details of the architecture and how it works, I want to list some of the things that concerned me:

1. After adding the intermediary information in the packet we are still defying the end-to-end principle. What happens if the intermediary crashes?
   
2. The unique identifiers are said to be 160 bit long. The packet is supposed to have 2 160-bit identifiers. Isn't this an overhead for small packets?
3. The idea seems to be interesting but I am concerned about performance. Even though the architecture provides flexibility by allowing the intermediaries to be anywhere and not in the path to the destination. The packet now has to be first traversed to the intermediary and then to the destination. Also, it is required to lookup of the path to the intermediary.
4. Another question that get raised with such systems is scalability. With so many machines in the Internet, if every machine sends the message to an intermediary and the DHT being used for EID resolving, an important question arises that we are relying on the performance of the DHT for lookup and information retrieval.