Scalable Network Architecture & Measurements

Scalable Network Architecture & Measurements
for Multicast and Adaptive QoS Xin Wang Work under Professor Henning Schulzrinne Internet Real -Time Laboratory Columbia University Xin Wang, Columbia University

Scope of this Talk Main work Other work
Resource Negotiation, Pricing, and QoS for Adaptive Multimedia Applications Other work Measurements and Analysis of LDAP Performance IP Multicast Fault Recovery in PIM over OSPF You don’t have the context to describe your outline. Delete this one, just begin the next slide by saying: I’ll begin by providing some background on my work…. 9/22/2018 Xin Wang, Columbia University Xin Wang, Columbia University

Resource Negotiation, Pricing and QoS
for Adaptive Multimedia Applications Xin Wang With Henning Schulzrinne Internet Real -Time Laboratory Columbia University Xin Wang, Columbia University

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 Regional Networks Application SLA Regional Networks Backbone Network Regional Networks A large number of new applications are appearing in the Internet. This includes real-time audio, video, and mission-critical financial data. At the same time, revenue from the traditional connectivity services (raw bandwidth) is declining The ISP has new business opportunities, but also new challenges. Let’s look at some specific challenges….. 1. Growth of new IP services and applications with different bandwidth and quality of service requirements 2. Revenue from the traditional connectivity services is declining 3. New services present opportunities and challenges for service providers 9/22/2018 Xin Wang, Columbia University Xin Wang, Columbia University

The Needs of Next Generation Service Providers
Increase revenue by offering innovative services VoIP, VPN, Applications Hosting, etc Deliver high-margin, differentiated services Gain competitive advantage - rapidly deploy and scale new services Meet service expectations of diverse services: Over-provision - add enough raw bandwidth to backbone and access networks AND/OR Provision and manage network more efficiently (greater automation, dynamic provisioning) The service provider need to provide different premium, value-added services, such as…. They have to be able to add new services quickly and efficiently They need to provision the network to meet the high quality expectations of these services. This requires adding a lot of raw bandwidth, OR more efficient and economical utilization of the existing capacity, by automating network and service management, and allocating and re-configuring network resources dynamically. Let’s look at the trade-offs between adding capacity, and investing in more efficient network management. 9/22/2018 Xin Wang, Columbia University Xin Wang, Columbia University

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 Xin Wang, Columbia University Xin Wang, Columbia University

NORDUnet Traffic Analysis (cont’d)
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 are: 9/22/2018 Xin Wang, Columbia University Xin Wang, Columbia University

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. Cost of fiber optics is declining. But network management costs - switches and routers, state of the art POP, data centers - are high. T megabits per second (24 DS0 lines) T megabits per second (28 T1s) OC megabits per second (100 T1s) OC megabits per second (4 OC3s) OC gigabits per seconds (4 OC12s) OC gigabits per second (4 OC48s) The price for a Chicago NAP connection is distance sensitive and based on the location where the ISP's network meets Ameritech's. ATM pricing also varies with contract length with price deductions for longer term contracts. NAP connection prices start at $3,900 per month for a DS3 and $4,700 per month for an OC3. Duration of 12, 36 or 60 month terms are available. Bandwidth may be cheap, but not free Higher-speed connection -- higher recurring monthly costs. 9/22/2018 Xin Wang, Columbia University Xin Wang, Columbia University

Is Simple Over-Provisioning Enough?
Even though average bandwidth utilization is low, congestion can happen; access links get congested frequently Wireless bandwidth is even more scarce Bandwidth prices are not dropping rapidly How much bandwidth is enough? No intrinsic upper limit on bandwidth use So, as we have seen, Access and backbone networks get congested frequently Bandwidth prices are not dropping rapidly It is difficult to predict the various user requirements, especially due to the quick deployments of new applications. Also, recent history tells us that 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. Now we consider a more efficient service model than simply over-provisioning. What are the desirable things to have in such a model? Option - manage the existing bandwidth better, with a service model which uses bandwidth efficiently. 9/22/2018 Xin Wang, Columbia University Xin Wang, Columbia University

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 does a user need to pay? Application adaptation Source rate adaptation based on network conditions - congestion control and efficient bandwidth utilization Adaptation of service (QoS level)? Why would an application adapt? QoS: Provide value-added services with QoS expectations even during high user demand. Provide multiple levels of QoS to meet diverse user requirements. In general, adding multiple levels of QoS requires more network management, and greater user-network negotiation. Clearly, providing different services also means that we need a differentiated pricing structure. Adaptation schemes in literature assume user adapts source rate based on knowledge of network statistics (polling, etc.) - able to control congestion at high loads Do not consider adaptation of QoS, (by selecting different service) Assume well-behaved users, adapt without any incentive 9/22/2018 Xin Wang, Columbia University Xin Wang, Columbia University

A More Efficient Service Model (cont’d)
Requirements of QoS/adaptive model: mechanism to select and negotiate services adaptive applications short-term resource configuration for better response to user demand and network conditions, for more efficient resource usage Allow dynamic resource negotiation during ongoing service price network services based on QoS (resources consumed), allocate resources based on user willingness-to-pay provide signal / incentive for user adaptation through pricing A dynamic service selection and resource negotiation mechanism Usage-,QoS-,demand-sensitive pricing To support multiple services with QoS - we need a service selection and negotiation mechanism (well-known example - RSVP) For efficient resource usage - network should be able to commit resources for a short-term, dynamically re-configure resources based on demand, particularly if users are adaptive Network should price services based on QoS, or resources consumed to provide a certain QoS, and allocate resources based on user willingness-to-pay. Pricing should also serve as a signal and/or incentive for users to adapt All of the above translate to two main requirements: ….. 9/22/2018 Xin Wang, Columbia University Xin Wang, Columbia University

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 Xin Wang, Columbia University Xin Wang, Columbia University

What We Add... (cont’d) Demonstrate a complete resource negotiation framework (RNAP, pricing model, user adaptation) on test-bed network Show significant advantages relative to static resource allocation and fixed pricing using simulations: 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 Xin Wang, Columbia University Xin Wang, Columbia University

Outline Background RNAP: architecture and messaging Pricing models:
Comparison of models Proposed pricing model User adaptation Testbed demonstration of Resource Negotiation Framework Simulation and discussion of Resource Negotiation Framework Resource Negotiation Framework 9/22/2018 Xin Wang, Columbia University Xin Wang, Columbia University

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 Xin Wang, Columbia University Xin Wang, Columbia University

Protocol Architectures: Distributed (RNAP-D)
Local Resource Negotiator 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) are implemented at 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 Xin Wang, Columbia University Xin Wang, Columbia University

Close: Tears down negotiation session
RNAP Messages 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: Confirms 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 Xin Wang, Columbia University Xin Wang, Columbia University

Message Aggregation (RNAP-D)
Turn off router alert Turn on router alert Edge Routers Sink-tree-based aggregation 9/22/2018 Xin Wang, Columbia University Xin Wang, Columbia University

Message Aggregation (RNAP-D)
Turn on router alert Turn off router alert Sink-tree-based aggregation 9/22/2018 Xin Wang, Columbia University Xin Wang, Columbia University

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 Xin Wang, Columbia University Xin Wang, Columbia University

Bandwidth time 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 Xin Wang, Columbia University Xin Wang, Columbia University

Comparison of models Proposed pricing model User adaptation Testbed demonstration of Resource Negotiation Framework Simulation and discussion of Resource Negotiation Framework Resource Negotiation Framework 9/22/2018 Xin Wang, Columbia University Xin Wang, Columbia University

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 works 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 Xin Wang, Columbia University Xin Wang, Columbia University

Two Volume-based Pricing Strategies
Fixed-Price (FP): fixed unit volume price Flat pricing (FP-FL): same per-byte charge 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 Xin Wang, Columbia University Xin Wang, Columbia University

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 Xin Wang, Columbia University Xin Wang, Columbia University

Proposed 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: maximize the provider’s profit, constrained by resource availability 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 Xin Wang, Columbia University Xin Wang, Columbia University

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 Xin Wang, Columbia University Xin Wang, Columbia University

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 Xin Wang, Columbia University Xin Wang, Columbia University

Congestion Price: Second Mechanism - M-bid Second-price Auction
Auction models in literature: Assume unique bandwidth/price preference, one bid Service uncertainty: user does not know about high demand until rejected Other issues: setup delay, signaling burst, one-time auction, user response to auction results 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 Periodic auctions - support congestion control Inter-auction admission to reduce setup delay 9/22/2018 Xin Wang, Columbia University Xin Wang, Columbia University

Example of M-bid Auction
Total capacity 70, congestion price is 2 Bid Bandwidth Bid Price Bidder Bid Selection 5 10 1 10 2 4 15 1 4 20 3 3.5 25 2 3 Cutoff 2 30 3 Congestion Price 9/22/2018 Xin Wang, Columbia University Xin Wang, Columbia University

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 Xin Wang, Columbia University Xin Wang, Columbia University

Rate Adaptation of Multimedia System
Gain optimal perceptual value of the system 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 Xin Wang, Columbia University Xin Wang, Columbia University

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 Xin Wang, Columbia University Xin Wang, Columbia University

Two Rate-Adaptation Models
Model1: User adaptation under CPA-TAT (tatonnement-based pricing) Optimize perceived surplus of the multimedia system subject to budget and application requirements With the example utility functions, resource request of application i: Without budget constraint: x i = i / pi With budget constraint: x i = bi / pi, with b i = b ( i / Σl  k ) Model2: User adaptation under CPA-AUC (second-price auction) Submit M-bid derived by sampling utility function; adapt rate based on allocated bandwidth/QoS 9/22/2018 Xin Wang, Columbia University Xin Wang, Columbia University

Stability and Oscillation Reduction
Congestion-sensitive pricing has been shown to be stable Oscillation reduction Users: re-negotiate only if price change exceeds a given threshold Networks: update price only when traffic change exceeds a threshold; negotiate resources in larger blocks between domains just say “we have shown our Congestion-sensitive mechanism to result in a stable price”, otherwise it looks like a paper 9/22/2018 Xin Wang, Columbia University Xin Wang, Columbia University

Testbed Architecture Demonstrate functionality and performance improvement: blocking rate, loss, delay, price stability, perceived media quality Host HRN negotiates for a system Host processes (HRN, VIC, RAT) communicate through Mbus Network Router: FreeBSD ALTQ 2.2, CBQ extended for DiffServ NRN: (1) Process RNAP messages; (2) Admission control, monitor statistics, compute price; (3) At edge, dynamically configure the conditioners and form charge Inter-entity signaling: RNAP RAT VIC Mbus HRN RNAP NRN The main objective behind our testbed work was to demonstrate the functionality of our resource negotiation framework, including RNAP, pricing, and user adaptation. We were also able to demonstrate performance improvements relative to a non-adaptive, fixed-price environment in terms of blocking rate, average loss and delay, price stability, and perceived media quality . I’ll discuss the testbed work very briefly in the next few slides, talking about the fumctions implemented in the routers, the implementation of the NRNs (the network agents in RNA), and performance results obtained by monitoring the network states 9/22/2018 Xin Wang, Columbia University Xin Wang, Columbia University

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 Xin Wang, Columbia University Xin Wang, Columbia University

Functions of Network Resource Negotiator (NRN)
Process RNAP messages 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 Xin Wang, Columbia University Xin Wang, Columbia University

Network States Per-class bandwidth and price variations
Reduction in blocking due to adaptation Can you write some notes for this one? 9/22/2018 Xin Wang, Columbia University Xin Wang, Columbia University

Simulation Design Performance comparison: Four groups of experiments:
Network with dynamic service negotiation 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 load; (2) Effect of admission control ; (3) Effect of traffic burstiness; (4) Load balance between classes; 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 Xin Wang, Columbia University Xin Wang, Columbia University

Simulation Models Network Simulator (NS-2)
Weighted Round Robin (WRR) scheduler Three classes: EF, AF, BE EF: tail dropping, load threshold 40%, delay bound 2 ms, loss bound 10-6 AF: RED-with-In-Out (RIO), load threshold 60%, delay bound 5 ms, loss bound 10-4 BE: Random Early Detection (RED), load threshold 90%, delay bound 100 ms, loss bound 10-2 Sources: mix of on-off traffic and Pareto on-off traffic (shape parameter: 1.5) Negotiation period: 30 s, session length 10 min 9/22/2018 Xin Wang, Columbia University Xin Wang, Columbia University

Simulation Architecture
Topology 1 (60 users) Topology 2 (360 users) 9/22/2018 Xin Wang, Columbia University Xin Wang, Columbia University

Effect of Traffic Load Average packet loss Average packet delay
9/22/2018 Xin Wang, Columbia University Xin Wang, Columbia University

Effect of Admission Control
Average packet delay Average packet loss 9/22/2018 Xin Wang, Columbia University Xin Wang, Columbia University

Average price and standard deviation
Effect of Admission Control (cont’d) Average price and standard deviation Blocking rate 9/22/2018 Xin Wang, Columbia University Xin Wang, Columbia University

Effect of Admission Control (cont’d)
Network revenue Average user benefit 9/22/2018 Xin Wang, Columbia University Xin Wang, Columbia University

Effect of Traffic Burstiness

Load Balance Between Classes

Simulation Results Congestion-price-based policy (CPA) + user adaptation vs Fixed price policy (FP) + no adaptation: limit congestion lower request blocking rate, higher user satisfaction higher network revenue Differentiated service requires different target loads in each class Even without admission control, CPA policy restricts load to targeted level, can meet service assurance With admission control, blocking rate and price dynamics further reduced Allowing service class migration allows for service assurance at predicted level and further stabilizes price 9/22/2018 Xin Wang, Columbia University Xin Wang, Columbia University

Other Results Users with different demand elasticity share bandwidth proportional to their willingness to pay Even a small proportion of adaptive users (e.g 25%) results in a significant performance improvement for the entire user population (18% improvement) Performance of CPA further improves as the network scales and more connections share the resources Both M-bid auction and tatonnement process can be used to calculate the congestion price; auction gives higher perceived user benefit and network utilization at cost of implementation complexity and setup delay 9/22/2018 Xin Wang, Columbia University Xin Wang, Columbia University

Conclusions Proposed a dynamic resource negotiation framework incorporating: A Resource Negotiation And Pricing protocol (RNAP) A rate and QoS adaptation model for adaptive applications A long-term pricing model and congestion-control pricing 9/22/2018 Xin Wang, Columbia University Xin Wang, Columbia University

Conclusions (cont’d) RNAP
Supports dynamic service negotiation between network and adaptive/non-adaptive users, and between peer networks Includes mechanisms for price and charge collation, auction bids and results distribution Allows 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 9/22/2018 Xin Wang, Columbia University Xin Wang, Columbia University

Conclusions (cont’d) Pricing models User adaptation
Based on resources consumed by service class relative to long-term user demand Congestion-sensitive component to motivate user demand adaptation during resource scarcity M-bid Auction Model serves more users than comparable auction schemes, and eliminates uncertainty of service availability User adaptation A rate and service adaptation model to maximize perceived user satisfaction in response to price changes 9/22/2018 Xin Wang, Columbia University Xin Wang, Columbia University

Conclusions (cont’d) Simulations compare proposed framework with static pricing+non-adaptive applications: Effectively limits congestion, allows for service assurance under high and bursty load Provide lower blocking rate, higher user satisfaction and network revenue Performance improves with number of connections. Admission control and inter-service class adaptation give further improvements in blocking rate and price stability Testbed implementation with multimedia system demonstrates functionality of framework Stable pricing, congestion control Improvements in blocking rate, average loss and delay, perceived media quality compared to static pricing+non-adaptive framework 9/22/2018 Xin Wang, Columbia University Xin Wang, Columbia University

Further Work Interaction of short-term resource negotiation with longer-term network provision A light-weight resource management protocol Cost distribution in QoS-enhanced multicast network Pricing and service negotiation in the presence of alternative data paths or competing networks User valuation models for different QoS Resource provisioning in wireless environment 9/22/2018 Xin Wang, Columbia University Xin Wang, Columbia University

Some References X. Wang, H. Schulzrinne, “Auction or Tatonnement - 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, 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 X. Wang, H. Schulzrinne, “Comparison of Adaptive Internet Multimedia Applications,” IEICE Transactions on Communications, Vol. E82-B, No. 6, pp , June 1999. 9/22/2018 Xin Wang, Columbia University Xin Wang, Columbia University

Measurements and Analysis of
LDAP Performance Xin Wang Internet Real -Time Laboratory Columbia University Joint work with Henning Schulzrinne (Columbia university) Dilip Kandlur, and Dinesh Verma (IBM Research) Xin Wang, Columbia University

Motivation and Experiment
Lightweight Directory Access Protocol (LDAP): widely used, but little study of performance Our work: developed a benchmark tool to analyze the performance of LDAP 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 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 Xin Wang, Columbia University Xin Wang, Columbia University

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 Xin Wang, Columbia University Xin Wang, Columbia University

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 Xin Wang, Columbia University Xin Wang, Columbia University

IP Multicast Fault Recovery
in PIM over OSPF Xin Wang Internet Real -Time Laboratory Columbia University Joint work with Chien-ming Yu (Microsoft) Henning Schulzrinne (Columbia) Paul Stirpe and Wei Wu (Reuters) Xin Wang, Columbia University

Motivation and Experiment
Many IP multicast applications require high availability Study failure recovery in a complete architecture: IGMP + OSPF (unicast) + PIM (multicast) Focus: the interplay of underlying protocols; the interactions of failure recovery, between routers, links, 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 Xin Wang, Columbia University Xin Wang, Columbia University

Result (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 Xin Wang, Columbia University Xin Wang, Columbia University

Result (Cont’d) PIM Enhancement for Fault Recovery
Fast recovery from Dedicated Router (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 records the last-hop router address, does not wait for an IGMP report to reactivate its oif to the LAN Use interrupts instead of polling to reduce delay 9/22/2018 Xin Wang, Columbia University Xin Wang, Columbia University

Questions and Answers Thanks ! Xin Wang, Columbia University

Scalable Network Architecture & Measurements

Similar presentations

Presentation on theme: "Scalable Network Architecture & Measurements"— Presentation transcript:

Similar presentations

About project

Feedback

Log in

Auth with social network:

Scalable Network Architecture & Measurements

Similar presentations

Presentation on theme: "Scalable Network Architecture & Measurements"— Presentation transcript:

Similar presentations

About project

Feedback