迅速打造DMPO通道　搞定SD-WAN監控優化

2018-11-20

饒康立

企業採用NSX SD-WAN方案時，其中的DMPO（動態多路徑最佳化）的內部機制可以優化Application的傳輸表現，對此，這裡將透過比較說明以及案例示範來解釋為何企業核心的業務系統即使透過價錢相對低廉的Internet/廣域網路方案傳輸，仍然可以保持良好的應用傳輸品質。

Packet Loss（網路封包遺失）

小幅度的網路封包遺失，在Voice、Video等應用可能影響還不會太大，用戶只會聽到語音有雜音或畫面有雜訊。但是當Packet Loss到達一定程度，例如視訊會議時，就可能出現一大堆像馬賽克的雜訊。而在TCP連線如檔案傳輸，Packet Loss影響會很大。終端設備會基於TCP機制要求大量的封包重傳，而且TCP連線的傳輸速率也會下降。

Jitter（封包傳輸時間變動量太大）

在打網路電話時有時會聽到整句話亂掉前言不對後語，就可能是這個樣子，因為後面的封包（聲音）比前面的封包（聲音）先到。有時Jitter量太大，封包也可能直接被丟掉，就變成Packet Loss的狀態。

從圖6可以看到，管理者能夠透過Orchestrator看到單一設備不同線路（圖中的MPLS/Comcast Cable）的品質狀況。如果顯示綠色，代表品質優良，但如果呈現灰色（MPLS線路），這代表那段時間出現斷線（Blackout）。如果是黃色或紅色，表示線路品質不佳（Brownout），此時也能顯示出來品質不佳的理由是基於Latency/Jitter/Packet Loss。在圖6中，Comcast Cable在5:50時出現的狀況是有變異量9毫秒的Jitter，以及1.56%的掉包。

▲圖6 透過Orchestrator查看單一設備不同線路的品質狀況。

監控機制改善傳輸品質

藉由DMPO的傳輸監控機制，在很短的時間內（通常是在300～500毫秒內）就會發現目前應用傳輸出現了Blackout或是Brownout的狀況。那此時要怎麼辦呢？DMPO有下列幾種方法可以改善傳輸品質的問題：

Forward Error Correction（FEC）

對於Voice/Video這類要求即時傳輸的應用機制，Velocloud會在應用傳輸的兩端設備啟用FEC機制。這個機制包括了直接在傳送Voice、Video等UDP封包時，一開始就傳送兩份，以及在傳輸終端自動依據Sequence Number重新將這些即時應用的封包排序，並移除重複的封包。這樣的機制可以大幅減少Packet Loss、Jitter對語音和影像等即時傳輸應用的影響。

Jitter Buffer

同樣對應到Voice和Video這些即時傳輸應用，當Velocloud偵測到這個通道目前的Jitter量過大，終端的設備會啟用Buffer機制儲存10個或是200毫秒的交通量，確保能夠有足夠的封包提供正確的排序。

Negative Acknowledgement（NACK）

對於檔案傳輸這類的TCP形式應用，DMPO終端（Edge or Gateway）只要一偵測到掉包，馬上就會通知DMPO來源端（另一台Edge或Gateway）立即重傳，然後以完整沒有掉包的Traffic送往目的端用戶。因此，應用來源與目的端的用戶或設備完全沒發現中間有封包掉落的問題，TCP連線當然也不會有重傳或降速的狀況出現。

啟用優化機制進行快速錯誤修正

圖7是Velocloud透過VoIP語音應用，在兩種線路（線路有2% Packet Loss，線路內的Jitter高達33毫秒）的狀況下進行的MOS（Mean Opinion Score）測試。可以看到在右邊有啟用DMPO機制，以及左邊沒有啟用的情況之下，語音品質有明顯的差別。

▲圖7 右圖啟用DMPO機制，左圖沒有啟用，兩者的語音品質有明顯差異。

另一個例子，同樣是由Box.com的50MB檔案下載，左邊是走傳統的Internet線路，右邊是有Velocloud的DMPO機制建立於外點及Box.com之間，頻寬都是兩條20Mbps的線路。

首先是傳輸時間的差異。本文後面會提到，Velocloud甚至能夠同時使用多條線路進行傳檔。但更重要的是，在線路有2%的Packet Loss狀況下，左邊傳統機制採用TCP重傳的方式，檔案要花原本六倍的時間才傳送完成。而右邊在VMPO機制的保護下，2% Packet Loss所造成的影響僅多了1秒，終端用戶應該毫無感覺，如圖8所示。