上一篇 Introduction to Computer Networks - Reliable Transmission （上） 中提到了為什麼會需要使用 Reliable Transmission 和 Reliable Transmission 有哪些方式，但任何方式都有好有壞，雖然 Reliable Transmission 可以提供穩定且可靠的傳輸，但也會遇到不少的挑戰，詳細內容就持續望下看吧。

Issues with Sliding Window Protocol

雖然使用 Sliding Window Protocol 可以一次發送多個封包且確保封包能正確收到（Reliable Transmission)，但也會有他自己的問題存在。

• 當 Sender 在發送某個封包時，如果發生 Timeout 的話由於需要重送該封包導致 Window 無法滑動，所以會降低整體傳送的效率。
• 如果傳入封包的過程中發生了封包遺失的話，就必須要等待到 Timeout 後重新發送該封包，而由於 Silding Window 的特性，當一個封包遺失（ Receiver 無法回傳 Ack）的話，就會使 Windown 停下來無法 Silding，導致傳送效率下降。
  • 要盡快發現封包遺失的話就需要調整 Timeout 的時間，盡快發現無法從 Receiver 端接收 Ack 而重新發送遺失的封包的話才能儘早使 Window 繼續 Silding，而能夠盡快偵測封包遺失的話有三種方式
    • Negative Acknowledgement (NAK)
    • Additional Acknowledgement
    • Selective Acknowledgement

How to improve this?

Negative Acknowledgement (NAK)

傳統 Ack 模式是當 Receiver 接收到正確的封包時才會發送，如果今天 Receiver 接收到的是損毀的封包，那他也只會拋棄這個封包而持續等待 Sender 發生 Timeout 後的重發，而 Negative Acknowledgement 則是變成當 Receiver 接收到錯誤或是損毀的封包時，也會回傳一個 Ack 給 Sender，帶這個 Ack 代表 Receiver 沒有接收到正確的封包，當 Sender 接收到表示錯誤的 Ack 後就可以提早重送該封包而不用等到 Timeout。

Additional Acknowledgement

傳統 Ack 模式下 Receiver 只會發送一個 Ack 表示收到某個 SeqNum 的封包，而 Additional Acknowledgement 則會發送多個 Ack 給 Sender，比如說如果封包 2 遺失了但 Receiver 端只收到了封包 3 那麼 Receiver 就會發送 一組 Ack 表示 Receiver 接收到封包 3 並且 還沒收到封包2 ，簡單來說就是 Receiver 不只會發送已收到指定封包的 Ack 還會多送一個用於表示目前接收狀況的 Ack。

Selective Acknowledgement

如果 Sender 連續發送封包 2, 3, 4, 5, 6，而 Receiver 端只接收到了 3, 4, 5, 6 的話，Receiver 端就只會 選擇性 的發送 Ack 3, 4, 5, 6，而當 Sender 端發現只有封包 2 沒有回傳 Ack 的話，就可以知道封包 2 可能已經損毀或遺失。

How to select the window size?

要決定適當的 Window size 也是 Sliding window protocol 重要的一點，設定良好的 window size 可以使資料傳輸更順暢

• 對於 Sender 端來說，window size 代表一次可以發送幾個封包而不用等待 Ack，最簡單的方法便是利用 Bandwidth 計算
  • Delay * Bandwidth
• 對於 Receiver 端來說有兩種做法
  1. 設定 Receiver 的 window size 為 1：代表即使 Sender 端發送了多個封包，但 Receiver 一次也只能接收一個封包且這個封包的 SeqNum 必須要按照順序（落在非 RWS 中的 SeqNum 皆不會接收），雖然 Receiver 端會丟棄非按照順序的封包，但由於 Sender 端遲遲沒到被 Receiver 端丟棄的風包的 Ack 時也會重送一次（Timeout），所以即使 Receiver 端的 window size 只設定為 1 一樣可以正常工作，只是傳輸速率會比較差。
  2. 設定 Receiver 端的 window size 大小設定和 Sender 端一樣

即使 Receiver 端的 window size 設定的比 Sender 端大其實是沒有用的，因為即使 Receiver 端可以接收更多的封包但 Sender 卻沒辦法發送這麽多封包。

Finite Sequence Number

封包的 header 中會添加 Sequence Number 作為驗證封包的 id，如果設計的 Sequence Number 小於 Sender 可以發送的封包數量（小於 Sender 端的 window size）那 Sequence Number 就需要 重複使用

How to distinguish between different frames of the same sequence number?

為了避免重複使用 Sequence Number 導致 Receiver 端無法辨認封包的問題，那就需要 正在傳遞的封包數量要小於 sequence number 的大小，為了達到這個目的而定義了一個變數稱為 MaxSeqNum 就適用於設定最多可以使用多少 sequence number，其大小為

雖然以上面的公式設定 MaxSeqNum 可以滿足 RWS = 1 的狀況（Stop and Wait Protocol），但如果一次傳送多個封包的話就會發生問題，比如說如果 sequence number = 0 ~ 7 而 RWS = SWS = 8 - 1 = 7 這樣的條件下會發生什麼

1. Sender Sends sequence number 0, 1, … 6
2. Receiver receive 0, 1, … 6
3. Receiver send ack 0, 1, … 6，但是如果 Ack 0 ~ 6 通通遺失的話
4. Sender 沒收到 Ack 0 ~ 6 而引發 Timeout 重送 0 ~ 6
5. 雖然 Sender 重新發送了 0 ~ 6 的封包，但由於 Receiver 端已經確實接收到 0 ~ 6 了所以就會把 window sliding 到 7, 0, 1, …, 5，這樣的話對於已經 sliding 過的 Receiver 端來說，Sender 重新發送的 0 ~ 6 就會發生錯誤

所以如果只把 MaxSeqNum 設定為 SWS + 1 的話就不夠安全可能會發生上述的問題，而比較嚴謹的方式是

如果這樣設定後碰到剛剛的情況會發生什麼？

1. RWS = SWS = (8 + 1) / 2 = 4.5 = 4
2. Sender send sequence number 0, 1, 2, 3
3. Receiver receive 0, 1, 2, 3 這時 Ack 0, 1, 2, 3 也全部丟失了
4. Sender 沒收到 Ack 0, 1, 2, 3 而引發 Timeout 重送 0, 1, 2, 3
5. 雖然和上面一樣 Receiver 端已經 sliding window 到 4, 5, 6, 7，但由於 Sender 重送的 0, 1, 2, 3 並不在 Receiver 的 window 裡面，所以不會有收到重複的封包的問題

Sliding Window Protocol provides three features

• Reliable Transmission： Sender 要發送下一個或下一組封包之前需要先收到 Receiver 端發送的 Ack，如果沒有收到 Ack 的話則會觸發 Sender 端的 Timeout 進而重新發送該封包
• Preserve the order：雖然封包在傳輸的過程中抵達 Receiver 端的順序可能會改變，但可以利用 Sequence Number 來重新調整封包順序
• Flow control：可以透過 Receiver 可以接收的封包數量（RWS）來調整傳輸的流量

Summary

• Reliable Transmission 建立在 Receiver 端回傳的 Ack 和 Sender 端的 Timeout 機制產生。
• Stop and Wait Protocol 雖然是 Reliable Transmission 但由於一次只能傳遞一個封包所以傳輸效率較差。
• Sliding Window Protocol 也是 Reliable Transmission 且由於一次可以傳遞多個封包所以傳輸效率較好。

Reference

• 國立清華大學開放式課程 - 計算機網路概論 - 區域網路可靠傳輸技術 － 滑動視窗技術 (黃能富 教授)