shivkumar kalyanaraman rensselaer polytechnic institute 1 edge-based traffic management building...

Shivkumar KalyanaramanRensselaer 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

EI

E

Logical FIFO

B


2

Private Networks vs Public Networks QoS vs Congestion Control: the middle ground ?

Overlay Bandwidth Services: Key: deployment advantages A closed-loop QoS building block

Services: Better best-effort services, Assured services, Quasi-leased lines…

Overview


3

Motivation: Site-to-Site VPN Over a Multi-Provider Internetwork

International Linkor

International Linkor


4

Private networks over Public networks Can we reduce (not eliminate !) coordination requirements

for QoS deployment? Tolerate heterogeneity Incremental deployment Faster deployment cycles Dynamically provisioned services

Complexity Issues: Design: int-serv, RSVP, RTP … Implementation: diff-serv, CSFQ… Upgrades Configuration Management

Focus of this talk!


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


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


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


8

Queuing Behavior: Without Closed-loop Control

End system

Bottleneckqueue


9

Queuing Behavior: With Overlay Edge-Edge Control

edge devices

Results: efficient core operation, rate adaptation in O(RTT)


10

Edge-based Performance Customization Key idea: bottlenecks consolidated at edges, closer to application => incorporate application-awareness in QoS

Eg: L4-L7 aware buffer management. For TCP traffic: dramatically reduce timeouts:

Do not drop retransmissions or small window packets

Potential: application-level QoS services, active networking, edge-based diff-serv PHB emulation etc


11

Closed-loop Building Block Reqts

#1. Edge-to-edge overlay operation, #2. Robust stability #3. Bounded-buffer/zero-loss,

#4. Minimal configuration/upgrades + incremental deployment

#5. Rate-based operation: for bandwidth services

Not available in any congestion control scheme… Related work: NETBLT, TCP Vegas, Mo/Walrand, ATM

Rate/Credit approaches


12

Overlay Control: Concepts

Load: = i ; Capacity: ; Output Rates: i At all times: >= i (single bottleneck)

During congestion epochs, set i < i, Eg: i = min{i , i} Single bottleneck: Reverse queue growth within 1 RTT

Key: detect congestion: a) purely at the edges => overlay technology b) detect in a loss-less manner!

i

1

.

.

.

n

1

.

.

.

n


13

Implementation model

Overlay state: Edge-to-edge VL association at ingress and egress One token-bucket shaper (LBAP) per VL loop: Rate = i(t) ; burstiness:

Ingress Edge(Shapes edge-to-edge aggregate at rate i)

Egress Edge (feeds back measured rate i during congestion epochs)

Interior Node(modeled to identify congestion epochs)

i(t)

Ingress shaper

End-to-end traffic

ri(t)


14

Congestion Detection: Hypothetical Model

Mark all packets if the interior queue crosses N N is upper bound on transient burstiness during underload (I.e.

when i < )

If any marked packets seen by egress edge during measurement interval , i is fed back: begin epoch

If marked packets are not seen for a full interval , declare end of epoch and stop feedback of i.

Ingress Edge(Shapes edge-to-edge aggregateat rate i)

Egress Edge (feeds back measured rate i during congestion epochs)

Interior Node(helps identify congestion epochs)


15

Impln: Overlay Congestion Detection Emulate prior model, albeit without Interior assist

N: aggregate burstiness bound : per-VL accumulation bound.

Congestion epoch beginning: Measure per-VL accumulation qi = (i i) Per-VL accumulation qi exceeds 2 => epoch begins

Congestion epoch end: qi <= epoch ends Hysteresis helps ensure that queue drains


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


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


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


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…


20

Scalable Best-effort TCP Service


21

Isolation of Denial of Service/Flooding

TCP starting at 0.0s UDP flood starting at 5.0s


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


23

Bandwidth Assurances

Flow 1 with 4 Mbps assured + 3 Mbps best effort

Flow 2 with 3 Mbps best effort


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


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.


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


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.


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.


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

Edge-to-edge loops, queue bounds, policy/BB scalability, bridging approach to inter-domain QoS

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.


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


31

Summary

Private Networks vs Public Networks QoS vs Congestion Control vs Throwing bandwidth

QoS DeploymentL Simplified overlay QoS architecture

Intangibles: deployment, configuration advantages Edge-based Building Blocks & Overlay services:

A closed-loop QoS building block Basic services, advanced services

shivkumar kalyanaraman rensselaer polytechnic institute 1 edge-based traffic management building...

Documents