Shivkumar Kalyanaraman Rensselaer Polytechnic Institute 1 Edge-based Traffic Management Building Blocks David Harrison, Shiv Kalyanaraman, Sthanu Ramakrishnan Rensselaer Polytechnic Institute [email protected]http://www.ecse.rpi.edu/Homepages/shivkuma I E I E I E Logical FIFO B
31
Embed
Shivkumar Kalyanaraman Rensselaer Polytechnic Institute 1 Edge-based Traffic Management Building Blocks David Harrison, Shiv Kalyanaraman, Sthanu Ramakrishnan.
This document is posted to help you gain knowledge. Please leave a comment to let me know what you think about it! Share it to your friends and learn new things together.
Transcript
Shivkumar KalyanaramanRensselaer Polytechnic Institute
1
Edge-based Traffic Management Building Blocks
David Harrison, Shiv Kalyanaraman, Sthanu Ramakrishnan
Shivkumar KalyanaramanRensselaer Polytechnic Institute
5
Problem: Inter-domain QoS Deployment Complexity
Solutions: Enable incrementally deployable edge-based QoS New closed-loop building blocks for efficiency Reduce (not eliminate!) coordination reqts. No upgrades!Tradeoffs: limited service spectrum
Today’s solutions require upgrade of multiple potential bottlenecks, and complex multi-provider coordination
Internetwork or WANWorkstationRouter
Router
RouterWorkstation
Router
Router
Shivkumar KalyanaramanRensselaer Polytechnic Institute
6
Our Model: Edge-based building blocks
New: Closed-loop control !Policy/Bandwidth Broker
I E
I
EI
E
Logical FIFO
B
Model: Inspired by diff-serv; Aim: further interior simplification
Shivkumar KalyanaramanRensselaer Polytechnic Institute
7
Closed-loop BB: Take-Home Ideas
FIFO
B
Loops: differentiate service on an RTT-by-RTT basis using edge-based policy configuration.
B
Priority/WFQ
Scheduler: differentiates service on a packet-by-packet basis
Shivkumar KalyanaramanRensselaer Polytechnic Institute
8
Queuing Behavior: Without Closed-loop Control
End system
Bottleneckqueue
Shivkumar KalyanaramanRensselaer Polytechnic Institute
9
Queuing Behavior: With Overlay Edge-Edge Control
edge devices
Results: efficient core operation, rate adaptation in O(RTT)
Shivkumar KalyanaramanRensselaer Polytechnic Institute
10
Edge-based Performance Customization Key idea: bottlenecks consolidated at edges, closer to application => incorporate application-awareness in QoS
Shivkumar KalyanaramanRensselaer Polytechnic Institute
16
Increase/Decrease Dynamics Increase:
Additive increase of 1 pkt/ every interval ( >= RTT) Decrease:
i = min{i, i } every interval during the congestion epoch Properties (single bottleneck):
queue guaranteed to reduce within of feedback The lower rate is held till queue is drained
Input Rate Dynamics
i
time
i
can be set larger than 0.5
Shivkumar KalyanaramanRensselaer Polytechnic Institute
17
1
n n
1
+ -
+
1
n
)(ta n
Bottleneck { j }, Q ueue = q, Q ueue contribution of flow i = q
f
1
n
i F low { i}, Accum ulation = a , Input R ate = , O utput R ate =i i
D elay
j ji
i
Multi-bottleneck stability
Incremental drain provisioned for incremental accumulation Sum of input rates upper bounded; output rates lower bounded
Shivkumar KalyanaramanRensselaer Polytechnic Institute
18
Multiple Bottleneck FairnessThroughput versus Number of Bottlenecks
Linear Network: 1 flow (VL) crosses k bottlenecks. Each bottleneck has 4 cross flows (VLs).
Min-potentialdelay fairness
Proportionalfairness
Edge-to-edgeControl
Shivkumar KalyanaramanRensselaer Polytechnic Institute
19
Overlay Bandwidth Services
Basic Services: no admission control “Better” best-effort services Denial-of-service attack isolation support Weighted proportional/priority services
Advanced services: edge-based admission control Assured service emulation “Quasi-leased-line” service
Key: no upgrades; only configuration reqts…
Shivkumar KalyanaramanRensselaer Polytechnic Institute
20
Scalable Best-effort TCP Service
Shivkumar KalyanaramanRensselaer Polytechnic Institute
21
Isolation of Denial of Service/Flooding
TCP starting at 0.0s UDP flood starting at 5.0s
Shivkumar KalyanaramanRensselaer Polytechnic Institute
22
Backoff Differentiation Policy:
Backoff little (as) when below assurance (a), Backoff (as) same as best effort when above assurance (a) Backoff differentiation quicker than increase differentiation
Service could be potentially oversubscribed (like frame-relay) Unsatisfied assurances just use heavier weight.
Edge-based Assured Service Emulation
1 > AS >BE >> 0
r =r + min(r, AS aa
if no congestion
if congestion
Shivkumar KalyanaramanRensselaer Polytechnic Institute
23
Bandwidth Assurances
Flow 1 with 4 Mbps assured + 3 Mbps best effort
Flow 2 with 3 Mbps best effort
Shivkumar KalyanaramanRensselaer Polytechnic Institute
24
Assume admission control and route-pinning (MPLS LSPs). Provide bandwidth guarantee. Key: No delay or jitter guarantees!
Adaptation in O(RTT) timescales Average delay can be managed by limiting total and per-
VL allocations (managed delay) Policy:
Quasi-Leased Line (QLL)
1 > BE >> 0
r =r + if no congestion
if congestionmax(aaa
Shivkumar KalyanaramanRensselaer Polytechnic Institute
25
Quasi-Leased Line Example
Background QLL starts with rate 50Mbps
Best-effort VL quickly adapts to new rate.
Best-effort rate limit versus time
Best-effort VL starts at t=0 and fully utilizes 100 Mbps bottleneck.
Shivkumar KalyanaramanRensselaer Polytechnic Institute
26
Quasi-Leased Line Example (cont)
Bottleneck queue versus time
Starting QLL incurs backlog.
Unlike TCP, VL traffic trunks backoff without requiring loss and without bottleneck assistance.
Requires more buffers: larger max queue
Shivkumar KalyanaramanRensselaer Polytechnic Institute
27
Quasi-Leased Line (cont.)
Worst-case queue vs Fraction of capacity for QLLs
Single bottleneck analysis:
q < b
1-bB/w-delay products
For b=.5, q=1 bw-rtt
Simulated QLL w/edge-to-edge control.
Shivkumar KalyanaramanRensselaer Polytechnic Institute
28
Signaling/Configuration Issues Simple: Each edge-box independently sets up loops only with
other edges it intends to communicate Address-prefix list based configuration for VPN application Minimal overhead to maintain the loop: a leaky bucket, 8-
bytes every 250 ms or so of overhead
ISP configures ONE separate class at potential bottlenecks for overlay controlled traffic
Scalable to inter-domain VPNs as long as each edge does not have to manage > 100s of loops
Properties: Bounded scalability, simplified interior configuration, incremental deployment, simple set of overlay services.
Shivkumar KalyanaramanRensselaer Polytechnic Institute
29
Edge-to-Edge Principle ? Tradeoff between public and private network philosophies: Private network characteristics:
Differentiated Svcs, simple forms of overlay QoS Bounded scalability and heterogeneity
Public network characteristics: Incremental deployment. O(1) complexity. Stateless interior inter-network Minimal interior upgrades, configuration support. Use of robust, stable closed-loop control for efficiency and
adaptation in O(RTT) timescales.
Shivkumar KalyanaramanRensselaer Polytechnic Institute
30
Current Work With bottlenecks consolidated at the edge:
What diff-serv PHBs or remote scheduler functionalities can be emulated from the edge ?
What is the impact of congestion control properties and rate of convergence on attainable set of services ?
Areas: Application-level QoS: edge-to-end problem Dynamic (short-term) services Congestion-sensitive pricing: congestion info at the edge
Edge-based contracting/bidding frameworks Point-to-set svcs: more economic value than pt-to-pt svcs
Dynamic provisioning for statistical muxing gains
Shivkumar KalyanaramanRensselaer Polytechnic Institute
31
Summary
Private Networks vs Public Networks QoS vs Congestion Control vs Throwing bandwidth