Slide 1Slide 2Slide 3Slide 4Slide 5Slide 6Slide 7Slide 8Slide 9Slide 10Slide 11Slide 12Slide 13Slide 14Slide 15Slide 16Slide 17Slide 18Slide 19Slide 20Slide 21Slide 22Slide 23Slide 24Slide 25Slide 26Slide 27Slide 28Slide 29Slide 30Slide 31Slide 32Slide 33Slide 34Slide 35Slide 36Slide 37Slide 38Slide 39Slide 40Slide 41Slide 42Slide 43Slide 44CoDNS: Improving DNS Performance and Reliability via Cooperative LookupsKyoungSoo Park, Vivek Pai, Larry Peterson and Zhe WangPresented by Raoul Rivas and Chihung LuDNS Overviewcairo.cs.uiuc.edudns.uiuc.eduwww.telmex.com.mxDNS Overviewcairo.cs.uiuc.edudns.uiuc.edua.root-servers.netwww.telmex.com.mxwww.telmex.com.mxNS a.ns.mxDNS Overviewcairo.cs.uiuc.edudns.uiuc.edua.root-servers.neta.ns.mxwww.telmex.com.mxwww.telmex.com.mxm.mx-ns.mxDNS Overviewcairo.cs.uiuc.edudns.uiuc.edua.root-servers.neta.ns.mxm.mx-ns.mxns6.telmex.comwww.telmex.com.mxwww.telmex.com.mxwww.telmex.com.mxDNS Overviewcairo.cs.uiuc.edudns.uiuc.edua.root-servers.neta.ns.mxm.mx-ns.mxns6.telmex.comA 200.57.141.200www.telmex.com.mxwww.telmex.com.mxMotivation and Significance●DNS failures can be divided in client-side or server-side●Client Side failures are frequent and degrade performance and reliability of DNS●Most DNS lookup response times are between 10 ms and 1000 ms but they can be as large as 100,000 ms●DNS lookups contribute more than 1 second in 20% of the retrievals of web objects [CE Wills et al.]Motivation and Significance●Most DNS failures are transient●A small percentage of failure cases dominates the total response time50% of time spent on lookups >1000 msOrigin of Client-Side Failures●Packet Loss●DNS servers can be a few hops far away●Overloading of the nameserver●High bursty traffic causes UDP buffer to fill●Maintenance Mistakes●Heavy non-related processes running on the DNS serverDesign Constraints●Incrementally deployable●Minimal Resource requirements●Failures on DNS are uncorrelated●Number of “healthy” nameservers is always high●DNS requests and responses are small●Focus on Low latency rather than high bandwidthLookups in CoDNS●Contact the local nameserver first●Wait for a dynamically established timeout (200ms initially)●Pick n-1 peers from a list of CoDNS peers ●Issue n-1 simultaneous lookups ●Use the first response either from a peer or DNSpeerDNSpeerpeerDNSwww.yahoo.compeerLookups in CoDNS●Contact the local nameserver first●Wait for a dynamically established timeout (200ms initially)●Pick n-1 peers from a list of CoDNS peers ●Issue n-1 simultaneous lookups ●Use the first response either from a peer or DNSpeerDNSpeerpeerDNSwww.yahoo.compeerwww.yahoo.comLookups in CoDNS●Contact the local nameserver first●Wait for a dynamically established timeout (200ms initially)●Pick n-1 peers from a list of CoDNS peers ●Issue n-1 simultaneous lookups ●Use the first response either from a peer or DNSpeerDNSpeerpeerDNS200.1.28.54peerwww.yahoo.comwww.yahoo.comArchitecture and Design●CoDNS is implemented as a daemon in the client●A non-blocking Master process receives lookup queries from the Application or other Peers●The Master process forwards the query to a blocking slave processAppCoDNSMasterprocessCoDNSSlaveprocessQuery to DNSCoDNSSlaveprocessQueryFrom other peersClientQuery to other peersList of PeersArchitecture and Design●The Master process is in charge of the following:●Record the timeout of the query●Send and Receive remote queries●Select a peer based on the Highest Random Weight Hash–Consistent Hashing, low overhead, minimal impact if a server leaves or joins, load balanced [Thaler et al]●Monitor peers health by sending a periodic heartbeatArchitecture and Design●Peer queries are sent only after trying to obtain a fast response form the DNS●Lookups are generally fast●Avoid unnecessary traffic●Avoid overloading marginal DNS servers●CoDNS works as an insurance in which if the DNS is too slow the peers try to resolve the query before the local DNS●Minimal overhead if the system is function properlyBootstrapping●CoDNS must resolve the names of the peers before it can start working.●CoDNS resolves the name of the first peer by using local DNS and then it start using that peer to resolve other namesResults●Improved Average Response Time●Minimal Overhead●Even using only 1 extra lookup the average response time reduces by more than half●No overhead if the lookup is local (98% of the requests)ResultsResultsMinute granularity Average Response Time for one day on planetlab1.cs.cornell.eduResults●Improved Availability●99.9% availability on 70% of the node (as opposed to 99% availability on 60% using DNS)●Minimal adverse effect on CDN protocolsCriticism●If a node gets compromised it can respond with a different address●CoDNS relies on DNS to bootstrap●SEDNS in Rearchitecting DNS [Pfeifer et. al]●Requires the deployment of a P2P component●Some other approaches obtain similar or better results using redundant lookups●CoDoNS [Ramasubramanian et. Al], SEDNSDiscussion●If CoDNS was widely deployed. Do you think that in practice the system is prone to attacks from malicious peers?●Is it preferable to use redundancy strategies over a P2P component?●Is it feasible to overcome the limitation that CoDNS requires DNS to bootstrap?●Other studies propose to replace DNS with a P2P (maybe Pastry). Would this be a better approach?Storage management and caching in PAST, a large-scale, persistent peer-to-peer storage utilityAnthony Rowston, Peter DruschelPresented by Raoul Rivas and Chihung LuPastry Overview●Peer to peer routing substrate●Efficiency, Scalability, Fault Resiliency, Self Organization●Pastry can route to the numerically closest node for a given ID in O(log n)●Pastry keeps a routing table a leaf set and a neighborhood setPAST Goals●PAST is a P2P storage system aimed to achieve:●Global Storage●Strong Persistence●High Availability●Scalability●Security●Note: PAST is deployed on top of Pastry but in theory it can be deployed on top of any otherPAST Operations●fileID=Insert(name, credentials, k, file)●Stores a file in k different locations●Returns an unique identifier, making files immutable●file=Lookup(fileID)●Retrieves a file from a close node●Reclaim(fileID, credentials)●Delete but with weaker semantics●NO guarantee that it exists but it might be there●Avoid using agreement protocolsPAST Insert●Compute fileID
View Full Document
Unlocking...