EECS 122: Introduction to Computer Networks Multicast - PowerPoint PPT Presentation

1 / 48
About This Presentation
Title:

EECS 122: Introduction to Computer Networks Multicast

Description:

Department of Electrical Engineering and Computer Sciences. University of ... but single packet from edge can explode into millions of packets within network ... – PowerPoint PPT presentation

Number of Views:43
Avg rating:3.0/5.0
Slides: 49
Provided by: sto2
Category:

less

Transcript and Presenter's Notes

Title: EECS 122: Introduction to Computer Networks Multicast


1
EECS 122 Introduction to Computer Networks
Multicast
  • Computer Science Division
  • Department of Electrical Engineering and Computer
    Sciences
  • University of California, Berkeley
  • Berkeley, CA 94720-1776

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 lt hundreds of nodes
  • Typical application chat

4
Narada End System Multicast
Stanford
Gatech
Stan1
Stan2
CMU
Berk1
Berk2
Berkeley
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
  • 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
Delay from CMU to Berk1 increases
Stan1
Gatech

Stan2
CMU
Berk2
Berk1
Duplicate Packets Bandwidth Wastage
Stanford
Gatech
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
M1
M2
M3
control (join) messages
data
11
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

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 94720-1776

14
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)

15
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

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
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
18
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
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
  • 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

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
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
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
3
7
5
4
1
8
authoritative name server ns1.berkeley.edu
requesting host whistler.cs.cmu.edu
www.berkeley.edu
24
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
25
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

26
DNS Records (contd)
  • Type CNAME
  • name hostname
  • value canonical name
  • Type MX
  • name domain in email 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
  • 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!

28
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

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

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
Client 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 cant satisfy the request

37
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
38
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
39
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

40
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
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
Client 2
Proxy
Proxy
Server
Client N
44
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

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

46
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
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
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....
Write a Comment
User Comments (0)
About PowerShow.com