Network

Multicast

Prakash Linga

Last ClassCOReL: Algorithm for totally-ordered multicast in an asynchronous environment, in face of network partitions and process failures.

MotivationWhy Multicast?

Reduce network and host overhead for multi-destination delivery

Interesting applicationsConferencing 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 topologyOr 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 multicastSRM (Scalable Reliable Multicast)RMTP (Reliable Multicast Transport Protocol)PGM (Pragmatic General Multicast)Bimodal multicast (Next class)

IP MulticastTransmission 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 multicastIf 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.

SRMALF (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 deliveryMost operators are idempotent except some like delete.A receiver uses timestamps on the drawing operations to determine the rendering orderThis 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 lossesEstimate 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 parametersThese parameters could be chosen based on topology and n/w conditionsPartitioning 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

RMTPUses 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 basedRetransmission is either unicast or multicast based on the number of errorsLagging 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 receiverTo 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 rateProvides sender and receiver with the

required connection parametersChooses 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.

PGMWorkable 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 multicastSource 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)