Todays Lecture P2P and DNS Required readings Peer-to-Peer Systems Do incentives build robustness in BitTorrent? Optional readings DNSCaching, Coral CDN, Semantic-Free Referencing 1 2 Overview DNS P2P Lookup Overview Centralized/Flooded Lookups Bittorrent 3 Obvious Solutions (1) Why not centralize DNS? Single point of failure Traffic volume Distant centralized database Single point of update Doesnt scale! 4 Obvious Solutions (2) Why not use /etc/hosts? Original Name to Address Mapping Flat namespace /etc/hosts SRI kept main copy Downloaded regularly Count of hosts was increasing: machine per domain machine per user Many more downloads Many more updates 5 Domain Name System Goals Basically building a wide area distributed database Scalability Decentralized maintenance Robustness Global scope Names mean the same thing everywhere Dont need Atomicity Strong consistency CAP theorem hard to get consistency, availability and partition tolerance 6 DNS Records RR format: (class, name, value, type, ttl) DB contains tuples called resource records (RRs) Classes = Internet (IN), Chaosnet (CH), etc. Each class defines value associated with type FOR IN class: Type=A name is hostname value is IP address Type=NS name is domain (e.g. foo.com) value is name of authoritative name server for this domain Type=CNAME name is an alias name for some canonical (the real) name value is canonical name Type=MX value is hostname of mailserver associated with name 7 DNS Design: Hierarchy Definitions root edunet org ukcom gwuucbcmubu mit cs ece cmcl Each node in hierarchy stores a list of names that end with same suffix Suffix = path up tree E.g., given this tree, where would following be stored: Fred.com Fred.edu Fred.cmu.edu Fred.cmcl.cs.cmu.edu Fred.cs.mit.edu 8 DNS Design: Zone Definitions root edunet org ukcom ca gwuucbcmubu mit cs ece cmcl Single node Subtree Complete Tree Zone = contiguous section of name space E.g., Complete tree, single node or subtree A zone has an associated set of name servers 9 DNS Design: Cont. Zones are created by convincing owner node to create/delegate a subzone Records within zone stored multiple redundant name servers Primary/master name server updated manually Secondary/redundant servers updated by zone transfer of name space Zone transfer is a bulk transfer of the configuration of a DNS server uses TCP to ensure reliability Example: CS.CMU.EDU created by CMU.EDU administrators 10 Servers/Resolvers Each host has a resolver Typically a library that applications can link to Local name servers hand-configured (e.g. /etc/resolv.conf) Name servers Either responsible for some zone or Local servers Do lookup of distant host names for local hosts Typically answer queries about local zone 11 DNS: Root Name Servers Responsible for root zone Approx. dozen root name servers worldwide Currently {a-m}.root- servers.net Local name servers contact root servers when they cannot resolve a name Configured with well- known root servers Physical Root Name Servers Several root servers have multiple physical servers Packets routed to nearest server by Anycast protocol 346 servers total 12 13 DNS Message Format Identification No. of Questions No. of Authority RRs Questions (variable number of answers) Answers (variable number of resource records) Authority (variable number of resource records) Additional Info (variable number of resource records) Flags No. of Answer RRs No. of Additional RRs Name, type fields for a query RRs in response to query Records for authoritative servers Additional helpful info that may be used 12 bytes 14 DNS Header Fields Identification Used to match up request/response Flags 1-bit to mark query or response 1-bit to mark authoritative or not 1-bit to request recursive resolution 1-bit to indicate support for recursive resolution 15 Typical Resolution Client Local DNS server root & edu DNS server ns1.cmu.edu DNS serverNS ns1.cmu.eduNS ns1.cs.cmu.edu A www=IPaddr ns1.cs.cmu.edu DNS server 16 Typical Resolution Steps for resolvingApplication calls gethostbyname() (RESOLVER) Resolver contacts local name server (S 1 ) S 1 queries root server (S 2 ) for (www.cmu.edu)www.cmu.edu S 2 returns NS record for cmu.edu (S 3 ) What about A record for S 3 ? This is what the additional information section is for (PREFETCHING) S 1 queries S 3 forS 3 returns A record forCan return multiple A records what does this mean? 17 Lookup Methods Recursive query: Server goes out and searches for more info (recursive) Only returns final answer or not found Iterative query: Server responds with as much as it knows (iterative) I dont know this name, but ask this server Workload impact on choice? Local server typically does recursive Root/distant server does iterative requesting host surf.eurecom.fr gaia.cs.umass.edu root name server local name server dns.eurecom.fr authoritative name server dns.cs.umass.edu intermediate name server dns.umass.edu 7 8 iterated query 18 Workload and Caching What workload do you expect for different servers/names? Why might this be a problem? How can we solve this problem? DNS responses are cached Quick response for repeated translations Other queries may reuse some parts of lookup NS records for domains DNS negative queries are cached Dont have to repeat past mistakes E.g. misspellings, search strings in resolv.conf Cached data periodically times out Lifetime (TTL) of data controlled by owner of data TTL passed with every record 19 Typical Resolution Client Local DNS server root & edu DNS server ns1.cmu.edu DNS serverNS ns1.cmu.eduNS ns1.cs.cmu.edu A www=IPaddr ns1.cs.cmu.edu DNS server 20 Subsequent Lookup Example Client Local DNS server root & edu DNS server cmu.edu DNS server cs.cmu.edu DNS server ftp.cs.cmu.edu ftp=IPaddr ftp.cs.cmu.edu 21 Reliability DNS servers are replicated Name service available if one replica is up Queries can be load balanced between replicas UDP used for queries Need reliability must implement this on top of UDP! Why not just use TCP? Try alternate servers on timeout Exponential backoff when retrying same server Same identifier for all queries Dont care which server responds 22 Reverse Name Lookup ? Lookup in-addr.arpa Why is the address reversed? Happens to beand mammoth.cmcl.cs.cmu.edu what will reverse lookup return? Both? Should only return name that reflects address allocation mechanism 23 Prefetching Name servers can add additional data to any response Typically used for prefetching CNAME/MX/NS typically point to another host name Responses include address of host referred to in additional section 24 Root Zone Generic Top Level Domains (gTLD) =.com,.net,.org, etc Country Code Top Level Domain (ccTLD) =.us,.ca,.fi,.uk, etc Root server ({a-m}.root-servers.net) also used to cover gTLD domains Load on root servers was growing quickly! Moving.com,.net,.org off root servers was clearly necessary to reduce load done Aug 2000 25 New gTLDs.info general info.biz businesses.aero air-transport industry.coop business cooperatives.name individuals.pro accountants, lawyers, and physicians.museum museums Only new one actives so far =.info,.biz,.name 26 New Registrars Network Solutions (NSI) used to handle all registrations, root servers, etc Clearly not the democratic (Internet) way Large number of registrars that can create new domains However, NSI still handle root servers 27 Do you trust the TLD operators? Wildcard DNS record for all.com and.net domain names not yet registered by others.com.net September 15 October 4, 2003 February 2004: Verisign sues ICANN Redirection for these domain names to Verisign web portal (SiteFinder) What services might this break? Attack On Internet Called Largest Ever David McGuire and Brian Krebs, Washington Post The heart of the Internet sustained its largest and most sophisticated attack ever, starting late Monday, according to officials at key online backbone organizations. Around 5:00 p.m. EDT on Monday, a "distributed denial of service" (DDOS) attack struck the 13 "root servers" that provide the primary roadmap for almost all Internet communications. Despite the scale of the attack, which lasted about an hour, Internet users worldwide were largely unaffected, experts said. 28 Protecting the Root Nameservers Redundancy: 13 root nameservers IP Anycast for root DNS servers {c,f,i,j,k}.root-servers.net RFC 3258 Most physical nameservers lie outside of the US Sophisticated? Why did nobody notice? seshan.org NSDefense Mechanisms 29 Protecting the Root Nameservers Redundancy: 13 root nameservers IP Anycast for root DNS servers {c,f,i,j,k}.root-servers.net RFC 3258 Most physical nameservers lie outside of the US Sophisticated? Why did nobody notice? seshan.org NSDefense Mechanisms 30 Defense: Replication and Caching source: wikipedia 31 DNS Hack #1: Load Balance Server sends out multiple A records Order of these records changes per-client DNS Hacks: Blackhole Lists First: Mail Abuse Prevention System (MAPS) Paul Vixie, 1997 Today: Spamhaus, spamcop, dnsrbl.org, etc. 32 % dig bl.spamcop.net ;; ANSWER SECTION: bl.spamcop.net IN A ;; ANSWER SECTION: bl.spamcop.net IN TXT "Blocked - seeDifferent addresses refer to different reasons for blocking 33 DNS Experience 23% of lookups with no answer Retransmit aggressively most packets in trace for unanswered lookups! Correct answers tend to come back quickly/with few retries % negative answers most = no name exists Inverse lookups and bogus NS records Worst 10% lookup latency got much worse Median 85 97, 90 th percentile 447 1176 Increasing share of low TTL records what is happening to caching? 34 DNS Experience Hit rate for DNS = 80% 1-(#DNS/#connections) Most Internet traffic is Web What does a typical page look like? average of 4-5 imbedded objects needs 4-5 transfers accounts for 80% hit rate! 70% hit rate for NS records i.e. dont go to root/gTLD servers NS TTLs are much longer than A TTLs NS record caching is much more important to scalability Name distribution = Zipf-like = 1/x a A records TTLs = 10 minutes similar to TTLs = infinite 10 client hit rate = client hit rate Some Interesting Alternatives CoDNS Lookup failures Packet loss LDNS overloading Cron jobs Maintenance problems Cooperative name lookup scheme If local server OK, use local server When failing, ask peers to do lookup Push DNS Top of DNS hierarchy is relatively stable Why not replicate much more widely? 35 36 Overview DNS P2P Lookup Overview Centralized/Flooded Lookups Bittorrent 37 Peer-to-Peer Networks Typically each member stores/provides access to content Basically a replication system for files Always a tradeoff between possible location of files and searching difficulty Peer-to-peer allow files to be anywhere searching is the challenge Dynamic member list makes it more difficult What other systems have similar goals? Routing, DNS 38 The Lookup Problem Internet N1N1 N2N2 N3N3 N6N6 N5N5 N4N4 Publisher Key=title Value=MP3 data Client Lookup(title) ? 39 Centralized Lookup (Napster) Client Lookup(title) N6N6 N9N9 N7N7 DB N8N8 N3N3 N2N2 N1N1 SetLoc(title, N4) Simple, but O( N ) state and a single point of failure Key=title Value=MP3 data N4N4 40 Flooded Queries (Gnutella) N4N4 Client N6N6 N9N9 N7N7 N8N8 N3N3 N2N2 N1N1 Robust, but worst case O( N ) messages per lookup Key=title Value=MP3 data Lookup(title) 41 Routed Queries (Chord, etc.) N4N4 Publisher Client N6N6 N9N9 N7N7 N8N8 N3N3 N2N2 N1N1 Lookup(title) Key=title Value=MP3 data 42 Overview DNS P2P Lookup Overview Centralized/Flooded Lookups Bittorrent 43 Centralized: Napster Simple centralized scheme motivated by ability to sell/control How to find a file: On startup, client contacts central server and reports list of files Query the index system return a machine that stores the required file Ideally this is the closest/least-loaded machine Fetch the file directly from peer 44 Centralized: Napster Advantages: Simple Easy to implement sophisticated search engines on top of the index system Disadvantages: Robustness, scalability Easy to sue! 45 Flooding: Old Gnutella On startup, client contacts any servent (server + client) in network Servent interconnection used to forward control (queries, hits, etc) Idea: broadcast the request How to find a file: Send request to all neighbors Neighbors recursively forward the request Eventually a machine that has the file receives the request, and it sends back the answer Transfers are done with HTTP between peers 46 Flooding: Old Gnutella Advantages: Totally decentralized, highly robust Disadvantages: Not scalable; the entire network can be swamped with request (to alleviate this problem, each request has a TTL) Especially hard on slow clients At some point broadcast traffic on Gnutella exceeded 56kbps what happened? Modem users were effectively cut off! 47 Flooding: Old Gnutella Details Basic message header Unique ID, TTL, Hops Message types Ping probes network for other servents Pong response to ping, contains IP addr, # of files, # of Kbytes shared Query search criteria + speed requirement of servent QueryHit successful response to Query, contains addr + port to transfer from, speed of servent, number of hits, hit results, servent ID Push request to servent ID to initiate connection, used to traverse firewalls Ping, Queries are flooded QueryHit, Pong, Push reverse path of previous message 48 Flooding: Old Gnutella Example Assume: m1s neighbors are m2 and m3; m3s neighbors are m4 and m5; A B C D E F m1 m2 m3 m4 m5 m6 E? E E E 49 Flooding: Gnutella, Kazaa Modifies the Gnutella protocol into two-level hierarchy Hybrid of Gnutella and Napster Supernodes Nodes that have better connection to Internet Act as temporary indexing servers for other nodes Help improve the stability of the network Standard nodes Connect to supernodes and report list of files Allows slower nodes to participate Search Broadcast (Gnutella-style) search across supernodes Disadvantages Kept a centralized registration allowed for law suits 50 Overview DNS P2P Lookup Overview Centralized/Flooded Lookups Bittorrent Peer-to-Peer Networks: BitTorrent BitTorrent history and motivation 2002: B. Cohen debuted BitTorrent Key motivation: popular content Popularity exhibits temporal locality (Flash Crowds) E.g., Slashdot/Digg effect, CNN Web site on 9/11, release of a new movie or game Focused on efficient fetching, not searching Distribute same file to many peers Single publisher, many downloaders Preventing free-loading 51 BitTorrent: Simultaneous Downloading Divide large file into many pieces Replicate different pieces on different peers A peer with a complete piece can trade with other peers Peer can (hopefully) assemble the entire file Allows simultaneous downloading Retrieving different parts of the file from different peers at the same time And uploading parts of the file to peers Important for very large files 52 BitTorrent: Tracker Infrastructure node Keeps track of peers participating in the torrent Peers register with the tracker Peer registers when it arrives Peer periodically informs tracker it is still there Tracker selects peers for downloading Returns a random set of peers Including their IP addresses So the new peer knows who to contact for data Can have trackerless system using DHT 53 BitTorrent: Chunks Large file divided into smaller pieces Fixed-sized chunks Typical chunk size of 256 Kbytes Allows simultaneous transfers Downloading chunks from different neighbors Uploading chunks to other neighbors Learning what chunks your neighbors have Periodically asking them for a list File done when all chunks are downloaded 54 55 BitTorrent: Overall Architecture Web page with link to.torrent A B C Peer [Leech] Downloader US Peer [Seed] Peer [Leech] Tracker Web Server.torrent 56 BitTorrent: Overall Architecture Web page with link to.torrent A B C Peer [Leech] Downloader US Peer [Seed] Peer [Leech] Tracker Get-announce Web Server 57 BitTorrent: Overall Architecture Web page with link to.torrent A B C Peer [Leech] Downloader US Peer [Seed] Peer [Leech] Tracker Response-peer list Web Server 58 BitTorrent: Overall Architecture Web page with link to.torrent A B C Peer [Leech] Downloader US Peer [Seed] Peer [Leech] Tracker Shake-hand Web Server Shake-hand 59 BitTorrent: Overall Architecture Web page with link to.torrent A B C Peer [Leech] Downloader US Peer [Seed] Peer [Leech] Tracker pieces Web Server 60 BitTorrent: Overall Architecture Web page with link to.torrent A B C Peer [Leech] Downloader US Peer [Seed] Peer [Leech] Tracker pieces Web Server 61 BitTorrent: Overall Architecture Web page with link to.torrent A B C Peer [Leech] Downloader US Peer [Seed] Peer [Leech] Tracker Get-announce Response-peer list pieces Web Server BitTorrent: Chunk Request Order Which chunks to request? Could download in order Like an HTTP client does Problem: many peers have the early chunks Peers have little to share with each other Limiting the scalability of the system Problem: eventually nobody has rare chunks E.g., the chunks need the end of the file Limiting the ability to complete a download Solutions: random selection and rarest first 62 BitTorrent: Rarest Chunk First Which chunks to request first? The chunk with the fewest available copies I.e., the rarest chunk first Benefits to the peer Avoid starvation when some peers depart Benefits to the system Avoid starvation across all peers wanting a file Balance load by equalizing # of copies of chunks 63 Free-Riding Problem in P2P Networks Vast majority of users are free-riders Most share no files and answer no queries Others limit # of connections or upload speed A few peers essentially act as servers A few individuals contributing to the public good Making them hubs that basically act as a server BitTorrent prevent free riding Allow the fastest peers to download from you Occasionally let some free loaders download 64 Bit-Torrent: Preventing Free-Riding Peer has limited upload bandwidth And must share it among multiple peers Prioritizing the upload bandwidth: tit for tat Favor neighbors that are uploading at highest rate Rewarding the top few (e.g. four) peers Measure download bit rates from each neighbor Reciprocates by sending to the top few peers Recompute and reallocate every 10 seconds Optimistic unchoking Randomly try a new neighbor every 30 seconds To find a better partner and help new nodes startup 65 BitTyrant: Gaming BitTorrent Lots of altruistic contributors High contributors take a long time to find good partners Active sets are statically sized Peer uploads to top N peers at rate 1/N E.g., if N=4 and peers upload at 15, 12, 10, 9, 8, 3 then peer uploading at rate 9 gets treated quite well 66 67 BitTyrant: Gaming BitTorrent Best to be the N th peer in the list, rather than 1 st Distribution of BW suggests 14KB/s is enough Dynamically probe for this value Use saved bandwidth to expand peer set Choose clients that maximize download/upload ratio Discussion Is progressive tax so bad? What if everyone does this? Next Lecture DHTs and CDNs Required readings DHTSurvey (read fully) Chord (skim) Optional readings DHT Geometry Comparison 68