Today’s last mile The perils of the fixed pricing model Trade & Cap: A Custom er- Managed, Market- Based System for Trading Bandw idth Allow ances at a Shared Link � It’s here to stay; metered pricing rejected Azer Bestavros Computer Science Department � Implications: Boston University Joint work with � Customer has no incentive to save bandwidth Jorge Londono (BU � U Pontificia Bolivariana) Jorge Londono (BU � U Pontificia Bolivariana) � I SP cost depends on peak demand – 95/ 5 rule Nikos Laoutaris (BU � Telefonica) � Reigning in bandwidth hogs is incompatible with Net Neutrality � Must devise mechanism s that take ISPs out of the “traffic shaping” business http:/ / w w w .cs.bu.edu/ groups/ w ing Usenix/ ACM NetEcon’10, Vancouver, Canada October 3, 2010 October 3, 2010 Trade and Cap @ Usenix/ ACM NetEcon'10 2 October 3, 2010 Trade and Cap @ Usenix/ ACM NetEcon'10 3 3 DSLAM “last-mile” architecture Solution: Create a marketplace The Marketplace � Recognize the two types of user traffic: � Each user gets a fixed budget per epoch � Reserved Traffic (RT) � Budget proportional to level of service � For interactive browsing, VoI P, messaging, gaming, … � An epoch is a fixed number of time-slots, � Limited bandwidth; highly sensitive to response time e.g., 1 day = 288 5-min slots � Fluid Traffic (FT) � Fluid Traffic (FT) Broadband Remote � P2P, Network backup, Netflix/ software downloads, … Access Server DSL Access � Trade & Cap Multiplexer � Open-ended bandwidth; less sensitive to response time � User engages in a pure strategies game that yields a schedule for its RT bandwidth � Create a marketplace: Traffic shaping done at BRAS � User acquires as much FT bandwidth as its 1. Give users rights to DSLAM bandwidth, and remaining budget would allow 2. Let users trade RT/ FT allocations over time October 3, 2010 Trade and Cap @ Usenix/ ACM NetEcon'10 4 October 3, 2010 Trade and Cap @ Usenix/ ACM NetEcon'10 5 October 3, 2010 Trade and Cap @ Usenix/ ACM NetEcon'10 6 1
Trading Phase: Strategy Space Trading Phase: Cost Function Trading Phase: Illustration � Session: � Let x ik be the bandwidth used in slot k by a chosen RT session schedule for user i . An RT session is the sequence of slots during which an RT Cost(User 2) = 6 application is active � The cost incurred by user i is given by: � Slack: ⎛ ⎛ ⎞ ⎞ ∑ ∑ ∑ ⎜ ⎜ ⎟ ⎟ = ⋅ = c x U x x User may have flexibility in scheduling RT sessions; slack ⎜ ⎟ i ik k ik jk User 2 User 2 specifies the number of slots that an RT session is allowed to ⎝ ⎠ k ∈ slots k ∈ slots j ∈ users be shifted back/ forth � Cost of user i depends on the choices User 1 User 1 � Strategy Space: made by other users – hence the game! The set of all possible arrangements of RT sessions within allowable slack define the strategy space for a user U p 2 2 0 0 1 1 2 0 October 3, 2010 Trade and Cap @ Usenix/ ACM NetEcon'10 7 October 3, 2010 Trade and Cap @ Usenix/ ACM NetEcon'10 8 October 3, 2010 Trade and Cap @ Usenix/ ACM NetEcon'10 9 9 Trading Phase: Illustration Trading Phase: Best Response Trading Phase: Findings � BR of user i is a schedule of RT sessions � Provably converges to Nash Equilibrium, that minimizes its cost c i even in presence of constraints Cost(User 2) = 4 � Computing BR is NP-hard, equivalent to � For n users, Price of Anarchy is n , but in practice below 2, especially for n > 10 solving a generalized knapsack problem � Dynamic programming solution is � Experimentally, large reduction of peak User 2 User 2 pseudo-polynomial in the product of the utilization, even with small flexibility number of sessions and number of slots User 1 User 1 � Scales well for all practical settings – 100s of users and 100s of slots U p 1 2 1 0 1 1 1 1 October 3, 2010 Trade and Cap @ Usenix/ ACM NetEcon'10 10 October 3, 2010 Trade and Cap @ Usenix/ ACM NetEcon'10 11 11 October 3, 2010 Trade and Cap @ Usenix/ ACM NetEcon'10 12 2
Capping Phase: Best Response Capping Phase: Budget Capping Phase: Findings � Let V be some desirable upper bound on the � BR of user i is to maximize total FT � Locally computing BR is efficient using total traffic per slot allocation Lagrange Multipliers method ∑ = w w � The ISP sets a target capacity C = V / R , � Provably, converges to a unique global i ik where R ≥ 1 reflects its “resistance” to traffic ∈ k slots ( (social) optimum that maximizes the FT ) p � Th ISP ll � The ISP allocates C in some proportion C i t ti allocations of all users (thus could be subject to the budget constraint (e.g., equally) to all n users over all slots done centrally by ISP) ⎛ ⎞ ∑ ∑ � This constitutes the budget B assigned to a ⋅ ⎜ + ⎟ = − w U w B c ⎜ ⎟ � Experimentally, smoothes the aggregate ik jk i i user over an epoch T 0 ⎝ ⎠ ∈ ∈ k slots j users RT+ FT traffic to any desirable level C = ⋅ B T controlled by the resistance parameter R n October 3, 2010 Trade and Cap @ Usenix/ ACM NetEcon'10 13 October 3, 2010 Trade and Cap @ Usenix/ ACM NetEcon'10 14 October 3, 2010 Trade and Cap @ Usenix/ ACM NetEcon'10 15 Trade & Cap: Implementation Trade & Cap: Implementation Trade & Cap: Implementation notes � On Client Side (e.g., DSL Modem): � User Input: Trace-driven Linux Boxes � As simple as checking box to join marketplace, + Strategic agent to execute Trade & Cap workload and as elaborate as micromanaging RT slacks + Operational service to profile, classify, and shape � May set a fraction of “budget” as insurance Bulk traffic � Client-side Profiler: � Client side Profiler: � May be explicitly controlled by applications (or I nteractive traffic user settings) � Client-side Traffic Shaper: � ISP Side (e.g., DSLAM or BRAS): � Work-conserving (not reservation based) Linux + Support exchange between strategic agents Hierarchical Token Bucket (HTB) + Enforce total traffic/ slot/ user from Trade & Cap � Allows FT to use underutilized RT bandwidth October 3, 2010 Trade and Cap @ Usenix/ ACM NetEcon'10 16 October 3, 2010 Trade and Cap @ Usenix/ ACM NetEcon'10 17 October 3, 2010 Trade and Cap @ Usenix/ ACM NetEcon'10 18 3
Experimental Evaluation Trading Phase: Experimental PoA Trading Phase: Smoothing effect Max Reduction Workload Slack in 9 5 % Value proposition to ISPs Derived from WAN traces Over 5 slots Over 10 slots 3 15% of MAWI project† 6 24% � I dentify users from volume 12 31% and direction of flows to kno known ports (e.g., most n po ts (e g most 0.95 traffic destined to port 80) Traffic Volume / Slot � I dentify user RT sessions using thresholds on per-IP CDF traffic intensities over time � Slack introduced using Theoretical PoA is n but not in practice various models (e.g., fixed, proportional, etc.) † Reported results are negatively impacted by less-than-ideal (atypical) trace. Time Slot Traffic Volume / Slot October 3, 2010 Trade and Cap @ Usenix/ ACM NetEcon'10 19 October 3, 2010 Trade and Cap @ Usenix/ ACM NetEcon'10 20 October 3, 2010 Trade and Cap @ Usenix/ ACM NetEcon'10 21 Trade & Cap: Flexibility pays off! Trade & Cap Trade & Cap: Beyond DSLAMs � Trade & Cap is a general mechanism Value proposition to customers A win-win for ISPs and customers I t can be used to coordinate how a shared resource is used by selfish parties who are not subject to raffic (FT) Volume the “pay as you go” model – e.g., “fixed pricing” Normalized Traffic V Normalized Fluid Tr � Examples � Coordinating consumption of “reserved” versus “fluid” (CPU/ network) capacities of VMs sharing a single host � Coordinating “reserved” versus “fluid” bandwidth utilization by multiple I SP customers (e.g., enterprises) Total Reserved Traffic (RT) in MB Time Slot October 3, 2010 Trade and Cap @ Usenix/ ACM NetEcon'10 22 October 3, 2010 Trade and Cap @ Usenix/ ACM NetEcon'10 23 October 3, 2010 Trade and Cap @ Usenix/ ACM NetEcon'10 24 4
Recommend
More recommend
