From: Shivaram V [shivaram.smtp@gmail.com] on behalf of Shivaram Venkataraman [venkata4@illinois.edu] Sent: Thursday, March 04, 2010 12:18 PM To: Gupta, Indranil Subject: 525 review 03/04 Shivaram Venkataraman - 4 March 2010 UsenetDHT: A low-overhead design for Usenet Usenet is a popular file-sharing and communication medium used by millions of users and serves terabytes of data everyday. Traditional Usenet servers replicate the file contents through flood filling and this results in a large amount of data being transferred across them. This paper proposes UsenetDHT in which a set of co-operative servers are organized as a Distributed Hash Table (DHT) and share the storage providing a O(n) reduction in load. The architecture of UsenetDHT consists of frontend servers which use the NNTP protocol to communicate with the frontends and a DHash DHT in which the files are stored. The DHT uses 'Passing Tone' a new maintenance protocol to ensure that enough replicas of the files are present when servers fail. A typical Usenet post first reaches the frontend server which calculates a SHA1 hash to get the file name for this post. The metadata about the file is broadcast to all the other servers and k replicas of the file are inserted into the DHT. Broadcasting the metadata has the benefit that local frontends can handle common queries like listing the new messages etc. When a file needs to be downloaded, the frontend server performs a lookup in the DHT and caches the files locally to avoid multiple downloads for the same file. One of the bigger challenges in the design of UsenetDHT is the algorithm used to maintain enough number of replicas of a file. Passing Tone is designed to minimize the bandwidth usage and minimize the replica movement and creation. This is achieved by only maintaining synchronization data for objects stored locally and by sharing the responsibility of ensuring enough replicas with other servers in the replica set. The local maintenance procedure uses the predecessor and successor lists stored in Chord and synchronizes the object details with each of them. The objects are maintained in a Merkle tree for efficiency and hashes of the entire tree and leaf nodes are present to restrict the number of branches that need to be verified. The Merkle trees are sized appropriately to avoid multiple disk seeks. Additionally documents are expired by removing them from the Merkel synchronization tree and a global maintenance algorithm is used to mark all objects that need not be stored by a particular server. Pros - Efficient new technique to maintain enough replicas without a lot of overhead. Cons - All the UsenetDHT servers need to have the same expiration time and are assumed to be co-operative. Interesting points: - Choosing the file name as SHA-1 provides a simple way to verify the file integrity during lookup. Storage Management and caching in PAST, a large scale persistent peer-to-peer storage utility This paper present PAST, a large scale, decentralized, persistent and scalable storage utility. PAST nodes are organized as an overlay network and use the Pastry routing scheme to ensure that client requests are routed efficiently. PAST supports three major operations to clients: 1. Insert: Given a filename, owner's credentials, number of replicas desired (k), PAST generates a suitable fileId and stores the file at 'k' nodes that are nearest in the Id-space. The fileId is a SHA-1 hash of the file's name, owner's public key and a randomly chosen salt. 2. Lookup: Retrieves a copy of the file from the nearest available replica. 3. Reclaim: Reclaims the storage of k copies of the file but does not guarantee that the file is no longer available. Due to variation in the size distribution of the inserted files and as the capacity of each PAST node may not be similar, there could be storage imbalances in the system. There are two schemes proposed to handle such imbalances: 1. Replica diversion: If one of the k closest nodes to the given fileId does not have enough space to store the file, it looks for another node in its leafset, which has enough space and no other copy of the file. If such a node is found, the file is stored in that node and a pointer to that is maintained in the original node. To handle failures, this pointer is replicated in the k+1th node, which would be the node that would take over when a failure occurs. 2. File diversion: If no suitable node is found for replica diversion, the entire request is reverted and the client is forced to choose a different fileId by using a different salt. This is a costly operation and is performed based on thresholds which can be configured. Simulations show that file diversion is required only for up to 4% of the requests when the leaf set size is 32. Additionally to handle larger number of lookups for selected files, PAST nodes cache any files which are routed through them in unused free space. Pros - High integrity guarantees due to the signatures and hash values being stored. - Simulations show high utilization using storage management schemes proposed. Cons - The diversion schemes are optimized for small files and may not work as well for larger files. - Nodes close in the ID-space (leaf-set) may be across wide area links and the time to detect failure could be high. - The overhead due to additional lookups in replica/file diversion could lead to higher latencies From: Rini Kaushik [rinikaushik@yahoo.com] Sent: Thursday, March 04, 2010 12:02 PM To: Gupta, Indranil Subject: CS525 review 03/04 Rini Kaushik CS 525 Storage management and caching in PAST, a large-scale, persistent peer-to-peer storage utility ---------------------------------------------------------------------------------------------- The authors propose a solution for storage management and caching in PAST, a large-scale, persistent peer-to-peer storage utility. PAST is based on self-organizing Internet based overlay network of storage nodes that cooperatively route file queries, store multiple replicas of files, and cache additional copies of popular files. Cons/Thoughts: 1) PAST ensures that there is no correlation between the value of the nodeId and the node’s geographic location, network connectivity, ownership, or jurisdiction. I have a concern with that approach. It is possible that corporations may want more control over the location of the replicas. There may be jurisdiction or compliance issues that may prevent some sites from being used as a replication destination. A scheme like PAST does replication in a totally transparent manner to the user/application. While a transparent scheme has its own advantages, an option to be able to control the replica destination would be good. 2) The purpose of replica diversion is to balance the remaining free storage space among the nodes in a leaf set. I would argue that simply balancing the remaining free space is not good enough to ensure load balancing. The free space may be balanced. However, that doesn't mean that the load is balanced. PAST is not doing anything to remove hotspots. It is focusing on only the storage capacity aspect of utilization. 3) How does PAST figure out the utilization of all the nodes? What is the monitoring module and what is its frequency? 4) When replica diversion does happen, now two pointer hops will be necessary instead of one. This goes against the claim that the underlying Pastry chooses the "nearest" replica for servicing a request. The first node may indeed be closer to the requester node; however, once the pointer traversal is done to the node actually containing the replica, the distance traversed may be much longer than anticipated. I would have liked to see an evaluation of the performance impact of replica diversion. 5) There seem to be no trust negotiations involved and any node can join the network. The lack of trust and security can be a significant concern for any storage utility as the privacy of file contents (especially if unencrypted) may get compromised. 6) Space reclamation upon deletion is not done which can lead to storage inefficiencies. UsenetDHT: A low-overhead design for Usenet ------------------------------------------- This paper describes the design and implementation of UsenetDHT, a Usenet system that allows a set if cooperating sites to keep a shared distributed copy of Usenet articles. Usenet has high storage needs: users typically post over 1 terabyte of data per day. Simply replicating the data on all the servers, as done in the traditional Usenet, is both inefficient in terms of bandwidth and storage and not scalable. Instead, UsenetDHT stores the contents of the Usenet articles in a DHT while the metadata is distributed and replicated as before. Cons: 1) Usenet-DHT initially stores only two copies of an article for the entire deployment; the extra copy allows for recovery from failure. Even though this simple policy cuts down on storage costs significantly, just two copies may not be enough to guarantee availability or fault tolerance. 2) On one hand, caching data upon first access is beneficial for the subsequent accesses; it will result in much higher first byte access than a local replica for the first access. I am not sure if Usenet strives to provide any SLA guarantees on first access. 3) Assumes a trusted environment which restricts Usenet’s applicability. Pros: 1) UsenetDHT relies on caching to guarantee performance after the first access. As per the paper, users access only 1% of the articles received. Thus, caching will still result in less space overhead than traditional Usenet. 2) The authors consider expiration time which leads to better storage-efficiency. From: vivek112@gmail.com on behalf of Vivek Kale [vivek@illinois.edu] Sent: Thursday, March 04, 2010 12:01 PM To: Gupta, Indranil Subject: 525 review 3/4 CoDNS Core Idea: The Domain Name System is integral to translating machine names to ip addresses. CoDNS is an alternative to the traditional DNS lookup systems. In this paper, the problem of reliability of DNS lookup is investigated. It is shown that the problems are not caused by the reliability of nodes, but rather the local name service. Overall, the case is made for a more reliable solution. The paper proposes that reliability can be acheived by using the peer nodes as helpers when the lookup on a node has failed. The idea is to forward name lookup queries to peer nodes using the ideas of Content Distribution Networks (particularly CoDeeN). They show through thorough experimentation that sources of delay are reduced through a locality aware and proximity aware design of their cooperative DNS lookups. Pros: - This is one of the few papers that has considered standard deviation and performance variation, rather than performance optimization. By doing this, they provide data in a way that one realizes performance predictability rather than pure performance numbers. - The paper uses sound and clear probability theory to establish the design of CoDNS. For example, look at Figure 8 on response time vs number of nodes queried. Here, it shows that if just one peer is queried, the response time can be reduced in half. Cons: - Two overheads are listed in the paper (section 5.3). It is good that these have been brought up in the paper. In the research that they have done, they argue that these overheads are small. Are there certain contexts in which these overheads are not acceptable? It seems they are considering general cases, but not the specific ones. - Was the test done on PlanetLab nodes? Or have they been experimenting on more testbeds? - Section 5.2 (analysis of CoDNS results) seems very brief for the amount of data they have. Moreover, what is the broader impact of it? This is the one part of the paper that needs to be more substantiated. PAST In this paper, the large-scale persistent storage utility known as PAST is understood. It is based on self-organizing internet-based overlay networks. The crucial idea behind it is that the statistical assignement of files to each node is established, and this allows for balancing the storage of files across nodes. They use trace-driven experimetnation to show how query load is balanced for many popular files, and how it allows for graceful degradation at the point when global storage utilization reaches a critical level(they define this as being 95%). A primary design goal is to improve caching and reduce what they call fetch distance( this is essentially the time it takes for client to retrieve a file). Pros: - addresses the issue of storage load balance very thoroughly - The paper makes many different comparisons to other related systems in its related work section. This gives the ability to see where their design fits in and can be used, and what it is not trying to do. Cons: - Aree these experiments only performed using Pastry nodes? - It seems that this paper was written in 2001, they had used just one experimental setup environment. They use Java 2 SDK and they consider a quad processor AlphaServer ES40. But if their results are to truly be impactful and meaningful as a general solution, should they not consider or discuss how their design would be applicable and portable to next-generation platforms? From: gh.hosseinabadi@gmail.com on behalf of Ghazale Hosseinabadi [ghossei2@illinois.edu] Sent: Thursday, March 04, 2010 11:52 AM To: Gupta, Indranil Subject: 525 review 03/04 UsenetDHT: A low-overhead design for Usenet Usenet is a distributed messaging and file sharing service: servers in Usenet flood articles over an overlay network to replicate articles across all servers. In Usenet each server should pay the cost of receiving and storing over 1 Tbyte/day. In this paper, UsenetDHT is introduced, which is a Usenet system in which a set of cooperating sites to keep a shared, distributed copy of Usenet articles. In this method, instead of replicating all articles at all sites, the replication is shared among sites. In this way the cost of storage is also shared among cooperating sites. UsenetDHT uses a distributed hash table (DHT) to provide a single logical storage system for all sites. Data placement, load balancing and replica maintenance are all done by using DHTs. UsenetDHT reduces the load of receiving and storing articles per server by a factor of O(n). Messages exchange for reads and writes in UsenetDHT is composed of the following steps: When client A posts an article to his local NNTP front-end, the front-end stores the article in DHT. After successful writes, the front-end propagates the article’s metadata to other front-ends. Later, when client B checks for new news and asks for the article, B’s front-end retrieves the article from the DHT and returns it. Efficient update of DHTs is achieved by an algorithm called passing tone. In Passing Tone, each server makes maintenance decisions by synchronizing its locally stored objects with its successor and predecessor. In synchronization process, the objects that the server should replicate but doesn’t are determined. These objects are then copied from server’s neighbors. A local maintenance algorithm is also designed to ensure that sufficient replicas exist to each of the servers in the current replica set. Local maintenance guarantees that a server obtains all replicas that it is responsible for but does not have. On the other hand, they designed a global maintenance algorithm that considers replicas that a server is not responsible for but it stores them. Pros: This paper considers the problems related to Usenet. The main issue of Usenet is that it replicates an article at all servers. In this way, under high workloads servers have to pay high costs. The authors proposed a solution to overcome these two main problems. Their idea of designing a system in which storage as well as cost is shared among servers is novel and interesting. Furthermore, using DHT enables efficient way (i.e. with low overhead) of storing the location of articles. Cons: It is not clear how much the overhead of UsenetDHT is. The authors claim that it has low-overhead but how much low that is, is not clear. Using DHT is one way of achieving the goals they had in mind, but how far their method is from optimal is not clear. There is no explanation for why k = 2 is the best choice for Usenet DHT. Maybe larger values of k gives us lower overhead in terms of messages exchanged. CoDNS: Improving DNS Performance and Reliability via Cooperative Lookups This work considers some issues related to DNS s (Domain Name Servers) and tries to modify them in order to obtain more efficiency as well as reliability. One main issue of DNSs is that they show local DNS lookup failures. This might be caused because of reasons like Packet loss, overloading, Cron jobs and maintenance problems. DNS failure make causes problems. Some Examples are as follows: It increases user-perceived latency, and random delays in web access, It also kills HTTP proxies, web services, and busy mail servers. Their proposed solution is called CoDNS (Cooperative DNS). CoDNS works as follows: If local server OK, use local server. If not, (which means a failure happened), peers are asked to do lookup. Through simulations they found how many peers are needed and what is the effect of timeout on the performance of CoDNS. Pros: The designed method CoDNS resolves the problems occurred after a local failure by using peers to help the process of searching. It reduces the average response time, and increases availability of the service. Cons: The parameters that effect number of peers needed are not explained here. One parameter might be the topology of the network. The other is the spatial and temporal relationship among failures. Because there might be spatial correlation among server failures it might not be always a good idea to always choose peers close to the server. From: Kurchi Subhra Hazra [hazra1@illinois.edu] Sent: Thursday, March 04, 2010 11:24 AM To: Gupta, Indranil Subject: 525 review 03/04 Storage Management and caching in the PAST, a large-scale, persistent peer-to-peer storage utility --------------------------------------------------------------------------------------------------------------- Summary ------------ The authors in this paper present PAST, an internet based peer to peer global storage utility composed of a self-organizing overlay network of PAST nodes. These nodes may either act as access points for a user, or optionally contribute storage to past and participate in routing file operation requests. PAST uses Pastry for its overlay construction and request routing. An insert request results in routing of the request with a fileID following Pastry paradigms to the appropriate node with the same nodeID as the fileID. To increase availability of the file, the file is then inserted in k leaf nodes of this node with node IDs numerically closest to the fielD, where k represents the replication factor. In addition, for high global storage utilization, PAST introduces concepts of replica diversion and file diversion. When a node among the k leaf nodes that are to store replica of the present file, cannot accommodate a local copy, it chooses another node from the same leaf set but not among the k leaf nodes to store the file. In addition, it stores a pointer to this node in its own table to cater to lookup requests. However, if the node to which the request had originally routed is not able to accommodate replica copies of a file in its leaf set, PAST uses a different salt value to generate a new fileID and retry storage at a different node. This is known as file diversion. In addition, PAST also utilizes unused space in nodes to cache copies of files in intermediate nodes that participate in routing. Pros ------ -- PAST considers the heterogeneity of the system, for example, nodes may not have the same capacity, file sizes may differ and so on. They try to use replica diversion as a weapon against this. -- PAST does achieve high global storage utilization as the results demonstrate. -- The routing is built on Pastry, which is efficient and usually has a minimal number of nodes to traverse, when considered in terms of number of hops. Cons ------- -- No consideration is given at all to the time taken to insert or fetch a file. Since internet is the communication infrastructure being used, with its varying delays, the fetch or insertion time should be a prime concern when using a system like PAST. -- When inserting, PAST routes the file alongwith the fileID. Similarly, on lookup, the entire file is routed back to the requesting client through the PAST overlay. This appears to me extremely inefficient, increasing delay, and unnecessary bandwidth utilization of the intermediate nodes. -- Geographical distribution of a file increases availability of a file is true. However, a complete random assignment of files may not always work out. Consider a file that will typically be used only within a certain country in Europe. Storing such files in separate continents will uselessly delay lookup requests of such files. -- The system is optimized to store small files. However, small files for the authors are very small in todays world. At 80% utilization, the system rejects files of size 0.5 MB. However, 0.5 MB is less than most general file sized in use such as audio, video, documents and so on. CoDNS: Making DNS Delays via Cooperative Lookups ----------------------------------------------------------------------- Summary ------------- The authors in this paper present CoDNS, a co-operative DNS (Domain Name System) lookup service that uses a locality and proximity aware design to achieve lower latency lookup service when local DNS servers fail. The motivation of this work comes from the authors observation that failures in the lookup service of the Domain Name System (DNS) induce latency into internet access. The authors show that one experiences such failures from any point of the internet, and that a reasonable number of healthy name servers even when one local name server fails, and these healthy servers can be used to mask locally-observed delays. In order to achieve this, CoDNS forwards name lookup service to peer nodes when the local name service is experiencing a problem. The delay between the initial query and a redirected query to a peer node is dynamically adjusted based on the recent performance of the local name-server, so as to reduce the overhead incurred due to unnecessary remote requests. Each CoDNS node maintains 30 peers within a reasonable latency boundary and maintains the list by sending heartbeats to each node. Experimental results show that 18.9% of real traffic uses remote queries and 34.6% of these queries return a valid DNS response faster than the local DNS lookup. Pros-- -------- -- The authors realize the extra overhead that they induce into the system to perform CoDNS lookups. They strive to minimize such overhead. -- DNS came into existence in the 1980s. Since then computer science theory and infrastructure has evolved a great deal. The paper takes an interesting look into how modern infrastructures, such as peer to peer systems, can be used to improve already existing but old systems. Cons-- ---------- -- The statistics shown by the authors do not convince me about how useful their system could be. Firstly, the delay due to DNS lookup failures is neither frequent nor significant. Secondly, in case of failures, the authors are not able to achieve very good performance. A reason for this could be that the system uses peers that are remotely situated on the internet, and have high RTT values. In case a node does not have a close enough peer, their system is going to breakdown. -- The nodes simply maintain a list of healthy peer nodes. However, a node can continuously send requests to nodes whose local servers are misbehaving, hence increasing delay. Thanks, Kurchi Subhra Hazra Graduate Student Department of Computer Science University of Illinois at Urbana-Champaign From: ashameem38@gmail.com on behalf of Shameem [ahmed9@illinois.edu] Sent: Thursday, March 04, 2010 11:03 AM To: Gupta, Indranil Subject: 525 review 03/04 Paper 1: CoDNS: Improving DNS Performance and Reliability via Cooperative Lookups ===================================================================================== DNS is an integral part of web for more than two decades. DNS consists of two components: server-side component and client-side component. Prior researches mainly focused on server side component ignoring the client side infrastructure. However, in the paper titled "CoDNS: Improving DNS Performance and Reliability via Cooperative Lookups", the authors argued that, client-side DNS failure are widespread and frequent which in fact degrades DNS performance and reliability. In this paper, the authors implemented CoDNS, a lightweight, cooperative DNS lookup service that can be independently deployed to augment existing nameservers. CoDNS operates in conjunction with local DNS nameservers. CoDNS can be incrementally deployable without substantial resource consumption. The concept of CoDNS is built on cooperative name lookup scheme. According to this scheme, if local nameserver is OK, local nameserver should be used. Otherwise, other remote CoDNS peers need to be asked for help. Since CoDNS peers reside in an overlay network, the scheme doesn't need to make any change to the server. Through experiment using live traffic, the authors showed that, CoDNS can reduce average DNS lookup latency by 27-82% and increase the service availability by an additional 9. Pros: • The work is based on solid and insightful observation, which is backed-up by comprehensive experiments. • Service availability is improved by an additional 9. • CoDNS is incrementally deployable. • CoDNS limits the number of remote requests which helps to prevent potential attacks. Cons: • It is implicitly assumed that all the peers are trusted • Based on configuration, the neighbors are chosen. This scheme can be improved by incorporating dynamic option. • CoDNS is vulnerable to DoS attack if too many packets are queued up. Paper 2: Storage management and caching in PAST, a large-scale, persistent peer-to-peer storage utility ============================================================================================================= PAST is a p2p storage system which achieves the following goals: global storage, strong persistence, high availability, scalability, and security. PAST is built on top of Pastry, a scalable, self-organizing, fault-tolerant DHT-based p2p routing system. However, in theory, PAST can be deployed on top of any other DHT system. In the paper titled "Storage management and caching in PAST, a large-scale, persistent peer-to-peer storage utility", the authors presented and evaluated the storage management and caching scheme in PAST. The goal of storage management in PAST is to achieve high global storage utilization. Storage management relies on local coordination among nodes with adjacent node ids and incurs only modest performance overhead. As a storage management technique, PAST adopts diversion technique to relocate file or replica. For a replica, another close node is chosen and for a file, another set of nodes are chosen in the id space. Replica diversion is local which allows storage choice between nodes around fileid. On the other hand, file diversion is triggered when an insert with a fileid fails. In PAST, the free space is used to cache files aimed to minimize client access latencies, to maximize query throughput, to balance query load, and to create additional replicas. Cached copies can be discarded at anytime. Cache performance degrades gracefully as the node utilization increases. The authors evaluated the storage management and caching system of PAST through a trace driven experiments in an emulated network environment. Their results showed that, PAST can achieve high global storage utilization while ensuring minimal failure of file insertion when the system storage capacity is nearly full. Cons: • No search capability or directory lookup service are provided in PAST. • How to achieve file delete / file modification if a user wants to do so? • According to the paper, the free space is used as cached space. So, cache performance will surely degrade when storage usage goes up. - Shameem From: liangliang.cao@gmail.com on behalf of Liangliang Cao [cao4@illinois.edu] Sent: Thursday, March 04, 2010 10:57 AM To: Gupta, Indranil Subject: 525 review 03/04 Reviews by Liangliang Cao, cao4@illinois.edu, March 4, 2010 Paper 1: Storage management and caching in PAST, a large-scale, persistent peer-to-peer storage utility, A. Rowstron et al, SOSP 2001 This paper presents and evaluates the storage management and cashing in PAST. In PAST peer-to-peer system, a file can be replicated across multiple nodes for availability. Files in PAST are associated with identifier fileID and possibly decryption key. Although PAST storage system enjoy strong persistence and high availability, it is assumed that the users interact primary with a conventional filesystem, which acts as a local cache for files in PAST. PAST provides following operation: insert, lookup, and reclaim. Pros: 1. PAST permit a group of nodes to jointly store or publish content that would exceed the capacity or bandwidth of individual node. 2. The Reclaim function acts as a weak “delete”, but is more efficient and avoids complex agreement protocols. 3. The designed management scheme achieve high utilization (>98%). Cons: 1. PAST system has to reject few file insert request as the sacrifice of high utilization. Even worse, such rejection is heavily biased towards large files. This limitation might cause a problem in practice. 2. PAST is not as attractive as FarSite since the latter provide traditional file system semantics. I guess the benefits of PAST are that it is less expensive and it is easier to maintain. However, I am still wonder whether the business model of PAST is better than FarSite. Paper 2: UsenetDHT: A Low-Overhead Design for Usenet, Emil Sit et al, NSDI 2008 This paper tries to alleviate the storage and retrieval of full replicate design for Usenet, which cost 1Tbye/day for the popular distributed messaging and file sharing service. The basic idea is to introduce the “partitions” and “levels” to minimize the replica. UsenetDHT provides a DHT scheme which using Passing Tone to operate with only pairwise communications. With the DHT scheme, UsenetDHT replce the local article storage at each NNTP server with shared DHT storage. Pros 1. The experiment in a local gigabit network shows that the system scales linearly as servers are added. 2. Instead of transmitting and storing n copies of an article, UsenetDHT initially stores only two copies: one for entire deployment, and the extra for recovery from failure. 3. The cashing scheme in the front-ends ensures that each article is retrieved at most once for local clients. 4. The success of UsenetDHT validates the power of DHT scheme: even for some systems which originally are not peer-to-peer, we can still employ the DHT to improve the performance or reduce the cost. Cons: 1. UsenetDHT did not consider the failure and recover scenario when both the initial copy and the recovery copy are damaged. In such a case, UsenetDHT might not be able to recover the data. If this problem happens often, the author should consider the possibility of retrieving the data from the shared DHT system. 2. The construction of DHT is more complex than the classical Usenet. I am a little worried that the original merits of Usenet, robustness with blocking, and absence of administration and etc, might not be as easy to obtain as before in the new UsenetDHT system. From: Jayanta Mukherjee [mukherj4@illinois.edu] Sent: Thursday, March 04, 2010 10:27 AM To: Gupta, Indranil Subject: 525 review 03/04 Peer-to-Peer Applications Jayanta Mukherjee NetID: mukherj4 UsenetDHT: A Low-Overhead Design for Usenet: by Emil Sit et al: UsenetDHT uses a distributed hash table (DHT) to store and maintain Usenet articles across participating sites. The authors presented the design and implementation of UsenetDHT, a system that allows a group of cooperating servers to share the network and storage costs of providing Usenet service. UsenetDHT consists of client-facing Usenet NNTP front-ends and a distributed hash table (DHT) that provides shared storage of articles across the wide area. The authors described “Passing Tone”, a new replica maintenance algorithm built on DHash and Chord to minimize the impact of monitoring replication levels on memory and disk resources by operating with only pairwise communication. UsenetDHT provides a way for the mutually trusting organizations to cooperate and share the storage and network load and it aims to: Reduce bandwidth and storage costs in the common case for all participants; Minimize disruption to users by preserving an NNTP interface Preserve the economic model of Usenet, where, clients pay for access to their local NNTP server and can publish content without the need to provide storage resources or be online for the content to be accessible. Pros: 1.UsenetDHT reduces the load of receiving and storing articles by a factor of O(n). 2.The authors proved that from the results it can be said that a DHT-based design may be a viable way to redesign Usenet and globally reduce costs. 3.UsenetDHT creates more copies than Usenet, and can improve performance by caching. 4.The DHT of UsenetDHT must also provide data availability and durability through replica maintenance. 5.As suggested in the paper, UsenetDHT is incrementally deployable and scalable. Also, it provides a cost-effective solution. UsenetDHT aggregates n servers into a DHT that stores the content of Usenet. This approach reduces the costs of storing and receiving a feed to O(1/n). 6. The Passing Tone implementation described in the paper can make writes, deletion and synchronization operations more efficient. 7.The author demonstrated that, an implementation of UsenetDHT can support MIT’s Usenet feed and should scale to the full feed. 8.Distributing metadata to all sites is beneficial, as it guarantees that a site will be able to respond to NNTP commands such as LIST and XOVER without consulting other front-ends and it leaves sites in control over the contents of a group as presented to their local users. 9.Each site will receive article in proportion to the storage that they contribute, rather than the complete copy of the feed. Cons: 1.Passing Tone does not guarantee consistency as the Passing Tone do not consider a consistent set of objects across several servers. 2.Passing Tone can maintain replicas in a system where constant writes produce large numbers of objects and the need to continuously delete expired ones. This may result into congestion and high page-fault rates. No experimental data has been provided to show that, how higher rate of replication affect the performance at a particular node. 3.Each site works like a storage, so, no protocols has been developed or tested to prove the cache-consistency or even data consistency across machines at different sites. Global maintenance algorithm does not deletes replicas from local files even if they are misplaced to recover in case of a failure. But, it may result in recover from a relatively older version without even noticing the fact that, the data has been updated somewhere else. Comments: Too much replication, can take care of failures, but, packets from different site locations will have different timestamps and the data may not be updated in the correct order. Storage management and caching in PAST, a large-scale, persistent peer-to-peer storage utility,by A. Rowstron et al.: The authors evaluated a large-scale peer-to-peer persistent storage utility called PAST. PAST is based on a self-organizing, Internet-based overlay network of storage nodes that cooperatively route file queries, store multiple replicas of files, and cache additional copies of popular files. Most of the concentration of this paper is to evaluate caching and storage capabilities of PAST. The PAST system exports the following set of operations to its clients: fileId = Insert(name, owner-credentials, k, file) stores a file at a user-specified number k of diverse nodes within the PAST network. file = Lookup(fileId) reliably retrieves a copy of the file identified by fileId if it exists in PAST and if one of the k nodes that store the file is reachable via the Internet. Reclaim(fileId, owner-credentials) reclaims the storage occupied by the k copies of the file identified by fileId. Pros: 1.PAST minimizes fetch distance, that it balances the query load for popular files, 2.A storage-utility like PAST obviates the need for physical transport of storage media to protect backup and archival data by exploiting the multitude and diversity (in geography, ownership, administration, jurisdiction, etc.) of nodes in the Internet to achieve strong persistence and high availability. 3.PAST permits a group of nodes to jointly store or publish content that would exceed the capacity or bandwidth of any individual node. 4.PAST obviates the need for physical transport of storage media to protect backup and archival data; likewise, it obviates the need for explicit mirroring to ensure high availability and throughput for shared data. 5.PAST uses the routing algorithm Pastry to ensures that client requests are reliably routed to the appropriate nodes. Pastry is a peer-to-peer routing substrate that is efficient, scalable, fault resilient and self-organizing. 6.PAST adopts a better security model with the public-key crypto-system and cryptographic hash function. Cons: 1.As described in the work, PAST displays graceful degradation of performance as the global storage utilization increases beyond 95%. 2.The routing algorithm Pastry is deterministic and thus vulnerable to malicious or failed nodes along the route that accept messages but do not correctly forward them. Comments: PAST seems to be a better system than UsenetDHT with better global caching scheme and with better security features. -With regards, Jayanta Mukherjee Doctoral Researcher Department of Computer Science University of Illinois, Urbana-Champaign Urbana-61801, IL, USA Mobile:+1-217-778-6650 From: Nathan Dautenhahn [kainospur@gmail.com] Sent: Thursday, March 04, 2010 8:08 AM To: Gupta, Indranil Subject: 525 review 03/04 Paper Reviews: March 4, 2010 Nathan Dautenhahn 1 UsenetDHT: A low-overhead design for Usenet Authors: Emil Sit, Robert Morris, and M. Frans Kaashoek 1.1 Summary and Overview of Contributions The paper introduces UsenetDHT, which attempts to store Usenet articles by using a DHT to reduce the network and storage costs of a typical Usenet server. The problem with Usenet is that it replicates all articles on all the servers, which is a ton of data. This makes it hard for smaller sites to create Usenet servers. Thus, UsenetDHT is developed in order to distribute the storage and network costs by only replicating an article on two nodes in a given ... They also introduce Passing Tone maintenance algorithm to handle the data retention components of the Usenet system. Some things that I like about the paper: • UsenetDHT does not require the alteration of client nodes in the system, which makes it easy for end users to opt into the new system. • Reduces the storage costs by O(1/n), which can become extremely huge as n increases. • Article caching is really cool because it helps to reduce bandwidth, and if this is downloaded once it is worth the cost of storage to keep it at a local zone. The costs of the storage is an interesting one, but I think the cost of network bandwidth between the sites would be higher. • This is an extremely well written report. The introduction flows smoothly, and provides excellent motivation for the problem. • The real world deployability of the design is amazing! I really like novel research that results in the development of a system that really works. 1.2 Questions, Concerns, and Comments My primary concerns are as follows: • As the number of sites grows, how do the participating cites manage the overall settings? • What type of mechanisms/policies (legal?) must be in place for participating sites to find security in implementing this system? Can one site trust the rest to uphold their load? 2 Storage management and caching in PAST, a large-scale, per- sistent peer-to-peer utility Authors: Antony Rowstron and Peter Druschel 2.1 Summary and Overview This paper introduces PAST, a peer-to-peer persistent storage utility. PAST is built on top of the Pastry routing scheme to handle the routing and distribution of the data. PAST uses an Overlay networking scheme. In order to provide security PAST requires the use of smart cards to enable authentication of nodes. This is important because PAST needs to enforce quota limitations on the end users and without it would have not other way to do this. Other key elements of PAST include its load balancing and caching systems. The intent of PAST is to be a P2P archival storage system. 2.2 Questions, Comments, and Concerns I have several concerns with this paper, and a few are as follows: - The motivation in this paper was somewhat slim. The begin by stating that P2P systems are important, and then going straight to PAST. They don’t give any motivation for me wanting to use this P2P storage system over anything else, including non-P2P solutions. - The paper claims that the storage system is primarily for archival storage, which to me somewhat defeats the purpose of a P2P system. I think at its core a P2P system is for sharing and wide distribution. If they gave an application domain that might make sense and motivate it, but in the end I think this type of archival storage system would want a different mechanism than a P2P system. - This limitation also exposes itself in the immutable nature of the files. Whenever an update to a file occurs it must be recreated and re-distributed. How do they handle overwrites, so that users can save on their quota but update the new information into the storage system? -Security: who is going to trust a bunch of end users? My data will be stored on another person’s system that I have no guarantees on its security. Who is liable for data lost in this system, or exposed data. To secure against these issues fully encryption would need to be used. How does this change the costs of storage and network bandwidth in PAST? 3 Common Themes These two papers both attempt to reduce the cost of a service by distributing the load of storage across a P2P sharing system. UsenetDHT provides this for open data that many people will see, and as such don’t have much of the limitations that PAST have in that they are focused on providing an archival storage system. PAST is limited compared to UsenetDHT due to the fact that it does not allow for querying or advanced file system features.From: gildong2@gmail.com on behalf of Hyun Duk Kim [hkim277@illinois.edu] Sent: Thursday, March 04, 2010 2:07 AM To: Gupta, Indranil Subject: 525 review 03/04 525 review 03/04 Hyun Duk Kim (hkim277) * CoDNS: Improving DNS Performance and Reliability via Cooperative Lookups, KyoungSoo Park et al, OSDI 2004 This paper introduces a reliable DNS name server lookup system, Cooperative domain name server (CoDNS). There are various failures in DNS servers which induces delays. Those failures are widespread, uncorrelated, and can be a significant source of DNS lookup delays. To solve this delay problem, they suggested CoDNS which hides failures by neighbor healthy local servers. This method is reliable and consistent than other methods. While usual papers focus on problem solving with simple problem definition, this paper explains problem finding steps in detail. This paper explains how they found DNS server delay in PlanetLab system, and explored more for finding better explanation of the problem. They execute various analyses such as how often failure occurs, how related and how it can affect performance. This helps readers to understand problem clearly. However, compared to the problem exploration, it does not show much exploration in solution, CoDNS, itself. The reason may be that the basic idea of the solution is simple. Dynamic threshold adaptation is a very good idea for better performance. CoDNS changes delay threshold which decides if it uses neighbor or not based on the delay history. Although it may not work well at the beginning when they do not have history data, the performance of the system can be improved as time goes by. With the dynamic adaptation, CoDNS can work well with different servers in various locations, and it will automatically turn off CoDNS specialized function when servers work well. If there is more fundamental problem exploration of why DNS server fails, it would be great. According to the problem explorations, there are many failures in DNS, and they make much delay. In a common sense, server should not be failed easily. Instead of hiding the failure by other servers, it would be also good to find out the reason of failures. If we can find fundamental reasons, it even could improve the entire performance. * Storage management and caching in PAST, a large-scale, persistent peer-to-peer storage utility, A. Rowstron et al, SOSP 2001 This paper introduces a new peer-to-peer storage management system PAST. PAST is Internet-based a peer-to-peer global storage system, which aims to provide strong persistence, high availability, scalability and security. PAST makes replicas of each inserted file and maximizes utilization by distributing files uniformly. It also considers popularity of files, so maximizes the utilization with caching. This paper presents a new P2P based file storage system. On the contrary to other P2P systems, this system also considers security. It uses encryption and manages file authorities with certificates. This system seems like fitting to a system for frequent lookup and less insertion. Most of overhead is on inserting and replicating files. Therefore, if there are a lot of changes in file list, it will increase overhead significantly. Many ideas such as replication and caching are also for the lookup. We can quite sure that this system will be more beneficial for 'more lookup' usage. Segmenting large files can improve the system. This paper briefly mentioned the possibility of file segmentation, but did not explored seriously. I think the advantage of file segmentation can go over possible disadvantages. Main overhead of the proposed algorithm is handling replicas. If we segment large files to smaller fragments, we can read different segments from several replicas when lookup. Also, when we make replicas, we can accelerate replication. For example, we can download different parts from replica 1 and 2 to make replica 3. This paper does not show complete experiments. Authors mainly compared the proposed system with the system without target feature to evaluate. Or most of later evaluation part is about sensitivity of parameter values. As the related work section mentions, there are many similar previous work. If PAST was compares with other systems on various aspects, it could be more interesting. The paper does not explain 'delete' step. It just says that PAST uses reclaim steps instead of deletion. Can we just assume it delete files when they are reclaimed? Although PAST puts emphasis on utilization, using many replicas does not look good for utilization. When we make k replicas, the usable storage becomes 1/k. Also, there are a lot of constraints about file size. Sometimes, it does not take large file, and does not allow join small storage node. Many replication will increase these kinds of restrictions. ------ Best Regards, Hyun Duk Kim Ph.D. Candidate Computer Science University of Illinois at Urbana-Champaign http://gildong2.com From: Wucherl Yoo [arod99@gmail.com] Sent: Thursday, March 04, 2010 1:22 AM To: Gupta, Indranil Subject: 525 review 3/4 P2P Apps, Wucherl Yoo (wyoo5) Storage management and caching in PAST, a large-scale, persistent peer-to-peer storage utility, A. Rowstron et al, SOSP 2001 Summary: PAST is a large-scale persistent P2P storage utility based on Pastry overlay network. The node join and leave are managed by Pastry layer. Each node and file is assigned with uniformly distributed identifier. The files are replicated to k nodes that are numerically closest to the fileId. PAST supports three file operations: insert, lookup, and reclaim. The reclaim operation does not guarantee strong semantics to avoid agreement among the modes. File insertion is immutable associated with a file certificate (hashcode of file name, client’s public key, and a random salt) after receiving acknowledgement from k nodes to store the replica. A chosen node (among k closest nodes to the fileId) may not accommodate the file due to insufficient space. In this case, the node diverts the replica to its local leaf set and maintains a pointer to the diverted node. If the replica diversion is unsuccessful, the client node can do file diversion: reinserting the file with a different salt value. To improve performance, PAST nodes cache files that seem popular among local clusters of clients by using unused portion of advertised disk space. This can amortize the topological dispersion of k copies of the files. Pros: 1. Interesting load balancing effort for P2P storage (especially local load balancing among a leaf set including replica diversion and file diversion) with replicas of files given the statistical variation in the assignment of nodeIds and fields, the variance of the size distribution of inserted files, and the variance of the storage capacity of the nodes 2. Interesting caching effort using unused disk space; GreedyDual-Size policy and LRU work as similarly efficient. Cons: 1. Heterogeneous storage capacity of nodes increase latency of inserting file due to rejection of the insert requests from nodes with small capacity 2. May not handle the overhead gracefully with churn 3. Fully cooperative model with lack of discussion about incentives except storage quota; inserting large number of small size file increases relatively high overhead provided storage quota UsenetDHT: A Low-Overhead Design for Usenet, Emil Sit et al, NSDI 2008 Summary: UsenetDHT decreases storing and receiving feeds by using DHT to partition the burden of storing articles. Passing Tone is a replica maintenance algorithm. It can reduce the overhead of monitoring replication level by adapting by requiring communication only to successors and predecessors. Pros: 1. UsenetDHT is more scalable by reducing cost of storing and receiving feeds and incrementally deployable. It also provides more data availability and failure resilience. 2. Passing Tone provides low overhead replica maintenance mechanism Cons: 1. Stabilization of Passing Tone may not be scalable 2. Increased lookup latency due to the use of DHT (maybe tradeoff between latency and scalability) -Wucherl From: Ashish Vulimiri [vulimir1@illinois.edu] Sent: Thursday, March 04, 2010 12:14 AM To: Gupta, Indranil Subject: 525 review 03/04 Storage management and caching in PAST, a large-scale, persistent peer-to-peer storage utility, A. Rowstron et al, SOSP 2001 This paper present PAST, a storage mechanism built on top of the Pastry DHT that uses Pastry to identify and locate file objects. The additional features it adds on to Pastry, specific to the storage management problem, are replica and file diversion (designed to handle cases when the nodes that should actually store the file according to the DHT mechanism run low on storage capacity), and a caching mechanism that uses unused space on the nodes to store extra copies of popular files. + Uses Pastry for its underlying replica location mechanism, which has the advantage that it is generally very tolerant of network failures (e.g. unlike Chord, Pastry has a rapid failover when the network partitions). - Four differences from standard filesystem semantics i) Files are immutable ii) No guaranteed delete operation iii) Cannot list or search for files. PAST doesn't really attempt to provide anonymity (and in fact replicas can, in general, be stored at any arbitrary node), so the lack of searchability has to be classified as a bug, not a feature. iv) Flat structure (no directory-like hierarchy) CoDNS: Improving DNS Performance and Reliability via Cooperative Lookups, KyoungSoo Park et al, OSDI 2004 [ppt] In this paper, the authors monitor DNS failures at several sites located on Planetlab, and observe that i) failure rates at individual sites can be surprisingly high, but ii) failures at different sites are generally uncorrelated. Based on this observation, they build a cooperative DNS service (CoDNS), in which nodes automatically contact one of several remote DNS servers if the local one goes down. They show through an experimental evaluation that a 50% improvement in response time can be obtained with just one extra DNS peer, which works out to a 10-20% overhead in terms of number of DNS requests, and a 0.3% overhead in absolute terms (i.e., as a percentage of total traffic -- note that DNS traffic should be a fairly small component of the total traffic, so a small percentage increase in this value should be acceptable). + Interesting analysis of DNS failures. - CoDNS magnifies the trust problem with regular DNS -- the attack surface is significantly broadened. Of course, regular DNS by itself is also fairly insecure. It should be noted the DNSSEC security extensions that have been proposed to the (ordinary) DNS standard should also solve the attack problems in CoDNS. - They don't really talk about how the nodes initialize the list of peers. In the Planetlab context, this is fairly simple since they operate in a closed network, but the problem is much more significant on the larger Internet. From: Fatemeh Saremi [samaneh.saremi@gmail.com] Sent: Wednesday, March 03, 2010 11:49 PM To: Gupta, Indranil Subject: 525 review 03/04 Paper 1: PAST PAST is an Internet-based, p2p storage utility which provides high degrees of availability, scalability, persistence and security. The PAST nodes form a self-organizing overlay network. It is built on top of Pastry project which ensures that clients requests are routed to the appropriate nodes respecting locality as well. The idea is that multiple replicas of files are stored in a diversity of geographical locations, ownership, administration, network connectivity, jurisdiction, etc. To balance the number of files stored on each node, identifiers assigned to nodes and files are distributed uniformly. However, to capture non-uniformity in storage node capacity, file size, and file popularity, more explicit storage load balancing are employed, e.g., additional copies of popular files are cached to minimize fetch distance and balance the query load. The experimental results show that the storage management scheme of PAST achieves global storage utilization of 98% and the rate of failed file insertions remains below 5% at 95% storage utilization and that the insertion fails are mostly related to large files. The results indicate that the caching policy is also effective and reduces fetch distance and network traffic. The feature that PAST distributes multiple replicas of files in a diversity of locations, besides load balancing results in high availability. Privacy of users is preserved (anonymous distribution of files). Thats a good point that unlike some other approaches there is no correlation between the nodes identifier and the geographical location of it (due to secure hashing using a random part). Although mitigated, concurrent corruption of nodes could cause routing failures and therefore denial of service. The policy for accepting a replica is based on the ratio of the size of the file to the remaining free storage space of the node, while it would be more reasonable to have it based on the absolute free space in the node. The number of replicas is the same for all files while correlating the number with popularity of files might be more effective (rather than capturing the effect only by caching of popular files, since it is not always guaranteed). On one hand, it is appreciated that users store/share more number of files. On the other hand, they should (somehow) pay for the storage they use. I wonder how the story is handled, whether some sort of a strategy-proof mechanism like VCG is required or not (actually if thats the way it was mentioned above). Paper 2: CoDNS The paper proposes CoDNS as an alternative lookup system which improves the total name lookup time as well as improving the mean latency with minimal extra overhead. Therefore it results in high availability and less variability. Based on extensive simulations, they report with certainty that there are DNS lookup failures hidden by the internal redundancy in DNS deployments which highly affect the total lookup time. Therefore, they propose to forward name lookup queries to peer nodes when the local name service is experiencing a problem. Through simulation study, they determine when to send remote queries and how many peers to involve in order to obtain an efficient method. Availability and responsiveness have improved. CoDNS provides resilience against temporary problems with the legacy DNS, but is not intended as a replacement. Instead of choosing a remote peer with no goodness criteria, it might be better to proactively and periodically finding some peer(s) based on some specific features, e.g., the one with minimal load, less latency, etc. The peers are implicitly trusted. All justifications and results are solely based on observations. From: ntkach2@illinois.edu Sent: Wednesday, March 03, 2010 8:39 PM To: Gupta, Indranil Subject: 525 review 03/04 Nadia Tkach –ntkach2 CS 525 – paper review 7 P2P Apps Paper 1: Storage Management and Caching in PAST, a large-scale, persistent peer-to-peer storage utility Paper describes a new approach to large distributed data storage on peer-to-peer networks. It works as a self-organizing overlay network of storage nodes which support file querying and routing, file replication for high availability and caching of the most popular files in order to minimize the retrieval delay. PAST also provides strong persistence, scalability, approximate load balancing and security. It is based on Pastry p2p routing and location scheme, and offers logarithmic traversal time under normal operation. PAST works in a way that it assigns fileID and nodeID to each file and node in the system and stores files in those nodes that most closely match their fileID. Since the ID numbers are assigned uniformly they provide some load balancing and high availability in case of a failure. Pros: • Provides scalability and some load balancing • File replication and caching for high availability • Logarithmic traversal time • Can specify the k number of file replicas to be created in the system Cons: • PAST still requires additional load balancing mechanisms as global storage utilization increases • PAST is designed as a storage and distribution system only, not general-purpose filesystem • The overhead of nodes leaving and joining has to be considered for any specific system implementation • Participating nodes require a special software Paper 2: UsenetDHT: A low-overhead design for Usenet The authors introduce new system architecture for managing and storing Usenet data distributed across multiple servers with reduced bandwidth and operational cost. It consists of two components: the Distributed Hash Tables (DHTs) with NNTP front-end, and Passing Tone algorithm for efficient management of DHTs. UsenetDHT collect information about space availability from multiple servers and creates a DHT which acts as a virtual shared disk. NNTP front-end handles all news article user requests, collects data and metadata and creates a mapping from newsgroup to the actual articles data. Passing Tone algorithm is used for maintenance of DHTs and essentially is built on Chord and DHash. When a new article is uploaded, the system initially creates and stores only 2 replicas. Passing Tone works in a way that it ensures that there are k replicas existing at all times by partitioning servers into sets and regularly checking the availability of all replicas. Pros: • Provides scalability, load balancing, durability, and availability • Costs of storing and receiving reduced to O(1/n) Cons: • The time to propagate changes to the newsgroup can create a delay that some users might not be willing to tolerate • Assumption that data is stored on static servers which would not leave or re-join the system at random times (although server failures and re-boots are considered and handled with Passing Tone algorithm) From: Shehla Saleem [shehla.saleem@gmail.com] Sent: Wednesday, March 03, 2010 3:48 PM To: Gupta, Indranil Subject: 525 review 03/04 Storage management and caching in PAST, a large-scale, persistent peer-to-peer storage utility This paper presents peer-to-peer storage tool PAST, where nodes cooperate with each other to store multiple copies of files. It is specifically aimed at providing load balancing and improving lookup latency. Load balancing is provided by understanding the following intuition. The previous p2p solutions like chord try to achieve load balancing by making sure that all the nodes will be assigned almost the same number of files. This approach however becomes invalid in the case where files may be of different sizes. Also, the storage capabilities of nodes must also be taken into account when assigning them files to store. PAST on the other hand provides storage based load balancing and provides high availability by maintaining replicas of files. It uses Pastry as its underlying routing algorithm. In PAST, nodes and files are assigned unique Ids and files are stored at k nodes whose Ids are closest to the fileId. PAST presents two optimizations to improve upon the scenario where a node’s storage capacity is being pushed to its limits. File diversion and replica diversion. So if a node is unable to store a file, it diverts the file to another node in its leaf set. They also give some policies to avoid unnecessary replica diversion. Moreover, when a file cannot be saved at nodes that are close to the fileId, the sending node uses file diversion to generate a new fileId. Both these mechanisms help improve the load balancing. Another simple enhancement comes from the use of caching. Nodes with sufficient left-over (unused) storage cache popular files that are routed through them. This helps decrease the latency of accessing the files and improves availability at the same time and the benefits are very pronounced if there is some spatial locality in terms of a file’s demand. The cached files can be written over if the node is assigned a new file that it is responsible for storing. The experiments are quite thorough and they tune different parameters to provide comprehensive results. The results show the efficiency of the algorithm. Yet another attractive feature is that with nodes being assigned their own keys, the system provides a certain level of security against malicious nodes. Overall, it does seem to achieve the goals of high global storage utilization and graceful degradation in performance when nearing capacity. Some of the issues however still need to be looked over. PAST is closer to an archiving solution rather than a general purpose filesystem. PAST does not support searching, directory lookups or key distribution. It also does not provide for modifying files once they have been stored and file owners can only reclaim the files and not actually delete them. Can some simple kind of authenticated updates from the creater/owner of the file be used to achieve this? Also, since the communication is done only with immediate neighbors, the file has to travel multiple hops to reach the node where it can be stored. Whereas this provides opportunities for intermediate nodes to cache the file, it might also generate unnecessary traffic for large files. Can the files be transferred directly? Finally, they mention that if a node has a large storage capacity, it can join the system as multiple nodes. In such a case, how can we avoid the possibility that the virtual multiple nodes all end up having such nodeIds that all the replicas of some file are stored in the same physical storage? This is inefficient as well as more prone to failure in case the single node fails, all replicas of the file will be lost simultaneously. CoDNS: Improving DNS Performance and Reliability via Cooperative Lookups CoDNS incorporates cooperation among peer nodes to provide a faster and more reliable DNS lookup service and does this at minimal cost in terms of resources. The motivation behind this work lies in the claim that most of the work done for DNS lookup services focuses on trying to identify room for improvement on the server side. This paper however, takes a look at the problem from the client side and comes up with a solution also at the same side. Their proposal is backed by careful studies of lookup failure behaviors and their statistics show that most of the failures occur within the local network. The clients usually experience failures because of the inherent use of UDP by the nameservers, and so any packet losses result in long latencies seen by the clients. Another possibility might be that the nameserver was overloaded temporarily. Their solution to this problem is to redirect queries to healthy remote peer nodes when the local nameserver seems to not function properly. This takes care of the latency problem right away. They use certain thresholds to let a client decide when to forward queries locally and when to try resolving them remotely. The lookup latency improvement results are impressive giving a reduction ranging from 27% to 82% and also the DNS availability is improved from 99% to 99.9%. They also exploit request locality which contributes to the total improvement. Any lookup-latency-sensitive applications can highly benefit from this solution. In addition to that, one of the main strengths lies in the fact that this solution can be deployed incrementally and therefore should face less resistance from existing infrastructure. On the flip side, first of all, there has been no talk of how to develop a trust relationship between peers. Blindly trusting all the peers can cause problems in case of Byzantine failures and so the solution seems vulnerable to potential security threats. Moreover, requests to the remote peers are sent out aggressively until a response is received. This might exacerbate the situation if the problem at hand is that of an overloaded service and packet losses.