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…. 11/29/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 11/29/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. 11/29/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. 11/29/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 Statistics shows …. Even though average utilization is only 20-30% the peak …. The reasons for the congestion are: 11/29/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. 11/29/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 No intrinsic upper limit on bandwidth use So, as we have seen, 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 In addition, 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. Another option: manage the existing bandwidth more efficiently Option - manage the existing bandwidth better, with a service model which uses bandwidth efficiently. 11/29/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 How to manage multiple service more efficiently? How much to charge a service? Application adaptation Source rate adaptation based on network conditions - congestion control and efficient bandwidth utilization Best effort service Why would an application adapt? Two models currently can lead to more efficent bandwidth usage: QoS and Application adaptation 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 Literature work in multimedia adaptation assumes best effort service, users are well-behaved, would adapt even without any incentive 11/29/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 - service providers need to provide 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 and network conditions, 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: ….. 11/29/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 Includes mechanisms for price and charge collation, auction bids and results distribution 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 Our work: We designed a A dynamic resource negotiation protocol: RNAP to enable to provide Service predictability to support Multi-party negotiation to be Reliable and scalable to be Lightweight and flexible: embedded in other protocols, e.g., RSVP, or implemented independently We proposed A demand-sensitive pricing model which supports differential charging for multiple levels of services, reflecting the cost and long-term user demand The model also allows for congestion pricing to motivate user adaptation 11/29/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 Our work: We demonstrate a complete resource negotiation framework on test-bed network We show significant advantages of this framework relative to static resource allocation and fixed pricing using simulations. The resource negotiation framework provides much lower service blocking rate under resource contention, provides service assurances even under large or bursty offered loads. It provides higher perceived user benefit and higher network revenue 11/29/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 11/29/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 11/29/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. At network edge, LRNs dynamically configure traffic conditioners, based on on-going user requests. Internal Router Transit Domain 11/29/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 We presents the messaging sequence between the users and network. This sequence also works between two network domains. If users do not need to find the service information, it could directly send the reserve message, instead of sending Query and wait for Quotation message first. If a user request negotiation functionality from network, the network will periodically provides the users with updated network status, allowing users to modify their requests. Commit Close: Tears down negotiation session Close Release: Releases the resources Release 11/29/2018 Xin Wang, Columbia University Xin Wang, Columbia University

Message Aggregation (RNAP-D)
Turn off router alert Turn on router alert If each flow needs a RNAP session, it can’t scale. We consider a sink-tree based aggregation mechanism: aggregate messages when senders share the same destination network Messages merged by source or intermediate domains At network edge, the router alert function is turned off. As a result, the original per-flow messages will be tunneled directly to the destination network, without interception by intermediate RNAP agents; aggregate message reserves and collects price at intermediate nodes/domains Messages de-aggregated at destination border routers (RNAP-D), or NRNs (RNAP-C) Overhead Reduction Processing overhead, storage of states Edge Routers Sink-tree-based aggregation 11/29/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 11/29/2018 Xin Wang, Columbia University Xin Wang, Columbia University

Message Aggregation (RNAP-C)
We use the RNAP-D as an example, the aggregation process is similar for RNAP-C, but with the NRN performing the aggregation and de-aggregation NRN Sink-tree-based aggregation 11/29/2018 Xin Wang, Columbia University Xin Wang, Columbia University

Block Negotiation (Network-Network)
Aggregated resources are added/removed in large blocks to minimize negotiation overhead and reduce network dynamics Bandwidth In the above aggregation scheme, all the flows need to be synchronized, which is not practical. Each flow arrival will modify the aggregation message, resulting high overhead. In practice, we proposed to use the block negotiation mechanism: aggregated resources are added/removed in large blocks to minimize negotiation overhead and reduce network dynamics time 11/29/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 11/29/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 11/29/2018 Xin Wang, Columbia University Xin Wang, Columbia University

Two Volume-based Pricing Strategies
Fixed-Price (FP): fixed unit volume price During congestion: higher blocking rate OR higher dropping rate and delay Congestion-dependent-Price (CP): FP + congestion-sensitive price component 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 During resource contention, fixed price based frame work can only block the future arrivals or drop and delay the packets that have arrived. If adaptive pricing is allowed, there are some other options for users: 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. As a result, the blocking rate and average packet loss and delay of the whole network can get improved. We will show this later in our simulation. 11/29/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 11/29/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) We proposed a pricing model, which comprise holding price, usage price and congestion price: The holding price is set to be proportional to the difference of the usage price of two neighboring service classes The usage price is set to maximize the network revenue, under the constraint of network resources. The congestion price is set to drive user demand to the target network resource utilization We will consider the usage price and congestion price setup in more details. 11/29/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) For an environment with multiple service classes, a class with lower target utilization level will provide higher QoS expectation, but it will also involve higher bandwidth cost Assume bandwidth are fully used, and the basic price is pbasic; , assume the expected load of s service class is  j the price of a service class can be set to be reverse proportional to the target load of a service class If we assume the fixed elasticity user demand, that is the user demand will be reverse proportional to the usage price of the bandwidth, we can obtain the effective bandwidth usage as: xe j ( puj ) = Aj / ( puj  j ) If we set the price so that the network revenue is optimized, we can obtain the basic bandwidth price as … the price of a class is inverse proportional to the target load of the class, as we have seen earlier. 11/29/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) We consider two models for setting up the congestion price In the tatonnement model, the congestion price is adjusted that the demand is driven to the supply. Generally, there is an upper limit of the congestion price. 11/29/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, user response to auction results M-bid auction Model User bids (bandwidth, price) for a number of bandwidths, bids obtained by sampling utility function. Reduce uncertainty 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 We proposed an M-bid auction model, which is particularly useful for adaptive applications, with multiple preferences for different bandwidth. An application normally has higher value to the basic bandwidth, and hence would bid higher price for basic bandwidth. During network contention, the higher price bids get selected, and hence the most valued bandwidth get supported first, and hence more users could be allocated with their valuable bandwidth This model also support short-term resource auction, and allows inter-auction admission to reduce setup delay: as long as one bid from a user is higher than the recent bidding price, the user’s request can get admitted 11/29/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 11/29/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 11/29/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 Utility function: users’ preference or willingness to pay Cost U1 U2 Utility/cost/budget U3 Budget Bandwidth 11/29/2018 Xin Wang, Columbia University Xin Wang, Columbia University

Example Utility Function
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 11/29/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 When the total resource requirements of all applications are within user’s budget, the resource allocated is set to be the user’s willingness to pay bandwidth 11/29/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 11/29/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 11/29/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. 11/29/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 11/29/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? 11/29/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 11/29/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 11/29/2018 Xin Wang, Columbia University Xin Wang, Columbia University

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

Effect of Traffic Load Average packet loss Average packet delay
Without admission control, we can see the delay and loss increase almost linearly when the load is beyond the target level, and the targeted service are seriously violated. If adaptive framework is used, all the targeted service are assured 11/29/2018 Xin Wang, Columbia University Xin Wang, Columbia University

Effect of Admission Control
Average packet delay Average packet loss With admission control the loss and delay can be maintained at target level even under high load. 11/29/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 This is at the cost of higher user blocking rate. Combining admission control and user adaptation, the blocking rate can be greatly reduced (up to 40 times) Compared to without admission control, the price dynamics is reduced for the dynamic pricing scheme. 11/29/2018 Xin Wang, Columbia University Xin Wang, Columbia University

Effect of Admission Control (cont’d)
Network revenue Average user benefit The network revenue is kept almost constant when admission control is used, since the load above targeted level is blocked. The CPA framework gain much higher revenue since it serves the high valued customers. Since we have using the example user utility function that is sensitive to the loss and delay, the average user benefit of the static service drop sharply due to the higher loss and delay at high load. 11/29/2018 Xin Wang, Columbia University Xin Wang, Columbia University

Effect of Traffic Burstiness
Average packet delay Average packet loss (Don’t need to explain this slide and next slide in detail to save time) The trend are similar for burstiness case and when allowing the user to shift to difference classes. Even only 10% of users are encouraged to shift to different classes, the overall QoS level for a service class can be maintained. 11/29/2018 Xin Wang, Columbia University Xin Wang, Columbia University

Load Balance Between Classes
Average packet delay Average packet loss 11/29/2018 Xin Wang, Columbia University Xin Wang, Columbia University

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 The simulation results indicate that the proposed negotiation framework can effectively limit congestion, provide lower request blocking rate, higher user satisfaction and higher network revenue For providing some qualitative expectation of the service level, a class needs to restrict the load to the targeted level, with admission control, or to encourage user to back off. 11/29/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 11/29/2018 Xin Wang, Columbia University Xin Wang, Columbia University

Conclusions Proposed a dynamic resource negotiation framework: A Resource Negotiation And Pricing protocol (RNAP) , a rate and QoS adaptation model, and a pricing model RNAP: Supports dynamic service negotiation between network and users, and between peer networks Pricing models Based on resources consumed by service class and long-term user demand, including congestion-sensitive component to motivate user demand adaptation during resource contention M-bid Auction Model serves more users than comparable auction schemes, and reduces uncertainty of service availability User adaptation: maximize perceived user satisfaction 11/29/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 11/29/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 11/29/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. 11/29/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 11/29/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 11/29/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. 11/29/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. 11/29/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. 11/29/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 11/29/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