1. II -a: Application Layer II. Application Layer (part b) lectured by Chang-jin Suh Soongsil University, Dep. of Computer Science Tel : 820-0686 www.netwarking.com Kurose ed. 5 Chapter II

2. II -a: Application Layer 2 II.5. Domain Name System  logical domain addr(name) and physical domain addr  distributed DNS server  hierarchies of name servers  DNS operating examples  recursive vs iterative query  DNS caching  DNS format (skipped)

3. II -a: Application Layer 3 DNS: Domain Name System People: many identifiers:  name, driver’s license #, Passport # Internet hosts, routers:  IP address (32 bit) - used for addressing datagrams by routers  domain name, e.g., gaia.cs.umass.edu (JFK’s server) - used by humans Q: map between IP addresses and name ? A: dns f : f(name)  IP Domain Name System:  distributed database implemented in hierarchy of many name servers  application-layer protocol host, routers, name servers to communicate to resolve names (name to IP address translation)  note: core Internet function, implemented as application-layer protocol  complexity at network’s “edge”

4. II -a: Application Layer 4 distributed DNS name servers Why not centralize DNS?  single point of failure  doesn’t scale!  traffic volume increased  heavy traffic near the single dns server  distant to centralized database  distributed hosts are closer to the clients  maintenance DNS services definition : Hostname to IP address translation  Host aliasing and e-mail server aliasing  Canonical and alias names  f(name1)=f(name2)=IP  Load distribution  Replicated Web servers: set of IP addresses for one canonical name  f(name)=IP1 or IP2 mathematically illegal function definition !

5. II -a: Application Layer 5 Root DNS Servers com DNS servers org DNS serversedu DNS servers poly.edu DNS servers umass.edu DNS servers yahoo.com DNS servers amazon.com DNS servers pbs.org DNS servers Distributed, Hierarchical Database Client wants IP for www.amazon.com; 1 st approx:  Client queries a root server to find com DNS server  Client queries com DNS server to get amazon.com DNS server  Client queries amazon.com DNS server to get IP address for www.amazon.com

6. II -a: Application Layer 6 DNS name servers  dns servers (common properties for all DNS servers below.)  if DNS query (request) is received, get mapping using local memory.  If failed, rely on other types of servers.  local name server  first and default DNS server  closest to hosts shortest response time if mapping succeeds.  maintained by organization or ISP  root name server  maintain TDL servers  may contain the contents of TLD servers

7. II -a: Application Layer 7 DNS name servers  TLD servers :  responsible for com, org, net, edu, etc, and all top-level country domains uk, fr, ca, jp.  (intermediate name server)  frequently TLD server does not know authoritative name server  If authoritative name server is distributed,  maintained by organization or ISP  authoritative name servers:  organization’s DNS servers, providing authoritative hostname to IP mappings for organization’s servers (e.g., Web and mail).  Can be maintained by organization or ISP

8. II -a: Application Layer 8 DNS: Root name servers b USC-ISI Marina del Rey, CA l ICANN Marina del Rey, CA e NASA Mt View, CA f Internet Software C. Palo Alto, CA i NORDUnet Stockholm k RIPE London m WIDE Tokyo a NSI Herndon, VA c PSInet Herndon, VA d U Maryland College Park, MD g DISA Vienna, VA h ARL Aberdeen, MD j NSI (TBD) Herndon, VA 13 root name servers worldwide (2002 Feb)

9. II -a: Application Layer 9 types of DNS query  choice is optional not mandatory  iterative query  recursive query  iterative query (See Fig next)  if mapping fails, the requested server tells the next DNS server to visit  “I don’t know this name, but ask the same question to this server”  1 request and 1 response for a query for a server

10. II -a: Application Layer 10 types of DNS query  recursive query  If mapping fails, the requested server asks the next server recursively. If finally mapping succeed, report the result to the requester.  “I don’t know this name, but if you wait, I will tell you the answer after asking same question to some server”  2 requests and 2 responses for a query for a serve.

11. II -a: Application Layer 11 recursive query  The example shows no TLD server  typically used by local, intermediate servers requesting host surf.eurecom.fr gaia.cs.umass.edu root name server local name server dns.eurecom.fr 1 2 3 4 5 6 authoritative name server dns.cs.umass.edu intermediate name server dns.umass.edu 7 8

12. II -a: Application Layer 12 iterative query  The example shows no intermediate server  typically used by root, and TLD servers requesting host cis.poly.edu root DNS server local DNS server dns.poly.edu 1 2 3 4 5 6 gaia.cs.umass.edu authoritative DNS server dns.cs.umass.edu 7 8 TLD DNS server

13. II -a: Application Layer 13 requesting host cis.poly.edu root DNS server local DNS server dns.poly.edu 1 2 3 4 5 6 gaia.cs.umass.edu authoritative DNS server dns.cs.umass.edu 9 10 TLD DNS server typical query  (shows when there is an intermediate name server)  Host at cis.poly.edu wants IP address for gaia.cs.umass.edu 7 8 intermediate name server dns.umass.edu

14. II -a: Application Layer 14 DNS: caching and updating records  once (any) name server learns mapping, it caches mapping  cache entries timeout (disappear) after some time  TLD servers typically cached in local name servers Thus root name servers not often visited  update/notify mechanisms under design by IETF  RFC 2136  http://www.ietf.org/html.charters/dnsind- charter.html

15. II -a: Application Layer 15 DNS records (skipped) DNS: distributed db storing resource records (RR)  Type=NS  name is domain (e.g. foo.com)  value is IP address of authoritative name server for this domain RR format: (name, value, type, ttl)  Type=A  name is hostname  value is IP address Type=CNAME  name is an alias name for some “cannonical” (the real) name  value is cannonical name  Type=MX  value is hostname of mail server associated with name

16. II -a: Application Layer 16 DNS protocol, messages (skipped) DNS protocol : query and reply messages, both with same message format msg header  identification: 16 bit # for query, reply to query uses same #  flags:  query or reply  recursion desired  recursion available  reply is authoritative

17. II -a: Application Layer 17 DNS protocol, messages (skipped) Name, type fields for a query RRs in response to query records for authoritative servers additional “helpful” info that may be used

18. II -a: Application Layer 18 II.6. p2p ( 서창진 ) 1. original p2p : Napster 2. modern p2p : BitTorrent

19. II -a: Application Layer 19 1. original P2P : Napster Example (See next Fig.)  Alice runs P2P client application on her notebook computer 1. Alice intermittently connects to Internet; (donates her own directory (key, value) to server) 2. Asks for “Hey Jude”  Application displays other peers that have copy of Hey Jude.  Alice chooses one of the peers, Bob. 3. File is copied from Bob’s PC to Alice’s notebook: HTTP  While Alice downloads, other users uploading from Alice.  Alice’s peer is both a Web client and a transient Web server. All peers are servers = highly scalable!

20. II -a: Application Layer 20 1. original P2P : Napster original “Napster” 1) central server maintains directory of (key, value) from connecting peers.  key : available contents e.g., “Hey Jude”  value : IP address of active nodes (IP addr. of Bob’s pc) 2.1) Alice queries for “Hey Jude”(key) and gets (value). 2.2) Napster gives all key- matching values(Bob’s IP). 3.1) Alice requests file from Bob 3.2) Alice downloads file from Bob. centralized directory server peers Alice Bob 1 1 1 1 2 3 (a) (b) (a) control : accessing directory (b) data : data transfer (a) control : accessing directory (b) data : data transfer

21. II -a: Application Layer 21 1. Evolution of P2P Napster (original P2P)  control : centralized directory  User chooses (1) the file to download and (2) IP to download from.  data : download from a single source  weak points  Copyright infringement  Single point of failure  Performance bottleneck  control : distributed directory  User chooses (1) the file to download only.  data : download from multiple sources BitTorrent (modern P2P)

22. 2: Application Layer22 2. modern P2P architecture  no “always-on(alive)” server  arbitrary end systems directly communicate  peers are intermittently connected and change IP addresses Three topics to cover 2.1. File distribution 2.2. Searching for information 2.3. Case Study: Skype peer-peer

23. II -a: Application Layer 23 II.2.1. File Distribution II.2.1.1. Delay Analysis - very quickly covered in this semester II.2.1.2. Tit-for-tat (separate material) II.2.1.3. modern p2p : BitTorrent

24. 2: Application Layer24 2.1.1. file distribution time : S-C vs P2P Question : How much time to distribute file from one server to N peers? usus u2u2 d1d1 d2d2 u1u1 dNdN uNuN Server_s Network (with abundant bandwidth) File, size F u s : server upload bandwidth u i : peer i upload bandwidth d i : peer i download bandwidth host_1host_2 host_n

25. 2: Application Layer25 2.1.1. file distrib. time: server-client usus d1d1 d2d2 dNdN Server network F  server sequentially sends N copies:  NF/u s time  client i takes F/d i time to download  d cs =delay to distribute F to N clients using client/server approach d cs = max { NF/u s, F/min(d i ) } i d cs = NF/u s (for very large N) increases linearly in N meaning long-delay is inevitable for a larger client group

26. 2: Application Layer26 2.1.1. file distribution : p2p p2p(BitTorrent) animation http://upload.wikimedia.org/wikipedia/commons/3/3 d/Torrentcomp_small.gif http://upload.wikimedia.org/wikipedia/commons/3/3 d/Torrentcomp_small.gif animation description  There are 7 peers and a server in the torrent.  Initially, the server only has 6 chunks in the torrent. (Chunks are denoted with 6 different colors below the devices in the animation.)  The server begins to distribute chunks in there. Sooner peers help chunk distribution by forwarding chucks received from servers or from peers.  Finally, every peer has all 6 chunks.

27.  server must send one copy: F/u s time  client i takes F/d i time to download  NF bits must be downloaded (aggregate)  fastest possible upload rate: u s +  u i 2: Application Layer27 2.1.1. File distribution time: p2p usus u2u2 d1d1 d2d2 u1u1 dNdN uNuN Server F d P2P ≥ max { F/u s, F/min(d i ), NF/(u s +  u i ) } i upload time from server download time to the server having the slowest download channel (total data to send)/ (fastest upload rate) (total data to send)/ (fastest upload rate) network

28. 2: Application Layer28 2.1.1. Server-client vs. P2P: example all clients has the same upload rate why ≥? Client upload rate = u, F/u = 1 hour, u s = 10u, d min ≥ u s conclusion : Download from multiple sources are much faster from a single source.

29. 2: Application Layer29 2.1.3. File distribution: BitTorrent tracker: tracks peers participating in torrent torrent: group of peers exchanging chunks of a file obtain i) peer Id ii) list of peers trading chunks peer  P2P file distribution p2p protocol BitTorrent server

30. 2: Application Layer30 2.1.3. BitTorrent (1)  file divided into 256KB chunks.  peer joining torrent:  initially does not have chunks, but will accumulate them over time  registers with tracker to get list of peers, connects to subset of peers (“neighbors”)  2jobs : while downloading, peer uploads chunks to other peers. : using tit-for-tat algorithm (an eye- for-an eye a tooth-for-a tooth, Read tit-for-tat.ppt.)  peers are not permanent : (they may come and go)  once a peer receives entire file, it may (selfishly) leave or (altruistically) remain

31. 2.1.3. BitTorrent (2) Pulling Chunks  at any given time, different peers have different subsets of file chunks  periodically, a peer (Alice) asks each neighbor for list of chunks that they have.  Alice sends requests for her missing chunks  rarest first Sending Chunks:tit-for-tat  Alice sends chunks to 4 neighbors currently sending her chunks at the highest rate  re-evaluate top 4 every 10 secs  every 30 secs: randomly select another peer, starts sending chunks  newly chosen peer may join top 4  “optimistically unchoke” II -a: Application Layer 31

32. 2.1.3. Tit-for-tat operation  (1) Alice “optimistically unchokes” Bob.  (2) If Alice become Bob’s one of top-4 providers, and then (3) if Bob becomes one of Alice’s top-four providers,  Alice and Bob shares a strong and stable connection.  If not, (= If (2) or (3) does not occur),  Alice and Bob’s connection disappears soon.  This is a core idea of tit-for-tat II -a: Application Layer 32

33. 2: Application Layer33 2.1.3. Tit-for-tat operation (1) Alice “optimistically unchokes” Bob. If (2) Alice become Bob’s one of top-4 providers, and then if (3) Bob becomes one of Alice’s top-four providers.  Alice and Bob shares a strong and stable connection. If not, (= If (2) or (3) does not occurs),  Alice and Bob’s connection disappears soon.  This is core idea of tit-for-tat With higher upload rate, we can find better trading partners & get file faster!

34. 2.2. Distributive database  distributive database environment  database of (key, value) is stored distributed in many active peers.  distr. database problem  which peer will store the (“key”, value)? e.g, who will store (“Led Zeppelin IV”, value)?  Suppose a peer P want to download “Led Zeppelin IV”. To which peer does P contact?  solution ? DHT used by BitTorrent. 2: Application Layer34

35. 2.2. Distri Hash Table (DHT)  DHT = distributed P2P database  Database has the directory of (key, value).  (“file to download”, “IP address to download the referred file from”)  Peers query DB with key  DB returns values that match the key  A certain peer replies with (key, value). 2: Application Layer35

36. 2.2. DHT Identifiers  A peer is given a random but distinct n-bit peer Id from tracker.  distinct : no two peer have the same peer Id.  A key is given an m-bit key Id. (m>=n)  Two different keys may have the same key Id. but with negligibly small probability.  To get integer keys, hash original key.  e.g, key = h(“Led Zeppelin IV”)  This is why its name is a Distributed Hash Table. 2: Application Layer36 In DHT we need n-bit simplified key, which can be chosen from the leading n bits among m bits.

37. 2.2. key assignment to peers?  Central issue:  Assigning (key, value) to peers.  Rule: assign key to the peer that has the closest ID.  Convention in lecture: “closest” is the immediate successor of the key. (See next slide)  Ex: 4-bit-Id peer list : 1,3,4,5,8,10,12,14; key = 4, then the closest peer = 4 key = 13, then the closest peer = 14 key = 15, then the closest peer = 1 2: Application Layer37

38. Circular DHT (1)  Each peer only aware of immediate successor and predecessor.  “Overlay network” : A link in p2p means a tcp- connection not necessarily a physical link 2: Application Layer38 1 3 4 5 8 10 12 14 13 15 The key 13’s immediate successor is 14. The key 13’s immediate successor is 14. The key 15’s immediate successor is 1. The key 15’s immediate successor is 1.

39. Circle DHT (2) 0001 0011 0100 0101 1000 1010 1100 1111 Who’s resp for key 1110 ? I am O(N) messages on avg to resolve query, when there are N peers 1110 Define closest as closest successor 2: Application Layer39

40. Circular DHT with Shortcuts  Each peer keeps track of IP addresses of predecessor, successor, shortcuts.  Reduced from 6 to 2 hops.  It is known that if every peer has O(log N) neighbors, O(log N) hops are required. 1 3 4 5 8 10 12 15 Who is responsible for key 1110 2 (=14)? 2: Application Layer40 shortcut All “red” connection not along the circle are shortcuts.

41. Peer Churn 1. Peer 5 abruptly leaves 2. Peer 4 detects; makes 8 its immediate successor; Peer 4 asks 8 who its immediate successor is; makes 8’s immediate successor its second successor.  What if peer 13 wants to join? 1 3 4 5 8 10 12 15 2: Application Layer41 peer churn : join or leave of peers  To handle peer churn, require each peer to know the IP address of its two successors.  for peer 1, successors=3,4  Each peer periodically pings its two successors to see if they are still alive. 출렁거림

42. Peer Churn (advanced) 2: Application Layer42 relocation of directory (key, values) (?)  Peer churn requires relocation of directory.  peer leave  Should deliver currently stored directory to its immediate successor before dying.  sudden peer death : Peer dies without doing above job.  To reduce the damage from sudden death, two successors should maintain directory backup.  Some information loss is inevitable for sudden death.  peer join  The immediate successor should relocate a part of its directory to the newly-joined peer.

43. 2: Application Layer43 P2P Case study: Skype  inherently P2P: pairs of users communicate.  proprietary application - layer protocol (inferred via reverse engineering)  hierarchical overlay with SNs  Index maps usernames to IP addresses; distributed over SNs Skype clients (SC) Supernode (SN) Skype login server 사기업가 만든 비공개 프로토콜 이라서 많은 부분을 역추적하여 해석하고 있음. ( 비슷한 예 원도우 )

44. 2: Application Layer44 Peers as relays  Problem when both Alice and Bob are behind NATs”.  NAT prevents an outside peer from initiating a call to insider peer  Solution:  Using Alice’s and Bob’s SNs, Relay (which is not behind NAT) is chosen.  Each peer (Alice & Bob) initiates session with relay.  Peers can now communicate through NATs via relay with the Relay’s sacrifice.

45. II -a: Application Layer 45 Chapter 2: Summary We have studied  protocols, especially application protocols.  how application protocols are built,  underlined knowledge for the protocol  especially how to design and implement application programs  using sockets  I appreciate for your efforts in this course.  Enjoy a lot in upcoming summer vacation.  I appreciate for your efforts in this course.  Enjoy a lot in upcoming summer vacation.