1、背景
在網絡中，鍊路故障的發生在所難免，為了降低故障帶來的影響，就需要重新路由，将資料傳輸到合适的鍊路上。當因為鍊路故障發生處的不同，也有不同的解決方法。
AS（Autonomous System）内發生的故障如下圖：
這種情況有現有的如下幾種重路由方案：
- IPFFR（IP Fast Reroute Framework，RFC 5714）
- LoopFree Alternates （RFC 5286）
- MPLS fast reroute （RFC 4090） 等等
上述的幾種重路由可以達到亞秒級的重路由
如上幾種重路由的方法有兩個共同點：
- 快速檢測：硬體信号通告；
- 快速恢複：使用預先計算的備份鍊路，而不是重新來計算鍊路；
2、要解決的問題
當故障發生在AS外時，如下圖所示：
現有也有幾種解決方案：
- BGP（Border Gateway Protocol）協定
- SWIFT （SIGCOMM '17 ）
SWIFT是優化了BGP的解決方案，SWIFT為了縮短收斂時間，利用一些已更新的BGP更新（例如，它們共享相同的AS-PATH）這一事實，從收到的一些BGP更新中預測了整個遠端失敗的程度。但是，SWIFT的基本問題是，在相應的資料平面故障後，而第一次BGP更新可能需要O（分鐘）才能傳播。
綜上，現有得方案在解決遠端故障是很緩慢的，所需要的時間是分鐘級，主要原因是要靠控制面來驅動重路由。
3、Blink
Blink:一個資料驅動的快速重路由架構，并基于可程式設計資料平面建構，目的為了實作遠端故障亞秒級的收斂。
Blink利用TCP事件信号直接在資料平面上檢測故障的發生。
TCP流在中斷時表現的可預測的行為：在時間上按指數間隔反複傳輸相同的封包，而當多個流混合時，TCP流中斷的重傳行為變會變成明顯的故障特征信号。
4、關鍵挑戰
- 1.資料平面的資源有限。無法跟蹤所有的TCP應用流，如果采用随機采樣，那常常會導緻跟蹤到無用流，例如傳輸很少的流；
- 2.如果隻發生暫時的擁塞，對任何重傳的封包進行重新路由，那麼可能會導緻适得其反的流量變化，需要區分短暫的擁塞和鍊路故障。
- 3.資料平面的故障信号并不提供發生故障的根本原因，如果在重新路由是不協調的路由決策，那麼很容易導緻一些問題的發生，例如：路由黑洞，環路，振蕩。
5、解決思路
- 1.使用流抉擇器來解決跟蹤流問題，該抉擇器會自動驅逐不活動的流并将其替換成活動的流。因為活躍的流幾乎會立即重傳，而不活動的流可能根本不會重傳。
- 2.即使沒有網絡故障，短暫的擁塞也會導緻TCP重傳。Blink系統主要對破壞性事件作出反應，不受噪聲和正常協定的影響。如下圖所示
論文閱讀：Blink-Fast Connectivity Recovery Entirely in the Data Plane - 3.随着TCP重傳數量随着時間逐漸減小，Blink系統在第一個TCP重傳過程中，捕獲到故障信号。
- 資料平面重路由對于轉發的正确性，隻能通過嘗試和觀察來判斷重路由的正确性，以資料驅動的方式來備份下一跳，驗證流量是否恢複。
附錄
論文位址：https://www.usenix.org/conference/nsdi19/presentation/holterbach
github源碼位址：https://github.com/nsg-ethz/Blink