1. EECS 122: Introduction to Computer Networks Multicast
Computer Science Division
Department of Electrical Engineering and Computer Sciences
University of California, Berkeley
Berkeley, CA

2. 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

3. 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 <= hundreds of nodes
Typical application: chat

4. Narada: End System Multicast
Gatech
Stanford
Stan1
Stan2
CMU
Berk1
Berkeley
Berk2
“Overlay” Tree
Stan1
Gatech
Stan2
CMU
Berk1
Berk2

5. 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

6. 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

7. Performance Concerns Stretch Stress
ratio of latency in the overlay to latency in the underlying network
Stress
number of duplicate packets sent over the same physical link

8. Performance Concerns Gatech Gatech Stanford Stan1 Stan2 Berk1 Berk2
Delay from CMU to
Berk1 increases
Stan1
Gatech
Stan2
CMU
Berk2
Berk1
Duplicate Packets:
Bandwidth Wastage
Gatech
Stanford
Stan1
Stan2
CMU
Berk1
Berk2
Berkeley

9. 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

10. Example Group members: M1, M2, M3 source control (join) messages data

11. What’s Wrong with SSM? Multiple sources? Algorithm?
can set up group per source, or...
source can serve as relay for other senders
Algorithm?
trivial
So, why isn’t SSM the answer?
multicast no longer serves as “rendezvous”
ok for “broadcast” apps, not good for “meeting” apps

12. What Do You Need to Know?
DVRMP
CBT
SSM
How they compare

13. 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

14. Internet Names & Addresses
Names: e.g., ariachne.berkeley.edu
human-usable labels for machines
conforms to “organizational” structure
Addresses: e.g.,
router-usable labels for machines
conforms to “network” structure
How do you map from one to another?
Domain Name System (DNS)

15. DNS: History
Initially all host-addess mappings were in a file called hosts.txt (in /etc/hosts)
Changes were submitted to SRI by
New versions of hosts.txt ftp’d periodically from SRI
An administrator could pick names at their discretion
As the internet grew this system broke down because:
SRI couldn’t 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

16. 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

17. Naming Hierarchy “Top Level Domains” are at the top
root
edu
com
gov
mil
org
net uk fr
etc.
“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
berkeley
mit
eecs
sims
argus

18. Host names are administered hierarchically
root
root
edu
edu
com
com
gov
gov
mil
mil
org
org
net
net uk uk fr fr
berkeley
berkeley
mit
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

19. 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

20. DNS Name Servers Local name servers: Authoritative 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 host’s (name, IP address)
Can perform name/address translation for that host’s name
Can also do IP to name translation, but won’t discuss

21. 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

22. authorititive name server
Simple DNS Example
root name server
Host whistler.cs.cmu.edu wants IP address of
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
local name server
mango.srv.cs.cmu.edu
authorititive name server
ns1.berkeley.edu 1 6
requesting host
whistler.cs.cmu.edu

23. 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 7 3
local name server
mango.srv.cs.cmu.edu
intermediate name server
(edu server) 4 5 1 8
authoritative name server
ns1.berkeley.edu
requesting host
whistler.cs.cmu.edu

24. Example of Iterated DNS Query
Iterated query:
Contacted server replies with name of server to contact
“I don’t know this name, but ask this server”
root name server
iterated query 2 3 4 5
intermediate name server
(edu server)
local name server
mango.srv.cs.cmu.edu 7 6 1 8
authoritative name server
ns1.berkeley.edu
requesting host
whistler.cs.cmu.edu

25. DNS Records Four fields: (name, value, type, TTL) Type = A: Type = NS:
name = hostname
value = IP address
Type = NS:
name = domain
value = name of dns server for domain

26. DNS Records (cont’d) Type = CNAME: Type = MX: name = hostname
value = canonical name
Type = MX:
name = domain in address
value = canonical name of mail server

27. 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
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!

28. Special Topics DNS caching DNS “hacks” dynamic DNS
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

29. Important Properties of DNS
Administrative delegation and distributed server architecture results in:
Easy unique naming
Fate sharing for network failures
Reasonable trust model

30. 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

31. Uniform Record Locator
protocol://host-name:port/directory-path/resource
Extend the idea of hierarchical namespaces to include anything in a file system
ftp://
Extend to program executions as well…
Server side processing can be incorporated in the name

32. Web and DNS URLs use hostnames
Thus, content names are tied to specific hosts
This is bad!
URNs are one proposal to achieve persistence

33. Hyper Text Transfer Protocol
Client-server architecture
Synchronous request/reply protocol
Runs over TCP, Port 80
Stateless
Uses unicast

34. Big Picture . Client Server TCP Syn Establish connection TCP syn + ack
request
TCP ack + HTTP GET .
Request
response
Close
connection

35. 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)

36. Response Codes 1x informational 2x success 3x redirection
4x client error in request
5x server error; can’t satisfy the request

37. Client Request GET /index.html HTTP/1.0
Steps to get the resource:
Use DNS to obtain the IP address of
Send to an HTTP request:
GET /index.html HTTP/1.0

38. Server Response HTTP/1.0 200 OK Content-Type: text/html
Content-Length: 1234
Last-Modified: Mon, 19 Nov :31:20 GMT
<HTML>
<HEAD>
<TITLE>EECS Home Page</TITLE>
</HEAD> …
</BODY>
</HTML>

39. Example (from Kurose and Ross)
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 it…contains ten jpeg images
Client repeats steps 1-4

40. HTTP/1.0 Example Client Server Request image 1 Transfer image 1
Request text
Transfer text
Finish display
page

41. 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)

42. 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

43. Web Proxies . Intermediaries between client and server Client 1
Proxy
Proxy
Server
Client N

44. HTTP/1.1 (1996) Performance: Support for virtual hosting
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

45. Persistent Connections
Allow multiple transfers over one connection
Avoid multiple TCP connection setups
Avoid multiple TCP slow starts

46. Pipelined Requests/Responses
Client
Server
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

47. What You Need to Know DNS: record types, and how they are used
HTTP basics (and essential differences between 1.0 and 1.1)

48. What’s 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....