Resource Negotiation, Pricing and QoS for Adaptive Multimedia Applications Xin Wang With Henning Schulzrinne Internet Real -Time Laboratory Columbia University http://www.cs.columbia.edu/~xinwang/RNAP.html
Outline Background RNAP: architecture and messaging Pricing models: Existing model Proposed pricing model User adaptation Testbed demonstration of Resource Negotiation Framework Simulation and discussion of Resource Negotiation Framework Resource Negotiation Framework 9/22/2018
bandwidth, loss, delay, jitter, availability, price Today’s IP Networks Service Level Agreements (SLA) are negotiated based on Application Specific Needs bandwidth, loss, delay, jitter, availability, price Application SLA ISP Networks & Applications IP Network Service User Large number of new applications are appearing in the Internet. This includes the real-time audio, video, and mission-critical financial data. This provides ISP more business opportunity, and also challenge. The value-added services normally require certain service expectations. Since different applications have different requirements in bandwidth and quality, network resource provision is challenging. SCOPE Growth of new IP services and applications with different bandwidth and quality of service requirements Presents opportunities and challenges for service providers 9/22/2018
The needs of Next Generation Service Providers Revenue from the traditional connectivity services (raw bandwidth) is declining Increase revenue by offering innovative IP services: VoIP, VPN, Applications Hosting etc Deliver high-margin, differentiated services Gain competitive advantage by deploying new services more quickly, placing a premium on time to market and time to scale Reduce cost and operation complexity Evolve from static network management to dynamic service provisioning Reduce costs by automating network and service management Since the revenue is declining, the network providers have to find other opportunities Service provider needs to provide different premium services, without big cost. The network management and resource provisioning should be automatic and fast. 9/22/2018
Internet Structure End User LAN POP NAP Backbone Provider Regional Provider End User Regional Provider LAN Backbone Provider POP NAP Private Peering Before introducing an appropriate service model for ISP, let’s take a look at the situation of the current Internet. Network is generally divided into different management domains, with direct peering or connect through Network Access Point (NAP). The Network Access Point (NAP) allows Internet Service Providers (ISPs) to interconnect and exchange information among themselves. The exchanging of Internet traffic is generally referred to as "peering". Backbone Provider Private Peering Private Network 9/22/2018
NORDUnet Traffic Analysis We show some traffic statistics of NORDUnet NORDUnet interconnects the Nordic national networks for research and education and connects these networks to the rest of the world. The current physical connections are shown on the connectivity map. NORDUnet provides its services by a combination of leased lines and Internet services provided by other international operators. 9/22/2018
NORDUnet Traffic Analysis Results: All access links (interconnect ISP’s or connect private networks to ISP’s, trans-Atlantic links) can get congested. Average utilization is low: 20-30% Peak utilization can be high: up to 100% Congestion Ratio (peak/average): as high as 5. Peak duration can be very long: Chicago NAP congested once in 8/00, lasted 7 hours. TeleGlobe links congested every workday in 8/00 and 9/00 Reasons: Frequent re-configuration and upgrading; Load balancing to protect own users. Statistics shows …. Even though average utilization is only 20-30% the peak …. The reasons for the congestion can be ascribed to the 9/22/2018
Solution - Over-provisioning? Add enough bandwidth for all applications in access network / backbone Will over-provisioning be sufficient to avoid congestion? How much bandwidth is enough? No intrinsic upper limit on bandwidth use How much does it cost to add capacity? It is difficult to predict the various user requirements, especially due to the quick deployments of new applications Demand: Availability of more bandwidth will create its own demand through increasing utilization of bandwidth intensive applications” .real-time audio/video, 3D image, virtual reality, etc. Supply: Cost of transportation using fiber optics is declining drastically. However, network management cost: switches and routers, state of the art POP, data centers, etc, will cost money. 9/22/2018
Bandwidth Pricing Reality: leased bandwidth price has not been dropping consistently and dramatically. 300 mile T1 price: 1987: $10,000/month 1992: $4,000/month 1998: $6,000/month (thanks to high Internet demand) Links connecting ISP’s are very expensive Transit DS-3 link: $50,000/month between carriers. Transit OC-3 link: $150,000/month between carriers. Bandwidth may be cheap, but not free Higher-speed connection -- higher recurring monthly costs. Option - manage the existing bandwidth better, with a service model which uses bandwidth efficiently. 9/22/2018
A More Efficient Service Model Quality of Service (QoS) Condition the network to provide predictability to an application even during high user demand Provide multiple levels of services Efficient bandwidth management? Can a user select one out of a spectrum of services? How much a user needs to pay? Application adaptation Source rate adaptation based on network conditions - congestion control and efficient bandwidth utilization How about also QoS? Why would an application adapt? Provision is more a business strategy. Now we consider some more efficient service models than simply over-provisioning. What are the desirable things to have in such a model? QoS: Protect the valuable applications through QoS. But will QoS add big complexity? Provide multiple levels of QoS to meet diverse user requirements Resource reservation and provisioning tend to be conservative due to the lack of quantitative knowledge of traffic statistics. Providing different servers needs differentiated pricing, otherwise, everyone will ask the best service and end up no services.We need to worry about and how to differentiate the different services through pricing Adaptations in literature assume no QoS, do not have the motivation to adapt, since the no- adaptive service may perform better 9/22/2018
A More Efficient Service Model (cont’d) Service selection and dynamic resource negotiation An integrated mechanism for a user to select a service Network commits resources for short intervals better response to changes in network conditions and user demand better QoS support for adaptive applications Usage-,QoS-,demand-sensitive pricing Network: price services based on resources consumed, allocate resources based on user willingness-to-pay Users: select appropriate service based on requirements, adapt demand during network resource contention Allows network to price services based on resources consumed, allocate resources based on user willingness-to-pay Gives users the incentive to …. To support services with QoS mechanisms, and user adaptation, a couple of other features are desirable….. 9/22/2018
What We Add to Enable This Model A dynamic resource negotiation protocol: RNAP An abstract Resource Negotiation And Pricing protocol Enables user and network (or two network domains) to dynamically negotiate multiple services Enables network to formulate and communicate prices and charges Service predictability: commit service and price for an interval Multi-party negotiation: senders, receivers, or both Reliable and scalable Lightweight and flexible: embedded in other protocols, e.g., RSVP, or implemented independently A demand-sensitive pricing model Enables differential charging for supporting multiple levels of services; services priced to reflect the cost and long-term user demand Allows for congestion pricing to motivate user adaptation 9/22/2018
What we add... (cont’d) Demonstrate a complete resource negotiation framework (RNAP, pricing model, user adaptation) on test-bed network Simulations show significant advantages relative to static resource allocation and fixed pricing: Much lower service blocking rate under resource contention Service assurances under large or bursty offered loads, without highly conservative provisioning Higher perceived user benefit and higher network revenue 9/22/2018
Outline Background RNAP: architecture and messaging Pricing models: Existing model Proposed pricing model User adaptation Testbed demonstration of Resource Negotiation Framework Simulation and discussion of Resource Negotiation Framework Resource Negotiation Framework 9/22/2018
Protocol Architectures: Centralized (RNAP-C) Host Resource Negotiator RNAP Messages Network Resource Negotiator NRN NRN NRN HRN HRN Access Domain - A We consider two alternative architectures for implementing RNAP in the network, a centralized architecture (RNAP-C) and a distributed architecture (RNAP-D) In RNAP-C, user negotiates through a HRN, each network domain has a NRN. In general, each NRN is in charge of admission control, monitoring network statistics, price quotation and charging for its domain. When a user wants to to apply for resources from the network, it first sends a request to the NRN of its access domain. This request is then propagated to next-domain NRN, and so on. Edge Router Access Domain - B Internal Router Intra-domain messages Transit Domain 9/22/2018
Protocol Architectures: Distributed (RNAP-D) RNAP Messages HRN LRN LRN LRN LRN LRN LRN LRN LRN LRN HRN LRN LRN Access Domain - A LRN LRN Edge Router Access Domain - B In RNAP-D, Local Resource Negotiators (LRN) were implemented on each router, for admission control, monitoring network statistics, forming price for each service class. At network edge, NRNs dynamically configure traffic conditioners, based on on-going user requests. Internal Router Transit Domain 9/22/2018
RNAP Messages Periodic negotiation Query: Inquires about available services, prices Query Quotation Quotation: Specifies service availability, accumulates service statistics, prices Reserve Commit Reserve: Requests services and resources, Modifies earlier requests Periodic negotiation Quotation Commit: Admits the service request at a specific price or denies it. Reserve Commit Close: Tears down negotiation session Close Release: Releases the resources Release 9/22/2018
Message Aggregation (RNAP-D) Turn off router alert Turn on router alert Sink-tree-based aggregation 9/22/2018
Message Aggregation (RNAP-D) Turn on router alert Turn off router alert Sink-tree-based aggregation 9/22/2018
Message Aggregation (RNAP-C) Aggregation when senders share the same destination network Messages merged by source or intermediate domains Messages de-aggregated at destination border routers (RNAP-D), or NRNs (RNAP-C) Original messages sent directly to destination/source domains without interception by intermediate RNAP agents; aggregate message reserves and collects price at intermediate nodes/domains Overhead Reduction Processing overhead, storage of states NRN Sink-tree-based aggregation 9/22/2018
Block Negotiation (network-network) Aggregated resources are added/removed in large blocks to minimize negotiation overhead and reduce network dynamics Bandwidth time 9/22/2018
Outline Background RNAP: architecture and messaging Pricing models: Comparison of model Proposed pricing model User adaptation Testbed demonstration of Resource Negotiation Framework Simulation and discussion of Resource Negotiation Framework Resource Negotiation Framework 9/22/2018
Pricing in Current Internet Access-rate-dependent flat charge Simple, price predictable Difficult to compromise between access speed and cost No incentive for users to limit usage congestion Usage-based charge Volume-dependent charge Time-base charge work better for uniform per-time unit resource demands, e.g., telephone Access charge + Usage-based charge Per-hour charge after certain period of use, or per-unit charge after some amount of traffic transmitted. Flat charge for basic service, usage charge for extra bandwidth or premium services Flat fee: Predictable fee for both users and providers. Avoid potentially considerable administrative costs of tracking, allocating and billing for usage Network resource can only be provisioned based on some predictions 9/22/2018
Two Volume-based Pricing Strategies Fixed-Price (FP): fixed unit volume price Flat pricing (FP-FL): per-byte charge are same for all services Priority pricing (FP-PR): service class dependent Time-dependent pricing (FP-T): time-of-day dependent Time-dependent priority pricing (FP-PR-T): FP-PR + FP-T During congestion: higher blocking rate OR higher dropping rate and delay Congestion-dependent-Price (CP): FP + congestion-sensitive price component CP-FL, CP-PR, CP-T, CP-PR-T During congestion: users have options to maintain service by paying more OR reducing sending rate OR switching to lower service class Overall reduced rate of service blocking, packet dropping and delay In period of resource scarcity, quality sensitive applications can maintain their resource levels by paying more \Quality insensitive applications will reduce their sending rate or change to a lower service class 9/22/2018
Important Time Scales Technical levels of interaction Monetary levels of interaction atomic short-term medium-term long-term Retransmission Error Handling Flow Control Resource Reservation Capacity Planning Scheduling Feedback Policing Routing time Congestion Time-of-day Pricing Flat Rates Pricing 9/22/2018
Pricing Strategies Holding price and charge: based on cost of blocking other users by holding bandwidth even without sending data phj = j (pu j - pu j-1) , chij (n) = ph j r ij (n) j Usage price and charge: optimize the provider’s profit max [Σl x j (pu1 , pu2 , …, puJ ) puj - f(C)], s.t. r (x (pu2 , pu2 , …, puJ )) R cuij (n) = pu j v ij (n) Congestion price and charge: drive demand to supply level (two mechanisms) 9/22/2018
Usage Price for Differentiated Service Usage price based on cost of class bandwidth: lower target load (higher QoS) -> higher per-unit bandwidth price Parameters: pbasic basic rate for fully used bandwidth j : expected load ratio of class j xij : effective bandwidth consumption of application i Aj : constant elasticity demand parameter Price for class j: puj = pbasic / j Demand of class j: xj ( puj ) = Aj / puj Effective bandwidth consumption: xe j ( puj ) = Aj / ( puj j ) Network maximizes profit: max [Σl (Aj / pu j ) pu j - f (C)], puj = pbasic / j , s. t. Σl Aj / ( pu j j ) C Hence: pbasic = Σl Aj / C , puj = Σl Aj /(C j) 9/22/2018
Congestion price: first mechanism - Tatonnement Tatonnement process (CPA-TAT): Congestion charge proportional to excess demand relative to target utilization pc j (n) = min [{pcj (n-1) + j (Dj, Sj) x (Dj-Sj)/Sj,0 }+, pmaxj ] ccij (n) = pc j v ij (n) 9/22/2018
Congestion price: second mechanism - M-bid Second-price Auction Auction models in literature: Assume unique bandwidth/price preference, one bid Service uncertainty: not know about high demand until rejected Higher setup delay, signaling burst, life-time auction, user response to auction results not considered M-bid auction Model User bids (bandwidth, price) for a number of bandwidths, bids obtained by sampling utility function. Network selects highest bids, charges highest rejected bid price During high demand: lower bandwidth (higher price per unit bandwidth) bids get selected; more users served Inter-auction admission to reduce setup delay Support auction for a period to help for congestion control 9/22/2018
Example of M-bid Auction Total capacity 70, congestion price is 2 Bid Bandwidth Bid Price Bidder Bid Selection 5 10 1 2 4 10 15 1 4 20 3 3.5 25 2 3 Cutoff 2 30 3 Congestion Price 9/22/2018
Outline Background RNAP: architecture and messaging Pricing models: Comparison of model Proposed pricing model User adaptation Testbed demonstration of Resource Negotiation Framework Simulation and discussion of Resource Negotiation Framework Resource Negotiation Framework 9/22/2018
Rate Adaptation of Multimedia System Gain optimal perceptual value based on the network conditions and user profile A Host Resource Negotiator (HRN) negotiates services with network on behalf of a multimedia system. Utility function: users’ preference or willingness to pay Cost U1 U2 Utility/cost/budget U3 Budget Bandwidth 9/22/2018
Example Utility Function User defines utility at discrete bandwidth, QoS levels Utility is a function of bandwidth at fixed QoS An example utility function: U (x) = U0 + log (x / xm) U0 : perceived (opportunity) value at minimum bandwidth : sensitivity of the utility to bandwidth Function of both bandwidth and QoS U (x) = U0 + log (x / xm) - kd d - kl l , for x xm kd : sensitivity to delay kl : sensitivity to loss 9/22/2018
Two Rate Adaptation Models User adaptation under CPA-TAT (tatonnement-based pricing) Optimize perceived surplus subject to budget and application requirements With the example utility functions: Without budget constraint: x i = i / pi With budget constraint: x i = bi / pi, with b i = b ( i / Σl k ) User adaptation under CPA-AUC (second-price auction) Submit M-bid derived by sampling utility function; adapt rate based on allocated bandwidth/QoS Adaptation of applications in multimedia system Distribute bid/allocated bandwidth among applications for optimal overall surplus 9/22/2018
Stability and Oscillation Reduction Congestion-sensitive pricing has been shown to be stable, see references. Oscillation reduction Users: re-negotiate only if price change exceeds a given threshold Network: update price only when traffic change exceeds a threshold; negotiate resources in larger blocks between domains 9/22/2018
Outline Background RNAP: architecture and messaging Pricing models: Comparison of model Proposed pricing model User adaptation Testbed demonstration of Resource Negotiation Framework Simulation and discussion of Resource Negotiation Framework Resource Negotiation Framework 9/22/2018
Testbed Architecture Demonstrate functionality and performance improvement: blocking rate, average loss and delay, price stability, perceived media quality Host HRN negotiates resources for a system Host processes (HRN, VIC, RAT) communicate through Mbus Network FreeBSD 3.4 + ALTQ 2.2, CBQ extended for DiffServ NRNs: Process RNAP messages Admission control, monitor service statistics, compute price At edge, dynamically configure the conditioners and form charge Inter-entity signaling: RNAP RAT VIC Mbus HRN RNAP NRN 9/22/2018
Functions of Routers Interior routers: per-class policing, e.g, TBMETER (in/out) for a class Edge routers: flow conditioning/policing based on SLA The NRN supports flexible definition of service classes and their specification. The spec is typically based on a set of QoS parameters. It also includes a pricing function for calculating price components. Identifier is typically a standard mechanism to identify the service to clients. For example, for a DiffServ service like Expedited Forwarding, the identifier is the DSCP. The NRN at edge routers performs per-flow policing and conditioning. The policing function can for example use a token-bucket to measure the flow’s usage and take appropriate measures. The NRN's running on interior routers do not maintain per-flow measurements. But they do keep track of per-flow allocation information. They do per-class policing using the DiffServ BA technique. 9/22/2018
Network Resource Negotiator (NRN) Monitor statistics and provide price for each service class Measurement-based admission control predict future demand, update congestion price based on predictions 9/22/2018
Network States Per-class bandwidth and price variations Reduction in blocking due to adaptation 9/22/2018
Adaptive Wireless Terminal WAP development over Nokia Toolkit 2.0 Currently cell phone services: Flat pricing and best effort: when congestion, all users get worse quality - coarse voice, busy signal, cut off New Service Option to users: Provide real-time pricing information, periodically (e.g., every 10 minutes) or per-call based Lower basic charge, e.g. 20 c/min instead of 30 c/min When congestion, raising price subject to upper limit Customer choices under congestion: pay a premium to have best quality; pay less by tolerating worse quality; back off to call another time. Reduce overall network blocking rate 9/22/2018
Outline Background RNAP: architecture and messaging Pricing models: Comparison of model Proposed pricing model User adaptation Testbed demonstration of Resource Negotiation Framework Simulation and discussion of Resource Negotiation Framework Resource Negotiation Framework 9/22/2018
Simulation Design Performance comparison: Four groups of experiments: Network with dynamic services and rate-adaptive users vs. network with non-adaptive users Fixed price policy (FP) (usage price + holding price) versus congestion price based adaptive service (CPA) (usage price + holding price + congestion price) Four groups of experiments: (1) Effect of traffic burstiness; (2) Effect of traffic load; (3) Load balance between classes; (4) Effect of admission control Engineering metrics: bottleneck traffic arrival rate, average packet loss and delay, user request blocking probability Economic metrics: average and total user benefit, end-to-end price and its standard deviation, network revenue 9/22/2018
Simulation Models Network Simulator (NS-2) Weighted Round Robin (WRR) scheduler Three classes: EF, AF, BE EF: tail dropping, limited to 50 packets; load threshold 40%, delay bound 2 ms, loss bound 10-6 AF: RED-with-In-Out (RIO), limited to 100 packets; load threshold 60%, delay bound 5 ms, loss bound 10-4 BE: Random Early Detection (RED), limited to 200 packets; load threshold 90%, delay bound 100 ms, loss bound 10-2 Sources: mix of on-off and Pareto on-off (shape parameter: 1.5) Negotiation period: 30 s, session length 10 min 9/22/2018
Simulation Architecture Topology 1 (60 users) Topology 2 (360 users) 9/22/2018
Effect of Traffic Burstiness Average packet delay Average packet loss 9/22/2018
Price average and standard deviation of AF class Effect of Traffic Burstiness (cont’d) Price average and standard deviation of AF class Average user benefit 9/22/2018
Effect of Traffic Load (cont’d) Average packet loss Average packet delay 9/22/2018
Price average and standard deviation of AF class Effect of Traffic Load Price average and standard deviation of AF class Average user benefit 9/22/2018
Load Balance between Classes (cont’d) Average packet delay Average packet loss 9/22/2018
Load Balance between Classes Variation over time of the price of AF class Ratio of AF class traffic migrating through class re-selection 9/22/2018
Effect of Admission Control Average packet delay Average packet loss 9/22/2018
Effect of Admission Control (cont’d.) Average and standard deviation of AF class price User request blocking rate 9/22/2018
Simulation Results CPA policy coupled with user adaptation effectively limit congestion, provide lower blocking rate, higher user satisfaction and network revenue than with the FP policy Differentiated service requires different target loads in each class Without admission control, contracted service can be assured by restricting the load to the targeted level With admission control, blocking rate and price dynamics get reduced Allowing service class migration allows for the service assurance and further stabilizes price 9/22/2018
Other Results Users with different demand elasticity share bandwidth proportional to their willingness to pay Even a small proportion of user adaptation results in a significant performance improvement for the entire user population Performance of CPA further improves as the network scales and more connections share the resources Both auction and tatonnement process can be used to calculate the congestion price; auction scheme gains higher perceived user benefit and network utilization at cost of implementation complexity and setup delay 9/22/2018
Conclusions RNAP Pricing model Application adaptation Supports dynamic service negotiation, mechanisms for price and charge collation, auction bids and results distribution Allows for both centralized and distributed architectures Supports multi-party negotiation: senders, receivers, or both Can be stand-alone, or embedded inside other protocols Reliable and scalable Pricing model Consider resource consumption, long-term user demand and short-term traffic fluctuation; use congestion-sensitive component to motivate user demand adaptation during resource scarcity Application adaptation Maximize user perceptual value, tradeoff between quality and expenditure 9/22/2018
Conclusions (cont’d) M-bid Auction Model Serves more users than comparable schemes, and has less signaling overhead, greater certainty of service availability, and lower setup delay Congestion price based adaptive service versus fixe price based static service Effectively limit congestion, allows for service assurance under high and bursty load Provide lower blocking rate, higher user satisfaction and network revenue 9/22/2018
Further Work Propose light-weight resource management protocol Cost distribution in QoS-enhanced multicast network Pricing in the presence of alternatives path or competitive network User valuation models for different QoS Resource provision in wireless environment 9/22/2018
Some References X. Wang, H. Schulzrinne, “Auction or Ttonnement - Finding Congestion Prices for Adaptive Applications”, submitted. X. Wang, H. Schulzrinne, “Pricing Network Resources for Adaptive Applications in a Differentiated Services Network,” In Proceeding of INFOCOM'2001, April 22-26, Anchorage, Alaska. X. Wang, H. Schulzrinne, “An Integrated Resource Negotiation, Pricing, and QoS Adaptation Framework for Multimedia Applications,” IEEE JSAC, vol. 18, 2000. Special Issue on Internet QoS. X. Wang, H. Schulzrinne, “Performance Study of Congestion Price based Adaptive Service,” In Proc. International Workshop on Network and Operating System Support for Digital Audio and Video (NOSSDAV'00), Chapel Hill, North Carolina, Jun. 2000. X. Wang, H. Schulzrinne, “Comparison of Adaptive Internet Multimedia Applications,” IEICE Transactions on Communications, Vol. E82-B, No. 6, pp. 806--818, June 1999. 9/22/2018
Measurements and Analysis of LDAP Performance Xin Wang Internet Real -Time Laboratory Columbia University http://www.cs.columbia.edu/~xinwang/LDAP.html Joint work with Henning Schulzrinne, Dilip Kandlur, and Dinesh Verma
Motivation and Experiment LDAP: widely used, but little study on performance Our work: developed a benchmark tool to analyze the performance of LDAP directories Experimental setup: Hardware: server- dual Ultra-2 processors, 200 MHz CPUs, 256 Mb memory; Clients- Ultra1, 170 MHz CPU, 128 MB memory; 10 Mb/s Ethernet LDAP server: OpenLDAP 1.2, Berkeley DB 2.4.14 Search filter: interface address, and corresponding policy object Default parameters: 10,000 entries, entry size 488 bytes cachesize: size in entries of in-memory cache; variable size dbcachesize: size in bytes of the in-memory cache associated with each open index file; 10 MB 9/22/2018
Results General Results: response latency 8 ms up to 105 requests/second Maximum throughput 140 requests/second 5 ms processing latency - 36% from backend, 64% from front end Connect time dominates at high load, and limits the throughput Disabling Nagle Algorithm reduces latency about 50 ms Entry Caching: for 10,000 entry directory, caching all entries gives 40% improvement in processing time, 25% improvement in throughput CPU: For in-memory operation, dual processors improve performance by 40%. Connection Re-use: 60% performance gain when connection left open. 9/22/2018
Results (cont’d) Scaling with Directory Size - determined by back-end processing In memory operation, 10,000 -> 50,000: processing time increases 60%, throughput reduces 21%. Out-of-memory, 50,000 ->100,000: processing time increases another 87%, and throughput reduces 23%. Scaling with Entry Size (488 ->4880 bytes): In-memory, mainly increase in front-end processing, i.e., time for ASN.1 encoding . Processing time increases 8 ms, 88% due to ASN.1 encoding, and throughput reduces 30%. Out-of-memory, throughput reduces 70%, mainly due to increased data transfer time. 9/22/2018
IP Multicast Fault Recovery in PIM over OSPF Xin Wang Internet Real -Time Laboratory Columbia University http://www.cs.columbia.edu/~xinwang/LDAP.html Joint work with Chienming Yu, Henning Schulzrinne, Paul Stirpe and Wei Wu
Motivation and Experiment Many IP multicast applications require high availability Study failure recovery in a complete architecture: IGMP + OSPF (unicast) + PIM-SM (multicast) Focus: the interplay of underlying protocols; the interactions of failure recovery, between router, link, WAN and LAN Method: quantitative analysis; Simulation over OPNET; Study failure recovery and implementation issues on test-bed Many IP multicast applications require high availability, for example, near real-time dissemination of financial information; Little work has been done in this field. OSPF: rapid fault recovery properties, widespread use, support of parameteric tuning; while RIP has long, non-tunable fair-over periods. PIM (DM and SM): dominant multicast routing protocols. DVMRP or CBT resemble dense and sparse mode respectively. Since fault recovery for rendezvous point (RP) for PIM SM has been studied extensively, our focus is on the sequence of events and interactions under different failures, between router, link, WAN and LAN; Consider single link and router faults. 9/22/2018
Results (cont’d) General observations Channel recovery time: dominated by unicast table re-construction time. Protocol control loads: PIM DM control load increases proportionally with the redundancy factor and decreases inversely with the percentage of receivers; OSPF load increases proportionally as OSPF Hello interval decreases Neither PIM nor OSPF has high control traffic during failure recovery. 9/22/2018
Results (cont’d) PIM Enhancement for Fault Recovery Fast recovery from DR failure: reduce Hello-Holdtime to detect neighbor failure faster; Backup DR; IGMP group information caching in all LAN routers. Fast recovery from last-hop router failure: DR record the last-hop router address, not wait for an IGMP report to reactivate its oif to the LAN; Use backup router PIM DM acting as DR for rapid detection of the last-hop router failure. Reducing extra delay due to polling: interrupts 9/22/2018