Network Multicast

1
Network Multicast

• 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 gt 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 applications protocol.
• Assumptions made in wbs reliable multicast
  design
• Data names unique and persistent
• Source-IDs 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 lt 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)