copyright © 1998 sun microsystems, inc. sml 98-0518 1 the java ™ reliable multicast ™ service...

1Copyright © 1998 Sun Microsystems, Inc.

SML 98-0518

The Java™ Reliable Multicast™ Service

Phil Rosenzweig

Boston Center for Networking

Sun Microsystems Laboratories

http://www.sunlabs.com/

[email protected]


SML 98-0518

Outline

• Multicast Technology

• Push and HTTP

• Multicast vs. HTTP for Information Distribution

• Reliable Multicast Applications and Requirements

• JRM Service Overview

• JRM Service Architecture

• Tree-base Reliable Multicast Protocol (TRAM)– Automatic Tree Formation

– Congestion Detection and Flow Control

• Project Status

• Future Directions

• Questions & Answers


SML 98-0518

SCALABILITY is the number one problem in networking…

Everything else is secondary


SML 98-0518

What is Multicast?

One Copy of Entire Data

StreamPer User

ClientClientClientClient



DataDataServerServerDataData

ServerServer

Customized Data Stream Shared

By All Usersin a Group




DataDataServerServerDataData

ServerServer

Unicast Multicast


SML 98-0518

S

R

R

R R

R

R

S

Routers Replicate Packets


SML 98-0518

NetworkLoad

Receivers

One-to-One(TCP, HTTP)

One-to-Many(Multicast, Broadcast)

Multicast Scales Better Than Unicast


SML 98-0518

Multicast is a Key Enabling Technology

• Provides a solution to bandwidth crisis, timely delivery and latency control

• Bandwidth– enabling audio/video broadcasting, multipoint collaborative applications

(shared whiteboard, virtual classroom), multicast file transfer (software distribution)

• Timely delivery– news updates, stock tickers, event notification

• Latency– make database coherency work

– remove serialization of multiple database updates

• Most applications require reliable delivery in order to be feasible


SML 98-0518

Current State of Multicast

• Most routers, switches, NICs and TCP/IP stacks support multicast– Product issues remain: pruning (routers), filtering (switches), addressing

(NICs), IGMP (TCP/IP stacks)

• MBONE operational on the Internet– See http://www.lbl.gov/WWW-Info/MBONE.html

• Significant work in IETF on standardization– IP Multicast (RFC 1112), IGMP, DVMRP, PIM, ...

• Reliable multicast is a research topic in the IRTF– Reliable Multicast Research Group (RM) started in March, 1997

– Many protocols proposed and under development• SRM (LBL), RMTP (Bell Labs), TMTP (UKentucky), RMP (Nasa), Starburst,

LRMP (Inria), TRAM (Sun Labs)

– Hard problems: Congestion control, address allocation, …


SML 98-0518

“Push” Technology

• Push technology category created by Pointcast, Marimba, others– Gives the illusion of automatic delivery of content to the desktop

• “Push” applications are really based on client “pull” technology or polling– Clients configured for what content to pull (minimal server side control)

– Clients periodically initiate interaction with server to check for updates

• Big problem! These systems are built over...– HTTP infrastructure of the web

– Unicast connections (point to point)

• Networks are clogged with automated update traffic

• Real push requires the ability to multicast updated content to many recipients

• Publish/subscribe (event driven updates) can also benefit from multicast


SML 98-0518

Top 10 Web Sites (bytes)

Source: Optimal Networks Corp Sixth Int’l WWW Conference


SML 98-0518

Internet

Pointcast

Server

Content from providers

Application

Pointcast Data Center

Corporate intranet

ISP

ISP

ISP

ISP

Desktop

Subscriber

Desktop

Subscriber

Clients Pull From ServerHTTP end to end

Desktop

Subscriber

Desktop

Subscriber

Desktop

Subscriber Desktop

Subscriber

Desktop

Subscriber

intranet


SML 98-0518

Pointcast with I-Server

Server

Application


Corporate intranet

ISP

ISP

Desktop

Subscriber

I-Server Pulls from Data Center Clients Pull From I-ServerHTTP end to end

Desktop

Subscriber

Desktop

Subscriber Desktop

Subscriber

Desktop

Subscriber

I-ServerContent from providers

intranet

Internet


SML 98-0518

Pointcast with Caching Manager and Multicast

Server

Application


Corporate intranetintranet

Internet

ISP

ISP

Desktop

Subscriber

Desktop

Subscriber

Desktop

Subscriber Desktop

Subscriber

Desktop

Subscriber

CachingManager

Caching Mgr pulls from Data CenterData pushed to clients from I-ServerAdministrative control at I-Server

Content from providers

HTTP

Multicast


SML 98-0518

Reliable Multicast Application TypesApplicationTypes andExamples

# Streams StartTime

Real Time Consistency Ordering Reliability

Bulk DataUsenet 1 Synch No File Level No Yes

Mail list 1 Synch No File Level No YesWeb Cache

Preload1 Synch No File Level No Yes

Live DataStock Prices 1 No Yes synchronized Yes YesNews Feed 1 No ? ? No desired

EventLogging

1 No No Yes ? No

ResilientStreams

StreamedMultimedia

1 No/Yes Yes No No Semi

Shared DataWhiteboard Many Many Yes Eventual No Yes

Editor Many Many Yes Eventual No YesConference

ControlMany Many Yes Yes ? Yes

HybridDistributedInteractiveSimulation(shared VR)

All All All All All All

Source: presentation by Mark Handley at the April 1997 meeting of the IRTF RMRG.


SML 98-0518

Server

NetworkWS

Mobileclient

PC

Mobileclient

Mobileclient

Thinclient

Thinclient

Sender

Thousands of Receivers

AppSW

Calendar

CorpData

ReutersCNN

SOURCES

RELIABLE DELIVERY

Example: News and Events Distribution


SML 98-0518

JRM Service - A Platform for Multicast Apps

• Enables building applications that multicast data from “senders” to “receivers” over “channels” with distributed control over content mix

• Organized as a set of libraries and services for building multicast applications

• Functional components:– A common API which supports multiple concurrent reliable multicast

transport protocols, selectable by applications depending on needs

– Tree-based Reliable Multicast Protocol designed for reliable multicast to very large numbers of receivers

– Services for multicast address allocation and channel management

– Dynamic filtering - Java software pushed into the network to implement policies and data customization downstream at the receiver which are configured at the server


SML 98-0518

Receivers Join

Userdata

Data & Policy

JRM Service Data Flow Model

• Sender advertises channels, receivers join• Sender sends data over channels to receivers• Data dynamically filtered by Java software downstream• Reliable multicast transport provides timely delivery using low bandwidth

Channel Advertisements

UnreliableMulticast

LAN/WAN

Data

Sender

Receivers (many)

Sending application with JRM Service libraries (reliable multicast)

Receiving application with JRM Service libraries (reliable multicast)

Reliable Multicast


SML 98-0518

Application

Channel Management

Transport Address Allocation

JRM Service Systems

• Transport system transports data over multicast

• Address allocation system manages multicast address allocation

• Channel management system manages channels. This includes:– creating, configuring, and destroying channels

– advertising or distributing channel information to receivers and others

– encrypting channel data and authenticating senders, receivers, etc.

– applying and distributing dynamic filters

– multiplexing several channels on a single multicast address


SML 98-0518

JRM Service Architecture

Application

Channel Management System

Multicast Address Manager

Tree-based

ReliableMulticastProtocol(TRAM)

Other Multicast Transport Protocols

Static Administratively

Scoped Allocator (SASA)

Session Announcement

Protocol Allocator (SAPA)

Multicast Transport API (MTAPI) Multicast Address Management SPI (MAMSPI)

Multicast Address Management API (MAMAPI)

Channel Management API (CMAPI)

Unreliable Multicast

SAP Support

SAP API

SecurityS

ecu

rity

AP

I

Authentication

Encryption

Server


SML 98-0518

Basic TRAM Model

Sender, Group Head

Receiver, Group Head

Receiver, Group Member

Groups

Data Cache

Multicast Data Message

Unicast Ack Message

Multicast Local Repair (Retransmission)


SML 98-0518

Automatic Tree Formation

• Build a tree from the sender which includes all of the receivers in the session– Each receiver is associated with a repair head

– Be able to add new receivers to the tree at any time

– Recover from head failure through re-affiliation

– Operate on networks which may or may not support bi-directional multicast

• What is a suitable repair head? – shortest TTL distance

– eagerness to be head

– number of members (large vs. small)

– head experience

– repair data availability


SML 98-0518

Repair Tree Construction - Unidirectional

1. Beacon sent with session TTL– Triggers heads to advertise

2. Heads advertise with expanding ring search (ERS)

3. Receivers pick “best” head– Smallest TTL

– Eager > reluctant

– Highest group member count

• Advantages– works for one-way multicast nets

• Disadvantages– Head advertisement bandwidth

– Head advertisements never stop

Sender

Head Head

Receiver

(1) Beacon

(2) HeadAdvertisements

(3) HeadBind

(4)AcceptMember


SML 98-0518

Repair Tree Construction - Bi-directional

1. Beacon send with session TTL– Triggers receivers to solicit heads

2. Receivers solicit with ERS

3. Heads advertise

4. Receivers pick “best “ head

• Advantages– Member solicitation avoids

continuous advertisement

– Member solicitation provides local isolation

• Disadvantages– Member solicitation bandwidth

issue when many receivers affiliating simultaneously in LAN environment

Sender

Head Head

Receiver

(1) Beacon

(3) HeadAdvertisements

(4) HeadBind

(5)AcceptMember (2) MemberSolicitation


SML 98-0518

Optimizations

• Combine unidirectional and bi-directional techniques– Unidirectional prior to start of data transmission

– Bi-directional following start of data

• Ongoing tree optimization– An optimal tree

• minimizes TTL of repairs - every member in a group is affiliated to the closest repair head

• promotes scalability - multiple repair groups that have few overlapping repair regions

– Likely that the initial tree constructed in TRAM is sub-optimal

– Every member and repair head continuously optimizes• A member hears from a better repair head

• Redundant repair heads (LAN)

• Unicast repairs

• Reducing the number of repair heads.

• Apply LAN-based tree formation algorithm


SML 98-0518

LAN-Based Tree Formation

• Bottom-up approach: build a subtree on the LAN before affiliating it with the rest of the tree

• Previous techniques not optimal for LANs:– Most of the LAN members will affiliate with repair heads that are not on

the LAN, resulting in increased TRAM traffic on the link.

– All LAN members that are potential repair heads will start advertising for members, causing increased traffic on the LAN.

• One repair head on the LAN, suppresses advertisements, reduces LAN to one logical member

• Elect a LAN head using bi-directional method and TTL 1

• Members on LAN naturally attach to LAN head

• LAN head attaches off the LAN

• Elect additional LAN heads from those already affiliated

• Small change to packets and algorithms


SML 98-0518

Congestion Detection and Flow Control

• Receivers (including heads) detect congestion

• Use repair tree to aggregate and propagate feedback to sender– Repair heads filter out duplicate congestion reports

– Sender filters out duplicate and old congestion reports

• Rate-based flow control

• Adaptive increase/decrease

• Adaptive adjustment cycle (to deal with feedback delay)

• Other optimizations– Staggering ACKs

– Rate monitoring at sender

– Limiting number of unACKed packets outstanding

– Duplicate retransmission suppression

– Pause sender to allow retransmissions at heads


SML 98-0518

Repair Tree and Feedback

• Use a window to implement selective ACKs

• Each receiver sends an ACK for each window to its parent

• ACK may contain a mask of lost packets

• ACK may also contain congestion indication

• Each receiver tries to send ACKs at a different point in ACK window


SML 98-0518

Detecting Congestion

• If a receiver sees an increase in the number of missing packets from last window to current window

• If a repair head’s cache grows to high-water-mark

• If a repair head gets an ACK that contains congestion report (not previously sent)


SML 98-0518

Rate Based Flow Control

• Sender uses a token bucket to send packets at a given rate

• Increases/decreases rate based on congestion signal

• Maintains rate within pre-configured maximum and minimum

• Receivers that cannot deal with the minimum rate get “pruned”


SML 98-0518

Adaptive Increase and Decrease

• Upon congestion, sender reduces rate by 50%, as recommended

• How much should the increase be? – Use “slow start” initially

• initial rate = 10% maximum

• increment = 10% maximum

• A constant amount is always wrong for some network

• Some bad ideas:– adapt using most recent peak rate

– adapt using moving average rate

– lead to diminishing increases, oscillation, inability to achieve optimal rate

• Following a decrease, recalculate increase amountincrement = ( historical peak rate - current rate ) / 4


SML 98-0518

Project Status

• Project start - 3/97

• 6 internal software releases completed

• Pilot applications built so far– File transfer

– Stock ticker

– Chat (multi-sender)

• 2 technical reports published– http://www.sunlabs.com/technical-reports/1998/1998.html


SML 98-0518

Future Directions

• Adaptive congestion control

• Repair tree optimization– Linkage to physical topology (router assist)

• Security in a multicast environment– Key distribution and management for authentication and encryption

– New IRTF research group forming

• Multicast address allocation– Coordination across organizational boundaries

– IETF malloc working group

• Performance

copyright © 1998 sun microsystems, inc. sml 98-0518 1 the java ™ reliable multicast ™ service...

Documents