Middlebox no longer considered harmful

This paper presents a new architecture of routing and naming so that the design of the Internet makes incorporating middleboxes easier. The authors argue that although middleboxes violates two of the tenets, the reason is that original Internet design is not flexible enough.

The new design uses the notion of EID to serve as global unique identifier, and uses method such as delegation to hop from one EID to another EID. This is how they enable middleboxes not on the physical path. It depends on DHT for naming lookup, translating EIDs to IP addresses or other EIDs.

It wasn't particularly clear to me that the problem with NAT and middleboxes are very serious. I think as ugly as middleboxes and NATs are, they are working fairly well. Everyone is buying them and manufacturs are coming up with various configuration tools to make sure they are set up correctly. This architecture has a clean design to it, but at what cost? Having an entire routing architecture depedant on a dynamic system like DHT just sounds like a bad idea. Particularly because the DHT is on the critical path of every flow until it is cached. The author recognizes the latency of DHT look up as a problem and throws out the caching as a general solution, but I think it is more difficult than that. Also the distributed nature of DHT makes it hard to find problems should one of the node respond slowly or fail.

DNS Performance and Effectiveness of Caching

This paper studies the performance of DNS by taking traces at two campus networks. The result was surprising because I rarely have issues with DNS lookup. Even more surprising is the fact that a large percentage of lookups are never answered.. I suspect the situation has improved since this study was done. Perhaps we need to do another round of study of this sort.

The authors conclude that since short TTL is being employed for a number of applications such as loadbalancing, NS caching is far more effective compared to caching of the actual result. The number of referrals have significant impact on the latency of the lookup.

I like this paper and this sort of large scale studies on the Internet, because there are just so many factors that affect a typical user's Internet experience. Users often do not know where the problem is when they experience a problem. DNS certainly would not be the first place I think of when I have connectivity issues.

Development of the Domain Name System

This paper describes the Domain Name System, which is the de-facto standard in Internet naming protocol. It describes the original goals of DNS, how it evolved and the design decisions behind DNS. Compared to other descriptions of DNS I have seen before, this paper focuses much more on the broader case of resource look up rather than the narrower sense of translating domain name into ip address. Unfortunately, some of these features such as multiple type and class did not see significant expansion even until today. This is not an isolated instance where systems were designed over generic.

In general, I liked this paper because it gave me a lot of historical perspective and the shortcoming and surprises that authors did not original expect. However, the description of DNS in this paper reads too much like a functional specification. A lack of typical usage pattern can cause some confusion for someone who is not very familar with DNS (me). In this respect, I find the second paper to be more helpful.

Chord

This paper describes in detail the design and implementation of Chord DHT system. It is a dynamic system that allows efficient content retrieval based on key value pairs and without centralized coordination.

The central idea to CHord is consistent hashing to allow some ways of balancing the load on different nodes in the chord ring. To further enhance the performance, Chord uses finger tables to allow O(log n) look up time of a particular key in the ring.

There are a couple of issues in this paper that were not clearly addressed. Issues such as fault recovery and migration of state between nodes on a planned take down of a node seems central to the correct functioning and operation of chord ring but received very little attention.

Another problem with this design is the latency in the lookup. Although Log(n) in terms of number of nodes in the hash space, the delay is still significant. Also each hop in the chord ring is an overlay and might translate into multiple hops in IP.

Overall, I still like this DHT compared to others in that it is simple to follow and works reasonably well. As system designers, in many cases, we tend to over design a system and makes it difficult to get implementation right. At some point, law of diminishing return kicks in and it is better to use the simpler design. I think Chord strikes a balance between simplicity and functionality, which is why it is one of the more popular DHTs.

Looking up data in P2P systems

This paper discusses reason behind P2p DHT like systems. Main reason for it is for fault tolerant data look up. They depend on symmetric lookup instead of hierarchical lookup. This way, no single failure is going to bring down the network , however, they tend to not scale as well.

The paper compares different DHT systems based on how they organize the data structure for key lookup. (tree vs. skiplist) and poses a number of open problems.

I like this paper because it gives a gentle introduction to set of problems in DHT and motivation behind it. It also gives nice taxonomy of different DHT project, which serves as a nice lead in to Chord.

Active Network

This paper talks about Active Network. Active networks allows per packet specific processing and embed the processing inside of packet using the concept of a capsule. This gives the network the flexibility to adapt to different need quickly and allows rapid deployment of new protocols.

The main problem that I see and author recognize in this setting is security and performance. To address security, they are using a restricted subset of Java. However, I don't think they are considering the problem of resource exhaustion. Of course, they have a certificate based solution as back up. However, that is very heavy weight, and usually the root trust has to be traced to one entity. I doubt all the networks in the world would trust a single entity to certify active code running in their networks. Subtle problems such as routing loops can occur simply because of a bug. Performance is also a critical issue. If the active content is not cached at the node, loading the node could introduce significant latency.

I like this paper in the curriculum because it introduces necessary background of active networks and gives some reflection on the experience of implementing such a toolkit.

RON

This paper describes an overlay network that is designed to improve recovery time in routing when failure happens and integrate path selection and routing more tightly with distributed applications. They argue that BGP infrastructure takes too long to stabilize.
Ron addresses this by forming a relatively small scale overlay network and maintain link state information to other Ron nodes. It actively sends out probes periodically to detect outage relatively quickly.

I like this paper because it gives a clear goal of overlay networks. It is usually designed to solve a particular issue that is difficult to solve without overhauling entire routing protocol. (in this case, BGP) However, just by limiting the scale of the problem and implementing functionality at application level, RON provides a practical path to deploy such systems. I think that is generally a big win for overlay networks and that's why they have been such active research areas.