PeerBased Recovery Strategy for Reliable Multicast Transport Protocol RMTP

1
Peer-Based Recovery Strategy for Reliable
Multicast Transport Protocol (RMTP)

• Clariza M. Lu, BS Math
• MSCS Thesis Proposal
• Adviser Dr. Cedric Angelo Festin

2
Multicasting

• Simultaneous delivery of packets from a sender to
  a selected group of recipients
• Can dramatically reduce network bandwidth
• Applications Live Conferencing (Audio and
  Video, Software Upgrade Distribution, White Board
  Collaboration Applications, Distributed Databases.

3
Multicasting
Unicast Implementation
Source
4
Multicasting
Ideal Implementation
Source
5
Real Time vs. Reliable Multicast
Real Time
Reliable

• Requires total reliability with the expense of
  delay
• Software Upgrade Distribution, White Board
  Collaboration Applications

• Cannot allow delays but can tolerate some data
  loss
• Live Feed/ Conferencing (Audio and Video)

6
Reliable Multicasting Issues

• Acknowledgment Implosion Effect
• Maintaining an updated list of receivers
• Congestion Control
• Efficient Recovery Mechanisms
• Support of Late Joins

7
Error Detection

• Sender-reliable
• Wait for ACKs from all receivers.
• Easy resource management
• - Not Scalable ACK implosion Solution

• Receiver-reliable
• Receivers NACK loss packets
• Less work for sender
• - NACK implosion

8
Recovery Schemes

• Sender-based
• Peer-Based
• Server-Based (Representative)

9
Reliable Multicast Protocols

• Reliable Multicast Transport Protocol (RMTP)
• Scalable Reliable Multicast (SRM)
• Pragmatic General Multicast (PGM)
• Log-Based Receiver-reliable Multicast (LBRM)
• Reliable Multicast Protocol (RMP)
• STructure Oriented Resilient Multicast (STORM)
• Tree-based Multicast Transport Protocol (TMTP)
• Distance Vector Multicast Routing Protocol
  (DVMRP)
• Protocol Independent Multicasting (PIM)
• Multicast Open Shortest Path First (MOSPF)
• Core-Based Trees (CBT)

10
Scalable Reliable Multicast (SRM)

• Uses the concept of Application Level Framing
• Designed to meet only the minimal definition of
  reliable multicast eventual delivery of all
  data to all the group members, without enforcing
  any particular delivery order
• Best-effort with possible duplication and
  re-ordering of packets and builds reliability
  on an end-to-end basis
• Prototyped in WB, a distributed whiteboard
  application

11
Scalable Reliable Multicast (SRM)

• Transmit
• Each source uniquely names a data segment and
  multicast it
• Send Status
• Each receiver is responsible for detecting lost
  segment and requesting retransmission (loss
  through sequence number)
• On loss detection by Rx, a repair-request is
  scheduled
• On expiry of the timer the repair-request is
  multicast
• If a repair request for the lost packet is
  received by Rx, the Rx resets its timer and does
  an exponential back-off

12
Scalable Reliable Multicast (SRM)

• Retransmit
• When Ry receives the repair request, it schedules
  a retransmission
• If another receiver retransmits the packet, Ry
  cancels the packet, otherwise, Ry retransmit the
  packet
• Session Messages are used to estimate RTT

13
Scalable Reliable Multicast (SRM)

• Ideal execution on packet loss
• Only one receiver will send the repair request
• Only one receiver will multicast the loss packet
• Worst Case
• The repair request takes time to reach all
  receivers several repair request may be sent
  resulting in NACK implosion
• Several retransmission may occur
• Conclusion Timers have to be set-up very
  accurately

14
Pragmatic General Multicast (PGM)

• Experimental protocol introduced in 1998 as an
  internet draft
• Formerly known as Pretty Good Multicast
• Intended as a workable solution for multicast
  applications with basic reliability requirements
• Central design goal is simplicity of operation
  with due regard for scalability and network
  efficiency

15
Pragmatic General Multicast (PGM)

• Loss Detection
• NACK Suppression
• Receivers detect lost packets and unicast a NAK
  for each missing packet to the next-hop upstream
  PGM network element
• Multicasts a NAK Confirmation (NCF) to confirm
  the receipt of a NAK across a single PGM hop
• NACK Elimination
• By multicasting the NCF, other receivers see it
  and suppress their NAKs

16
Pragmatic General Multicast (PGM)

• Loss Recovery
• Local Repair
• Any receiver that receives an NCF for which it
  has the corresponding requested data may
  multicast that data.
• Designated Local Re-transmitter (DLT)
• A dedicated host function configured to act as a
  re-transmitter for selected groups in which it
  must also act as a receiver.

17
RMTP

• developed by John Lin and Sanjoy Paul
• first protocol to propose using a hierarchical
  structure to achieve scalability.
• uses a receiver-driven approach to manage
  reliability
• Introduces Designated Receivers or DRs

18
RMTP
19
RMTP Packet Types
20
RMTP Components
21
Tracer Protocol

• Allows receivers to discover if they share a
  common path
• Provides requester and re-transmitter with the
  exact name of the last router common to both
• Enables deterministic grouping of receivers with
  exact packet loss correlation
• Allows only acceptable relationships between
  re-transmitters and requesters
• Relies on MTRACE
• Built in in IGMP
• Allows hosts to trace its path from the source
  for a specified number of hops
• MTRACE query traverses each router to
  receiver-to-source order

22
RMTP Recovery Scheme
S
DR
DR
Received Window Status
Retransmission
23
SRM Recovery Scheme
Repair Request
Retransmission
24
PGM Recovery Scheme
S
DLR
NACK
NCF
Retransmission
25
Statement of the Problem

• To study the cost of having additional
  "neighbor" information per receiver and the
  benefits of having these neighbors help the
  acknowledgment processors in retransmissions and
  immediate transmissions for late joins on a
  protocol based on RMTP.

26
Proposed Solution

• Recovery Retransmission Requests
• Use Tracer protocol for getting neighbor
  information
• Retransmission requests scope limited using hop
  count
• Sent via unicast
• Retransmitter pool qualification criteria
• Must not be downstream relative to the DR
• RTT relative to neighbor must be a fraction of
  the RTT relative to DR

27
Proposed Solution

• Recovery Retransmission of Lost Packets
• Deterministic
• Multicast to all downstream hosts
• Unicast to requester

28
Methodology

• Study Protocol Mechanism
• Design Recovery Mechanisms
• Model Protocols
• Develop Test Cases
• Implement Test Cases
• Data Analysis and Performance Evaluation

29
Timeline

• Activity 1 - Study Protocol Mechanism
• Activity 2 - Design Recovery Mechanisms
• Activity 3 - Model Protocols
• Activity 4 - Develop Test Cases
• Activity 5 - Implement Test Cases
• Activity 6 - Data Analysis and Performance
  Evaluation
• Activity 7 - Documentation

30
Thank You!