Multicast technology: what it is, what have been done
Download
Report
Transcript Multicast technology: what it is, what have been done
Multicast technology:
what it is, what have been done,
what's next?
C. Pham
Univ. Lyon 1, INRIA RESO/LIP
Some parts of this talk borrow materials from a tutorial
presented at ICT'2003 (C. Pham & V. Roca)
Tuesday, June 24th, LIP, ENS Lyon
multicast!
How multicast can change the
way people use the Internet?
multicast!
talking
multicast!Everybody's
about multicast!
Really annoying !
What is it exactly?
multicast!
multicast!
multicast!
multicast!
multicast!
multicast!
Purpose of this tutorial
Provide a comprehensive overview of
current multicast basic technologies
Show what are the main problems and
how they can be solved
Show future directions and hot spots in
multicasting
3
This tutorial will…
explain how multicast can change the
way people use the Internet
present the main technologies behind
multicast, both at the routing and
transport level
state on the current deployment of
multicast technologies and the problems
encountered for large scale deployment
4
From unicast…
Sending same
data to many
receivers via
unicast is
inefficient
Popular WWW
sites become
serious
bottlenecks
Sender
data
data
data
data
data
data
Receiver
Receiver
Receiver
5
…to multicast on the Internet.
Not n-unicast from
the sender
perspective
Efficient one to
many data
distribution
Towards low
latence, high
bandwidth
Sender
data
router at branching
points perform
packet duplication
data
data
data
Receiver
Receiver
Receiver
6
New applications for the Internet
Think about…
high-speed www
video-conferencing
video-on-demand
interactive TV programs
remote archival systems
tele-medecine, white board
high-performance computing, grids
virtual reality, immersion systems
distributed interactive simulations/gaming…
7
A whole new world for multicast…
8
The delivery models (1)
model 1: streaming (e.g. for audio/video)
multimedia data requires efficiency due to its size
requires real-time, semi-reliable delivery
asynchronous
9
The delivery models (2)
model 2: push delivery
synchronous model where delivery is
started at t0
usually requires a fully reliable delivery,
limited number of receivers
Ex: synchronous updates of software
t0, tx starts...
transmission
receiver ready...
receiver ready...
time
ok, receiver leaves
ok, receiver leaves
10
The delivery models (3)
model 3: on-demand delivery
popular content (video clip, software,update, etc.)
is continuously distributed in multicast
users arrive at any time, download, and leave
possibility of millions of users, no real-time
constraint
time
receiver ready... ok, receiver leaves
receiver ready...
ok, receiver leaves
11
A very simple example in figures
File replication (PUSH) with ftp
10MBytes file
1 source, n receivers (replication sites)
512KBits/s upstream access
n=100
Tx= 4.55 hours
n=1000
Tx= 1 day 21 hours 30 mins!
12
A real example: LHC (DataGrid)
1 TIPS = 25,000 SpecInt95
Online System
~100 MBytes/sec
~PBytes/sec
Bunch crossing per 25 nsecs.
100 triggers per second
Event is ~1 MByte in size
Tier 1
~ 4 TIPS
France Regional
Center
PC (1999) = ~15 SpecInt95
Offline Farm
~20 TIPS
~100 MBytes/sec
~622 Mbits/sec
or Air Freight
Tier 0
UK Regional
Center
Italy Regional
Center
CERN Computer
Center > ~20 TIPS
Fermilab
~2.4 Gbits/sec
Tier 2
Tier2 Center
Tier2 Center
Tier2 Center
Tier2 Center Tier2 Center
~622 Mbits/sec
Tier 3
Institute
Institute Institute
~0.25TIPS
Physics data cache
Workstations
source DataGrid
100 - 1000
Mbits/sec
Institute
Physicists work on analysis “channels”.
Each institute has ~10 physicists working
on one or more channels
Data for these channels should be
cached by the institute server
13
Reliable multicast: a big win for
grids
Data replications
Code & data transfers,
interactive job submissions
SDSC IBM SP
1024 procs
5x12x17 =1020
224.2.0.1
Data communications for
distributed applications
(collective & gather
operations, sync. barrier)
NCSA Origin Array
256+128+128
5x12x(4+2+2) =480
Databases, directories
services
CPlant cluster
256 nodes
Multicast address group 224.2.0.1
14
Wide-area interactive simulations
computer-based
sub-marine simulator
display
INTERNET
battle field simulation
(x,y,z)
human in the loop
flight simulator
15
The challenges of multicast
SCALABILITY - SECURITY - TCP Friendliness - MANAGEMENT
SCALABILITY
SCALABILITY
SCALABILI
16
Part I
Getting started
Multicast BONE at the ENS Lyon
SDR (Session DiscoveRy)
18
Multicast on E-Toile (RNTL)
Demo June 5th,
2003 showing
multicast on
computational
grids
CEA
ROCQ
VTHD
ENS
CERN
source
19
Demo was successfull!
CERN
ENS
source
ENS
ENS
20
Part I
Basic of IP multicast model
IP multicast routing
A look back in history of multicast
History
Long history of usage on shared medium
networks
Resource discovery: ARP, Bootp.
1973
radio
network
1983
Ethernet
1985
1986
Bootp (RFC 951)
ARP (RFC 826)
Deering's work
IP multicast
(RFC 966, 988, 1054, 1112)
22
The Internet group model
multicast/group communications means...
1n
as well as
nm
a group is identified by a class D IP address
(224.0.0.0 to 239.255.255.255)
abstract notion that does not identify any host!
source
site 2
194.199.25.100
source
host_1
Ethernet
host_1
from logical view...
multicast router
host_2
receiver
multicast group
225.1.2.3
multicast router
...to physical view
host_3
host_2
receiver
133.121.11.22
receiver
194.199.25.101
site 1
Internet
receiver
multicast router
multicast distribution tree
host_3
Ethernet
23
The group model is an open model
anybody can belong to a multicast group
a host can belong to many different groups
no restriction
a source can send to a group, no matter
whether it belongs to the group or not
no authorization is required
membership not required
the group is dynamic, a host can subscribe
to or leave at any time
a host (source/receiver) does not know the
number/identity of members of the group
24
Example: video-conferencing
The user's perspective
224.2.0.1
Multicast address group 224.2.0.1
from UREC, http://www.urec.fr
25
What's behind the scene?
224.2.0.1
domain
peering point
access router
Internet router
26
IP multicast TODO list
Receivers must be able to subscribe to
groups, need group management facilities
A communication tree must be built from
the source to the receivers
Branching points in the tree must keep
multicast state information
Inter-domain routing must be
reconsidered for multicast traffic
Need to consider non-multicast clouds
good luck…
27
unicast island
TCP
routing
multicast island
?
incremental deployment
groups management
session advertising
tree construction
address allocation
duplication engine
forwarding state
routing
28
Multicast and the TCP/IP layered
model
Application
security
reliability
mgmt
user space
kernel space
congestion
control
other building
blocks
higher-level
services
Socket layer
TCP
ICMP
UDP
IP / IP multicast
IGMP
multicast
routing
device drivers
29
The two sides of IP multicast
local-area multicast
use the potential diffusion capabilities of the physical
layer (e.g. Ethernet)
efficient and straightforward
wide-area multicast
requires to go through multicast routers, use
IGMP/multicast routing/...(e.g. DVMRP, PIM-DM, PIM-SM,
PIM-SSM, MSDP, MBGP, BGMP, MOSPF, etc.)
routing in the same administrative domain is simple and
efficient
inter-domain routing is complex, not fully operational
30
IP Multicast Architecture
Service model
Hosts
Host-to-router protocol
Routers
Multicast routing protocols
31
Internet Group Management
Protocol (RFC 1112)
IGMP: “signaling” protocol
to establish, maintain,
remove groups on a subnet.
Objective: keep router upto-date with group
membership of entire LAN
Hosts
Routers
Routers need not know who all
the members are, only that
members exist
Each host keeps track of
which mcast groups are
subscribed to
Socket API informs IGMP
process of all joins
32
IGMP: subscribe to a group (1)
224.2.0.1
224.2.0.1
224.5.5.5
224.2.0.1
Host 1
Host 2
periodically sends
IGMP Query at 224.0.0.1
Host 3
empty
224.0.0.1 reach all multicast host on the subnet
33
IGMP: subscribe to a group (2)
somebody has
already
subscribed for
the group
224.2.0.1
Host 1
224.2.0.1
224.5.5.5
224.2.0.1
Host 2
Host 3
Sends Report
for 224.2.0.1
224.2.0.1
34
IGMP: subscribe to a group (3)
224.2.0.1
Host 1
224.2.0.1
224.5.5.5
224.2.0.1
Host 2
Host 3
Sends Report
for 224.5.5.5
224.2.0.1
224.5.5.5
35
Data distribution example
224.2.0.1
224.2.0.1
224.5.5.5
224.2.0.1
Host 1
Host 2
OK
Host 3
224.2.0.1
224.5.5.5
36
IGMP
Join
37
IGMP: leave a group (1)
224.2.0.1
224.5.5.5
224.2.0.1
Host 1
Host 2
Host 3
Sends Leave
for 224.2.0.1
at 224.0.0.2
224.2.0.1
224.5.5.5
224.0.0.2 reach the multicast enabled router in the subnet
38
IGMP: leave a group (2)
224.2.0.1
224.5.5.5
224.2.0.1
Host 1
Sends IGMP Query
for 224.2.0.1
Host 2
Host 3
224.2.0.1
224.5.5.5
39
IGMP: leave a group (3)
Hey,
I'm
still
here!
224.2.0.1
Host 1
224.2.0.1
224.5.5.5
Host 2
Host 3
Sends Report
for 224.2.0.1
224.2.0.1
224.5.5.5
40
IGMP: leave a group (4)
224.2.0.1
224.2.0.1
Host 1
Host 2
Host 3
Sends Leave
for 224.5.5.5
at 224.0.0.2
224.2.0.1
224.5.5.5
41
IGMP: leave a group (5)
224.2.0.1
224.2.0.1
Host 1
Host 2
Host 3
Sends IGMP Query for 244.5.5.5 224.2.0.1
42
IGMP
Leave
43
IGMP: leave a group (5)
224.2.0.1
224.2.0.1
Host 1
Host 2
Host 3
Sends IGMP Query for 244.5.5.5 224.2.0.1
44
OK, now I can express local
interest, so what?
224.2.0.1
Host 1
224.2.0.1
224.5.5.5
224.2.0.1
Host 2
Host 3
224.2.0.1
224.5.5.5
?
45
Does all paths lead to Roma?
source
46
Before going further…
Multicast on Ethernet LAN
How can a end-host get link-layer (MAC) packets?
Review of Ethernet filtering
By default, the Ethernet device listen on
its (Ethernet) MAC address fixed in a PROM
The broacast MAC address FF:FF:FF:FF:FF:FF
Other Ethernet addresses must be explicitely
programmed into the driver
For multicast, one must listen at:
the Ethernet-equivalent of 224.0.0.1 (all multicast host in
the LAN)
The Ethernet-equivalent address on which multicast
sessions are advertised
47
Mapping of IP multicast address
A MAC address is built from a mapping
of IP multicast addr (Deering88)
IP multicast address
1110
Group bit
28 bits
32:1 ratio
0000000100000000010111100
23 bits
Organizationally Unique Identifier (OUI, see RFC 1700 Assigned Number
Special OUI for IETF: 0x01-00-5E
LAN multicast address
48
224.x.y.z
Part I
Basic of IP multicast model
IP multicast routing
IP multicast routing
Find a tree (dedicated, shared) between the
source(s) and the receivers
Dense Mode
Assume that there are many many receivers willing
to get multicast traffic
Sparse Mode
Assume that the number of receivers is small.
Require an explicite query from the receivers.
50
Dense mode protocols, DVMRP
The Ancestor: DVMRP (Distance Vector
Multicast Routing)
Based on Reverse Path Forwarding (RPF)
A multicast router forwards packets received
from a link which is on the shortest path to the
source, and drops other packets
physical topology
source
R3
R2
R1
dropped
R4
dropped
R5
receiver
51
DVMRP... (cont’)
resulting multicast distribution tree
source
different sources lead to diff. trees
improves load distribution on the links
source
creates a spanning tree…
52
DVMRP... (cont’)
add “flood and prune” algorithm to
dynamically update the tree
step 1: flood the Internet (only limited by the packet’s TTL)
source
step 2: prune useless branches
“pruned”
receiver
“pruned”
source
PRUNE
PRUNE
Stop, no
receiver
here!
receiver
source
receiver
53
DVMRP... (cont’)
flooding/pruning is done periodically to
update the tree
required to discover new receivers and remove
branches to receivers who left the session
limitations:
creates signaling load (PRUNE message)
periodically creates important traffic (flooding)
all routers keep some state for all the multicast
groups in use in the Internet
54
DVMRP deployment
large scale deployment of DVMRP in the
MBONE (multicast backbone) since 1992
tunnels are set up to link “multicast
islands” through unicast areas
unicast only routers
source
R1
multicast routers
encaspsulation
dst = unicast @R2
R2
decaspsulation
receiver
multicast routers
55
Multicast tunnelling illustrated
IP x
IP multicast
router
IP a
IP a | IP b x|224.4.4.9
None IP multicast
router
x|224.4.4.9
None IP multicast
router
224.4.4.9 ?
IP multicast
router
IP b
x|224.4.4.9
224.4.4.9
56
The early MBone with tunnels
source K. Almeroth's paper. IEEE Networks Magazine, Vol.14(1)
57
Mixing tunnels and native multicast
source K. Almeroth's paper. IEEE Networks Magazine, Vol.14(1)
58
DVMRP on Linux: the mrouted daemon
59
DVMRP summary
it works but... this is far from perfect
periodical flooding creates a heavy load on routers/links
each multicast router must keep some forwarding state
for each group
tunneling quickly became anarchic
this is a flat architecture (the same protocol is used
everywhere)
conclusion: “dense mode protocols” like DVMRP
are not scalable enough for WAN multicast
routing
dense mode assumes a dense distribution of receivers,
wrong in practice!
60
DVMRP uses Source-based Trees
Router
S Source
R Receiver
R
R
S
R
S
R
Source Shivkumar Kalyanaraman
61
Moving to a Shared Tree
Router
S Source
R Receiver
R
R
S
RP
R
S
R
Source Shivkumar Kalyanaraman
62
Shared vs. Source-Based Trees
Source-based trees
Shortest path trees – low delay, better load
distribution
More state at routers (per-source state)
Efficient in dense-area multicast
Shared trees
Higher delay (bounded by factor of 2), traffic
concentration
Choice of core affects efficiency
Per-group state at routers
Efficient for sparse-area multicast
Source Shivkumar Kalyanaraman
63
Sparse mode protocols
The newcomers: PIM-SM/MSDP/MBGP
PIM-SM : Protocol Independent Multicast - Sparse Mode
MSDP: Multicast Source Discovery Protocol
MBGP: Multi-protocol Border Gateway Protocol
domain site, or ISP network
similar to “autonomous systems” of unicast routing
intra-domain mcast routing uses PIM-SM
inter-domain mcast routing requires MBGP
the discovery of sources in other domains requires
MSDP
64
PIM-SM Protocol Overview
Basic protocol steps
Routers with local members Join toward
Rendezvous Point (RP) to join shared tree
Routers with local sources encapsulate data
in Register messages to RP
Routers with local members may initiate
data-driven switch to source-specific
shortest path trees
PIM v.2 Specification (RFC 2362)
Source Shivkumar Kalyanaraman
65
PIM-SM: Build Shared Tree
Shared tree after
R1,R2 join
Source 1
Join message
toward RP
(*,G)
RP
(*,G)
(*,G)
(*,G)
(*,G)
(*,G)
Receiver 1
Receiver 2
Source Shivkumar Kalyanaraman
Receiver 3
66
Data Encapsulated in Register
Unicast encapsulated data packet to RP in Register
Source 1
(*,G)
RP
(*,G)
(*,G)
(*,G)
(*,G)
(*,G)
Receiver 1
Receiver 2
Receiver 3
RP de-capsulates, forwards down shared tree
Source Shivkumar Kalyanaraman
67
RP Send Join to High Rate Source
Shared tree
Source 1
Join message
toward S1
(S1,G)
RP
Receiver 1
Receiver 2
Source Shivkumar Kalyanaraman
Receiver 3
68
Build Source-Specific Distribution Tree
Shared Tree
Source 1
Join messages
(S1, G)
(S1,G),(*,G)
RP
(S1,G),(*,G)
(S1,G),(*,G)
Receiver 1
Receiver 2
Receiver 3
Build source-specific tree for high data rate source
Source Shivkumar Kalyanaraman
69
PIM-SM... (cont’)
moving to a per-source tree is efficient
for bulk data transfer, but has a higher
cost in case of multiple sources
one tree per source versus a single shared
tree
source
source
RP
receiver
source
from shared tree...
source
receiver
...to per-source tree
70
PIM-SM on Internet routers
PIM-SM is implemented on all major
Internet routers (CISCO, JUNIPER,
Alcatel AVICI, PROCKET…)
A linux package exists, see
http://netweb.usc.edu/pim/ (I haven’t
tried it yet)
71
Example: PIM-SM on VTHD
T640
Source doc VTHD
72
Configuration on CISCO routers
Enabling PIM
ip multicast-routing distributed
!
For each interface
interface XX/XX
ip pim sparse-dense-mode
!
Declaring the RP
IP addr of the RP
ip pim rp-address w.x.y.z
73
Ok, now I have a tree, so what?
?
RP
Sender
Receivers
74
MBGP for inter-domain connectivity
MBGP (MultiProtocol BGP, RFC 2283) is an extension to BGP4
to carry more than IPv4 route prefix (MP_REACH_NLRI)
Maintained a separate M(ulticast)-RIB
The internal domain’s topology is only known to the local MBGP
router
Each MBGP router only knows how to reach other multicast
domains
domain 1
MBGP
router
BGP
router
creation of inter-domain MBGP
topology running MBGP router
BGP
router
domain 3
BGP
router
MBGP
router
domain 2
75
BGP background (1)
From CISCO
76
BGP background (2)
From CISCO
77
BGP background (3)
From CISCO
78
Multiprotocol BGP
From CISCO
79
Ok, now I have inter-domain
routing, so what?
A
Where’s the sources? How can we discover them?
RP
Source
C
RP
B
D
RP
RP
80
MSDP for inter-domain src discov.
each domain runs PIM-SM with its own local
RP to avoid third-party dependency
problem: how can a receiver in a domain be
informed of a source located in another
domain... with MSDP!
domain 1
source
RP1
receiver
new source detected
MSDP
peer
MSDP
peer
source active (SA)
message
domain 3
RP2
receiver
MSDP
peer
domain 2
81
How MSDP works with PIM-SM
A
SA
RP
Source
C
D
SA
Join
B
Join
RP
RP
Join
Join
Join
Receiver
RP
SA
Source Shivkumar Kalyanaraman
MSDP peer
PIM message
Physical link
MSDP message
82
Example: MBGP/MSDP on VTHD
RP’s address is announced with MBGP
External active sources are discovered
with MSDP
Border Router
Source doc VTHD
83
MSDP… (cont’)
problem with some applications
reducing the join latency requires using a cache in each
peer of active sources
follows a soft-state model, where entries must be
periodically refreshed
does not work with low frequency bursty applications
soft-state is lost each time a packet sent… receivers never
get any packet
limited scalability in terms of nb groups
each peer informs every other peer of local sources, and
everybody knows everything !
84
Conclusions PIM-SM/MBGP/MSDP
works, currently operational
deployed in VTHD (http://www.vthd.org)
deployed in the GEANT European network
http://www.dante.net/nep/GEANT-MULTICAST/
but this is not the long term solution...
high signaling load for dynamic groups
problems with low frequency bursty applications
limited scalability with the number of groups
long term solution may be quite different...
85
Single-Source Multicast (SSM)
Source-specific channel (S,G)
only S can send to G
another source S’ must use a
separate channel (S’,G)
hosts join channels, so a
member joining only (S,G) will
NOT receive traffic from S’
(S,G)
(S’,G)
Current infrastructure uses
Any-Source Multicast (ASM)
any source can send to any
group at any time
Source Shivkumar Kalyanaraman
86
Why SSM?
Network Operator
trivial address allocation (16 million addresses per
host)
no network-layer source discovery (PIM RP and/or
MSDP moved to the application layer)
overcomes two significant obstacles to deployment
Content Provider
exclusive access to multicast groups (no
interruptions)
permanent multicast groups (easy to advertise)
provides better service
Source Shivkumar Kalyanaraman
87
How SSM Works
A
Source
C
D
Join
B
Join
Join
Join
Join
Join
Receiver
PIM message
Physical link
Source Shivkumar Kalyanaraman
88
SSM Advantages (cont’d)
No RP, No need for MSDP
All joins are (S,G), so no need for Class D address
allocation
More security
Receivers find out about sources through out-of-band
means (such as a web site)
SSM-only implementations are much simpler than the
full PIM-SM
No RP, No Bootstrap RP Election
No Register state machine
No need to keep (*,G), (S,G,rpt) and (*,*,RP) state
No (*,G) Assert State
Source Shivkumar Kalyanaraman
89
Source specific multicast... (cont’)
works with limited modifications of
current protocols
use IGMPv3 in hosts and 1st hop routers
use a modified version of PIM-SM (no RP, use
directly to the per-source tree)
probably the future of IP Multicast
routing…
unless the importance of many-to-many
applications overwhelms SSM?
90
Part II
Introducing reliability
End-to-end solutions
FEC-based solutions
Layered solutions
Router-assisted solutions
The Wild Wild Web
UDP data
heterogeneity,
link failures,
congested routers
packet loss,
packet drop,
bit errors…
?
92
Reliability Models
Reliability => requires redundancy to recover
from uncertain loss or other failure modes.
Two types of redundancy:
Spatial redundancy: independent backup copies
Forward error correction (FEC) codes
Problem: requires huge overhead, since the FEC is also
part of the packet(s) it cannot recover from erasure of all
packets
Temporal redundancy: retransmit if packets
lost/error
Lazy: trades off response time for reliability
Design of status reports and retransmission optimization
important
93
Temporal Redundancy Model
Packets
Timeout
Status Reports
• Sequence Numbers
• CRC or Checksum
• ACKs
• NAKs,
• SACKs
• Bitmaps
Retransmissions
• Packets
• FEC information
94
Part II
Introducing reliability
ACK/NACK end-to-end solutions
FEC-based solutions
Layered solutions
Router-assisted solutions
End-to-end reliability models
Sender-reliable
Sender detects packet losses by gap in ACK
sequence
Easy resource management
Receiver-reliable
Receiver detect the packet losses and send
NACK towards the source
96
Challenge: scalability (1)
many problems arise with 10,000 receivers...
Problem 1: scalable control traffic
ACK every 2 packets (à la TCP)...oops, 10000ACKs / 2 pkt!
NAK (negative ack) only if failure... oops, if pkt is lost
close to the source, 10000 NAKs!
source
source implosion!
97
Challenge: scalability (2)
problem 2: scalable repairs/exposure
receivers may receive several time the same
packet
98
A piece of the solutions (1)
solutions to problem 1: scalable control traffic
solution 1: feedback suppression at the receivers
solution 2: proactive FEC (forward error
correction)
each node picks a random backoff timer
send the NAK at timeout if loss not corrected
send data plus additional FEC packets
any FEC packet can replace any lost data packet
solution 3: use a tree of intelligent routers/servers
use a tree for ACK aggregation and/or NAK suppression
PGM, ARM, DyRAM
99
A piece of the solutions (2)
solutions to problem 2: scalable repairs
solution 1: use TTL-scoped retransmissions
solution 2: use proactive/reactive FEC
repair packets have limited scope
proactive: always send data + FEC
reactive: in case of retransmission, send FEC
solution 3: use a tree of retransmission servers
a receiver can be a retransmission server if he has the
requested data
100
Scalable Reliable Multicast
Floyd et al., 1995
Receiver-reliable, NACK-based
NACK local suppression
Delay before sending
Based on RTT estimation
Deterministic + Stochastic
Every member may multicast NACK or
retransmission
Periodic session messages
Sequence number: detection of loss
Estimation of distance matrix among members
101
SRM Request Suppression
Src
from Haobo Yu , Christos Papadopoulos
102
SRM Request Suppression
Src
next packet
from Haobo Yu , Christos Papadopoulos
103
SRM Request Suppression
Src
from Haobo Yu , Christos Papadopoulos
104
SRM Request Suppression
Src
each node picks a
random backoff timer
from Haobo Yu , Christos Papadopoulos
105
SRM Request Suppression
Src
each node picks a
random backoff timer
from Haobo Yu , Christos Papadopoulos
each node picks a
random backoff timer
106
SRM Request Suppression
Src
each node picks a
random backoff timer
each node picks a
random backoff timer
each node picks a
random backoff timer
from Haobo Yu , Christos Papadopoulos
107
SRM Request Suppression
Src
from Haobo Yu , Christos Papadopoulos
108
SRM Request Suppression
Src
from Haobo Yu , Christos Papadopoulos
109
SRM Request Suppression
Src
from Haobo Yu , Christos Papadopoulos
110
SRM Request Suppression
Src
from Haobo Yu , Christos Papadopoulos
111
SRM Request Suppression
Src
from Haobo Yu , Christos Papadopoulos
112
Deterministic Suppression
Time = T1
Time = T2
A
B
Time = T4
Time = T3
distance = (T4 - T3 + T2 - T1) / 2
3d
d
data
time
2d
session msg
d
d
d
nack
3d
repair
= sender
= repairer
d
4d
d
from Haobo Yu , Christos Papadopoulos
Delay = C1dS,R
= requestor
113
Simple TTL-scoped of repairs
use the TTL field of IP packets to limit
the scope of the repair packet
Src
TTL=1
TTL=2
TTL=3
114
Summary: reliability problems
What is the problem of loss
recovery?
feedback (ACK or NACK)
implosion
Design goals
reduce the feedback
traffic
reduce recovery latencies
improve recovery isolation
replies/repairs duplications
ACK/NACK aggregation
based on timers are
approximative!
TTL-scoped retransmissions
are approximative!
Heterogeneity of receivers
(crying baby, congestion
control)
difficult adaptability to
dynamic membership changes
115
Part II
SKIP
Introducing reliability
ACK/NACK end-to-end solutions
FEC-based solutions
Layered solutions
see ICT 03 Tutorial
Router-assisted solutionshttp://www.ens-lyon.fr/~cpham
•
•
•
••
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
••
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
10 human years (means much more in computer year)
•
•
Application-based
•
•
•
•
•
•
•
••
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
RMX •
•
•
•
•
•
•
•
•
••
•
•
•
•
•
•
•
•
…
•
•
•
•
•
•
••
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
NARADA
•
•
•
•
•
•
MTP
•
•
•
•
•
•
••
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
••
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
••
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
AFDP
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
RMDP
•
•
•
• •
•
•
•
•
•
•
••
••
•
•
•
•
•
•
•
•
•
•
•
•
PGM
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
AER•
•
•
•
•
•
•
•
•
•
•
•
•
•
RMANP
•
•
•
•
•
•
•
•
••
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
••
•
•
•
•
•
•
•
ARM
•
•
•
ALC/LCT
•
••
•
•
•
•
•
•
•
•
•
•
•
•
•
•
••
DyRAM
•
•
•
••
•
•
•
•
•
•
•
•
•
•
Layered/FEC
•
•
•
•
•
•
•
••
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
• •
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
••
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
••
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
LBRM
•
•
XTP
•
••
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
RMF
•
••
•
•
•
•
•
•
•
•
•
•
Router assisted,
active networking
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
••• •
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
SRM
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
••
•
•
•
•
•
•
•
LMS
•
•
•
•
••
•
•
•
•
End to End
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
RMTP •
•
•
•
•
•
•
•
•
•
•
•
••
•
•
•
•
•
•
•
•
•
•
TRAM
••
•
•
•
•
•
•
•
•
•
•
•
•
••
•
•
•
•
•
•
•
••
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
Logging server/replier
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
The
reliable
multicast
universe
•
•
•
•
•
••
•
•
•
•
Part III
Status and Deployment of
Multicast Technologies
Academics vs Users
Multicast has been
around for more
than a decade, and
we've proposed
many protocols!
Yes, but very few real
applications have
been deployed on the
Internet!
SRM, DVMRP
CBT, RMTP,
LMS, MOSPF,
MBGP, PIM-DM,
MSDP, IGMP,
RPM, HBH,
LBRM,
DyRAM…
119
unicast island
multicast island
?
TCP
routing
inter-domain routing
tunnelling
security
congestion control
incremental deployment
groups management
session advertising
tree construction
address allocation
duplication engine
forwarding state
routing
Connecting the two world
is difficult!
120
Inter-domain agreement
BGP
domain
MBGP
peering point
access router
INTERNET
Internet router
121
Users' accesses
PSTN 56Kbps
ADSL 128/512 Kbps
Cable shared 10Mbps
ISDN 128Kbps
…
offices
residentials
OC-3
Network
Provider
metro ring
OC-3
OC-12
Internet
Data
Center
2Mbps, FR
OC-12
OC-3
campus
Network Provider
100BaseTX
CORE NETWORK
Gbps, DWDM
small offices
122
Links heterogeneity
Backbone links
optical fibers
2.5 to 160 Gbps with DWDM techniques
End-user access
9.6Kbps (GSM) to 2Mbps (UMTS) V.90
56Kbps modem on twisted pair
64Kbps to 1930Kbps ISDN access
128Kbps to 2Mbps with xDSL modem
1Mbps to 10Mbps Cable-modem
155Mbps to 2.5Gbps SONET/SDH
123
Internet routers: key elements of
internetworking
Routers
run routing protocols and build
routing table,
receive data packets and
perform relaying,
may have to consider Quality of
Service constraints for
scheduling packets,
are highly optimized for packet
forwarding functions.
124
Multicast in Points of Presence
POP2
A
POP1
POP4
B
C
source N. McKeown
POP3
E
POP5
POP6
POP7
D
POP8
F
125
Multicast, a threat for highperformance routers!
Please!
Don't turn
multicast
ON!
126
The open model
no-security
CONTRACT
Can not control sources
Can not control receivers
Can not control groups
Can not control traffic
Please sign
?
127
BGP table size
source www.multicasttech.com/status
128
MBGP table size
BGP ~118000
source www.multicasttech.com/status
129
Relative Size of the Multicast
Enabled Internet
source www.multicasttech.com/status
130
The gap in images
INTERNET
multicast AS
unicast AS
131
Autonomous Systems in the Multicast Enabled
Internet: Totals and Those With Active
Sources
~33%
source www.multicasttech.com/status
132
Last solution…
if you don't have access to IP Multicast you could try
using:
Overlays, End-system Multicast, Host-level, Application-level
Multicast
MIT1
MIT
Berkeley
MIT2
UCSD
CMU1
CMU
CMU2
Berkeley
MIT1
Overlay Tree
MIT2
UCSD
CMU1
source Yang-hua Chu
CMU2
133
Conclusions (1)
Multicast: a technology with high potential…
… but also awfully complex !
Technology starts to be mature:
problems are well known and some protocols are
already standardized (ALC family)
ACK/NACK protocols are on the way to
standardization (takes more time as problems are
tougher)
does not prevent the use of private reliable
multicast solutions
134
Conclusions (2)
Deployment is mainly driven by academic
networks…
where are the killing applications ?
video and popular content distribution to
clients… yes
high performance computing over
datagrids… yes
Where should we go?
More specific models (i.e. SSM),
More security, more control
135