1. 2: Application Layer1 Chapter 2 Application Layer Computer Networking: A Top Down Approach, 4 th edition. Jim Kurose, Keith Ross Addison-Wesley, July 2007. (Updated Apr 09, Sept 10). (Updated Aug 2012).

2. 2: Application Layer2 Creating a network app write programs that  run on (different) end systems  communicate over network  e.g., web server software communicates with browser software No need to write software for network-core devices  network core devices do not run user applications  applications on end systems allows for rapid app development, propagation application transport network data link physical application transport network data link physical application transport network data link physical

3. 2: Application Layer3 Application architectures r Client-server r Peer-to-peer (P2P) r Hybrid of client-server and P2P

4. 2: Application Layer4 Client-server architecture server:  always-on host  permanent IP address  server farms for scaling Clients (in general):  communicate with server  intermittently connected  have dynamic IP addresses  do not communicate directly with each other client/server

5. 2: Application Layer5 Pure P2P architecture r there is no always-on server r arbitrary end systems directly communicate r peers intermittently connected & change IP addresses r example: Gnutella Highly scalable but difficult to manage peer-peer

6. 2: Application Layer6 Hybrid of client-server and P2P Skype  voice-over-IP P2P application  centralized server: finding address of remote party  client-client connection: direct (not through server) Instant messaging  chatting between two users is P2P  centralized service: client presence detection & location user registers IP address with central server when it comes online user contacts central server to find IP addresses of buddies

7. 2: Application Layer7 Web and HTTP First, a review… r Web page consists of objects r Object can be HTML file, JPEG image, Java applet, audio file,… r Web page consists of base HTML-file which includes several referenced objects r Each object is addressable by a URL r Example URL: www.someschool.edu/someDept/pic.gif host name path name

8. 2: Application Layer8 HTTP overview HTTP: hypertext transfer protocol r client/server model  client: browser that requests, receives, displays Web objects  server: Web server sends objects in response to requests r HTTP 1.0: RFC 1945 r HTTP 1.1: RFC 2068 (persistent TCP) PC running Explorer Server running Apache Web server Mac running FireFox/Chrome HTTP request HTTP response

9. 2: Application Layer9 HTTP overview (continued) Uses TCP: r 1. client initiates TCP connection to server,port 80 r 2. server accepts TCP connection from client r 3. HTTP (application-layer) messages exchanged between HTTP client and HTTP server r 4. TCP connection closed HTTP is “stateless” r server maintains no information about past client requests Protocols that maintain “state” are complex! r Past history (state) must be maintained r if server/client crashes, views of “state” may be inconsistent, must be reconciled r state is added via ‘cookies’ Design Issues: - Stateful vs Stateless vs Hybrid - Hard vs Soft State vs Hybrid A ‘state’ is information kept in memory of a host, server or router to reflect past events: such as routing tables, data structures or database entries

10. 2: Application Layer10 HTTP connections I. Nonpersistent HTTP r At most one object is sent over a TCP connection. r HTTP/1.0 uses nonpersistent HTTP II. Persistent HTTP r Multiple objects can be sent over single TCP connection between client and server. r Used in HTTP/1.1 by default:  A. persistent with pipelining  B. persistent without pipelining

11. 2: Application Layer11 Persistent HTTP Nonpersistent HTTP issues: r requires 2 RTTs per object r OS overhead for each TCP connection r browsers often open parallel TCP connections to fetch referenced objects Persistent HTTP r server leaves connection open after sending response r subsequent HTTP messages between same client/server sent over open connection Persistent without pipelining: r client issues new request only when previous response has been received r one RTT for each referenced object Persistent with pipelining: r default in HTTP/1.1 r client sends requests as soon as it encounters a referenced object r as little as one RTT for all the referenced objects

12. 2: Application Layer12 Cookies: keeping “state” (cont.) client server usual http response msg cookie file one week later: usual http request msg cookie: 1678 cookie- specific action access ebay 8734 usual http request msg Amazon server creates ID 1678 for user create entry usual http response Set-cookie: 1678 ebay 8734 amazon 1678 usual http request msg cookie: 1678 cookie- spectific action access ebay 8734 amazon 1678 backend database

13. 2: Application Layer13 Cookies (continued) What cookies can bring: r authorization r shopping carts r recommendations r user session state (Web e-mail) Cookies and privacy: r cookies permit sites to learn a lot about you r you may supply name and e-mail to sites aside How to keep “state”: r protocol endpoints: maintain state at sender/receiver over multiple transactions r cookies: http messages carry state

14. 2: Application Layer14 Web caches & proxy servers r user sets browser: Web accesses via cache r browser sends all HTTP requests to cache  object in cache (cache hit): cache returns object  else (cache miss) cache requests object from origin server, then returns object to client  Cache keeps copy of object for future use Goal: satisfy client request without involving origin server client Proxy server client HTTP request HTTP response HTTP request origin server origin server HTTP response - Can all objects be cached? - Proxy vs. local browser cache

15. 2: Application Layer15 More about Web caching r cache acts as both client and server r typically cache is installed by ISP (university, company, residential ISP) Why Web caching? r 1. reduce response time for client request r 2. reduce traffic on an institution’s access link r 3. other: hiding original requester!

16. 2: Application Layer16 Caching example Assumptions r average object size = 100k bits r avg. request rate from institution’s browsers = 15 req/sec r delay from institutional router to any origin server and back = 2 sec Consequences r utilization on LAN = 15% r utilization on access link = 100% r total delay = Internet delay + access delay + LAN delay = 2 sec + minutes + milliseconds origin servers public Internet institutional network 10 Mbps LAN 1.5 Mbps access link

17. 2: Application Layer17 Caching example (cont) one solution: install cache r suppose cache hit rate is 0.4 consequence r 40% requests will be satisfied almost immediately r 60% requests satisfied by origin server r utilization of access link reduced to 60%, resulting in negligible delays (say 10 msec) r total avg delay = Internet delay + access delay + LAN delay =.6*(2.01) secs +.4*milliseconds < 1.4 secs origin servers public Internet institutional network 10 Mbps LAN 1.5 Mbps access link institutional cache

18. 2: Application Layer18 FTP: the file transfer protocol r client/server model  client: side initiating transfer, server: remote host r ftp: RFC 959, ftp server: port 21 r Separate data and control connections  Control connection “out of band” r FTP server maintains “state”:  current directory, earlier authentication file transfer FTP server FTP user interface FTP client local file system remote file system user at host FTP client FTP server TCP control connection port 21 TCP data connection port 20

19. 2: Application Layer19 Electronic Mail: SMTP [RFC 2821] r uses TCP to reliably transfer email message from client to server, port 25 r direct transfer: sending server to receiving server r three phases of transfer  1. handshake, 2. transfer of messages, 3. closure r SMTP uses persistent connections: sending mail server sends all its messages to the receiving mail server over one TCP connection r Email Scenario: user agent mail server mail server user agent 1 2 3 4 5 6 Send mail Rcv mail user agent sender’s mail server user agent SMTP access protocol receiver’s mail server

20. 2: Application Layer20 SMTP: Comparison with HTTP: r HTTP: pull r SMTP: push r both have ASCII command/response interaction, status codes r HTTP: each object encapsulated in its own response msg r SMTP: multiple objects sent in multipart msg Protocol Design Issue: - Pull vs. Push vs. Hybrid (spectrum) - how far do we push/pull - Issues & factors to analyze: - access pattern, delay, object dynamics, …

21. 2: Application Layer21 DNS: Domain Name System Internet identifiers for hosts, routers:  IP address used for addressing datagrams  “name”, e.g., ww.yahoo.com - used by humans Q: map between IP addresses and name, and vice versa ? Domain Name System: r distributed database implemented in hierarchy of many name servers r application-layer protocol host, routers, name servers to communicate to resolve names (address/name translation)  note: core Internet function, implemented as application-layer protocol  complexity at network’s “edge”

22. 2: Application Layer22 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: r client queries a root server to find com DNS server r client queries com DNS server to get amazon.com DNS server r client queries amazon.com DNS server to get IP address for www.amazon.com

23. 2: Application Layer23 DNS: Root name servers r contacted by local name server that can not resolve name r root name server:  contacts authoritative name server if name mapping not known  gets mapping  returns mapping to local name server 13 root name servers worldwide b USC-ISI Marina del Rey, CA l ICANN Los Angeles, CA e NASA Mt View, CA f Internet Software C. Palo Alto, CA (and 36 other locations) i Autonomica, Stockholm (plus 28 other locations) k RIPE London (also 16 other locations) m WIDE Tokyo (also Seoul, Paris, SF) a Verisign, Dulles, VA c Cogent, Herndon, VA (also LA) d U Maryland College Park, MD g US DoD Vienna, VA h ARL Aberdeen, MD j Verisign, ( 21 locations)

24. 2: Application Layer24 TLD and Authoritative Servers r I. Top-level domain (TLD) servers:  responsible for com, org, net, edu, etc, and all top-level country domains uk, fr, ca, jp.  Network Solutions maintains servers for com TLD  Educause for edu TLD r II. Authoritative DNS servers:  organization’s DNS servers, providing authoritative hostname to IP mappings for organization’s servers (e.g., Web, mail).  can be maintained by organization or service provider

25. 2: Application Layer25 III. Local Name Server r does not strictly belong to hierarchy r each ISP (residential ISP, company, university) has one.  also called “default name server” r when host makes DNS query, query is sent to its local DNS server  acts as proxy, forwards query into hierarchy

26. 2: Application Layer26 requesting host cis.poly.edu gaia.cs.umass.edu root DNS server local DNS server dns.poly.edu 1 2 3 4 5 6 authoritative DNS server dns.cs.umass.edu 7 8 TLD DNS server DNS name resolution example r Host at cis.poly.edu wants IP address for gaia.cs.umass.edu A. iterative query: r contacted server replies with name of server to contact r “I don’t know this name, but ask this server”

27. 2: Application Layer27 requesting host cis.poly.edu gaia.cs.umass.edu root DNS server local DNS server dns.poly.edu 1 2 4 5 6 authoritative DNS server dns.cs.umass.edu 7 8 TLD DNS server 3 B. recursive query: r puts burden of name resolution on contacted name server r heavy load? DNS name resolution example

28. Pure P2P architecture r no always-on server r arbitrary end systems directly communicate r peers are intermittently connected and change IP addresses Three topics:  file distribution  searching for information  case Study: Skype peer-peer Application 2-28

29. 2: Application Layer29 P2P: centralized directory original “Napster” design 1) when peer connects, it informs central server:  IP address  content 2) Alice queries for “Hey Jude” 3) Alice requests file from Bob centralized directory server peers Alice Bob 1 1 1 1 2 3

30. 2: Application Layer30 P2P: problems with centralized directory r single point of failure r performance bottleneck r copyright infringement: “target” of lawsuit is obvious file transfer is decentralized, but locating content is highly centralized Advantages vs. disadvantages Search time and overhead?

31. 2: Application Layer31 Query flooding: Gnutella r fully distributed  no central server r public domain protocol r many Gnutella clients implementing protocol overlay network: graph r edge between peer X and Y if there’s a TCP connection r all active peers and edges form overlay net r edge: virtual (not physical) link r given peer typically connected with < 10 overlay neighbors Advantages vs Disadvs of overlays? - Flexibility – Scalability - Loss of optimality - – Maintenance overhead

32. 2: Application Layer32 Gnutella: protocol 1 Query 7 QueryHit 3 Query 4 Query 5 QueryHit 2 Query 6 Query Hit 8 File transfer: HTTP r Query message sent over existing TCP connections r peers forward Query message r QueryHit sent over reverse path Scalability: limited scope flooding

33. 2: Application Layer33 Gnutella: Peer joining 1. joining peer Alice must find another peer in Gnutella network: use list of candidate peers 2. Alice sequentially attempts TCP connections with candidate peers until connection setup with Bob 3. Flooding: Alice sends Ping message to Bob; Bob forwards Ping message to his overlay neighbors (who then forward to their neighbors….) r peers receiving Ping message respond to Alice with Pong message 4. Alice receives many Pong messages, and can then setup additional TCP connections

34. 2: Application Layer34 Hierarchical Overlay r between centralized index, query flooding approaches r each peer is either a group leader or assigned to a group leader.  TCP connection between peer and its group leader.  TCP connections between some pairs of group leaders. r group leader tracks content in its children

35. 2: Application Layer35 Comparing Client-server, P2P architectures

36. 2: Application Layer36 P2P Case Study: BitTorrent tracker: tracks peers participating in torrent torrent: group of peers exchanging chunks of a file obtain list of peers trading chunks peer r P2P file distribution

37. 2: Application Layer37 BitTorrent (1) r file divided into 256KB chunks. r peer joining torrent:  has no chunks, but will accumulate them over time  registers with tracker to get list of peers, connects to subset of peers (“neighbors”) r while downloading, peer uploads chunks to other peers (requiring nodes to be contributors!). r peers may come and go r once peer has entire file, it may (selfishly) leave or (altruistically) remain

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

39. 2: Application Layer39 P2P Case study: Skype r P2P (pc-to-pc, pc-to- phone, phone-to-pc) Voice-Over-IP (VoIP) application  also IM r proprietary application- layer protocol (inferred via reverse engineering) r hierarchical overlay with SNs r Index maps usernames to IP addresses; distributed over SNs Skype clients (SC) Supernode (SN) Skype login server

40. 2: Application Layer40 Skype: making a call r User starts Skype Skype login server r SC registers with SN  list of bootstrap SNs r SC logs in (authenticate) r Call: SC contacts SN will callee ID  SN contacts other SNs (unknown protocol, maybe flooding) to find addr of callee; returns addr to SC r SC directly contacts callee, overTCP

41. Distributed Hash Table (DHT) r DHT: distributed P2P database r database has (key, value) pairs;  key: ss number; value: human name  key: content type; value: IP address r peers query DB with key  DB returns values that match the key r peers can also insert (key, value) peers Application 2-41

42. DHT Identifiers r assign integer identifier to each peer in range [0,2 n -1].  Each identifier can be represented by n bits. r require each key to be an integer in same range. r to get integer keys, hash original key.  e.g., key = h(“Led Zeppelin IV”)  this is why they call it a distributed “hash” table Application 2-42

43. How to assign keys to peers? r central issue:  assigning (key, value) pairs to peers. r rule: assign key to the peer that has the closest ID. r convention in lecture: closest is the immediate successor of the key. r e.g.,: n=4; peers: 1,3,4,5,8,10,12,14;  key = 13, then successor peer = 14  key = 15, then successor peer = 1 Application 2-43

44. 1 3 4 5 8 10 12 15 Circular DHT (1) r each peer only aware of immediate successor and predecessor. r “overlay network” Application 2-44