Network Multicast

1. NetworkMulticast Prakash Linga

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

3. Motivation • Why Multicast? • Reduce network and host overhead for multi-destination delivery • Interesting applications • Conferencing etc

4. Ideal Multicast Protocol • Scalable • Reliable • Low join and data propagation latency • Easy to join and leave groups • Robust unknown destination delivery

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

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

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

8. SSTM(2) Bridges maintain a table. Table entry: (Address, (outgoing_branch, age), … )

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

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

11. Multicast Protocols for WANs • IP multicast • SRM (Scalable Reliable Multicast) • RMTP (Reliable Multicast Transport Protocol) • PGM (Pragmatic General Multicast) • Bimodal multicast (Next class)

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

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

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

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

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

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

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

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

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

21. RMTP • Uses DRs to avoid ACK implosion. • DR caches received data, processes and emits ACKs. • DRs statically chosen for a given multicast session.

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

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

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

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

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

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

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

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

30. PGM(4) • “Repeated Retransmission”

31. Next Class • Probabilistic approach (Ex: Bimodal Multicast)