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 multi- destination 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 T expire 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 T ack 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 W s <= W r 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)