
1. Notation中 $P_{packet-in}$、$P_{packet-out}$ 這種類型的變數不夠明確、直觀。
  * p13：Packet-in rate: $P_{packet-in}$ -> PIR
  * p13：Packet-out rate: $P_{packet-out}$ -> POR
  * p14：Table pipeline gain: $P_{pipeline}$ -> P

2. $table_{n-1}$ 與後續的說明不一致。
  * p16：修改為 $table_n$

3. Approach overview 帶出先前 survey 的相關參數，要與先前的說明一致。
  * p17：加入 parameters 欄位說明。

4. 增加循序圖跟公式的細節，讓圖跟公式能更清楚的表達測試的方法。
5. 在圖上標式出 $Acc_{idle-timeout}$ 的公式中 $T_{idle-duration}$ 的範圍。
  * p25, p26：修正 pkt 處理順序，並註明各時間參數範圍。

6. 說明 dut 規格，並再後續的數據多執行一種 switch 觀察與現有 switch 的差異。
  * p29：新增 switch 規格表，並加入 Edge-corE AS4610、Centec V350 兩台 switch。

7. Results 需要加入方法正確性的相關數據。
  * p31：加入 action time 白箱測試數據，證明方法準確度。

8. 總結測試方法的缺陷及 dut 之間的差異。
  * p36：以大量traffic、封包修改及multi table面向總結出各家switch較適合處理。
  * p37：提出目前方法尚未考慮的因素

9. Open vSwitch 可能因 security 因素增加 Packet-in rate limit 導致其 Packet-in rate 較低。
  * 在 trace code 後，Open vSwitch 確實有 Packet-in rate limit 參數，但其預設為 0。

10. Througput 沒有明確說明其單位。
  * p33：修改為 packet per second (packet-in, packet-out)

11. 說明為什麼 swtich 在 buffer size 處理 128 ~ 1024 byte 封包時，會產生這麼多的 error message。
  * 因處理 Packet-out 時，switch 需要從 buffer 中取出對應封包，但因 buffer overflow 導致該封包無法存取。

12. Busy ratio 這個名詞定義會誤導讀者，並需要設想在 48 port 滿頻寬時會發生什麼情況。
  * p34：將 Busy ratio 更改為 Pipeline gain，並加入若 48 port 的設想情況。

13. hardware switch 可能最多只有 10 張的硬體 flow table
14. 需加入每個 switch 實際可使用的 table 數量的數據。
  * p34：目前方法只能精確至20~30張table，無法鑑別出 flow table 為硬體還是軟體實作
  * p34：數據顯示，各個 switch 於70張table時皆無法正常進行 pipeline。其實際可用table數量約為60幾張。

15. Conculsion 應分為 method evaluation 跟 dut evaluation，並能從中觀察出 switch 的實作問題。
  * p36: 強調 7 項測試參數中能從當中的6個觀察出結論，並以大量traffic、封包修改及multi table面向總結出各家switch較適合處理。
