Back to the future with circuit switching

1
SECTION 11

• Back to the future with circuit switching

2
overview

• Multimedia requirements CSC 461
• Best-effort IP service as too-early binding
• RSVP
• Utility Model Optimal Admission Control problem

3
Textbook reading

• Section 16.3 RSVP

4
Optimal Admission Control forInternet
multimedia trafficthe best way to design a
controller

• Rob Watson , Mostofa Akbar, Doug Johnson,
  Shahadat Khan, Ali Shoja
• Eric Manning
• New Media Innovation Centre of B.C. and
• PANDA Lab
• University of Victoria

5
The problem

• Tech wreck , telecomm spending collapse
• Internet traffic continues to grow
• Too little of it attracts REVENUE! So,
• Got to find some new apps . . .
• Video on demand Blockbuster,
• videoconferencing since 9/11,
• Interactive video . . .

6
The Problem

• BUT
• multimedia applications like
• movies
• high-quality videoconference
• Web/video/audio hybrid forms
• have stringent Quality of Service requirements
  (data rate, latency, BER, etc)

7
But . . .

• Current InterNet cannot guarantee QoS
• IP datagram based
• Too-late binding of resources to datagrams

8
Dave Hudsons Nortel IdeaThe High Performance
Optical Overlay

• A second set of networks
• carries IP datagrams, but
• designed for guaranteed QoS
• augments the current InterNet

9
The High Performance Optical Overlay
Admission controller
High Performance Optical Overlay
Client-side content switch
InterNet
clients
10
Optical Overlay

• like Highway 401 North of Toronto
• free taxpayers pay collectivist
• no admission control
• no QoS versus
• Highway 407 Express Toll Route
• toll users pay free-market
• admission control
• QoS guarantee

11
The High Performance Optical Overlay

• Observations
• 1 must contain some form of real circuit
  construct fixed route, built before traffic
  flows
• else we cant bind resources to flows
• CANet 4, InterNet II architectures are,
  happily, circuit-switched
• 2 must limit resource consumption - e.g. by
  session admission control
• else we cant guarantee a session the resources
  necessary to deliver specified QoS level

12
Summary

• We seek Admission control algorithms which will
• guarantee QoS at some level to every admitted
  session, and
• admit upgrade sessions so as to optimize a
  network utility function e.g.
• constrained optimization problem

13
The Utility Model

• Original Purpose manage the consumption of
  resources in a multimedia server
• Examples CPU time and bus bandwidths
• Each session has a Service Level Agreement
• a list of sets of resource requirements
• One set per level of QoS AND
• a value of utility assigned to each set ()

14
QoS Levels

• Selection of a level of QoS
• (e. g. Gold, Silver or Bronze)
• implies
• value of utility to optimize
• (e.g. revenue in per hour) subject to
• set of resource requirements (constraints)

15
The Utility Model (UM) this famous figure
pinched by Jong-Wook Baek - IEEE Comm. Mag.,
March 01

session i
gold
bronze
silver
Quality Qi
session utility function
resource mapping
session utility ui(Qi)
session resources r (Qi)
system utility objective
system resource constraints
å r (Qi) R
16
Knapsack Problems (KP)

Volume p 39
17
Multidimensional Multiconstraint Knapsack
Problem (MMKP)


18
The Utility Model as an MMKP (Khans insight)
Let stones be sessions at QoS levels (Gold,
Silver, Bronze ) piles of stones be
sessions volume be multidimensional (multiple
resources) Choose one stone per pile to
maximize utility - usually revenue - (weight)
subject to all resource constraints
(multidimensional volume)
19
Solving the Adaptive Media Problem (deciding
which sessions to admit at which QoS levels to
optimize utility)

20
Solving the MMKP
algorithm BBLP gives optimal solutions -
slowly heuristic HEU gives approximate but fast
solutions - promising for real-time SLA
admission control
21
But what about the High Performance Optical
Overlay??
22

• Apply the Utility Model
• to the links of a data network
• resources to manipulate
• bandwidth (conserved) and latency (not conserved)
  of each link
• (instead of server cpu cycles, I/O bw and Mp
  bytes)

23
Problems

• Determine which path a proposed new or changed
  flow (e.g. an MPLS or RSVP flow ) should use,
  based on
• satisfaction of QoS constraints (feasibility)
  i.e.
• enough free bandwidth
• low enough latency on the path
• Optimal revenue utility
• Admission control decision - should the flow be
  admitted ? (Optimal utility )

24
Assumptions

• fixed latency ignore queuing
• simplifies things, can be relaxed
• adequate switch capacities
• ditto

25

Assumptions

• setup and teardown time for flows are
  negligible
• wont split a session over several paths

26

Assumptions

• Network supports fixed routing of flows, e.g.
  RSVP/CoS, MPLS, Int II
• (present InterNets best-effort datagram service
  considered harmful )
• Auctions good, fixed pricing bad

27
Observation

• In a non-sparse network, the number of paths that
  can satisfy the resource requirements for any
  given flow may be VERY large
• so bound the number of possibilities studied -
• heuristic, not algorithm

28
Methodby an example

29
An Example
N
30
An Example QoS requirement increases

• Assume that Flow (S, D) has increased by ?
• Given
• Former state of the network N
• Old new traffic matrices T and T
• Old routing table R of N including (S, D)
• All old link capacities

31

• Need to find
• (possibly) new routing for (S,D)
• and maybe other flows
• New link capacities
• New state of N , including revenue-optimal
  selection of (session, QoS_level) pairs

32
Tactics

• 1 change nothing
• Existing route has enough surplus capacity? else
• 2 try to re-route (S,D) changing nothing else
  (spare capacity elsewhere) , else
• 3 try rerouting (S,D) and other flows (Benes)
  , else
• 4 increase link capacities somewhere ()

33
To optimize revenue while respecting QoS
constraints

The Utility Model
34
Gory Details . . .Or skip to 39

35
1 2 try to re-route (S.D), changing nothing
else

• Look for paths (S,D) with spare capacity
• 1 existing path (S,D)

T(S,D) T D
36
1 2 try to re-route (S.D), changing nothing
else

• 2 other paths
• 1 generate paths P(S,D) which are short enough
  (acceptable latencies -- k shortest paths
  algorithms)

P
D
shortest
shortest 1
shortest 2
S
Find k of them
37
1 2 try to re-route (S.D), changing nothing
else

• Invoke UM on P to
• 2 find
• CAP bw

CAP
D
38
1 2 try to re-route (S.D), changing nothing
else

• 3 select cap in CAP of maximum revenue

cap
D
Max
S
39
How?

• Remove links by Shortest Paths Alg from N to
  create P,
• k shortest paths from S to D
• Apply Utility Model to
• P,
• Submatrix of the new traffic matrix,
• existing routing
• to get CAP and then cap

P
T(S,D)
The Utility Model
CAP
D
40
3 reroute existing paths

• We skip the gory details

41
4 increase link capacities somewhere

• Homogeneous case assume cost of adding delta to
  capacity of all links of N is constant

42
increase link capacities somewhere

• 1 increase (S,D) by ?. Call UM. If revenue
  increases, stop. Else
• 2 increase (S,D)1 by ?. Call UM. If revenue
  increases, stop. Else . . .
• (continue until nearly out of time)
• N advise the customer to increase her bid by ?
• This is a heuristic!

43
Experimental results

44
Parameters

• 35-node real Enterprise network
• batches of O(100) SLAs
• Branch and bound algorithm used
• to determine optimal solutions in order
• to evaluate fast heuristics
• most runs on a slow Pentium II some on PIII
• Java implementation (perhaps X10 speedup feasible)

45
Very preliminary results

• .

46
NB

• Contention typically begins at 10 - 15 SLAs
  (using our SLA maker and 10000 unit bandwidths)
• of Paths k 5 typically of little value
  increases computation cost a lot
• number of QOS levels / SLA 3
• Low contention scenarios give VERY good (optimal)
  results in SLAOpt

47
RuntimeNortel Topology20 paths /SLA are too
many!
48
RuntimeNortel topology 5 paths/SLA is more
like it.
49
Nortel topology revenue (utility)
50
How close to maximum utility ?

• For
• no contention
• everybody gets admitted at Gold QoS
• SLAOpt Utility BBLP utility, as it should
• For 20 SLAs
• BBLP takes days of runtime, so no exact answer
  yet
• Data

51
Performance of SLAOpt in 9 node Networkis 80-95
of optimal in this case
52
Performance of SLAOpt in 31 node Nortel
NetworkPIII 800 Mhz is 85-90 of optimal
53
Performance of SLAOpt in 100 node Network, PIII
800 MHzshowing the effect of k too large on
runtime ... K 3 or 5 is a bad idea
54
Further research

• Explore the tuning of parameters of SLAOpt
• value of k in k shortest paths
• number of paths considered in k shortest paths
• tree pruning in searches
• value of tactic 3
• Carefully measure SLAOpt performance

55
N.B.

• These runtimes of a few seconds (100 SLAs,
  Nortel customer network) obtained from Java
  implementation on 500 MHz Pentium
• re-implementing in C will yield about 10x
  speedup, according to local Java experts
• fast enough for realtime admission with a
  batching epoch of a second or more

56
Implementation QoSNet

• prototype for High Performance Optical Overlay
• Tim Ducharme

57
QoSNET Concept
Use Admission Controller (SLACtl) to admit
/reject traffic streams Customer requests
admission by specifying the stream parameters
(BW, latency,) using SLAs (Service Level
Agreements) SLACtl routes the new stream,
then determines if it can admit it while
respecting current SLAs,
58
Admission Controller
Based on Khans Utility Model Adaptation of
Watsons SLAOpt simulator Shown theoretical
results of 80 resource utilization Communicates
with PassPort 7400 switches to setup/teardown
MPLS paths
59
MPLS
Multi-Protocol Label Switching Need ER-MPLS
(Explicit Routed) to provide externally-specifiabl
e end-to-end routes through the network Alpha
version available only in latest release routing
software (pcr2.3 -mid June 2001)
60
Alternative

• RSVP with Diffserv and COS
• unavailable from Nortel,
• available only in prototype from Cisco
• maybe less scalable?

61
Test Process
62
Recent research progress

• Mostofa Akbars work
• Distributed version of the admission controller
• Controls interconnected set of Enterprise
  Networks ENs and servers
• Modelled as interconnected set of MMKPS-
• The Multiple Knapsack MMKP or MMMKP

63
Distributed SLAOpt

traffic
servers
64
Approximate Solutions to the MMMKP?

• First try
• centralized algorithm calculations replicated by
  complete negotiations among sites to find optimum
• No loss of optimality naturally, but
• Message traffic far too high

65
Approximate Solutions to the MMMKP?

• Second try
• Simplifying approximations
• Less iteration among nodes to search for global
  optimum
• Results about 70 of optimal
• No use of path tactics, heuristics purely at the
  MMKP level
• Tolerable message traffic
• Detailed evaluation going on now

66
More ideas. . .

• Network operator accepts bids from lambda-vendors
• Lambda-vendors accept bids from fibre-vendors
• Fibre-vendors accept bids from conduit-vendors
• Multiple interacting auctions
• Can be modelled by array of MMKPs?
• Properties?

67
THE END