# Optimal VNFs Placement in CDN Slicing Over Multi-Cloud Environment

## Paper detail
I. Benkacem, T. Taleb, M. Bagaa and H. Flinck, "Optimal VNFs Placement in CDN Slicing Over Multi-Cloud Environment," in IEEE Journal on Selected Areas in Communications, vol. 36, no. 3, pp. 616-627, March 2018, doi: 10.1109/JSAC.2018.2815441.

## Paper Introduction

### I Introduction
  現在 CDN 很厲害而且很多公司都從中獲利，為了保證使用者的 QoE ，CDN slice 上的 VNFs 如何擺放是至關重要的。作者提出一個 CDN as a Service (CDNaaS) 平台，這個平台的 CDN slice 有一群在多個雲域（指不同公司的雲端）下的邊緣伺服器。這些邊緣伺服器就是 VNFs，可以是 virtual cache、virtual transcoder、virtual streamer 和一個 CDN-slice-specific coordinator 來管理這個 slice 資源的生命週期和上傳的影片和訂閱者。這個平台可以在不同的私人或公共機構上（像是 Amazon AWS service、Microsoft、Azure、Rackspace 和 OpenStack-managed cloud）最大化延展和縮小的彈性。此外，此平台可以創造一個性價比高、並且有 QoE 保證的 CDN slice。具體來說，他在考慮 QoE 的情況下，可以找出最佳的 VNFs 數量跟他們的放置位置（所以可以節省開銷）。此設計可以使供應商和營運商雙贏，供應商保證 QoE ，營運商建置成本降低。注意：這邊供應商在文中可能會稱為使用者、消費者、CDN 擁有者，在現實中它可能是 Netflix 或 YouTube 等內容提供者。

### III CDN as a Service Platform

#### Architecture
  作者說他們的 CDNaaS 平台不只像一般的 CDN 只能當作一個內容暫存器，還可以在跨多個雲域創建多個虛擬 CDN 切片並進行生命週期管理。CDN 切片的功能包含 virtual transcoders、 virtual streamers、 virtual caches 和一個 CDN-slice-specific Coordinator，CDN-slice-specific Coordinator 負責管理上傳的影片和訂閱者以及不同私人和公共基礎設施即服務 (IaaS) 提供者的切片資源，這些設施有像是 OpenStack 管理的資料中心、Amazon AWS 服務、Microsoft Azure 和Rackspace。整個架構如下圖(a)所示，切片上的所有 VNFs 由 Coordinator 負責管理並由它跟其他的 VNFs 通訊。


#### A Components

##### The Orchestrator server
  允許顧客透過 IaaS 供應商創建、修改和刪除 CDN 切片。包括指定其風格的新虛擬機器的實例化、現有虛擬機器的終止以及用於管理切片資源的策略的定義或更新（例如，擴展和縮小）。

##### The Coordinator server
  每個 CDN 切片只有一個 VNFs 管理者 ，我們稱為 Coordinator。他確保 virtual cache servers、 virtual transcoder servers 和 virtual streaming servers 之間的通訊。切片的擁有者可以透過其各自的 Coordinator 管理其視訊並管理其訂閱者。Coordinator 運行的具體方法包括智慧選擇最接近且負載最少的 virtual transcoder。 它還定義了切片 VNF 之間的服務功能鏈 (SFC)，然後將作業發佈到相關伺服器的佇列中。

##### The Cache server
  CDN 切片本質上由地理上分散的快取伺服器網路組成。Cache server 快取靜態內容並儲存最終用戶上傳的影片以及轉碼輸出。當用戶請求特定解析度和品質的影片時，距離該用戶最近的快取將傳輸內容，確保最短的距離（即最少的延遲），從而提供最佳的用戶體驗。

##### The Transcoder server
  此網路功能負責對不同格式和不同解析度的影片進行轉碼。它消耗大量的運算資源。虛擬轉碼器始終透過排隊管理伺服器監聽來自協調器的命令。它收到快取伺服器要轉碼的指令後，開始轉碼，向協調器發送回饋，即時指定進度，並在轉碼操作成功完成後通知協調器。

##### The Streaming server
  此網路功能扮演負載平衡器的角色，因為它接收來自最終用戶的播放特定視訊的請求，並將請求重新導向到適當的快取伺服器。Streaming server 還追蹤視訊存取並將統計資料發送回 Coordinator 以用於資料分析，以提高相關 CDN 切片的商業智慧。

#### B Sequence Diagram
  整個流程如下圖所示，其實這張圖講得蠻清楚的，論文裡面有更詳細講解。


#### C Management and Orchestration

  這邊稍微介紹了一下 CDNaaS orchestrator ，其架構如下圖所示：


  CDNaaS orchestrator 分為前端核後端，前端服務有助於滿足使用者的偏好，並為協調器、快取、轉碼器和串流媒體影像設定 VNF，就如我們前面介紹的那些。至於 orchestrator 中所用到的後端相關函數如下：
* Main Orchestration component: 此元件負責檢查資料庫和VNF的建立和刪除。
* Data Manager Component: 此元件包含資料管理所需的所有與資料庫相關的方法。
* Coordinator Agent: 包含編排器和不同CDN切片的協調器之間通訊所需的方法。 例如，代理使協調器了解其切片的拓撲。 它使用所有關於分片VNF 的有用資訊填充協調器資料庫，包括公有和私有IP、網路功能/服務、雲端提供者、位置（緯度和經度）以及映像ID。在實例化新虛擬機器或刪除現有虛擬機器的情況下，代理程式會不斷更新協調器有關切片拓撲的任何變更。
* Amazon AWS Agent: 包含與 Amazon AWS IaaS 供應商的 EC2 控制器介面所需的方法。
* Microsoft Azure Agent: 包含與 Microsoft Azure IaaS 供應商的控制器互動所需的方法。
* OpenStack Agent: 包含與基於 OpenStack 的虛擬基礎架構管理器 (VIM) 互動所需的方法。
* RackSpace Agent: 包含與 RackSpace IaaS 供應商的控制器介面所需的方法。

建立 CDN 切片的主要步驟如下圖所示：


R1：客戶（即 CDN 切片消費者）要求建立指定其要求的 CDN 切片。
R2：根據這些要求，編排器確定虛擬資源的數量、它們的位置和各自的 IaaS 供應商，以及要在每個虛擬實例中安裝的 VNF。 編排器會向每個 IaaS 提供者發送請求，指示要實例化的 VNF 實例並指定要在每個實例上執行的映像（即虛擬快取、轉碼器、串流媒體和協調器）。
R3：使用正確的圖像，建立 VNF，並將有關這些 VNF 狀態的資訊傳達給編排器。
R4：使用者（即CDN所有者）可以透過編排器的API管理其CDN切片的VNF。

  特定 CDN 切片的協調器伺服器負責從協調器獲取有關其 CDN 切片中可用機器的信息，並管理不同節點之間的通信，例如轉碼請求（即由協調器發送到轉碼器）或轉碼回复（即由轉碼器傳送到協調器）如圖2所示。創建 CDN 切片後，CDN 切片所有者可以透過協調器管理其視頻，協調器是用於管理整個 CDN 切片（包括快取、轉碼器和串流媒體）的必備組件。它使所有者能夠上傳、修改或刪除視頻，在可用的轉碼器、快取和串流媒體中選擇首選轉碼器、快取和串流媒體，將一個或一組視頻轉碼到所需的分辨率，儲存和串流轉碼後的影片。
  快取主要負責儲存使用者上傳並經過選定的轉碼伺服器轉碼後的影片。轉碼器收到協調器的請求，並按照 CDN 所有者指定的速率對視訊進行轉碼。串流媒體的作用是負載平衡和接收最終用戶播放特定影片的請求，並將請求重新導向到適當的快取伺服器（見圖 2）。
  為了創建經濟高效且具有 QoE 感知能力的 CDN 切片，系統必須確保在可用 IaaS 上智慧放置 VNF，並決定為每個 VNF 分配哪些虛擬資源。 這種放置涉及 VNF 的地理位置以及可用 IaaS 供應商提供的 VM（例如 CPU、記憶體和儲存）的風格 [38]。 事實上，快取、轉碼器和串流媒體的放置對 QoE 有很大影響。 此外，它還會影響 CDN 所有者支付的成本（即，本質上類似於基於雲端的電信 [28]、[31] 情況下的一般 VNF 放置問題）。

### IV System Model and Problem Formulation

  這章重點就是介紹了一些 problem 會用到的變數。然後其實下一張才開始介紹 problem。

### V Proposed Solution

  這章列出了兩個問題，一個是希望為營運商著想，減少成本的設計（Efficient Cost Solution）。另一個是為使用者著想，最佳化 QoE 的設計（Efficient QoE Solution）。

#### A. ECS: Efficient Cost Solution

  這邊如果有看懂論文列的參數，那我們就繼續說下去。他們列出總開銷如下


估計的大小如下（某種程度代表開銷）：


最小化成本（Efficient Cost Solution）的問題如下：


這邊我們要注意在 objective function 裡的花體 S 是我們要解的變數。前兩個限制主要就是在說明我們的設計必須大於估計的值。

#### B. EQS: Efficient QoE Solution

所有的 QoE 如下


最大化 QoE 的問題如下：

這邊我們要注意在 objective function 裡有三嵙變數，花體 S 跟剛剛一樣，但多了花體 N 跟 l 代表我們也要求解的 VNFs 的位置。

#### C. FTS: Fair Trade-Off Between Cost and QoE Solution

而怎麼樣可以同時滿足這兩個問題呢？作者套用賽局理論中的 Nash bargaining game 模型，並且用某篇論文提出的方法求解。這個模型的解法主要是說兩個在遊戲中的人，互相犧牲一點東西來換取自己的利益最大化。大概念如下圖所示，我們希望找到兩個人都滿意的解


而作者就將他的兩個問題當作這兩個在遊戲中的人，最終去求出最佳解。

# Comment
  這篇模擬很簡單所以我就不放了。整體來說這個 CDNaaS 跟一般的 CDN 其實差不多，它的貢獻在於 slice 上的各種彈性設計和最終他們提出的賽局理論的解法。當然業界不可能直接拿來用，但可以給他們一些 insight 讓能怎麼樣去設計 slice 和 VNF 來提升整體服務品質並減少開銷。