Somecast a paradigm for real time adaptive reliable multicast
This presentation is the property of its rightful owner.
Sponsored Links
1 / 18

SomeCast A Paradigm for Real-Time Adaptive Reliable Multicast PowerPoint PPT Presentation


  • 72 Views
  • Uploaded on
  • Presentation posted in: General

SomeCast A Paradigm for Real-Time Adaptive Reliable Multicast. Presented by: Ibrahim Matta IEEE Real-Time Technology and Applications Symposium (RTAS ‘2000), May 30 – June 2, 2000, Washington D.C. Joint work with Jaehee Yoon and Azer Bestavros Computer Science Department Boston University

Download Presentation

SomeCast A Paradigm for Real-Time Adaptive Reliable Multicast

An Image/Link below is provided (as is) to download presentation

Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.


- - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - -

Presentation Transcript


Somecast a paradigm for real time adaptive reliable multicast

SomeCastA Paradigm for Real-Time Adaptive Reliable Multicast

Presented by: Ibrahim Matta

IEEE Real-Time Technology and Applications Symposium (RTAS ‘2000), May 30 – June 2, 2000, Washington D.C.

Joint work with Jaehee Yoon and Azer Bestavros

Computer Science Department

Boston University

{matta, jaeheey, [email protected]


The somecast paradigm

The SomeCast Paradigm

Network is

best-effort

e.g., Internet

QoS requirements

- reliability

- timeliness

  • Real-Time data

  • stocks

  • auctions

  • Data encoding is distributed to proxies (senders)

  • Sender multicasts its data

  • Client (receiver) joins as many multicast groups as needed

  • to reliably recover data by its deadline


Why a new paradigm

Why a New Paradigm?

  • RTP/UDPtrades reliability for timeliness

  • ARQtrades timeliness for reliability

    - e.g., TCP for unicast, SRM for multicast

  • Deadline-aware ARQimproves timeliness, butdoes not hide congestion-induced delays

    - e.g., Li, Ha and Varghavan work on TCP

  • FECapproaches are not deadline-aware

    - e.g., SHARQFEC of Kermode, our ARM


Why a new paradigm1

SomeCast accesses SOME servers basedon

current network state and client’s deadline

Why a New Paradigm?

  • AnyCastselects “best” server

    - e.g., Fei, Bhattacharjee, Zegura and Ammar

  • ManyCastaccesses replicated servers concurrently

    - e.g., work of Byers, Luby and Mitzenmacher


Somecast features

SomeCast Features

  • Supports Real-Time ReliableMulticast

  • Receiver-initiated, thus scalable in

    - number of receivers

    - diverse path characteristics and conditions

  • Meet QoS while conserving resources

    - receiver joins SOME concurrent multiCAST sessions

    - approaches AnyCast when deadline is loose

    - approaches ManyCast when deadline is stringent


Fec dispersal and reconstruction

FEC Dispersal and Reconstruction

  • Source employs FEC (e.g., Reed-Solomon Codes)

  • Original K data packets are dispersed into s K packets;

  • s > 1 is “stretch” factor

  • Receiver reconstructs original data by recombining

  • any K packets


A somecast protocol overview

A SomeCast Protocol: Overview

  • s K encoded packets distributed to senders

  • Sender multicasts data as long as one or more receivers are members of its group

  • Initially, a receiver joins one or more groups

  • Receiver periodically estimates its throughput from each sender

  • Receiver adjusts number of groups it is a member of based on number of packets it expects to receive by its deadline


Somecast receiver

SomeCast Receiver

  • Receiver maintains number of packets received from each sender

  • When K packets are received by deadline, receiver decodes data and leaves all groups it is a member of

  • Receiver periodically updates its throughput estimate from each sender

  • Receiver estimates number of packets expected from each sender by the deadline:

    expPkts = Throughput x (Deadline - now)


Somecast receiver cont d

K = 20 pkts

Received

8+5+2=15 pkts

Received 8 pkts

Member of S1 with

thruput 100 pkt/s

Deadline

100 ms

time

Join S2

(thruput 40 pkt/s)

Expects 5 more pkts

from S1 and 2 from S2

Received 22 pkts

(successful recovery)

SomeCast Receiver (cont’d)

  • Receiver computes total number of packets it expects from senders it is subscribed to

  • Receiver joins additional sender(s), or leaves redundant sender(s)


Somecast extensions

SomeCast Extensions

  • Selection of the best set of senders

    - static and dynamic measures, e.g., distance,

    congestion, load

  • TCP-friendly transmission by senders

    - even if sender reduces its rate, a receiver can

    recover by joining more senders


Simulation model

Simulation Model

  • SomeCast compared against UniCast and ManyCast using ns simulator

  • UniCast: receiver only joins primary sender

  • ManyCast: receiver joins all senders all the time

  • SomeCast-1

    - receiver starts with one sender (the primary)

  • SomeCast-N

    - receiver starts with all N senders


Simulation model cont d

Simulation Model (cont’d)

  • Senders are CBR, N = 5

  • Up to 32 on-off cross

  • connections on each link,

  • up to 30% loss rates at receivers

  • 1 MB original data, K=1000 packets

  • Each sender has 2K encoded packets

  • Simulation stopped when every receiver

  • receives K packets by deadline, or

  • simulation clock exceeds deadline


Performance metrics

Performance Metrics

  • Guaranteed Deadline Percentage

    - percentage of receivers which successfully

    received K packets by deadline

  • Goodput

    - ratio of useful packets received to packets sent

  • Average Number of Groups Joined

    - average number of groups that a receiver joins


Performance vs laxity

Performance vs Laxity

  • SomeCast strikes a good balance

  • - approaches ManyCast at lower laxities

  • - approaches UniCast at higher laxities


Number of groups vs laxity

Number of Groups vs Laxity

  • SomeCast receiver adapts number of groups

  • to which it subscribes depending on deadline


Effect of update frequency in somecast 1

Effect of Update Frequency in SomeCast-1

  • With more frequent updates, a receiver can adjust its

  • level of service in a more timely fashion

  • SomeCast-1 receiver can join more senders at lower laxities


Effect of update frequency in somecast 5

Effect of Update Frequency in SomeCast-5

  • With more frequent updates, especially at higher laxities,

  • a receiver can leave redundant groups in a timely fashion


Conclusions

Conclusions

  • SomeCast paradigm supports

    - reliable multicast of real-time data

    - a large set of heterogeneous receivers

  • Receiver-initiated, thus scalable in

    - number of receivers

    - diverse path characteristics/conditions

  • SomeCast performance

    - superior to ManyCast and AnyCast


  • Login