EE122: DNS and the Web after a little more multicast

1
EE122 DNS and the Web(after a little more
multicast)

• October 27, 2003

2
EECS 122 Introduction to Computer Networks DNS
and WWW

• Computer Science Division
• Department of Electrical Engineering and Computer
  Sciences
• University of California, Berkeley
• Berkeley, CA 94720-1776

3
Barriers to Multicast

• Hard to change IP
• multicast means change to IP
• details of multicast were very hard to get right
• Not always consistent with ISP economic model
• charging done at edge, but single packet from
  edge can explode into millions of packets within
  network
• Troublesome security model
• Anyone can send to a group
• Denial-of-service attacks on known groups

4
Application Layer Multicast (ALM)

• Let the hosts do all the special work
• only require unicast from infrastructure
• Basic idea
• hosts do the copying of packets
• set up tree between hosts
• Example Narada Yang-hua et al, 2000
• Small group sizes lt hundreds of nodes
• Typical application chat

5
Narada End System Multicast
Stanford
Gatech
Stan1
Stan2
CMU
Berk1
Berk2
Berkeley
Overlay Tree
Stan1
Gatech

Stan2
CMU
Berk1
Berk2
6
Algorithmic Challenge

• Choosing replication/forwarding points among
  hosts
• how do the hosts know about each other
• and know which hosts should forward to other
  hosts

7
Advantages of ALM

• No need for changes to IP or routers
• No need for ISP cooperation
• End hosts can prevent other hosts from sending
• Easy to implement reliability
• use hop-by-hop retransmissions

8
Performance Concerns

• Stretch
• ratio of latency in the overlay to latency in the
  underlying network
• Stress
• number of duplicate packets sent over the same
  physical link

9
Performance Concerns
Delay from CMU to Berk1 increases
Stan1
Gatech

Stan2
CMU
Berk2
Berk1
Duplicate Packets Bandwidth Wastage
Stanford
Gatech
Stan1
Stan2
CMU

Berk1
Berk2

Berkeley
10
Single Sender Multicast

• Many problems with IP multicast disappear if each
  group is associated with a single source
• Hosts joining multicast group can send join
  messages to source
• this sets up delivery tree
• no worry about root being in wrong place
• This solves several problems
• better security and charging model
• simple algorithm

11
Example

• Group members M1, M2, M3

source
M1
M2
M3
control (join) messages
data
12
Whats Wrong with SSM?

• Multiple sources?
• can set up group per source, or...
• source can serve as relay for other senders
• Algorithm?
• trivial
• So, why isnt SSM the answer?
• multicast no longer serves as rendezvous
• ok for broadcast apps, not good for meeting
  apps

13
What Do You Need to Know?

• DVRMP
• CBT
• SSM
• How they compare

14
Todays Lecture 17
17, 18, 19
2
Application
10,11
6
Transport
14, 15, 16
7, 8, 9
Network (IP)
Link
21, 22, 23
Physical
25
15
Internet Names Addresses

• Names e.g. ariachne.berkeley.edu
• human-usable labels for machines
• conforms to organizational structure
• Addresses e.g. 169.229.131.109
• router-usable labels for machines
• conforms to network structure
• How do you map from one to another?
• Domain Name System (DNS)

16
DNS History

• Initially all host-addess mappings were in a file
  called hosts.txt (in /etc/hosts)
• Changes were submitted to SRI by email
• New versions of hosts.txt ftpd periodically from
  SRI
• An administrator could pick names at their
  discretion
• As the internet grew this system broke down
  because
• SRI couldnt handled the load
• Names were not unique
• Many hosts had inaccurate copies of hosts.txt
• Internet growth was threatened!
• Domain Name System (DNS) was born

17
Basic DNS Features

• Hierarchical namespace
• as opposed to original flat namespace
• Distributed storage architecture
• as opposed to centralized storage (plus
  replication)
• Client--server interaction on UDP Port 53
• but can use TCP if desired

18
Naming Hierarchy
root
edu
gov
mil
net
uk
fr
etc.
com
org

• Top Level Domains are at the top
• Depth of tree is arbitrary (limit 128)
• Domains are subtrees
• E.g .edu, berkeley.edu, eecs.berkeley.edu
• Name collisions avoided
• E.g. berkeley.edu and berkeley.com can coexist,
  but uniqueness is job of domain

mit
berkeley
eecs
sims
argus
19
Host names are administered hierarchically
root
root
edu
gov
mil
net
uk
fr
edu
gov
mil
net
uk
fr
com
org
com
org
mit
berkeley
berkeley

• A zone corresponds to an administrative authority
  that is responsible for that portion of the
  hierarchy
• eecs controls names x.eecs.berkeley.edu
• berkeley controls names x.berkeley.edu and
  y.sims.berkeley.edu

eecs
eecs
sims
sims
argus
20
Server Hierarchy

• Each server has authority over a portion of the
  hierarchy
• A server maintains only a subset of all names
• Each server contains all the records for the
  hosts in its zone
• might be replicated for robustness
• Each server needs to know other servers that are
  responsible for the other portions of the
  hierarchy
• Every server knows the root
• Root server knows about all top-level domains

21
DNS Name Servers

• Local name servers
• Each ISP (company) has local default name server
• Host DNS query first goes to local name server
• Authoritative name servers
• For a host stores that hosts (name, IP address)
• Can perform name/address translation for that
  hosts name
• Can also do IP to name translation, but wont
  discuss

22
DNS Root Name Servers

• Contacted by local name server that can not
  resolve name
• Root name server
• Contacts authoritative name server if name
  mapping not known
• Gets mapping
• Returns mapping to local name server
• Dozen root name servers worldwide

23
Simple DNS Example
root name server

• Host whistler.cs.cmu.edu wants IP address of
  www.berkeley.edu
• 1. Contacts its local DNS server,
  mango.srv.cs.cmu.edu
• 2. mango.srv.cs.cmu.edu contacts root name
  server, if necessary
• 3. Root name server contacts authoritative name
  server, ns1.berkeley.edu, if necessary

2
4
3
5
authorititive name server ns1.berkeley.edu
1
6
requesting host whistler.cs.cmu.edu
www.berkeley.edu
24
Example of Recursive DNS Query
root name server

• Root name server
• May not know authoritative name server
• May know intermediate name server who to contact
  to find authoritative name server?
• Recursive query
• Puts burden of name resolution on contacted name
  server
• Heavy load?

6
2
3
7
5
4
1
8
authoritative name server ns1.berkeley.edu
requesting host whistler.cs.cmu.edu
www.berkeley.edu
25
Example of Iterated DNS Query

• Iterated query
• Contacted server replies with name of server to
  contact
• I dont know this name, but ask this server

root name server
iterated query
2
3
4
5
7
6
1
8
authoritative name server ns1.berkeley.edu
requesting host whistler.cs.cmu.edu
www.berkeley.edu
26
DNS Records

• Four fields (name, value, type, TTL)
• Type A
• name hostname
• value IP address
• Type NS
• name domain
• value name of dns server for domain

27
DNS Records (contd)

• Type CNAME
• name hostname
• value canonical name
• Type MX
• name domain in email address
• value canonical name of mail server

28
DNS as Indirection Service

• Can refer to machines by name, not address
• not only easier for humans
• also allows machines to change IP addresses
  without having to change way you refer to machine
• Can refer to machines by alias
• www.berkeley.edu can be generic web server
• but DNS can point this to particular machine that
  can change over time
• But, this flexibility applies only within domain!

29
Special Topics

• DNS caching
• improve performance by saving results of previous
  lookups
• DNS hacks
• return records based on requesting IP address
• dynamic DNS
• allows remote updating of IP address for mobile
  hosts
• DNS politics (ICANN) and branding battles

30
Important Properties of DNS

• Administrative delegation and distributed server
  architecture results in
• Easy unique naming
• Fate sharing for network failures
• Reasonable trust model

31
The Web

• A distributed database of pages
• Core components
• Servers store files and execute remote commands
• Browsers retrieve and display pages
• URLs way to refer to pages
• Need a protocol to transfer information between
  clients and servers
• HTTP

32
Uniform Record Locator

• protocol//host-nameport/directory-path/resource
• Extend the idea of hierarchical namespaces to
  include anything in a file system
• ftp//www.eecs.berkeley.edu/122/Lecture6/presentat
  ion.ppt
• Extend to program executions as well
• http//us.f413.mail.yahoo.com/ym/ShowLetter?box4
  0B40BulkMsgId2604_1744106_29699_1123_1261_0_289
  17_3552_1289957100SearchNheadfYY31454order
  downsortdatepos0viewaheadb
• Server side processing can be incorporated in the
  name

33
Web and DNS

• URLs use hostnames
• Thus, content names are tied to specific hosts
• This is bad!
• URNs are one proposal to achieve persistence

34
Hyper Text Transfer Protocol

• Client-server architecture
• Synchronous request/reply protocol
• Runs over TCP, Port 80
• Stateless
• Uses unicast

35
Big Picture
Client
Server
TCP Syn
Establish connection
TCP syn ack
Client request
TCP ack HTTP GET
Request response
Close connection
36
Hyper Text Transfer Protocol Commands

• GET transfer resource from given URL
• HEAD GET resource metadata (headers) only
• PUT store/modify resource under given URL
• DELETE remove resource
• POST provide input for a process identified by
  the given URL (usually used to post CGI
  parameters)

37
Response Codes

• 1x informational
• 2x success
• 3x redirection
• 4x client error in request
• 5x server error cant satisfy the request

38
Client Request

• Steps to get the resource http//www.eecs.berke
  ley.edu/index.html
• Use DNS to obtain the IP address of
  www.eecs.berkeley.edu
• Send to an HTTP request

GET /index.html HTTP/1.0
39
Server Response
HTTP/1.0 200 OK Content-Type text/html Content-Le
ngth 1234 Last-Modified Mon, 19 Nov 2001
153120 GMT ltHTMLgt ltHEADgt ltTITLEgtEECS Home
Pagelt/TITLEgt lt/HEADgt lt/BODYgt lt/HTMLgt
40
Example (from Kurose and Ross)

• http//www.mylife.org/mypictures.htm
• After finding out the IP address of the host
• http client initiates a TCP connection on 80
• Client sends the get request via socket
  established in 1
• Server sends the html file, which is encapsulated
  in its response
• http server tells tcp to terminate connection
• http client receives the file and the browser
  parses itcontains ten jpeg images
• Client repeats steps 1-4

41
HTTP/1.0 Example
Server
Client
Request image 1
Transfer image 1
Request image 2
Transfer image 2
Request text
Transfer text
Finish display page
42
HHTP/1.0 Performance

• Create a new TCP connection for each resource
• Large number of embedded objects in a web page
• Many short lived connections
• TCP transfer
• Too slow for small object
• May never exit slow-start phase
• Connections may be set up in parallel (5 is
  default in most browsers)

43
HTTP/1.0 Caching

• Exploit locality of reference
• A modifier to the GET request
• If-modified-since return a not modified
  response if resource was not modified since
  specified time
• A response header
• Expires specify to the client for how long it
  is safe to cache the resource
• A request directive
• No-cache ignore all caches and get resource
  directly from server
• These features can be best taken advantage of
  with HTTP proxies
• Locality of reference increases if many clients
  share a proxy

44
Web Proxies

• Intermediaries between client and server

Client 1
Client 2
Proxy
Proxy
Server
Client N
45
HTTP/1.1 (1996)

• Performance
• Persistent connections
• Pipelined requests/responses
• Support for virtual hosting
• Efficient caching support
• Network Cache assumed more explicitly in the
  design
• Gives more control to the server on how it wants
  data cached

46
Persistent Connections

• Allow multiple transfers over one connection
• Avoid multiple TCP connection setups
• Avoid multiple TCP slow starts

47
Pipelined Requests/Responses
Server
Client

• Buffer requests and responses to reduce the
  number of packets
• Multiple requests can be contained in one TCP
  segment
• Note order of responses has to be maintained

Request 1
Request 2
Request 3
Transfer 1
Transfer 2
Transfer 3
48
What You Need to Know

• DNS record types, and how they are used
• HTTP basics (and essential differences between
  1.0 and 1.1)

49
Whats the Moral of this Story?

• QoS and IP Multicast
• interesting algorithmic and architectural issues
• thousands of academic papers
• ubiquitous in routers, but not deployed by ISPs
• little or no impact on end users
• DNS and the Web
• no research papers on topic before deployment
• really boring designs
• they changed the world....