Download Network Multicast

Network Multicast
Prakash Linga
Last Class
COReL: Algorithm for totally-ordered
multicast in an asynchronous environment, in
face of network partitions and process
failures.
Motivation
Why Multicast?

Reduce network and host overhead for multidestination delivery
Interesting applications

Conferencing etc
Ideal Multicast Protocol
Scalable
Reliable
Low join and data propagation latency
Easy to join and leave groups
Robust unknown destination delivery
Multicast Protocols for a
LAN
LANs like Ethernet support


Efficient broadcast delivery
Large space of multicast addresses
Extended LANs pose interesting problems
like



Additional routing and traffic costs may limit Scalability
Low delay, delivery with high probability etc difficult to achieve
Extension to routing to support multi-destination delivery
Multicast routing Protocols
for WANs
Extending some unicast routing
protocols ?
Single spanning tree routing (of extended LAN
bridges)
 Distance vector routing (used in internetworks)
 Link state routing (used in internetworks)

Single-Spanning-Tree multicast
routing
Bridges restrict all traffic to a spanning
tree by
forbidding loops in the physical topology
 Or running a distributed algorithm among the
bridges to compute a spanning tree

If groups members periodically issue
membership packets then the bridges
could learn the branches leading to the
group members
SSTM(2)
Bridges maintain a table. Table entry:
(Address, (outgoing_branch, age), … )
SSTM (3)
If a packet arrives with a
Multicast source address(?): record the arrival branch
and an associated age of zero in a table entry for that
multicast address
 Multicast destination address: Forward a copy of the
packet out every out-going branch (except the arrival
branch) recorded in the corresponding table entry (if
absent discard the packet).

SSTM(3)
Periodically increment the age fields of
all multicast table entries.
If an age field reaches an expiry
threshold Texpire delete the associated
outgoing-branch from the table entry.
If no outgoing-branches remain, delete
the entire entry.
Multicast Protocols for
WANs
IP multicast
SRM (Scalable Reliable Multicast)
RMTP (Reliable Multicast Transport
Protocol)
PGM (Pragmatic General Multicast)
Bimodal multicast (Next class)
IP Multicast
Transmission of IP datagram to a host
group
Best-effort delivery (neither the delivery
nor the order is guaranteed)
Membership of a host group is dynamic.
Host group may be permanent or
transient
IP Multicast(2)
Multicast routers handle forwarding of IP
multicast datagrams.
Host transmits an IP multicast datagram as a
local network multicast
If TTL > 1 then multicast router(s) forward it to
other networks that have members of the
destination group.
Attached multicast router completes delivery
of the datagram as a local multicast.
SRM
ALF (Application Level Framing) + LWS
(Light-Weight Sessions)
ALF: includes application semantics in the
design of that application’s protocol.
Assumptions made in wb’s reliable multicast
design




Data names unique and persistent
Source-ID’s are persistent
There is no distinction between senders and receivers
IP multicast datagram delivery is available
SRM(2)
No requirement for ordered delivery
Most operators are idempotent except
some like delete.
A receiver uses timestamps on the
drawing operations to determine the
rendering order
This captures temporal causality at a
level appropriate for the application.
SRM(3)
Each member sends periodic session
messages. These are required to:
Advertise sequence number of active page
for active sources
 Determine current participants of the
session
 Detect losses
 Estimate one-way distance between nodes

SRM(4)
When Host A detects a loss it schedules a
repair request at a random time in future.
When request timer expires A sends a
request for missing data and doubles the
request timer to wait for the data
When Host B receives a request, makes a
randomized wait and multicasts the repair
data unless it receives the repair during this
period.
SRM(5)
Wait periods are randomly chosen from a
uniform distribution on an interval.
Interval length is dependent on one-way
delay and some parameters
These parameters could be chosen based on
topology and n/w conditions
Partitioning and normal departure are
indistinguishable.
No ordering guaranteed.
SRM(6): Extreme Topologies
Deterministic suppression:
•exactly one NACK;
•exactly one repair.
Probabilistic suppression:
•at most g-1 requests
•as the length of the interval
is increased expected no. of
requests decreases but expected
delay increases.
SRM(7)
Performance much better if local recovery is
possible (no need to multicast to everybody).
Solutions:
•TTL-based scoping
•Separate multicast group for recovery
•Administrative scoping
RMTP
Uses DRs to avoid
ACK implosion.
DR caches received
data, processes and
emits ACKs.
DRs statically
chosen for a given
multicast session.
RMTP(2)
After initial setup sender starts transmitting
data.
On receiving a data packet receiver starts
emitting ACKs at Tack interval.
Connection termination is timer based
Retransmission is either unicast or multicast
based on the number of errors
Lagging receivers can catch up by sending
immediate transmission requests
RMTP(3)
Window-based flow
control mechanism
Ws <= Wr
Senders window
advance is determined
by the slowest receiver
To avoid redundant
transmission ACKs
should not be sent
frequently. Solution:
Measure RTT to AP
dynamically.
RMTP(4)
Receivers can join any time. Need to buffer
entire file during the session. A two-level
cache mechanism is used
Experiencing congestion: Decreases
congestion window size (to 1 in the worst
case). Later increases it linearly.
Receiver dynamically chooses a DR as its AP
(least upstream in the multicast tree).
RMTP(5)
Session Manager
Detects network partitioning and node crashes and
takes necessary actions
 Sets the maximum transmission rate
 Provides sender and receiver with the required
connection parameters
 Chooses DRs

RMTP(6)
Scalable because
State information at each node is independent of
number of nodes.
 Receiver driven approach.
 Uses DRs to distribute responsibilities of process
ACKs and performing retransmissions.

Reliable delivery not guaranteed when
nodes voluntarily or involuntarily leave a
multicast group.
PGM
Workable solution for multicast applications
with basic reliability requirements!
Receiver either receives all data packets from
transmissions and repairs, or is able to detect
unrecoverable data packet loss.
No notion of group membership. Members
may join and leave anytime.
Use NACKs for repair and reliability. But
dispense with PACK and use alternate buffer
management strategies (like timeouts).
PGM(2)
Runs over a datagram multicast protocol like
IP multicast
Source multicasts sequenced data packets
and receivers unicast selective NACKs
(repeats until it receives a NCF).
N/W elements forward NAKs hop-by-hop
to the source and confirm each hop by
multicasting a NCF.
Repairs provided by the source or
Designated Local Repairer in response to
a NAK.
PGM(3)
Source path messages (SPMs) are used by a
source to establish source path state in n/w
elements.
This ensures that NAKs returns from a
receiver to a source on the reverse of the
distribution path.
Only one NACK per (receiver, packet) is
propagated upwards.
Sender or DLR sends RDATA in response to
a NACK. RDATA retraces the path of NACKs.
PGM(4)
“Repeated Retransmission”
Next Class
Probabilistic approach (Ex: Bimodal
Multicast)