Receiver-driven Layered MulticastOverviewIntroductionApproaches to Rate-Adaptive MultimediaExample of HeterogeneityIssues and ChallengesLayered ApproachSlide 8Issue in Layered ApproachRLM – Network ModelRLM - Video StreamsRLM SessionsRouter MechanismsRLM - ProtocolRLM – Adding and Dropping layersSlide 16RLM – Join ExperimentsRLM Join ExperimentDetection TimeRLM - Issues with JoinsRLM – Shared LearningRLM - EvaluationSlide 23RLM – Performance MetricsRLM – Performance ResultsSlide 26Slide 27Slide 28Slide 29ConclusionsSlide 31ReferencesReceiver-driven Layered MulticastPaper by- Steven McCanne, Van Jacobson and Martin Vetterli – ACM SIGCOMM 1996Presented By – Manoj SivakumarOverviewIntroductionApproaches to Rate-Adaptive MultimediaIssues and challengesRLM - DetailsPerformance EvaluationConclusionsIntroductionConsider a typical streaming ApplicationWhat rate should the source send data at ?InternetReceiverSource128 Kb/s X Kb/sApproaches to Rate-Adaptive MultimediaRate Adaptation at Source – based on available network capacityWorks well for a Unicast environmentHow about multicast ?source Receiver 2128 Kb/s X2 Kb/sReceiver 1Receiver 3X1 Kb/sX3 Kb/sExample of HeterogeneityIssues and ChallengesOptimal link utilizationBest possible service to all receiversAbility to cope with Congestion in the networkAll this should be done with just best effort service on the internetLayered ApproachRather than sending a single encoded video signal the source sends several layers of encoded signal – each layer incrementally refining the quality of the signalIntermediate Routers drop higher layers when congestion occursLayered ApproachEach layer is sent to one multicast groupIf a receiver wants higher quality – subscribes to all higher level layer multicast groupsIssue in Layered ApproachNo framework for explicit signaling between the receivers and routersA mechanism to adapt to both static heterogeneity and dynamic variations in network capacity is not presentSolution - RLMRLM – Network ModelWorks with IP MulticastAssumeBest effort (packets may be out of order, lost or arbitrarily delayed)Multicast (traffic flows only along links with downstream recipients)Group oriented communication (senders do not know of receivers and receivers can come and go)Receivers may specify different sendersRLM - Video StreamsOne channel per layerLayers are additiveAdding more channels gives better qualityAdding more channels requires more bandwidthRLM SessionsEach session composed of layers, with one layer per groupLayers can be separate (i.e. each layer is higher quality) or additive (add all to get maximum quality)Additive is more efficientRouter MechanismsDropping of packetsDrop less preferential packets firstRLM - ProtocolAbstractionon congestion, drop a layeron spare capacity, add a layerRLM – Adding and Dropping layersDrop layer when packet lossAdd does not have counter-part signalNeed to try adding at well-chosen timesCalled join experimentRLM – Adding and Dropping layersIf join experiment failsDrop layer, since causing congestionIf join experiment succeedsOne step closer to operating levelBut join experiments can cause congestionOnly want to try when might succeedRLM – Join ExperimentsGet lowest layer and start timer for next probeInitially timer smallIf higher level fails then increase timer duration else proceed to next layer and start time for the layer above itRepeat until optimumRLM Join ExperimentHow to know is join experiment succeededDetection timeDetection TimeHard to estimateCan only be done experimentallyInitially start with a large valueProgressively update the detection time based on actual valuesRLM - Issues with JoinsIs this ScalableWhat if each node does join experiments and the same time for different layersWrong info to node that requests lower layer if the other node had requested higher layerSolution – Shared LearningRLM – Shared LearningEach node broadcasts its intent to the groupAdv’s – other nodes can learn from the result of this node’s experimentReduction in simultaneous experimentsIs this still foolproof ??RLM - EvaluationSimulations performed in NSVideo modeled as CBRParametersBandwidth: 1.5 MbpsLayers: 6, each 32 x 2m kbps (m = 0 … 5)Queue management :Drop TailQueue Size (20 packets)Packet size (1 Kbytes)Latency (varies)Topology (next slide)RLM - EvaluationTopologies1 – explore latency2 – explore scalability3 – heterogeneous with two sets4 – large number of independent sessionsRLM – Performance MetricsWorse-case lost rate over varying time intervalsShort-term: how bad transient congestion isLong-term: how often congestion occursThroughput as percent of availableBut will always be 100% eventuallySo, look at time to reach optimalNote, neither alone is okCould have low loss, low throughputHigh loss, high throughputNeed to look at bothRLM – Performance ResultsLatency ResultsRLM – Performance ResultsLatency ResultsRLM – Performance ResultsSession SizeRLM – Performance ResultsConvergence rateRLM – Performance ResultsBandwidth HeterogeneityConclusionsPossible PitfallsShared Learning assumes only multicast trafficIs this valid ??Is congestion produced by Multicast traffic aloneSimulation does not other traffic requests!!ConclusionsOverall – a nice architecture and mechanism to regulate traffic and have the best utilizationBut still needs refinementReferencesS. McCanne, V. Jacobson, and M. Vetterli, "Receiver-driven layered multicast," in Proc. SIGCOMM'96, ACM, Stanford, CA, Aug. 1996, pp.
View Full Document
Unlocking...