CS 598 MCC

Skip to end of metadata
Go to start of metadata

Project topics

Nathan Dautenhahn, Shivaram Venkataraman, Jason Croft: cloud computing* -- presenting 2/17 BandAid

Kurchi Hazra, Raoul Rivas:  energy pr* -- presenting 2/17

Amir Houmansadr, Ravinder Shankesi, Quirin Scheitle: pprp* -- presenting 2/22

Tae Hyun Kim: wireless sharing -- presenting 2/22

if anyone has background in (b) Verilog/VHDL/hardware programming (c) real-time systems can you let me know? I'd be very interested to chat with you.

some project topic areas I could tell you more about: FPGA support for data centers, data center performance, sybil detection in social networks, programming languages for networks, distributed debugging, kernel programming, wireless system setup

Guest lecture signups

Giving a lecture is a great skill to learn. Suggestions: (a) focus on breadth -- give an overview of the most important concepts in that area. Look around for slides that other schools use, and make sure you're covering all the right topics. Give a survey, making sure you hit on the most important concepts in the area (b) focus on depth -- communicate fundamental concepts that are important for people to know. I don't care about particular formats of packet headers or how  -- focus on the underlying algorithmic techniques/tradeoffs/concepts that will be useful for people to know ten years from now (c) explain clearly -- use animations, use color.

Stealing slides from the web is ok. Remember to give them credit, and if you majorly borrow from someone, email me the web link(s) you got material from.

Here's the sequence of steps, with due dates:

  • February 8: send topic and list of 10 subtopics to Matt
  • Feb 16: send first draft of slides to Matt
  • Feb 28: send second draft of slides to Matt addressing his feedback
  • Before your talk : do a practice talk to work out timings.

Nathan Dautanhahn: Intrusion and anomaly detection  -- March 8

Sonia Jahid: Social networking, -- March 10

Quirin Scheitle: The LISP and HIP future internet architectures  -- March 17

Ravinder Shankesi: (TBA) -- March 29

Kurchi Hazra: Network algorithms  -- March 31

Raoul Rivas: Linux Kernel Networking -- April 7

Shivaram Venkataraman: Network support for cloud computing -- April 12


my wishlist: anonymity and privacy in networks, optical networks_, failure reaction protocols,_ web security+ssl/tls, dns+dnssec

Paper reviews

Below you'll find a list of papers. Underneath each paper, write your name, and then append your review right after your name as a single paragraph (if you wrote multiple paragraphs, remove the carriage returns to make them a single long line of text). If you don't see the paper you reviewed listed, or if you don't see your name, please add it in. If the wrong paper is listed, feel free to change it to the right one. Feel free to also list questions you have about the paper (and feel free to answer each other's questions).

M. Casado, M. Freedman, J. Pettit, N. McKeown, S. Shenker, "Ethane: Taking Control of the Enterprise," SIGCOMM, August 2007.

Nathan Dautanhahn:
    This paper proposes Ethane a novel enterprise networking architecture. The
    main problem that the authors seek to address is network management and
    configuration problems. Ethane seeks to fundamentally review the network
    architecture with the goal of circumventing the configuration problems by
    enforcing centralized control over all networking decisions. Comments,
    concerns, and questions:
        - I really liked the Ethane approach. Obviously there are some issues
          when looking at the cost of implementing a centralized architecture,
          but I think they provide a great set of benefits in counter to the
          costs.
        - A key aspect to this is the automatic creation of identity for
          nodes in the network.
        - I had several concerns as I read through the paper (e.g., identity
          spoofing, how does this differ and maybe benefit from something like
          802.1X authentication), and the authors covered these topics in
          their discussion of Ethane's weaknesses.
        - I wonder how this approach would differ if all communication could be
          managed via host level firewalls? This is of course assuming one can
          assume the firewall will be distributed from a central server, and
          is tamper proof.

Rui Guo:

The paper identifies three fundamental principles that are important to any network management solution: 1) the network should be governed by policies declared over high level names. 2) Policy should determine the path that packets follow. 3) The network should enforce a strong binding between a packet and its origin. To achieve these goals, the paper suggests a centralized control architecture to address the concerns that are critical and normal to enterprise networks such as reliability and security. As a consequence, the paper presents Ethane, an instance of the centralized control architecture. Ethane is derived from SANE, a clean-slate approach to enterprise security, and extends SANE in three ways: 1) security follows management. 2) Incremental deployability. 3) Significant deployment experience. Ethane only allows the communication between end hosts with explicit permission. It enforces this requirement through two main components: central controllers and Ethane Switches. A central controller contains the global network policy that determines the fate of all packets. Multiple controllers can be there for redundancy and performance. An Ethane switch simply forwards packets under the direction of a controller. In order to map the global policy to physical entities, it is needed to reliably and securely associate a packet with the user, group, or machine that sent it. The paper also demonstrates the implementation of a policy language for Ethane, which is called Pol-Eth. The policies are declared as a set of rules consisting of predicates and the set of resulting actions for matching flows. Nevertheless, Ethane has its shortcomings too such as in broadcast and service discovery, application-layer routing, knowing what the user is doing, and spoofing Ethernet addresses. 

Kurchi Hazra:

This paper attempts to redesign existing enterprise network architectures in order for them to be more manageable and secure. In order to achieve this, the authors present Ethane which consists of a centralized controller and specialized switches and access points. All requests for flow setup and authentications are directed to the controller, through which network managers can implement the relevant policies. In addition, the controller also dictates the exact route that the flow should take, and direct the switches accordingly. The authors have deployed the system in a university department and have shown promising performances. However, the use of a single centralized controller does not look very promising. Firstly, they deployed it only within a department, and when it comes to larger enterprises (across buildings and so on), this may not scale as well, since the controller maybe at a greater distance from a host, increasing RTT of a packet. The authors have not performed any studies for this case. The authors have argued that one overcome the bottleneck induced by a single controller by using multiple controllers. However, this brings along many important and historic distributed systems problem which do not have perfect solutions, further complicating the entire system. Besides, the authors themselves point out various important shortcomings of Ethane in the paper learnt from their deployment experience. Questions--- 1. How is network management performed in a medium sized enterprise network in today's date? For example, when we login in our department we are first asked to authenticate. What is the course of actions in such a scenario? 2. Do switches cache flows here? It can be common for two hosts to talk to each other frequently.

Amir Houmansadr:

Yue Liu:

Raoul Rivas:

This paper proposes a new architecture for enterprises networks. The architecture proposes id backward compatible with existing Ethernet and therefore it can be incrementally deployed. The Ethane architecture is composed of a centralized Controller that performs routing decisions based on the policies specified by the network managers. It also implements switches that use flow tables containing he routing information of each flow provided by the Controller. I think that the centralized approach of the Controller might limit the scalability of the system especially if every new flow must first go through the controller. I think that a hierarchical approach with multiple local controllers in which only traffic across subnets must go through these controller is a more suitable approach. Also I think that the idea of using a high level language that gets compiled to C++ might cause practical deployment problems in networks that require immediate or frequent changes to the policy like giving new privileges to users or adding new or temporary services in the network. Also the authors mentioned that they observed issues with broadcasting, however boradcast is an important component of many already deployed protocols including DHCP, ARP/RARP and NetBIOS (Samba).

Quirin Scheitle:

The authors propose a central-managed approach to come by most uses of enterprise networks. While introducing major changes in traffic flow and network management, this approach can still be seen as evolutionary, as it is fully backwards compatible to recent Ethernet architectures. Their clearly stated aims for this work pretty well show the biggest problems of enterprise networks today. They want to see a decrease in complexity and human interference in daily administration, and a full path control as well as reliable end-host identification. They give a really good point in the fact that while the success of Ethernet is based on its simplicity and distributed manner, enterprise networks look for consistency in its complex requirements. This fundamental change in requirements gives reason to try a central based architecture for Ethane.  Their approach is that central-based that it offloads basically all the switches' functions to the controller, giving room for much simpler switches that are just told whether to drop a flow or to forward it and on what port. With the default policy to drop flows that are not permitted, the resulting network is actually much safer than a basic Ethernet, where each host can communicate which each other. They manage to actually turn the problem of broadcast protocols (which would open a lot of traffic flows) into an advantage, by having the controller answer ARP requests directly. They also have several resilience features for the controller, which is a single point of failure. These range from cold standby to active load-balancing failover.  They provide an effective policy language and special hardware-based switches. It turns Ethane scales pretty nicely, allowing for up to 20,000 hosts being controlled by one regular PC. They are also going through the shortcomings of their approach, mentioning broadcast protocols not known and therefore not answered by the controller, assuming that TCP/UDP port equals service type, and the fact that they can not control high level data flow, like if one user is forwarding to another user. Their approach sounds appealing to me as it is a surprisingly simple, yet all-mighty approach to give an administrator full control. It is also tested to a medium degree. In my opinion, this sounds like it might actually get deployed in a few years.

Nadia Tkach:
The paper focuses on the problem of enterprise network architecture and network management, policy enforcement and security at traffic flow level. The proposed approach, Ethane, adopts centralized network architecture with a Controller as the point of policy management and Switches distributed across the network that enforce the established policies. This work enables fault tolerance and scalability via Controller replication as well as incremental deployability of Ethane Switches on enterprise networks. It also supports simplified multicast and remote location switch management. While the proposed solution is pretty neat, some of the suggested approaches are controversial and depend on the underlined enterprise network topology. As such, enabling a Controller to control network flows and be the central management point raises the concern of security of the latter. If a single Controller is compromised, the entire network would be compromised causing serious security issues including unauthorized access to resources and/or denial of service attacks. The paper discusses performance evaluation of Ethane prototype, claiming that the proposed system can support sizable networks of about 20,000-25,000 hosts, but these numbers reflect mostly middle-sized organizations. Additionally, authors list a few shortcoming they encountered during system testing such as broadcast and service discovery, application-layer routing, MAC address spoofing, and usage of non-standard ports.

Shivaram Venkataraman:

C. Kim, M. Caesar, J. Rexford, "Floodless in SEATTLE: A Scalable Ethernet Architecture for Large Enterprises," SIGCOMM, August 2008 

Nathan Dautanhahn:

    This paper addresses the issue of providing a scalable and fast Ethernet
    layer that can expand beyond current limitations. The key point is that
    common solutions for Ethernet issues employ various tactics such as VLAN
    segmentation and subnetting, which introduces new overhead in the form of
    configuration management. The author propose SEATTLE, which uses a one-hop
    DHT to lookup the destination for a given MAC address. I have a few
    comments and concerns about the paper:
        - The authors are assuming some level of IP subnetting in the network.
          Is this in contrast to what the authors are seeking to do in terms of
          eliminating extra configuration?
        - The author suggests that DHCP management is hard, but it does not
          seem as though this is enough motivation to claim it is "too much" to
          manage.
        - The authors have a really cool insight in that handling broadcast
          frames the OS must be imposed upon, thus stealing resources in an
          indirect way, one that is not considered often.

Rui Guo:

This paper proposes an innovative network architecture called SEATTLE aiming to achieve the benefits of both IP networks and Ethernet in order to address the growing concern about efficiently managing large networks. SEATTLE offers plug-and-play functionality as in Ethernet using flat addressing, while ensuring scalability and efficiency through shortest-path routing and hash-based resolution of host information. To build a protocol that maintains the same configuration-free properties as Ethernet bridging, yet scales to large networks, SEATTLE offers the features of a one-hop, network-layer distributed hash table (DHT), traffic-driven location resolution and caching, and a scalable, prompt cache-update protocol. The paper examines the characteristics and shortcomings of Ethernet bridging, hybrid IP/Ethernet architecture, and virtual LANs. Based on these, it introduces a simple yet scalable mechanism that enables shortest-path forwarding while maintaining the same semantics as Ethernet in SEATTLE. SEATTLE is backwards-compatible with conventional Ethernet. Through simulation, SEATTLE has been proved to scale to networks that have two orders of magnitude more hosts than a conventional Ethernet network, and to reduce state requirements required to achieve low stretch by a factor of ten, and to improve path stability by over three orders of magnitude under typical workloads. SEATTLE also facilitates network topology changes and host mobility.      

Kurchi Hazra:

This paper presents yet another new enterprise network architecture, this time addressing the mechanisms used for host location discovery, routing and packet forwarding. The authors propose to use a one-hop DHT to reduce the lookup complexity in such networks and to prevent flooding mechanisms used in today's networks. The authors also handle scalability and failures in their system design. They backup their claim of a better performance than Ethernet via simulations. The graphs presented by the authors show promising performance. However, they fail to point out why they have used a distributed hash table and not considered any other data structure. That the authors made significant use of caching to improve performance was a welcome enhancement to the previous paper. However, the results are only via simulations, thus less convincing than a real deployment. Questions - How bad is the current enterprise network management plane to require a radical change such as the one suggested in the paper? The paper sure points out the disadvantages, but with respect to real life packet RTT and management needs, how necessary is a radical change? Perhaps some real-life data and plots to backup the motivation of the paper would be useful.

Amir Houmansadr:

Yue Liu:

Raoul Rivas:

This paper proposes a new architecture for enterprise networks. The approach of Seattle is to replace the current Ethernet architecture with a link-state routing protocol that uses a single hop DHT. Topology changes are handled through updates, deletes and inserts to the DHT. The Seattle provides the same semantics of an etherner architecture and therefore is backwards compatible.  I think however that because the architecture is a more radical design compared to the other paper I think that incremental deployment might be more difficult because a whole subnet might have to be replaced at once. However this architecture looks very scalable and much more resilient compared to the previous paper.

Quirin Scheitle:

The authors see that the simplicity of Ethernet and its 'plug-and-play' system is the reason for its success. Yet, they argue that the major shortcoming of this approach is that it not suitable for bigger networks, due to scalability and resilience issues as well as management complexity and a lack of monitoring. They also treat the common workaround to these problems, to break down Ethernet into small networks and apply IP routing to connect them. This brings further challenges, as it is breaking the simplicity and topological flatness of Ethernet. Their approach to combine the best of both worlds is called SEATTLE.  The main idea, to avoid broadcasting by registering and looking up services in a network-wide DHT seems promising.  They also provide a mechanism to notify end hosts in cases of failure instead of having long timeouts. Their approach has several other great advantages, like a consistent shortest-path instead of a spanning-tree routing. Another very interesting feature of this approach are the so called groups, which are comparable to Ethernets VLANs and can segment the network into arbitrary broadcast/multicast domains. This on the one handside fixes protocols that need broadcast, on the other handside adds great privacy and segmenting options. The paper is very thorough and even contains thoughts on load balancing for the DHTs, introducing several virtual switches for the bigger physical switches. They also have an approach for interconnecting several SEATTLE topologies, which then become comparable to OSPF areas. They add a very thorough, multi-topology simulation of SEATTLE, which shows the Seattle beats Ethernet on many levels, especially the sizes of the switches forwarding tables. It brings up impressive figures, like a reduction of control overhead by a factor of 1000.  They also showed that SEATTLE is more robust against failures then Ethernet, which makes sense given the fact that Ethernet uses just one Spanning Tree, while SEATTLE uses a consistent shortest-path algorithm. They also implemented SEATTLE to do further measurements, which further proof the concept.  To me, this approach appears appealing. It fixes scalability and management-complexity and reduces broadcasts by still having a distributed network. It would be interesting to see the security features of this approach more worked out to see whether it could provide similar features like Ethane and how this approach works against rogue switches or similar things. I think the DHT could actually have a secured registration process and provide some fields for security issues, which could result in great security while still being fully decentralized.

Nadia Tkach:
The paper proposes another enterprise network architecture, SEATTLE, that would provide scalable and efficient self-configuring routing. It is based on certain Ethernet principles, most importantly MAC address assignments (flat addressing) and shortest path routing. The main difference and innovativeness of this approach is the usage of hash functions and (multi-level one-hop) distributed hash tables to store MAC addresses and physical location information about each host. The proposed method supports node mobility and network dynamism. In my opinion one of the most important achievements of SEATTLE is a backward compatibility with traditional Ethernet from end-host perspective. The evaluation results show significant improvement from conventional Ethernet.

Shivaram Venkataraman:

P. Mockapetris, K. Dunlap, "Development of the Domain Name System," SIGCOMM, 1988.

Nathan Dautanhahn:

This paper discusses the development and initial deployment of the Domain Name System (DNS). The then primary naming system consisted of a single text file distributed via a centralized service. This approach did not scale as the number of nodes was growing rapidly. The key problem that the authors faced was to develop a distributed database for the DNS. I really liked their approach, in that the authors sought to create a system with as little complexity as possible while providing a functional and scalable system. I think they achieved this. I really like how they chose not to include some of the more advance databases concepts such as dynamic update, atomicity, voting, and backup considerations in favor of simplicity and speed of development. In addition to this I like how they developed the DNS as a hierarchical system where each institution participating in DNS maintains their own subtree. The last thing that I want to mention is that it seems like DNS was a direct result of a real system's needs, and I wonder if we want to do really impacting research we should be identifying those things that are new in development and have an engineering need.

Rui Guo:

The paper discusses the situation in the 1980s that there was an urge to replace the clumsy host.txt name resolution system. At that time, the mapping between hosts and addresses was maintained on a single, central server. Clients had to download a complete list called host.txt periodically from the server. This approach was not satisfactory in terms of scalability, and hence DNS was introduced. DNS, instead, uses a hierarchical architecture of servers, which contains some root servers, and many more local resolver and name servers. This architecture allows much more scalability. The DNS system is also interoperable with the previous hosts.txt system. Though DNS is a great leap from hosts.txt, it has some shortcomings. For example, it is somehow vulnerable to the attacks of DoS to the root servers which could affect the internet service seriously. How to avoid this potential vulnerability and make the DNS system more distributed will be interesting areas to work on.  

Kurchi Hazra:

This paper presents the design of the Domain Name System(DNS). It explains the need for scalability,  robustness and ease of distributed control that caused the authors to innovate a new naming service. The authors then explain the engineering principles behind the DNS. The DNS internal namespace is organized into a tree like structure free from any network topology. The host to address database is also distributed. The two other important concepts are zones and caching. Zones have information about a subtree of the original tree like namespace. Any organization has control over their own zone and is responsible for maintaining connectivity to the zone. Caching on the other hand relieves an end host from querying the DNS database for redundant information. Cached data is deemed obsolete on the basis of TTL. The paper also journals some lessons that the authors learned during the implementation and subsequent maintenance of DNS. Although caching, distributed processing and use of datagram for queries and replies paid off in terms of performance, the DNS also faced problems such as late or no adoption by softwares, and incompetent implementation of the DNS by administrators. This paper, however, presents a good perspective on the important policies that system designers may neglect, and how they affect performance and reliability of a system. In addition, it is questionable whether the DNS should have been pushed to the end hosts too. Thus, the design of the system could have included interfacing with clients and servers. In addition, one can also ask whether DNS today can be designed using more sophisticated techniques such as memcached. However, one can also argue that the simplicity of the design explains its performance stability throughout these years.Questions -- What are the current typical TTL values? Is this value more for more reliable organizations?

Amir Houmansadr:

Yue Liu:

Raoul Rivas:

 I think that the main contribution of this paper is to describe the engineering principles behind the DNS system. The paper also briefly describes all the features of DNS including classes, zones, root servers and how SMTP uses DNS to route mail. It would have been much more interesting however to read the original paper published in 1983. However, this paper written a couple of years latter provides a couple of lessons learned from the original design of DNS. I also think it is important to read this paper and look at the evaluation from a qualitative point of view rather than a quantitative perspective.  Also I think that while there are many approaches that are starting to be used like using DNS on Anycast and CoDNS, the DNS system is still the most important name resolution system on the internet and therefore important to analyze.

Quirin Scheitle:

I did not see too much of a scientific contribution in this paper.  While it is undoubtedly nice to read about the beginnings of this very important system, the lessons learned for me were actually just a few. Here I strongly have to mention that I was born in the year this paper was published, so I definitely cannot judge what was going on at that time. In the paper, the authors explain how and why the transition from HOSTS to DNS happened. I actually see a bunch of great design decision here, especially the adjustable caching via TTL setting. The paragraphs about network performance are no longer relevant I think. The paragraph about negative caching is a nice lesson on the impact of unexpected behavior. Paragraph 5.4 actually praises a feature that has caused a lot of trouble, which is that in a DNS reply arbitrary additional information can be included, which lead to cache poisoning and the Bailiwick constraint. But it is understandable that at that time no one was thinking about these problems.  They end of the paper reveals some very nice information about the "social" problems of technology, i.e. people not actually caring about the technology but just wanting it to run. The authors recognized that this behavior will not change and therefore strongly vote for e.g. reasonable figures in implementation examples.

Nadia Tkach:

The paper analyzes and evaluated the performance of DNS name service after a few years of its implementation on the Internet. It provides a discussion on the DNS functionality and features, assesses them from the data logs and statistics collected over time, and makes either a suggestion for improvement or supportive information for what has been done correctly. The paper itself doesn't seem to include too much of statistical data other than summarized percentages or averages, and would strongly benefit from variable graphical representation of the data changes over time. Nonetheless, all the conclusions of the paper are quite valuable. It shows that not just the paper but also DNS name service itself had a strong future vision when it has been implemented. As such, the authors express a concern about cached query information, its reliability and security. And indeed, the time revealed an attack on this DNS mechanism known as DNS cache poisoning attack. Some of the suggestions in the paper also included recommendation to web service providers as the success of the whole system depend on overall compatibility of all of its components. For example, many application providers were not using appropriate (misconfigured) TTL values which resulted in high number of queries.

Raul Gonzalez:

Need for a more robust naming service came about as the HOSTS.TXT file grew too large too quickly. A distributed model needed to be built that was lean and flexible. The outward appearance of DNS is a hierarchical name space with typed data at he nodes. There are 2 major active components: name servers and resolvers. Name servers are repositories of info that answer queries. resolvers talk to clients and implement the mechanisms needed to find and communicate with the name servers. DNS has two ways of getting information from nameserver to a client: Zones, and Caching. Zones are controlled by a specific organization which is responsible for distributing copies to servers around the internet. The organization maintains the zones data and provides redundancy to the servers in the zone.  Caching is simply when resolvers remember past queries for future use. One question I have: The paper mentioned that negative caching greatly improves the performance of the system and that it would most likely become standard in the future... my question is, did it? and has there been any issues with misuse? - since there are only a very limited number of positive responses that need to be cached, but an infinite amount of negative caches that might need to occur, is there any possibility for exploiting this? ...

Shivaram Venkataraman:

J. Jung, E. Sit, H. Balakrishnan, "DNS Performance and the Effectiveness of Caching," IEEE/ACM Transactions on Networking, V. 10, N. 5, (October 2002).

Nathan Dautanhahn:

This paper presents a detailed review of DNS performance issues from the perspective of the client, and efficacy of rigorous caching on overall Internet bandwidth caused by DNS. The primary consideration here is that there had not been any in depth review and analysis of DNS, and therefore the authors sought to expose the realities underpinning the current DNS deployment. The authors find that a surprisingly large number of requests go unheeded/unmatched, and several DNS responses are incorrect. They find that caching has little effect on DNS traffic. One thing I wonder about is whether the trace driven methodology is best in gathering these results. Obviously the trace driven is valuable, but I wonder if one could obtain similar results with a probabilistic model. I also like this paper because it represents a systems paper that is measurement focused, not providing a system. It is important to remember that we must analyze what we have in terms of technology so that we can understand it's weaknesses.

Rui Guo:

This paper gives a detailed analysis of traces of DNS and associated TCP traffic collected on the Internet links of MIT LCS and KAIST. The paper consists of two parts: the first part details the pattern and behavior of the clients to interact with the DNS, summarizing the performance that clients perceived and the statistics of failures and errors. The second part evaluates the effectiveness of DNS caching. The analysis points out that 23% of lookups receive no answer and these lookups account for more than half of all traced DNS packets. About 13% of all lookups result in an answer that indicates an error condition. Many of which appear to be caused by missing inverse (IP-to-name) mappings or name server records that point out to invalid hosts. 27% of the queries sent to the root name servers result in such errors. The papers also explore the effect of varying TTLs and varying degrees of cache sharing on DNS cache hit rates. It shows that client latency is not as dependent on aggressive caching as is commonly believed, and the widespread use of dynamic low-TTL A-record bindings should not greatly increase DNS related network traffic.  

Kurchi Hazra:

In this paper, the authors analyze and present DNS Performance as seen in three traces derived from links in MIT and Korea. The authors preprocess the traces to filter out relevant data that can help in the performance study. The results confirm that increasing number of referrals at the DS servers increase the latency of DNS queries. Results also show how the number of wasted queries due to retransmissions in the DNS increased over a period of time. In addition, the authors perform another study on the effectiveness of the caching mechanism of DNS. They point out how DNS scalability is leveraged by NS record caching. DNS cache sharing is most effective when the client size is limited to 10 or 20. They also claim based on the current data that one could decrease the TTL values for A-records without affecting load on remote servers. The authors, however, draw their entire analysis out of traces derived from queries originating in educational institutions. These may not be an ideal representation of everyday traffic in the internet or to the DNS servers. Other than that, the authors have performed a thorough study. It can be asked as to why we need to perform such studies when the DNS works efficiently enough in our day to day lives. However, such studies may throw light on some important design aspects that could have been neglected to this point.

Amir Houmansadr:

Yue Liu:

Raoul Rivas:

 The paper analyzes the effectiveness of DNS caching over the Internet. They perform several measurements on DNS requests and analyze the traces. The paper provides some counter intuitive results showing that aggresive caching on DNS records is not as important as it is thought for performance. Also they show that caching of NS records it is also a non contributing factor for scalability. However they show that A record caching  is important for scalability. In the paper they also analyze. the effects of varying the TTL  and how this effects caching. I think that while the paper provides very interesting results and can provide a good insight to new designs of name resolution systems, the applicability of the results found for the current DNS is limited.

Quirin Scheitle:

This paper performs a nice and thorough measurement on WAN DNS requests. From these measurements, they make valid-looking conclusions on the effectiveness of DNS caching. They provide several very interesting statistics and greatly widened my knowledge about DNS operation. They point out various common mistakes and problems in todays DNS configuration, e.g. that 23% of all negative lookups provide more than 50% of the overall DNS packets, due to excessive resolver retries. They make a strong point for negative caching and forward-filtering bogus queries. They state that NS records draw great benefit from long TTL values, while A records can have values of under an hour to sill work well in cached environments. They show how the requested domains follow a so-called Zipf-Distribution, which is a kind of power-law. This means, few domains aggregate lots of traffic and benefit greatly from DNS caching, while most other domains see few users and are not actually worth caching. This then explains why a cache reaches its  almost optimum efficiency with as few as 20 users. In my opinion, this paper provides very valuable insights in the practical aspects of DNS, and is a highly recommended read for researchers in DNS area as well as network operators that actually care about optimization.

Nadia Tkach:

This paper is more recent but similarly to the previous work analyzes and evaluates the performance of DNS name service. The authors collected DNS packet transmission data over 3 different periods of time and used this information to terms of how many requests were answered with success, unanswered, had negative answer and zero answer. One of the most interesting results found were the correspondence between various TTL values, hit rate and overall DNS performance. As it turns out, only the TTL values of less than 1000 seconds has any significant performance degradation, while the TTLs of any greater value have relatively similar performance benefit. As further analyzed the proposed explanation for this paradigm can be explained by the multiple successive look-up requests from the same client as a page being downloaded by a web browser. From here authors suggest that giving lower TTL values (but above 1000 sec) will not harm hit rate, which has a significant benefit for dynamic use of DNS such as mobile host location tracking. Also, interesting to notice that over 63% of DNS query packets were generated by look-ups that received no answer, and that's not even counting the duplicate packets. One shortcoming of this work that could skew the results was that the collected data only contained information about look-ups that required wide-area queries.

Raul Gonzalez:

This paper attempts to figure out if the widely held beliefs that hierarchy and aggressive caching are the truly the two factors that contribute to the scalability of DNS. To do their experiments, the researchers focused on performance of DNS as seen by the clients in terms of latency and failures. Another focus was how TTL and cache sharing impact the efficacy of caching. In order to do the analysis, the researchers used the fact that most TCP connections are preceded by a DNS query. They were able to trace the TCP traffic with the related DNS queries.  One observation they came upon is that over a third of all DNS lookups are not successfully answered. If a query is answered, it happens mostly within 2-3 retransmissions, after that there is a very high probability that the overall query will never get answered. Yet DNS servers continue to retransmit aggressively  and these retransmissions for queries that will never be answered account for more than half of all DNS traffic. It turns out that Caching Address records is not as effective as previously thought. This isn't necessarily a bad thing since many common practices today involve  techniques that undermine address caching. Name-server record caching however is extremely important to the scalability of DNS.

Shivaram Venkataraman:

C. Partridge, P. P. Carvey, E. Burgess, I. Castineyra, T. Clarke, L. Graham, M. Hathaway, P. Herman, A. King, S. Kohalmi, T. Ma, J. Mcallen, T. Mendez, W. C. Milliken, R. Pettyjohn, J. Rokosz, J. Seeger, M. Sollins, S. Storch, B. Tober, G. D. Troxel, D. Waitzman, S. Winterble, "A 50-Gb/s IP Router," IEEE/ACM ToN, 1998.

Nathan Dautanhahn:

This paper describes and discusses the development of a 50 Gb/s router. The authors tackled the hard issue of pushing routing hardware and software to the limit. They achieve this by providing five innovative components in their router: 1) forwarding engines have a complete set of the routing tables, 2) the router uses a switched backplane, 3) forwarding engines are placed on boards distinct from line cards (less of an innovation and more of a practical design choice), 4) forwarding engines can receive packets from line cards using different link layers, and 5) the implement QoS into their router. It is interesting to note that a lot of these innovations require or rather move responsibilities for tasks further down in the software/hardware stack. For example they save a lot of time by pushing routing tables to the line cards. One thing I see with this is that you gain in performance but you trade-off flexibility and compartmentalization. This is not necessarily a bad trade-off just important to note. Overall, a very innovative design. I am also interested in the fact that this paper is for the most part an engineering effort. I do not know of the related work and would be interested to know how innovative the design really was.

Rui Guo:

This paper proposes a multi-gigabit router (MGR) design that has internal bandwidth at multi-gigabit rate, enough processing power to forward several million packets per second, and conforms to a set of protocol standards all at the same time. This MGR design has multiple line cards and forwarding engine cards, all plugged into a high-speed switch. The major innovations are: 1) each forwarding engine has a complete set of the routing table instead of a modest cache of recently used routes. 2) The design uses a switched backplane instead of a shared bus. 3) The design separate forwarding engines from line cards. 4) The separation can facilitate the forwarding engines to receive packets from the line cards that use different link layers. 5) The design can include QoS processing. 

Kurchi Hazra:

In this paper, the authors present the design of a 50 Gb/s IP Router. The major innovations in the design that led to such high speeds are as follows. Each forwarding engine used its own summarized version of the router table called forwarding table, rather than a cached version of the central router table. The design also uses a switched backplane. Forwarding engines are placed on separate cards to make the forwarding process fast. Also, the forwarding engine software is designed to make the common case faster, some exceptions and rare cases are not handled by the fast path code. The line card has 16 interfaces with total bandwidth of each card being 2.5 Gb/s. In addition, the router also supports QOS processing. Routing table update is decoupled from forwarding table updates which results in avoiding effects of route flapping. However, this may also lead to packets being sent out on stale paths for sometime, even though the router is informed of a bad path. Overall, however, they have redesigned the router carefully to match up to the demands of the current and future internet.

Amir Houmansadr:

Yue Liu:

Raoul Rivas:

I think the paper is interesting from an historical point of view. The paper dates 1998 when Gigabit networks were not common. I think it would be interesting to compare current router architectures with this paper to see how much current designs of routers differ One interesting point of the design in the router is the fact that they use a switched backplane. This clearly show that COTS vendors really  overused the bus architecture in many low cost systems for more years than needed. Another important design feature is that each of the forwarding engines keep full routing tables allowing for fast  lookups. I think that the paper should have also tried to offload some of the routing cost by caching packet headers of flows similar as it is done in ATM.

Quirin Scheitle:

The paper says that there has been reasonable concern that routers might not scale up to the expected bandwidth growth in future years, and the authors made great success in proving that routers will easily scale for future years. They provide a device with a 50 Gbps backplane, capable of carrying a payload of 2.5 Gbps on each line card. They combined off-the-shelf hardware and OS with some individual components like FPGAs. Their major innovations are reasonable and proof to be right, like having a set of two routing tables in each forwarding engine and to use a switched backplane instead of a bus. They reason all of their design choices, involving which CPU they picked etc. They give further details on what look like thorough work on soft- and hardware design, which is basically just a bunch of deatails summed up. They strengthen their desgin choice to make the common case fast, as packets tend to form flows which greatly profit from route caching. While the paper itself does not seem too interesting, the fact that they achieved a speedup of a factor of two to ten compared to usual equipment at that time makes the paper very relevant and a great contribution to the scientific community.

Nadia Tkach:

The paper describes a new router design that provides higher performance and bandwidth at the hardware device level (unlike the link connection level or buffer size). Based on the design decisions and choice of hardware organization and usage, the proposed router can support up to 50 Gb/sec with 3.3 Gb/sec per card data bandwidth. The separation of forwarding engine from line cards and switch backplane provides expediency and flexibility, and allows the router to use multicast operations and maintain fine-grained balance between routing tables and forwarding tables to avoid route flaps. Also, having an independent forwarding engine enables easier support of virtual private networks. Additionally with the consideration of IPv6 and IPv4, the router doesn't check the IP checksum but only updates it as needed if one exists. Switch architecture is pipelines and support flow control. The performance degradation isn't caused by floating point operations in any way, but can be caused by multicast packet copying or invalidation of on-chip routing tables.

_Raul Gonzalez:_

This paper describes a way of implementing a high speed router. As link bandwidth and transmission links grow improve, routers seem to be one of the lagging technologies, but this router implementation is capable of supporting 50Gb/Sec speeds. The router, named MGR consists of line card and  forwarding engines plugged into a switch backplane. The MGR introduces several novel implementation details. For example, each forwarding engine has its own routing table  as opposed to having a central master routing table. The reason being that at high speeds, a centralized routing table becomes a bottleneck. Second, as already mentioned, the backplane is a switch instead of a shared bus for parallelism. additionally, the forwarding engines are separated from the line cards for expediency and flexibility. MGR also support a QOS processor. the MGR accomplishes all of the tasks that any other router can do - except for  checking the IP checksum.  The reason being that they could not find a way to do the check without compromising the speed of the MGR considerably. Fortunately, the checksum is not of great concern since more in depth checks are usually done at the ends such as CRC checks. Moreover, IPv6 removes the checksum alltogether. The heart of the high speed switch is the Allocator, which takes all of the (pipelined) requests ,computes a configuration and informs the source and destination cards on that configuration. In order to process requests fairly and at high speeds, the allocator creates a grid representing the inbound and outbound connection requests, randomizes the rows and columns (for fairness) and then  evaluates the requests in parallel. Parallelism is possible without causing conflicts between decisions by using a wavefront algorithm that only analyzes the requests that are physically impossible to contradict one another.

Shivaram Venkataraman:

A. Demers, S. Keshav, S. Shenker, "Analysis and Simulation of a Fair Queuing Algorithm"

Nathan Dautanhahn:

This paper discusses router queuing algorithms and their role in managing congestion control. The authors are attempting to handle problems associated with using a FIFO queue design, which primarily includes the issue of participants in theh protocol that for some reason or another do not conform their traffic to the standard. The end is given too much control in that case and as such it is easy for a given node to manipulate the network such that they can acheive a higher rate of data transfer than other nodes. The authors propose an algorithm that creates queues from each individual host. In this way the queues will be handled in a round robin fashion, which eliminates the potential for a node to gain greater bandwidth by tampering with the end-to-end algorithms.

Rui Guo:

Kurchi Hazra:

This paper was published in 1989 and presents the authors' efforts in coming up with a fair queuing algorithm in gateways. The authors firstly point out how FCFS is inadequate since one source can unfairly use a lion's share of the bandwidth. An algorithm that uses Round-Robin to transmit packet from different sources can suffer from a similar problem if a source uses arbitrarily long packet lengths. The authors thus introduce a modification to the Round-Robin based method. The authors propose that whenever a packet finishes transmission, the next packet sent is the one with the smallest value of the finishing time. The authors highlight the ability of their algorithm to punish and control ill-behaving sources. I liked the fact that they give a vivid explanation of what "sources" could mean and what do they mean exactly by "fair". The authors present simulation results of the performance of their algorithm using FCFS as a benchmark under different network congestion scenarios. It would be interesting to see how the algorithm would perform in today's network architectures.  However, suppose someone pays a service provider for extra bandwidth. It is not clear if such policies can be encompassed into this algorithm, although the algorithm can give faster service to certain users. 

Amir Houmansadr:

Yue Liu:

Raoul Rivas:

Quirin Scheitle:

Dating back to 1989, this paper identifies and solves most of the basic problem in queueing we are still struggling with today, in 2011. I was really surprised that the theoretical solutions proposed in '89 are still not implemented or used in practice. Especially the fact that the algorithm proposed by this paper penalizes bad users and therefore "changes the rules" of the game are especially interesting and make this effort feasibly to implement in practice. The paper is well produced, though being wrong in denying the wide future success of TCP. Still they are right in stating the bigger point that any malevolent user can simply alter its TCP implementation to gain more bandwidth if fairness would relay on end-to-host fair play. They take a novel way by spliiting up the fairness problem into three separate categories, adding delay to bandwidth and buffer space. This is important to meet the different demands of telnet-like from FTP-like traffic. They implement their fair queuing gateway mechanism and run thorough tests with various protocols and setups. These tests suggest that they greatly succeeded if their gateway is combined with a clever end-to-end protocol. They still provide better fairness, but less efficiency with a generic end-to-host flow control mechanism. They take very reasonable assumptions throughout the paper, provide a lot of credit and reference to related work and definitely show the shortcomings of their approach, especially doubting the feasibility for fast gateways. The thourogh measurements provide valuable insights. A great paper in my opinion.

Nadia Tkach:

The paper proposes a fair queuing algorithm in order to achieve improved congestion control / avoidance and enforce fair resource allocation among different flows. The suggested solution ensures that each user receives no more resources than it requested and no single has higher minimum allocation. The benefit of this paper is that the core allocation strategy is to impose less delay on those flows that utilize less than their fair share of bandwidth and penalize those users that are using the most buffer space and have a poor flow control. This scheme provides insurance to the rest of the network to protect well-behaved sources from ill-behaved ones. One downside of this solution is that it's designed solely to provide equal or less fair share of bandwidth per user but it doesn't prioritize the flows based on the type of communication or user privileges. One suggestion the authors make in this regard is for file or mail servers to establish a number of flows which could be each regarded as a new user thus achieving higher allocations. The problem with this approach that it can still result in high congestion and low throughput and can potentially be abused by malicious users.

Shivaram Venkataraman:

Ion Stoica, Scott Shenker, Hui Zhang, "Core-Stateless Fair Queueing: A Scalable Architecture to Approximate Fair Bandwidth Allocations in High Speed Networks", SIGCOMM'98

Kurchi Hazra:

This paper presents an architecture that attempts to allocate bandwidth in high speed networks in an approximately fair manner. In their architecture, some routers called edge routers compute per flow rate estimates, whereas core routers combine the information passed by edge routers along with their own estimates of aggregate traffic to probabilistically drop packets. The authors provide theoretical analysis of their approach and prove that their algorithm is fair in the sense that the excess service received by any flow is upper bounded by the fair share rate. They claim that their approach is less complex than existing queuing algorithms, but fail to provide any results to prove their point. In addition, they do not base their experiments on real-life internet traffic traces, which makes it difficult to understand the performance of the algorithm in real-life scenarios. It is not clear whether their proposed algorithm will be able to handle differentiated services and short bursts of traffic.

Quirin Scheitle:

The proposed approach takes some good assumptions about queueing itself, its core deployability  and its users incentives to accord. They end up with a solution that does not require per-flow state in the core. Their approach meets the crucial requirement of simplicity, yet being effective. They divide the network into core and edge. For a new flow, which starts at an each router, the ingress router calculates an amount alpha, representing the fair amount of bandwidth every flow should get. Then, it estimates the bandwidth used by a stream by its arrival rate k. The bandwidth allocated then is min(alpha,k). This (!) result is written into the packets when they are forwarded to the core, enabling those routers to quickly allocate bandwidth without performing complex computations.  It is important to note that this algorithm determines the drop rate of packets at routers, not the finally usable netto end-to-end bandwidth. This depends greatly on how the CA/CR porotocls on the end hosts react to packet drops. Their thorough simulations, including  most of the complexity and variety of todays networks, show that their CSFQ approach is performing well, but leaves room for some improvement. They also spend a great amount of time on discussing treatment of ill-behaved flows. This approach looks good to me, especially as it actually supports multi-.hop congestion control.

Nadia Tkach:

The paper proposed a new core-stateless fair queueing (CSFQ) scheme for classifying network flows, estimating flow rates, and avoiding congestion at the routers. CSFQ doesn't provide formal algorithms and is open to a further research but its main contribution is a proposed architecture of edge and core routers on a network / an island of routers. Separating edge routers from core routers allows to minimize the computation requirements at each core router in order to enforce fair queuing. Edge routers compute per flow state and assign labels to each packet which can be used by core routers to make queuing decisions. While preliminary results of the simulations discussed in the paper are promising, it would be interesting to see how the performance of the entire network is affected by implementing estimation algorithms at edge routers. In order to analyze each flow and assign labels to each packet, edge router might require more computational power or computational time and possibly a larger queue to store packets, and might impose a delay into each flow on the network. Another concern was the deployment limitations. As edge and core routers are assigned per island it restricts implementation of CSFQ to be performed only per island as a whole.

N Feamster and Hari Balakrishnan, "Detecting BGP Configuration Faults with Static Analysis," NSDI 2005.

Nathan Dautanhahn:

his paper proposes the router configuration checker (rcc), that identifies BGP configuration faults in AS level routers. The main problems in developing rcc is that BGP is a flexible protocol, which creates complex configurations making it hard to create a high level specification as to what constitutes a correct configuration, and secondly BGP is deployed in a distributed fashion making it hard to implement and verify. The author's basic approach is to define a correctness specification that is then turned into a set of correctness conditions. Then the authors create an intermediate representation of a router's configuration and compare this to the correctness conditions. The result  is a set of failures. Overall this paper is well written. I like its style, and the authors have shown a rigorous experimental approach to the project.

Rui Guo:

Kurchi Hazra:

This paper presents the design and implementation of a BGP router configuration checker tool that operates via static analysis of configurations before they are deployed on real networks. The work is motivated by the fact that many a times network faults and partitions result from BGP router misconfigurations. The authors try to identify two category of faults, path visibility faults, that is, faults prohibiting BGP from correctly dissemination information about an existing path, and route validity faults that enables BGP to advertise paths that do not exist. In order to do so, they use a normalized representation of the BGP configuration in the form of relational tables. The tool then derives constraints in order to detect possibly existing faults via several policy checks, formation of graphs and cycle checks in the graphs. The tool has been downloaded and successfully used by many network operators to discover faults in their configurations. However, the tool is not a complete solution to BGP configuration fault checking, since it assumes that the configuration is such that BGP will eventually converge to a stable state. In addition, the authors also point out that the tool is not fool-proof; it may raise false positives and ignore certain faults. Also, since some latent faults can only occur be triggered by a series of events, the tool may not be able to detect them. The tool will not discover faults involved in inter-AS routing. 

Amir Houmansadr:

 The paper presents a configuration checker for the BGP protocol. Network administrators configure BGP and before deploying this configuration they run a static analysis checker. The idea is to detect the failures before they are deployed. Rcc is composed of a preprocesor  and a parser that map the configurations from BGP into a cannonical representation (eg. only constraints without specific information). This constraints are then fed into the verifier who notifies the administrators of prossible configuration faults. The paper can identify route validation and route visibility problems and a few other problems. I think that tools like rcc are very useful and tend to reduce the number of bugs in rcc configurations, still does not solve the problem completely. While it is impossible to think that we can replace BGP completely,  I think that a better approach would be  to design a safe protocol that can be deployed incrementally so that major AS operators have a sound configuration and other AS operators that cannot replace their protocols due to location, resources or legacy equipment can still use BGP.

Yue Liu:

Raoul Rivas:

 The paper presents a configuration checker for the BGP protocol. Network administrators configure BGP and before deploying this configuration they run a static analysis checker. The idea is to detect the failures before they are deployed. Rcc is composed of a preprocesor  and a parser that map the configurations from BGP into a cannonical representation (eg. only constraints without specific information). This constraints are then fed into the verifier who notifies the administrators of prossible configuration faults. The paper can identify route validation and route visibility problems and a few other problems. I think that tools like rcc are very useful and tend to reduce the number of bugs in rcc configurations, still does not solve the problem completely. While it is impossible to think that we can replace BGP completely,  I think that a better approach would be  to design a safe protocol that can be deployed incrementally so that major AS operators have a sound configuration and other AS operators that cannot replace their protocols due to location, resources or legacy equipment can still use BGP

Quirin Scheitle:

This paper introduces a tool called rcc, which checks BGP configuration files of an AS for coherence and detects errors by doing so. The huge complexity of BGP configuration actually surprised me. A big problem in BGP configuration is the fact that the configuration of an AS should be coherent, but depends on each single node and its interaction with others. This makes the BGP configuration of the "system AS" one of a distributed nature, prone to hard-to-detect configuration errors. The authors come up with configuration constraints, which are actually things that should not happen. In parsing the config files, they try to detect these errors. They spend a good amount of writing on motivation, design and implementation, but the most interesting, yet least covered by the abstract, part is on which errors they found and how network administrators reacted on those. They draw some highly interesting high-level lessons from these. The most important one is I think that iBGP/route reflector design causes a lot of problems. If I would have to cope with BGP administration, I would definitely take a look at that paper and consider using rcc on my configuration files.

Question: "BGP is 10 years old" - What did people use before BGP?

Nadia Tkach:

The paper offers an interesting approach of using static analysis principles for BGP configuration correctness verification. It works at an AS network level analyzing not just configuration policies at each particular BGP router but also checking the correctness across pairs, clusters and network BGP routing as a whole. BGP static analysis is a complex task, and while the proposed tool performs a significant amount of verification, it still is not guaranteed to find all faults and sometimes identifies benign or false positive faults. In certain number of cases BGP configurations that are identified as faults are actually intentionally specified by the AS entity in a particular way. Such false positives results in notifications and extra manual analysis from network administrators. Another concern is existence of false negatives. We cannot be sure if the tool described in the paper doesn't produce any false negatives as they might not appear obvious on the network until a particular scenario is encountered.   

Shivaram Venkataraman:

R. Fonseca, G. Porter, R. Katz, S. Shenker, I. Stoica, "X-Trace: A Pervasive Network Tracing Framework," NSDI 2007.

Nathan Dautanhahn:

This paper presents X-Trace a traceroute like tool that spans multiple protocols, administration domains, and components. My initial response is that the paper is confusing. I seem to be able to grasp a vague impression of what the authors are purporting, but it is not obvious from the writing what the value of X-Trace is. It seems like the author's came up with their three use cases as a really novel way to identify some problems, and then attempted to generalized the solution into a framework. The problem of creating a traceroute like tool across such a broad spectrum is that one must consider all of the flexibility of the layered networking model and in some way deal with that complexity. I wonder if the X-Trace is truly a generalizable framework that can obtain consistent results. I do like the approach and the work the authors did just not necessarily the way it was sold. Another major issue I have with this paper is that it entails some major limitations, namely, the extensive modification to all components participating in the X-Trace (e.g., Apache, Proxy, Network Layer, etc.).

Rui Guo:

Kurchi Hazra:

This paper presents a framework that enables tracing a task, as requests made by the task propagate across a network. In order to do this, the framework embeds XTrace metadata to the requests being sent out as extensions in already existing headers of various network services and protocols. By tagging all network operations causally related to one task, the authors build a task-tree. In addition, when a node receives XTrace data, it generates a report and either stores it locally or reports it back to another machine, depending on the privacy policy. The task tree is then reconstructed offline, enabling post-task analysis. However, as pointed out by the authors, all protocols do not provide for extensions, in case of which, the authors had to make changes to protocol implementations. However, this may not also be possible in real-life scenarios. In addition, since the framework collect data across nodes which may or may not belong to the same network that the requesting machine belongs to, privacy issues may hamper the effectiveness of the tool. Also, XTrace introduces a latency of 15% in a single server, which may not be acceptable in servers with high load. 

Amir Houmansadr:

Yue Liu:

Raoul Rivas:

X-trace is an active diagnosis tool that embeds metadata in all the layers os the netwrok architecture to provide a complete view of the system and interaction of all the protocols. They support causal relations in their analysis and the data is sent out-of band to the user. I think X-trace is a step forward on what a packet sniffer can do and try to infer from the packet  information and static knowledge on the protocol. However i think that the main problem is that all the devices need to be instrumented which can limit its scope to local area networks or within a single ISP. I also think that the cost of implementing the backward compatibility modules that insert the data into the packets for legacy devices can be quite difficult for the administrators and might lead to less acceptance. Also the paper is not so clear about how devices that are not instrumented handle the augmented packet with xtrace metadata if we want to diagnose compliant devices but not legacy devices.

Quirin Scheitle:

The authors propose a novel approach of linking together debug information across various applications, layers and administrative domains. Their point is that the usual tools usually just handle one network layer or one application layer at the same time. By inserting metadata into their packets, they can trace packets vertically through layers as well as horizontally through application proxies. The evaluation of their approach is encouraging and giving a real and viable value to this approach, as they are able to identify some considered-though problems much faster then with usual analysis. Though being worked out very thorough and implemented by the authors in various environments and aplications, this approach has big drawbacks: It requires applications and protocols to be modified, and their model of dividing up administrative domains sounds rather complicated. Furthermore, the problems they show sometimes require permanent tracing enabled, as the problems are transient and would not show up again on a reload with tracing enabled. These usecases are in my opinion a too big waste of CPU cycles. For debugging specific problems this should be a fair approach. Generally, I think this approach is a good step in debugging complex problems in networking. Given the impact of changing basically everything, I would wait to see some more discussion about this before using it.

Nadia Tkach:

X-Trace framework provides the trace of the data path for specified user online task requests. The proposed solution seems to be very promising but has a few downfalls. First of all, it requires changes to the underlying protocols, clients, servers, network systems and devices. While authors argue that the framework can be adopted incrementally offering an incentive for more widespread adoption, it's still questionable how useful X-Trace can be when implemented only at a single layer. Another drawback is the performance overhead of using X-Trace. While the numbers mentioned in the paper don't show a drastic change with implementation of framework, the percentage of the performance overhead though reaches 15% in total system throughput. Consider links that are even slightly congested, the 15% increase load can make a significant difference overall.

Shivaram Venkataraman:

B. Fortz, J. Rexford, Mikkel Thorup, "Traffic Engineering with Traditional IP Routing Protocols," IEEE Communication Magazine, October 2002.

Nathan Dautanhahn:

Rui Guo:

Kurchi Hazra:

This paper presents a traffic engineering approach that aims at alleviating some bottleneck links in a network. The authors propose that every router could have a view of the network topology, along with information about the traffic demands in the network. Using a routing model, one should be able to compute a set of paths for each pair of routers. The model in conjunction with the traffic demand gives an estimate of the traffic volume in each link. Lastly, a human operator or a script should be able to change the weight associated with a bottlenecked link. After the network converges to a stable state, the traffic demands will readjust so that utilization of individual links is not considerably high. However, clearly, changing the link weights often will cause instability in the network, and hence the authors suggest making such changes infrequently. The authors also try to keep the maximum utilization below 100%, but in reality, network operators keep utilization below 20% to help cater to bursts of traffic.

Amir Houmansadr:

Yue Liu:

Raoul Rivas:

Quirin Scheitle:

The paper is not researching a new approach to traffic engineering, but rather giving a good overview of the existing techniques and evaluating one idea with proper measurements. Their idea is to use the tools we have right now, i.e. not changing routers or routing protocols to achieve an as close as possible approximation to a global optimal setting. They use standard OSPF or ISIS as a routing protocol and usual and simple path costs as their only way to modify the networks behavior. A very good point in my opinion is that they also consider path cost changes as a big impact change and try to minimize the number of required path changes. They used a different number of an optimal link utilization than we did in class (60% instead of 20%), which does not make sense to me (20% sounds far more reasonable). They achieve very good results, only about 3% under an optimal solution, and expect to be able to provide 50% more effective end-user bandwidth given the same hardware. They show that changes of very few results can give reasonable good results. While the paper is a nice read, I could not take too much value of it. It gives confirmation that good traffic management is possible with the recent infrastructure, but fails to give enough details to actually realize it. This might be caused by the partly corporate funding of the research. I would see it as a confirmation and motivation for researchers to do further research in that direction.

Nadia Tkach:

Shivaram Venkataraman:

S. Kandula, D. Katabi, B. Davie, Anna Charny, "Walking the Tightrope: Responsive Yet Stable Traffic Engineering," SIGCOMM 2005.

Nathan Dautanhahn:

Rui Guo:

Kurchi Hazra:

Amir Houmansadr:

Yue Liu:

Raoul Rivas:

Quirin Scheitle:

The authors work on an approach to create online traffic engineering. They realize that online parameter tuning will lead to a systems and control behaviour and do stabilization calculations according to this field. Their algorithm promises a good solution, but requires modification in he router software and a source-routing approach. While the source routing is achievable within a single ISP using MPLS or similar, the software modification is probably not as simple as the authors promise. The software requires to keep a lot of MPLS tunnels open, to send probes through the network, and balance the traffic flow-wise over these tunnels.  This requires to recognize and keep track of flows, to process measurements and keep state of its result. While these steps are probably necessary to a good online TE approach, I'd have liked to see some more thoughts on the feasibility of implementing all this behavior into highly optimized internet routers, which handle a lot of traffic. Over all, still a good paper and a nice proof that the complexity and stability of online TE are handable.

Nadia Tkach:

Shivaram Venkataraman:

S. Shenker, "Fundamental Design Issues for the Future Internet", IEEE JSAC, 1995.

Nathan Dautanhahn:

This paper reviews the standing of the Internet and discusses important considerations with respect to its future design. The goal is to analyze the Internet in light of the fact that new application paradigms are being created that require a different set of service guarantees than already present in the Internet. The author's argue that the Internet should incorporate multiple service delivery types, and consider adding an admission control framework. The key service requirement considered in this paper is that of dealing with applications requiring real-time like performance (e.g., voice, video, etc.).  Overall, the author is arguing for multiple classes of service models, and admission control. I think the paper presents itself at first as a general look into this issue of future design, but it has the hidden, or maybe not so hidden agenda of pushing the multi-class and admission control arguments. The author has provided great insight into the true issues at the core in a simple and easily understood manner. One thing I really liked about this paper is the discussion of how one evaluates the proposed system. The author suggests simply that the user's satisfaction with the service is the end result. He then creates a simple mathematical model to represent this, but I think it very keenly pushes the discussion towards those things that the user's of the system care about, and no t just some esoteric argument of why one thing is better than another. One concern I have about this paper is that the author is arguing to add to the Internet architecture for real-time like applications, but how many times/service models can one add before the complexity of the Internet is unmanageable?

Rui Guo:

Kurchi Hazra:

This paper dates back to 1995. The authors in the paper make some strong statements, claims and predictions. However, it is unfortunate that many of their legitimate suggestions have not taken effect in today's internet. For example, they argue that the internet should support more than best-effort services. Nevertheless, the internet continues to do so. They argue that increase in QOS should be accompanied by an increase in pricing when supporting more than one class of traffic. They also predict that overprovisioning the network to support real time applications will not be cost-effective. However, overprovisioning is precisely what today's internet does. It is disappointing to see that technical issues regarding real time applications on the internet that were concerns in 1995 continue to exist today.

Amir Houmansadr:

Yue Liu:

Raoul Rivas:

 Even the paper dates from 1995 I think that the internet still suffers from the same challenges. The keynote from Alain Fiocco at MMSys mentioned that the majority of traffic of the internet in 2014 is going to be video, followed by videogames and web pages. Cisco is working on implementing a more synchonous type of networking mechanisms to account for this incredible ammount of real-time traffic. After reading this paper it comes to me notion that maybe differentiated services are not going to be sufficient for this traffic increase. However integrated services do not scale well, and I think that it is crucial to find a middle ground that allows us to handle rea-time traffic from emerging applications like interactive 3D video and exergaming, where delays of 100 ms and above are not acceptable and where buffering and overprovisioning are not possible. It is going to be interesting how much this ideas in the paper show up again in the years to come.

Quirin Scheitle:

To me it was really interesting how reasonable the arguments of the authors and their conclusions were, and how completely wrong they turned out to develop in the real future then. They predict that we need more service models than best effort to maxmimize usage of infratructure in terms of user satisfaction instead of just thworing more and more bandwidth at the problem. They predict that an explicit control of the service type should happen in the application on the end host. They argue that the network should turn down streams that would decrease the overall user satisfaction. All these predictions, as well-reasoned they are, turned out completely wrong in the further development of the Internet, probably as the authors underestimated the financial incentives for ISPs to keep their network as simple as anyway possible. Still, the paper is a very good read and showed up some very good directions for 1995. I think user happiness would be better today if their suggestions would have been picked up. They have some very good points in the paper, such as that an admission control without a significant turndown rate does not have any benefit (as it will not stop networks from being dramatically overprovisioned), and theur graphs for bandwidth - user happiness relation are a pretty good point of view on networking. A good paper at that time, should have probably had more impact.

Nadia Tkach:

Shivaram Venkataraman:

D. Clark, S. Shenker, L. Zhang, "Supporting Real-Time Applications in an Integrated Services Packet Network: Architecture and Mechanism," 

Nathan Dautanhahn:

This paper proposes an architecture/framework to handle real-time applications in packet-switched networks. The primary problem with this is that packet switched networking did not provide the type of algorithms and queuing that are required for handling both real-time applications and other applications. The authors suggest an architecture that provides two types of service commitments -- guaranteed and predicted -- for real-time applications, defines the service interface, I.e., how a given application will state its requirements and be provided the guarantee from the network, scheduling algorithms that provide these real-time guarantees, and a discussion about admission control in the network. I think that the authors have really found a great problem, as is evidenced by current trends to send voice/video over IP. The authors have done a good job of clearly stating their case, and provide good algorithms to handle the issues. I like that this paper addresses both the real-time systems and networking communities. It is impressive that they have combined these into a coherent and cogent argument for their system.

Rui Guo:

Kurchi Hazra:

This paper presents an infrastructure and mechanisms to support real time applications in ISPNs. The authors first characterize the kind of real time applications that we use, and accordingly propose two real time services- guaranteed service, that uses a static worst case delay bound and predicted service . The authors describe the very famous token bucket filter. They then propose scheduling algorithms for these two levels of services separately followed by a unified scheduling algorithm in a common framework. These algorithms at each switch so that the service guarantees are kept. I felt that the paper was very well written. In addition, I was impressed by how they use simple concepts such as FIFO to solve the problem in hand. In addition, they categorize real time applications and the kinds of guarantees that such applications require in a very simple but comprehensive manner. However, since they propose changes in switches, I am not sure how adaptable it is to the real internet in today's world, when real-time traffic is steadily growing.

Amir Houmansadr:

Yue Liu:

Raoul Rivas:

 This paper presents an architecture for real-time applications through using an "integrated services" approach. I really like the charactreization of applications in terms of more stringent realtime requirement (guaranteed) and less stringent (predicted). I think that classification can be used to categorize current internet applications like gaming with high interactivity and tight requirements and video on-demand with less tight requirements due to buffering. The architecture supports admission control based on QoS requirements and it also supports adaptation in case that the QoS of the application change or the network conditions change. I think that this paper along others set the foundations of QoS in networks, however it is sad to see that this approaches have not reached the internet completely.

Quirin Scheitle:

Within this paper, the authors treat the case that the various types of applications inject various types of traffic into the Internet, demanding again various types of service provided by the network. They divide non-bulk traffic patterns into hard realtime traffic and soft realtime realtime traffic, which demand guaranteed service or predicted service from the network. They show that common FIFO is not optimal to meet all these demands. They provide highly interesting views by first looking at how to optimally provide guaranteed service, then how to to optimally provide predicted service. They bring up a very interesting view that was new to me, that in terms of real-time view, it is interesting to share jitter between applications. Therefore, their approach in which they  combine those two approaches, clearly distinguishes the needs for traffic sharing (FIFO is optimal) and traffic isolation (WFQ is optimal), which are also interesting and very clear thoughts. While the paper seemed a little long-breadth and confusing in the beginning, it revealed a clear, very straight-forward structure and approach of thinking in second glance. A good read to understand the challenges in queueing.

Nadia Tkach:

Shivaram Venkataraman:

D. Katabi, J. Wroclawski, "A Framework for Global IP-Anycast (GIA)," SIGCOMM, August 2000.

Kurchi Hazra

This paper presents a global, scalable and efficient IP-anycast service. The authors focus on routing and addressing issues only and want to minimize the routing table overhead as well as eliminate confining anycast addresses to pre-configured topological regions. The authors subdivide anycast groups into several categories namely internal, external, popular and unpopular groups and propose to handle each case separately. They concentrate on caching for external popular groups and exploring other BGP routers for searching for routes of such groups. However, their design requires changes in BGP routers, which may play a role in inhibiting its use. In addition, they cache the routes and are hence obviously limited by the router cache size. They argue that unpopular groups may anyway have to be deleted. However, if there is an explosion in the number of popular anycast groups, their scheme may not be a complete solution. 

Raoul RIvas

This paper presents a global anycast service. More specifically the paper solves the problem of how to disseminate anycast routes without having to broadcast all anycast routes globally or having to limit the routes to a small region. They solve the problem with a 'coarse' approach in which they provide default
routes and a 'fine' approach in which they provide customized routes. I think the approach is adequate and their experimental evaluation looks good.
However i think the style of the paper would be consider unorthodox for this days

Quirin Scheitle

The authors present a solution for global anycast, which might be used e.g. to configure all clients with the same DNS server IP adress and then just route this to the next available DNS server. Their approach to distinguish anycast adresses from unicast addresses sounds not very efficient to me. By placing the anycast indicator into the LSBs, every administrator of a network has to watch out to not assign e.g. .243 IPs to a host. Then, they use more parts of the IP adress to indicate anycast groups etc, which is in my opinion infeasible to do. It did not come clear to me how this approach should work efficiently in practice. Besides this addressing issue, which might be solved by using another protocol than the overcrowded IPv4, they divide anycast groups into popular and unpopular ones. Popular groups are routed by the network on a demand-basis to the most efficient anycast address. Unpopular ones are simply routed to the home adress, which is encoded into the IP anycast adress. Lookups for efficient anycast routes are propagated on a peer-to-peer basis, which is a interesting concept, as it correlates in some way to their assumption that certain services might be popular in one set of users while not in another set of users. Similar sets of users might somewhat be neighbours in the network (as they might exchange some more traffic). They did a good evaluation, based on what sounds like a realistic ISP topology, which shows that their approach scales well. However, their approach is built strongly on assupmptions that might not be true, like the relation/scale of popular and unpopular anycast services.

J. Byers, M. Luby, M. Mitzenmacher, A. Rege, "A digital fountain approach to reliable distribution of bulk data," SIGCOMM, September 1998.

Nathan Dautanhahn:

Rui Guo:

Kurchi Hazra:

This paper proposes using a different set of erasure codes called Tornado Codes than the then commonly used Reed Solomon codes for error correction to avoid losses in bulk data transmission. They show that although Tornado Codes may require transmission of an additional number of packets than that necessary in Reed Solomon Codes, the encoding time in the server and the decoding time in the host machines are much faster. However, there may be two arguments against using the Tornado Codes. Firstly, the machine that they used for benchmarking in order to show faster processing speeds of Tornado Codes had less RAM and processing speed. In today's world, when most host machines/servers are very fast and have high RAM, the encoding and decoding times maybe faster. In addition, the authors highlight that they are not focusing on real time applications; but as such applications are slowly but steadily becoming an important part of the internet network traffic, it may not be a good idea to transmit additional packets as Tornado Codes require; Reed Solomon or some other erasure code may prove more effective in today's scenario in that case. Also, by trading off between the number of packets transmitted and encoding/decoding times, the authors are entrusting the efficiency responsibility on the internet which is not in the hands of either the provider(server) or the clients(host machines). Encoding/ Decoding times, on the other hand, can be handled by provider/client by using more CPUs, RAM and by exploiting parallelism in the code. All these methodologies are very common in today's world.

Amir Houmansadr:

Yue Liu:

Raoul Rivas:

This paper proposes a protocol for reliable multicast and broadcast of data in heterogeneous clients. They call the protocol digital fountain. The protocol
uses erasure codes that use large block sizes. In general an erasure code is a forward error correction algorithm. It transforms a message of k symbols into a
message of n symbols that can b recovered by a subset of these n symbols. The paper proposes to use Tornado codes,a type of erasure code.

Quirin Scheitle:

This paper proposes an interesting approach called a digital fountain, in which as soons as a client receives a certain number of packets, no matter at which times he was listening, he will have a complete image of the distributed file. This is superior to traditional multi-/broadcast, as the client can pause, resume and lose packets at any time, without losing relevant efficiency (in terms of time listened/time net data received). To achieve the behaviour of a digital fountain, they use so called Tornado codes, which are more sparse than the to that time common Solomon Reed codes. This makes them slightly less efficient, but magnitudes faster in de/encoding. The name is derived from the fact that once a certain threshold of packets is achieved, a tornado equations will be solved. They also address scaling to large files, with the interesting "coupon collector's problem", and propose a scheme to use these codes for layered multicast. The approach sounds really interesting and significant, levering the problem of distributing files possibly by a lot. One very important fact for that is that a client can actually download from several sources at the same time without losing efficiency. The evaluations look proper and are well explained, so a good paper in my opinion. Questions: Is there a similar approach in use out there? Are tornado codes comparable to LDPC codes/aim for the same thing?

Nadia Tkach:

Shivaram Venkataraman:

Randy Baden, Adam Bender, Neil Spring, Bobby Bhattacharjee, Daniel Starin, "Persona: An Online Social Network with User-Defined Privacy", ACM SIGCOMM 2009

Sonia Jahid, Prateek Mittal, Nikita Borisov, "EASiER: Encryption-based Access Control in Social Networks with Efficient Revocation"
Kurchi Subhra Hazra:

This paper presents Easier that aims at reducing the overhead of reissuing keys to a group, or re-encrypting data while using attribute-based encryption in online social networks. Each user has a proxy with a secret proxy key assigned along with revocation information. The basic idea is that a user who wants to decrypt a data takes a part of the cipherext to the proxy. The proxy can then user its key to convert the ciphertext into a form that only an unrevoked user can combine it with its secret key to decrypt it whereas a revoked user cannot. The paper elaborates on how Easier achieves the above tasks. The authors also depict some evaluation. However, since the system is built for OSNs, it is not clearly how much dynamism one sees in the groups formed here. Some data or statistics about this would be helpful in motivating the purpose of the paper.

Quirin Scheitle:

The authors focus on the problem of revoking an user's access rights to content encrypted for a group once that user is removed from a group. Usually, this would require rekeying of the content, which would be expensive. The authors suggest a proxy that is modifying the encrypted data in a way that only non-revoced users can further decrypt it. To revoke a user, one has only to change the key deposited at the proxy. As the key deposited at the proxy is of no specific value itself, it can be trusted to the OSN provider. The paper shows a lot of math and that is feasible to share content with a potentially large group of users (O(100)) in feasible computational time. Though, providing some more background and a little more discussion could have helped the paper.

Tom Jagatic, Nathan Johnson,Markus Jakobsson and Filippo Menczer, "Social Phishing"

Kurchi Subhra Hazra:

This article presents an interesting study conducted by the authors on the students of Indiana University to comprehend the vulnerabilities of the subjects to phishing, especially when the source of phishing is derived from social contacts that the subjects have on the internet. Some results were very surprising, for example, the fact that many students continued to be deceived again and again, and the experiment was more successful when the source of the email appeared to be an individual of the gender opposite to the subject.  The study also well illustrates the evils of the information that we let out on the internet, and how such information can be exploited against us. 

Quirin Scheitle:

This study shows the impact of phishing mails sent to victims from their friends' email adresses. The results showed a shocking success rate of 72%, even in majors like science and computer science, though the usual signs of a phishing attack were still in place (like the wrong adress bar). One thing I miss a little is the point for which I myself might have fallen for such an attempt: The training of our brain to usual phishing patterns, and the improbability in terms of such patterns for an attack phishing for university credentials. Otherwise, I especially like their conclusions from users reactions, because they actually analyze all the anger and attacks they were opposed to. They show that users are still widely uneducated about the security threats in the Internet and though have big problems to admit their errors, which leads to a mitigation instead of public disclosure of those attacks. A very good paper, showing good research.

Yi Wang, Eric Keller, Brian Biskeborn, Jacobus van der Merwe, and Jennifer Rexford, "Virtual routers on the move: Live router migration as a network-management primitive," SIGCOMM, August 2008.

Nathan Dautanhahn:

Rui Guo:

Kurchi Hazra:

Amir Houmansadr:

Yue Liu:

Raoul Rivas:

Quirin Scheitle:

The authors prepose an architectur of virtual routers, being able to live-migrate on different hardware. They aim for the perfect case, live-migrating wihtout losing packets, degrading performance, or losing conncetivity in routing protocols. Their work stands on the base of previous work that explored the possibility to move "physical" links between different devices. This technology is not fully available off-the-shelf on a broad scale, but I think it is fair game to assume a recent or near future deployment of these techniques in big and/or interested ISPs, which are probably the target group for this technology. They state that up to 90% of all router maintenance could be performed without downtime using their approach. They also make a good point in power consumption, which can be reduced with virtualization. They take a very clean approach, separating the different needs for data plane and control plane, bringing up a very interesting point where a routers control plane actually controls two data plans in migration to avoid inconsistency. I wonder if this approach might be used to provide hot-standy functionality with permanently redundant data planes. They show some very good thought in only migrating the critical parts of the control plane, using given binary programs on routers and refilling the FIBs newly due to their size. The availability of two working data planes then allows them an asynchronous migration of links, greatly leviating constraints for this newest part of technology. Their implementation seems very thorough and flawless. Evaluation sounds impressive, with actually no data packets lost or severelly delayed or reordered in migration and migration times around a few seconds. Even two-second hello intervals can be hold up by the control plane on a fully equipped OSP-BGP router. They also bring up important points in migration scheduling, like not accidentally moving two routers built for redundancy on the same hardware, and mention that the scheduling overall might be a really hard problem, so they suggest find just good instead of optimal solutions. A really good and inspring paper in my opinion, though the introduction of this virtualization concept might bring up some issues through bugs in the virtualization layer.

Nadia Tkach:

Shivaram Venkataraman:

Microsoft Technet, "Virtual Private Networking: An Overview." (read "Introduction", skim "Tunneling Basics" and "Advanced Security Features" and "Accounting, Auditing, and Alarming")

Nathan Dautanhahn:

Rui Guo:

Kurchi Hazra:

This is a white paper that discusses the key features that any Virtual Private Network should provide to its users. In addition, the paper discusses how these features are implemented in new tunneling technologies such as PPTP and L2TP. This article serves as a good read for an overview of the details of VPN implementation, specifically in Windows 2000. 

Amir Houmansadr:

Yue Liu:

Raoul Rivas:

 The arcticle is a white paper that describes in an introductory manner two VPN technologies at Layer 2: Microsoft PPTP and L2TP. The L2TP works as a session layer protocol. It works by encapsulating layer 2 packets and tunneling them through UDP. In contrast, the PPTP uses the GRE protocol (a Cisco protocol for VPN). While both protocols provide basically the same functionalities. The main problem of PPTP is that routers must support the GRE protocol in addition to TCP/IP, which causes compatibility problem in low end routers.

Quirin Scheitle:

I think this article is somewhere between a feature summary of Windows 2000 for experienced administrations and an overview over VPN technologies for people that try the first time to set one up. It provides a nice, though clearly lacking depth, overview over available techniques and design decisions that have to be taken. I think it is a good overview about all these tunnel techniques that one has typically not heard of before (like L2TP) and giving useful hints on whether these approaches might be suitable for the situation or not.

Nadia Tkach:

Shivaram Venkataraman:

V. Paxson, "Strategies for Sound Internet Measurement," IMC, October 2004.

Nathan Dautanhahn:

Rui Guo:

Kurchi Hazra:

Amir Houmansadr:

Yue Liu:

Raoul Rivas:

Quirin Scheitle:

Nadia Tkach:

Shivaram Venkataraman:

TBD

Nathan Dautanhahn:

Rui Guo:

Kurchi Hazra:

Amir Houmansadr:

Yue Liu:

Raoul Rivas:

Quirin Scheitle:

Nadia Tkach:

Shivaram Venkataraman:

Matt Welsh, David Culler, Eric Brewer, "SEDA: An Architecture for Well-Conditioned, Scalable Internet Services," SOSP, 2001.

Nathan Dautanhahn:

Rui Guo:

Kurchi Hazra:

Amir Houmansadr:

Yue Liu:

Raoul Rivas:

Quirin Scheitle:

Nadia Tkach:

Shivaram Venkataraman:

Eric Brewer, "Lessons from Giant-Scale Services" IEEE Internet Computing, 2001.

Nathan Dautanhahn:

Rui Guo:

Kurchi Hazra:

Amir Houmansadr:

Yue Liu:

Raoul Rivas:

Quirin Scheitle:

Nadia Tkach:

Shivaram Venkataraman:

TBD

Nathan Dautanhahn:

Rui Guo:

Kurchi Hazra:

Amir Houmansadr:

Yue Liu:

Raoul Rivas:

Quirin Scheitle:

Nadia Tkach:

Shivaram Venkataraman:

Adolfo Rodriguez, Charles Killian, Sooraj Bhat, Dejan Kostic, Amin Vahdat, "MACEDON: Methodology for Automatically Creating, Evaluating, and Designing Overlay Networks," NSDI, 2004.

Nathan Dautanhahn:

Rui Guo:

Kurchi Hazra:

Amir Houmansadr:

Yue Liu:

Raoul Rivas:

Quirin Scheitle:

Nadia Tkach:

Shivaram Venkataraman:

Boon Loo, Tyson Condie, Joseph Hellerstein, Petros Maniatis, Timothy Roscoe, Ion Stoica, "Implementing Declarative Overlays," SOSP, 2005.

Nathan Dautanhahn:

Rui Guo:

Kurchi Hazra:

Amir Houmansadr:

Yue Liu:

Raoul Rivas:

Quirin Scheitle:

Nadia Tkach:

Shivaram Venkataraman:

Dave DeWitt, Jim Gray, "Parallel Database Systems: The Future of High Performance Database Systems," Communications of the ACM, 1992.

Nathan Dautanhahn:

Rui Guo:

Kurchi Hazra:

Amir Houmansadr:

Yue Liu:

Raoul Rivas:

Quirin Scheitle:

Nadia Tkach:

Shivaram Venkataraman:

Ron Avnur, Joe Hellerstein, "Eddies: Continuously Adaptive Query Processing," SIGMOD 2000.

Nathan Dautanhahn:

Rui Guo:

Kurchi Hazra:

Amir Houmansadr:

Yue Liu:

Raoul Rivas:

Quirin Scheitle:

Nadia Tkach:

Shivaram Venkataraman:

Frank Dabek, M. Frans Kaashoek, David Karger, Robert Morris, and Ion Stoica, Wide-area cooperative storage with CFS, ACM SOSP 2001, Banff, October 2001

Nathan Dautanhahn:

Rui Guo:

Kurchi Hazra:

Amir Houmansadr:

Yue Liu:

Raoul Rivas:

Quirin Scheitle:

Nadia Tkach:

Shivaram Venkataraman:

Sanjay Ghemawat, Howard Gobioff, Shun-tak Leung, "The Google File System," SOSP 2003.

Nathan Dautanhahn:

This paper addresses the design and implementation of the of the Google File
System (GFS). The key challenges addressed by this paper are how to deal and
leverage the following issues: component failures, larger files than common,
data modification is mostly of the append type, and a common understanding of
how applications will interface with the system. These issues are bi-products
of the type of systems and work that Google does, which forced them to
re-considered fundamental storage system principles. Additionally, the Google
work style also provides several variations, which can be leveraged such as
knowing how to optimize the file system for specific applications. It appears
as though the system performs well, as one would expect for it to be used as a
production level system at google. I have a few questions of how GFS would do
in different environemnts, but that is a small problem when looking at how
useful GFS is for Google.

Rui Guo:

Kurchi Hazra:

Amir Houmansadr:

Yue Liu:

Raoul Rivas:

Quirin Scheitle:

Nadia Tkach:

Shivaram Venkataraman:

Miguel Castro, Barbara Liskov,"Practical Byzantine Fault Tolerance," OSDI 1999.

Nathan Dautanhahn:

This paper proposes a new (in 1999) replication algorithm for tolerating
Byzantine faults in a system. The key problem being addressed is that current
approaches were either too theoretical leading to impractical algorithms in
practice or made synchronicity assumptions when dealing with an obviously
asynchronous environment such as the Internet and network communications. The
authors claim that their system will handle up to n-1/3 faulty nodes, which is
an improvement on the theoretically proven amount. This paper makes one very
large assumption, though, in that each node is assumed to fail independently of
the others. For this assumption to hold each node in the system must use some
different implementation, which for networks and the Internet is infeasible.
This is a common assumption for a research paper to make, but when considering
that the authors are seeking a realistic system it is a bit of a hindrance. It
does not take away from the contributions of the paper, but still mean that
there is a lot of work to do. I liked the simplicity of the algorithm, and the
discussion of how to deal with non-determinism. Overall, this is a great work.
The authors have provided an in depth and cogent discussion of important
issues.

Rui Guo:

Kurchi Hazra:

Amir Houmansadr:

Yue Liu:

Raoul Rivas:

Quirin Scheitle:

Nadia Tkach:

Shivaram Venkataraman:

DNSSEC

Nathan Dautanhahn:

Rui Guo:

Kurchi Hazra:

Amir Houmansadr:

Yue Liu:

Raoul Rivas:

Quirin Scheitle:

Nadia Tkach:

Shivaram Venkataraman:

Stefan Savage, Neil Cardwell, David Wetherall, Tom Anderson, "TCP Congestion Control with a Misbehaving Receiver," ACM Computer Communications Review, 1999.

Nathan Dautanhahn:

Rui Guo:

Kurchi Hazra:

Amir Houmansadr:

Yue Liu:

Raoul Rivas:

Quirin Scheitle:

Nadia Tkach:

Shivaram Venkataraman:

Victor Voydock, Stephen Kent, "Security mechanisms in high-level network protocols," ACM Computing Surveys, 1983.

Nathan Dautanhahn:

Rui Guo:

Kurchi Hazra:

Amir Houmansadr:

Yue Liu:

Raoul Rivas:

Quirin Scheitle:

Nadia Tkach:

Shivaram Venkataraman:

William Enck, Peter Gilbert, Byung-gon Chun, Landon P. Cox, Jaeyeon Jung, Patrick McDaniel, Anmol N. Sheth, "TaintDroid: An Information-Flow Tracking System for Realtime Privacy Monitoring on Smartphones," OSDI 2010.

Nathan Dautanhahn:

Rui Guo:

Kurchi Hazra:

Amir Houmansadr:

Yue Liu:

Raoul Rivas:

Quirin Scheitle:

Nadia Tkach:

Shivaram Venkataraman:

Michael Reiter, Aviel Rubin, "Crowds: Anonymity for Web Transactions," Communications of the ACM, 1998.

Nathan Dautanhahn:

Rui Guo:

Kurchi Hazra:

Amir Houmansadr:

Yue Liu:

Raoul Rivas:

Quirin Scheitle:

Nadia Tkach:

Shivaram Venkataraman:

H. Yu, M. Kaminsky, P. Gibbons, A. Flaxman, "SybilGuard: Defending Against Sybil Attacks via Social Networks," SIGCOMM 2006.

Nathan Dautanhahn:

Rui Guo:

Kurchi Hazra:

Amir Houmansadr:

Yue Liu:

Raoul Rivas:

Quirin Scheitle:

Nadia Tkach:

Shivaram Venkataraman:

Fernando Silveira, Christophe Diot, Nina Taft, Ramesh Govindan, "ASTUTE: Detecting a Different Class of Traffic Anomalies," SIGCOMM 2010.

Nathan Dautanhahn:

Rui Guo:

Kurchi Hazra:

Amir Houmansadr:

Yue Liu:

Raoul Rivas:

Quirin Scheitle:

Nadia Tkach:

Shivaram Venkataraman:

David Wagner, Drew Dean, "Intrusion detection via Static Analysis," IEEE Security and Privacy, 2001.

Nathan Dautanhahn:

Rui Guo:

Kurchi Hazra:

Amir Houmansadr:

Yue Liu:

Raoul Rivas:

Quirin Scheitle:

Nadia Tkach:

Shivaram Venkataraman:

Mark Handley, Vern Paxson, "Network intrusion detection: Evasion, traffic normalization, and end-to-end protocol semantics," USENIX Security, 2001.

Nathan Dautanhahn:

Rui Guo:

Kurchi Hazra:

Amir Houmansadr:

Yue Liu:

Raoul Rivas:

Quirin Scheitle:

Nadia Tkach:

Shivaram Venkataraman:

Frank McSherry, Ratul Mahajan, "Differentially-Private Network Trace Analysis," SIGCOMM 2010

Nathan Dautanhahn:

Rui Guo:

Kurchi Hazra:

Amir Houmansadr:

Yue Liu:

Raoul Rivas:

Quirin Scheitle:

Nadia Tkach:

Shivaram Venkataraman:

Roger Dingledine, Nick Mathewson, "Tor: The Second Generation Onion Router," USENIX Security, August 2004.

Nathan Dautanhahn:

Rui Guo:

Kurchi Hazra:

Amir Houmansadr:

Yue Liu:

Raoul Rivas:

Quirin Scheitle:

Nadia Tkach:

Shivaram Venkataraman:

Guo et al., "BCube: A High Performance, Server-centric Network Architecture for Modular Data Centers" SIGCOMM 2009.

Quirin Scheitle: I found the paper to be somewhere in between a technical report and a research paper, neither fully satisfying the demands of any direction. For a technical report, it lacks a good evaluation of the practability, for a research paper some theoretical in-depth analysis. The concept itself is still interesting, showing an easy and very practical way to come up with a quite new concept of networking. The concept is well done and the implementation looks promising, though its complexity and non-scalability limit the idea to this very niche of networking in container data centers.

Nathan Dautenhahn:

This paper proposes BCube,  which is an implementation of a Modular Data Center
(MDC),  and  specifically targets  the networking  components of  the MDC.  The
primary motivation  is that  industry requires large  scale computation  with a
myriad of commodity machines.  A key  technical characteristic is that the type
of jobs executing  on the data center are  data-intensive,  which requires high
end-to-end bandwidth for  optimal efficiency.  The network is  a key bottleneck
and a  primary motivation  for this  work.  BCube has  a spanning  tree routing
mechanism useful  for one-to-all communications  where the transmission  of the
data flows on separate  paths and provides an upper bound on  the time it takes
to  get that  message out.  I  really like  this mechanism.  BCube  uses source
based routing,  where  the source node  defines the routing  path traversed.  I
wonder how much  extra  traffic  is  caused  by  the  probing mechanism used to
execute the  source based  routing.  The evaluation coverage  is a  bit limited
considering that a real deployment will have a lot more nodes,  and most likely
the MDC is one of several MDCs, and as such some consideration must be given to
analyzing whether that bottleneck will become the same as for current machines.
What I mean is that we currently consider a machine as a our smallest unit, but
what if  we consider  the MDC  as a  smallest unit,  will  we receive  the same
bottlenecks?

S. Goldberg et al{}"How Secure are Secure Interdomain Routing Protocols?", SIGCOMM 2010.

Quirin Scheitle: Laying out all the different attacks on the BGP protocol, the authors are doing a really good job in showing that BGP security is much more than prefix hijacking and originating false paths. They mention very interesting problems like that of an intercepting attacker blackholing itself, and show the very problems of the fact that business relationships take direct influence in the way packets are routed, which proves to be on of the hardest to deal with problems. They also show the problem that attackers can announce just any path in the control plane and forward the packets any other way in the data plane. They very thoroughly evaluate various BGP security mechanisms and come up with some very surprising results. Definitely one of the best, if not the best work on BGP security coming to my attention so far.

LEISERSON, C E Fat-Trees: Universal Networks for Hardware-Efficient Supercomputing. IEEE Transactions on Computers. Vol. C-34, pp. 892-901. Oct. 1985

Nathan Dautenhahn:

  In this  paper the  authors propose  the development  of a  universal routing
  network called  a fat-tree network.  The primary  problem under consideration
  is how to efficiently route messages  between processors in a super computer.
  The challenges are dissimilar to what I would consider important today.  Much
  of the  challenge is  about making  the physical  fabric of  the interconnect
  infrastructure  as  minimal as  possible.  As  the  author's  suggest several
  previous works have  major limitations due to the  excessive cabling required
  to implement the  design.  I  really  like  that  the  consideration given to
  issues such  as VLSI  analysand theoretical description  and proposal  of the
  universality of Fat-Trees.  One thing I would  have liked to see is some type
  of evaluation  and implementation.  The authors do  cover this  a bit  by the
  theoretical discussion on fat-trees,  but as a systems researcher it would be
  nice to see how it performs.

Amir Houmansadr, Negar Kiyavash, and Nikita Borisov, "RAINBOW: A Robust And Invisible Non-Blind Watermark for Network Flows" NDSS, February 2009.

Kurchi Subhra Hazra:
This paper presents a watermarking strategy called RAINBOW to detect compromised hosts within a network, that are working as relays of traffic from internet attackers. The watermark is generated by introducing delays in packets which are smaller than the delays introduced in previous work, enabling them to distort the traffic little, thus making their watermark invisible to users and attackers of the watermarking scheme. Through analysis and implementation, they show that their strategy raises very little false positives. In addition, they also show that the resource demand of the strategy is very less. As such, a commodity computer could handle the traffic in an enterprise network. They also successfully evaluate and show the invisibility of their watermarking scheme.
Question - How does this scheme deal traffic generated by systems like Skype differently? (Since Skype has relay nodes)

Nathan Dautenhahn:

This paper  proposes RAINBOW,  a  general approach  to identifying  and linking
network flows  within some clean boundary  topology where the goal  is to match
one incoming  flow into  the network and  one outgoing  flow from  the network.
This approach assumes that the detector has  at least two nodes on the path for
the given flow.  The  idea  is  to  watch  flows  going  into  some type of mix
network,  and then monitor flows on the outgoing edges so that one can identify
the source of  the flow.  Two important applications for  this are in detecting
stepping stone attacks within some type of enterprise network and detecting the
end user for a  given  request   in  the  Tor  network.  The  idea  is to use a
watermark where the  entry node will insert  some watermark on the  flow in the
form of delaying some  packets,  and then this delay will be  looked for at the
exit edges.  RAINBOW  uses both watermarking  and timing  analysis correlation,
which enables  it to  improve greatly  on previous  works in  both performance,
visibility of watermarking, and false-positive rates.
Enter labels to add to this page:
Please wait 
Looking for a label? Just start typing.