This paper proposes an architectural revamping of the Internet to decouple the act of sending and receiving. In this scheme, packets carry identifiers rather than IP addresses - all packets with a given identifier are directed towards an i3 node using a Chord-style mapping infrastructure. Finally, receivers will trigger the appropriate i3 nodes to route packets to receivers with matching identifiers. In addition to using identifier matching at i3 nodes to route packets to the intended destination, partial matches can be used to simplify multicast and load-balancing mechanisms.
One immediate concern with this mechanism, quite like the ones that arose for the previous DOA paper, is that the DHT look-up and intermediate i3 node traversal could significantly hamper the round-trip latency. Implementing reliability mechanisms (i.e., TCP) on such an architecture could also be a mess, as could security complications. Overall, there are some neat ideas presented here (more so than in the DOA paper) but the concept seems quite unrealistic and impractical.
Thursday, November 6, 2008
Middleboxes No Longer Considered Harmful
This paper underscores the vital role of middle-boxes - specifically, NAT boxes and firewalls - in the modern Internet. Traditional networking principles dictate that such middle-boxes violate not only the end-to-end principle but also the notion that end hosts must be uniquely identifiable throughout a network. The authors claim, however, that these components provide essential security mechanisms, address space utilization and performance enhancements (in the case of caching). Instead of trying to achieve compliance with the "rules" of the Internet, the authors present a Delegation Oriented Architecture (DOA) that seamlessly incorporates middle-boxes. Essentially, DOA provisions unique endpoint IDs in a flat name-space and the ability for the sender and receiver to specify intermediaries that must be traversed (for example, a NAT that must process the packet).
In my mind, the proposed DOA architecture has several issues, starting with the fact that the intermediary specification still appears to defy the end-to-end principle. More importantly, the overhead introduced in the DOA packet header is considerable and I'm not sure how the authors underplayed this issue. Finally, the idea that DHT look-ups (going by previous papers, these are already intricate) will be required on a regular basis raises doubts over the performance and scalability of this architecture. The concept was interesting but the motivation is not very convincing (do we really want to introduce so much overhead just to maintain the sanctity of some networking "rules" or middle-boxes?) and the potential drawbacks are not sufficiently addressed.
In my mind, the proposed DOA architecture has several issues, starting with the fact that the intermediary specification still appears to defy the end-to-end principle. More importantly, the overhead introduced in the DOA packet header is considerable and I'm not sure how the authors underplayed this issue. Finally, the idea that DHT look-ups (going by previous papers, these are already intricate) will be required on a regular basis raises doubts over the performance and scalability of this architecture. The concept was interesting but the motivation is not very convincing (do we really want to introduce so much overhead just to maintain the sanctity of some networking "rules" or middle-boxes?) and the potential drawbacks are not sufficiently addressed.
Sunday, November 2, 2008
DNS Performance and the Effectiveness of Caching
This paper evaluates the performance of DNS over several network traces, specifically looking at query failures (no response or response indicating nonexistent record) and latency perceived by Internet clients. Moreover, it takes the discussion of DNS caching in the previous paper one step further by questioning its impact on overall performance. The authors claim that DNS caching may inherently conflict with some applications that use the naming system, such as Content Delivery Networks (I'm still a bit confused about exactly why there's a conflict here). Looking at the trace analysis, they conclude that caching does not significantly improve performance for the clients but merely acts as a load-controlling mechanism for the name servers.
Even though the evaluation results were convincing, an intuitive explanation for the minimal impact of caching on client-perceived latency (for example) seemed missing. Yet again, several critical performance issues (negative responses, negative caching, etc.) were identified but a deeper insight into these problems was not necessarily offered. The paper provided a useful understanding of the practical issues surrounding the DNS, especially as it begins to interact with other protocols (e.g. TCP) and mechanisms such as CDNs.
Even though the evaluation results were convincing, an intuitive explanation for the minimal impact of caching on client-perceived latency (for example) seemed missing. Yet again, several critical performance issues (negative responses, negative caching, etc.) were identified but a deeper insight into these problems was not necessarily offered. The paper provided a useful understanding of the practical issues surrounding the DNS, especially as it begins to interact with other protocols (e.g. TCP) and mechanisms such as CDNs.
Development of the Domain Name System
This paper discusses the motivation and design behind the Internet's Domain Name System (DNS). Initially, the authors describe the existing centralized HOSTS.TXT record file (which seems like a terrible idea right now, given the single point of failure) and the clear need for a distributed scheme. The hierarchical, tree-like structure that is presented seems quite intuitive and there is little mention of possible architectural alternatives. Unlike most previous papers in the syllabus, this one spends less time foreseeing potential problems; instead, the focus is on DNS design, functionality and a few immediately observed performance issues.
Caching was probably one of the more interesting points of discussion. One issues that was mentioned is that while meaningful query results are cached, negative results for nonexistent records are not. In my opinion, this is a valid but somewhat trivial concern. Instead, some foresight into security issues (i.e., cache poisoning) would have been appropriate. Interestingly, there appears to be a trend throughout many of the original Internet papers - strong assumptions are made about the trustworthiness of participants. Overall, this was an informative paper that underscored the reasons behind the DNS architecture. However, it did not pose as many questions going ahead; in a sense, it felt like undergraduate networking material.
Caching was probably one of the more interesting points of discussion. One issues that was mentioned is that while meaningful query results are cached, negative results for nonexistent records are not. In my opinion, this is a valid but somewhat trivial concern. Instead, some foresight into security issues (i.e., cache poisoning) would have been appropriate. Interestingly, there appears to be a trend throughout many of the original Internet papers - strong assumptions are made about the trustworthiness of participants. Overall, this was an informative paper that underscored the reasons behind the DNS architecture. However, it did not pose as many questions going ahead; in a sense, it felt like undergraduate networking material.
Thursday, October 30, 2008
Wednesday, October 29, 2008
Subscribe to:
Posts (Atom)