感覺好像少吃很多仙貝,總覺得聽下來不是很懂,老師也有說上過的人當複習。

可以修 電腦網路導論

TCP

TCP 全名叫做 Transmission Control Protocol。
從他的名稱可以知道,其目的是對傳輸進行控制,提供可靠的傳輸,和避免把網路塞爆。
他是 Transport layer,也就是第 4 層的。

控制的方法一樣利用到之前的老朋友,ACK,並搭配 sequence number 代表這是第幾個 ACK。
但是要注意的是:

不同層之間的 ACK 是不同的東西,最底下會提到

Window Floor Control

在 TCP 中有個重要的東西叫做 Window ,白話一點是 Quota 的意思,代表可以有多少東西在外面傳,以免把網路塞爆。

如果很久沒收到 ACK,「可能」就是 Windows 給太大,把外面塞爆了,所以要減少 window 的量。

Congestion window / cwnd

這就是上面講的 window。
最基礎的版本就是值設成 1 MSS (Maximum Segment Size)。

Additive Increase Multiplicative decrease / AIMD

簡單來說就是增加用加法,減少用乘法;也就是說減少的速度比較快。

增加

增加分成兩個階段 Phase,並且跟 CWND 這個參數有關。在基礎款的協議中,CWND 通常設成 1。

階段一 Slow Start

試水溫的階段,會有變快的趨勢,是還在「嘗試」的階段。

每次接收到一個 ACK,cwnd 就會加 1,但是要注意這樣的效果是「指數型成長」。
舉例如下:首先一開始 cwnd 是 1,然後現在收到 1 個 ACK,cwnd 就變成 2。
重點來了,cwnd 變成 2 代表,你可以傳輸兩個大小的東西出去,因此如果傳輸順利的話,下次收到的 ACK 就會變成 2,這樣 cwnd 會變成 4,所以以此類推,會再變成 8、16

所以一開始會長很快。
但是這樣一定會爆,所以會設置一個閾值,超過閾值就會進入第二階段。

階段 2 Congestion Avoidance

線性成長的階段,公式是加 cwnd = 1 / cwnd,原理跟上面一樣。

或者換個角度想, cwnd 代表的是當前可以回傳的 ack 數量,所以除以 cwnd 就代表下一次可以傳輸的數量只會加 1。

兩個階段如下圖:

Image Not Showing Possible Reasons
  • The image file may be corrupted
  • The server hosting the image is unavailable
  • The image path is incorrect
  • The image format is not supported
Learn More →

可以看到各個點對應的值跟上面敘述符合。

減少

說到減少,要先提在有線環境下的情況。

TCP 在有線的環境下,偵測到封包損失 packet loss 就會開始減少 windows。
因為在有線環境下,封包損失就代表負責轉運的路由器被塞爆了;所以現在在無線環境也以這個為基礎,覺得封包損失原因是自己把網路塞爆了。

但是

其實有可能是因為傳輸環境不好 (BER 很高),造成封包損失,或是傳輸速度很慢,ACK 來不及回來等等,也就是說無線環境多了很多其他因素造成封包損失,並非全都是由堵塞造成的。

傳輸速度降低的方法,有兩種,一個是直接歸零,一個是砍半。


TCP是一個端到端的協議

行動與無線

老師說回到第一堂課講的,對每個系統都要去注意,無線跟有線的差異,以及行動跟固定的差異。
在現在這個例子可以發現兩大問題:

  • 無線的環境可能會不好,也就是 BER 很大,造成誤判
    • 所以高 BER 就很像是懲罰兩次
    • 環境就已經不好傳輸了,還會被誤判為堵塞,造成傳輸速率下降,不就越來越慢
  • 移動可能會造成換手的封包損失,也會被誤判

總結來說就是「環境問題」跟「換手問題」。

Round Trip Time / RTT

一次的傳輸時間,也就是「傳遞出去」到「收到 ack」 的時間。

Image Not Showing Possible Reasons
  • The image file may be corrupted
  • The server hosting the image is unavailable
  • The image path is incorrect
  • The image format is not supported
Learn More →

所以一段 RTT 之間可以傳的量就是我的 throughout,而沒有收到 ACK 就會假設是發生封包損失,也就是假設發生堵塞。

Packet Loss

收不到 ACK 在無線 TCP 有兩種情況:

  • 超時,也就是超過預估時間沒有收到
    • 會有個 Retransmission TimeOuts / RTO timer 來計時
  • 收到重複的ACK
    • 重複 ACK 的來源是一個避免措施

在 TCP 當中,收到東西就一定會傳 ACK。如果正確的話,就會照著順序回傳 number;
但是如果接收方沒有照著順序收到封包,例如下圖中的 4 可能傳一傳不見了,當接收方收到的時候,發現跳號了,他就知道有可能是中間有人不見了,所以會回傳當前收到的最大 number 回去,也就是 3。

Image Not Showing Possible Reasons
  • The image file may be corrupted
  • The server hosting the image is unavailable
  • The image path is incorrect
  • The image format is not supported
Learn More →

在無線的環境可能又會有多條路,所以可能有些人會超車。
所以會設定收到幾個重複的號碼以上才視為真的有人不見了。

無線傳輸的情形

  • Limited bandwidth
    • 就是前面提到的傳輸速率很低
    • 要記得調高收取 ACK 的 Timer
  • Long Round Trip Time
    • 高傳遞時間
    • 常見於高緯衛星,延遲會很長
    • 或是 2G 和 3G 的網路,延遲很長
      • 因為耳朵聽得出時快時慢,但是聽不出同時快同時慢
      • 所以以前才沒有這個問題
  • High BER
    • 環境很差
    • 很常用 FEC 校正碼效率也會不佳
  • Short Flows
    • HTTP 等應用,常常需要傳一些小小的資料
    • 而每次傳這些資料 TCP 就需要三方握手,花費會很高
    • 老師說真正要傳輸的資料才是有效的資料,其他的都是cost,像是前面的建握手,校正碼等等
  • Power consumption
    • 有時候 TCP 傳輸會持續很久,像前面的 Slow Start,要花一段時間等待到好的速度
    • 這時候手機就要持續開著,就會有浪費電的問題

Mobile IP

專門設計給換手頻率少於一秒一次的。

老師說很像之前提到的 HLR、VLR 查找位置的那個關係。

問題

由於在無線的 TCP 中,收不到 ACK 就會預設認為是發生堵塞 congestion,因此觸發 congestion control。

但是實際上可能的原因,就是上面歸納出的 High BER 跟 Handoff。

而持續觸發 congestion control 的結果就是 window 很小,傳輸速率很慢。

解決方法

這個問題有非常多種解決的方法,但是也各有各的優缺點。
不過現在比較少有論文在介紹新的解決方法了,因為現在速度變很快,所以環境已經很像有線的情形。

解決方法依照修改的 Layer 而分類。

  1. Robust link layer

就是加強環境,使用 FEC 和 ARQ。

  1. TCP-Aware Link Layer solution

就是有名的 Snoop 方法

  1. TCP-Unaware Link Layer solution

TULIP 或 Delayed Duplicate ACK。

第 2 跟 3 個下面都會提到。

殘存
第四層跟第二層一起考量

Transport Layer Split connection

  • Indirect TCP (I-TCP)
    • 有線端保持舊的 TCP ,而無線的用新的 TCP ,中間再去用介面接起來
  • M-TCP
    • 改版改成不像 TCP。但是造成一個缺點,就是把 TCP 的端到端特性破壞掉了

Modified version of TCP

直接改版 TCP。

Other changes to TCP

修正原本 TCP 的選用選項。

New Transport Layer

使用新的協議。

WAP protocol stacks

直接是用一個另一種 protocol Stack

底下主要講 Link Layer 和 Transport Layer 的。


Link layer 解法

從下圖可以看出,我們動手的地方是 Link Layer。

前面有提到,TCP 會誤判的原因之一就是環境太差,那我們就不要讓 TCP 去知道環境差的錯誤就好了。

  • 方法一就是模擬出有線環境,也就是使用 FEC 降低 BER。
  • 方法二是減少頻段的錯誤率,例如使用
    • Automatic Repeat Request (ARQ)
      • ARQ 就是 retransmission
    • Forward Error Correction (FEC)
      • 就是校正碼
    • Hybrid FEC/ARQ scheme
      • 是將 ARQ 的部分搭配 coding 技巧

就是待會的重頭戲 Snoop。

好處

  • BS 不用維持 connection state
  • 保持 layered structure
  • 不讓 higher-layer 知道有 loss 發生

缺點

  • 無法解決 mobility 問題,也就是換手
    • 畢竟主要是調整環境而已
  • ARQ 的 retransmission 時間要很短,否則會被上層判定超時
  • 並且需要多花力氣重新傳輸

介紹一下

  • FEC
    • 大多數的通訊系統都會用 FEC 來校正
  • ARQ
    • Cellular system 通常都會用
    • 但是在某些系統中 ARQ 是選用的,如 802.16
  • AIRMAIL (1995)
    • FEC + ARQ
  • Hybrid ARQ
    • FEC + ARQ,並且搭配
    • Soft combining
      • 收到多份有損壞的,可以合併成一份好的
    • Promising technique in many systems

Snoop

意思就是偷聽或偷看。

會在 BS 裝一個 snoop agent,所以不需要改變有線網路的東西。

這個 snoop agent 會監測 UL 跟 DL,檢查所有的 TCP 活動。

並且如果偵測到一個 TCP segment,直到看到他的 ACK 送過來前,snoop agent 都會記著他,存在快取裡面;但是也不是都一直記著他,而是採用 Soft state ,就是有時效的資訊,也就是會讓他過期,不然一直堆著會爆。

特務的活動

  • 監測 Packet loss ,發生的情形可能為
    • 收到重複的 ACK
      • 就是前面提過的
    • 超時
      • 就是遲遲沒有看到 ACK 回來
  • 不讓有線網路知道發生 loss
    • 也就是上面說的,不讓 TCP 等高層知道發生 loss 了
    • 方法就是攔截重複的 ACK,並重新傳送一次

下面是 Protocol 的樣子

情境模擬

上圖中,黃色大的是資料,紫色小的是 ACK;可以看到 37 號遺失了。
在這裡我們有使用一個技巧叫做 delayed ACK ,也就是每兩個封包才回傳 ACK,並固定回傳後者,以節省 ACK 的頻率。

先持續傳輸。可以看到我們的特務會持續記錄有哪些資料出去了。

此時接收端發現 37 號不見了,所以就會回傳重複的 ACK 回來。

可以注意到一件事情,重複的 ACK 不會進行 Delayed,所以可以看到他的頻率變回兩倍了。

同時可以看到特務有收到某號 ACK 後,就會「將該號以前的都刪掉」,為甚麼說「該號以前」,要繼續看下去。

可以看到,特務把重複的 ACK 丟掉了,也就是隱瞞的動作;而另一個重要的動作是,特務從自己的cache 中找出遺失的 37 號資料重新傳輸。

這裡的 BS 就會叫做 TCP-aware

從上下兩張圖可以看到,特務的快取中記下越來越多資料,因為號碼都被 37 號卡著了

此時可以注意到,回傳的是 41 號,也就是收到 37 之前最大的號碼,這樣才可以用上面提到的原則,把特務快取中的號碼去除。

可以注意到另一件事情,沒有重複的 ACK,都會再傳到上層,但是像這裡重複的 ACK 36 號,就會被攔截下來,因為第一次的 36 號已經傳給上層了。

最後就是正常的將 41 號傳給 上層。

優點

  • 使用了 Soft State
  • 由於我們欺騙了上層,所以他就不會頻繁的降低 window
    • 因此我們的傳輸速度不會鋸齒狀的抖動

缺點

  • Link layer 要做很多事
  • 破壞了模組化設計原則 modular layer design principle
    • 跟上面提到的保持層狀結構意思不一樣
  • 需要修改 Mobile-side 的 TCP
  • 並且需要安插特務在 BS,也就是要修改 BS

所以感覺上,Link Layer 的第一個解法就是把環境盡力調整好
而第二個解法,也就是剛剛的 Snoop 那種的,是不告訴上面發生了錯誤

Split Connection Transport Layer

將原本 TCP 的特色「端到端連結 end-to-end connection」拆成兩段,Sender到 BS 和 BS 到 receiver;然後分別地處理有線和無線的 TCP。

I-TCP / Indirect TCP

將有線跟無線的 Packets loss 分開來,並且使用兩個獨立的 Control flow,有可能會需要用到特殊的 Protocol 來控制參數。

I-TCP 就是使用了兩個標準的 TCP。跟 Snoopy 很像,這裡也有個特別角色,MSR。

Mobility Support Router / MSR

他擔任 Sender 跟 Receiver 之間的中介人,他的 ACK 代表了 Receiver 的 ACK;也就是上面 BS 所擔任的角色。

或者又叫做 Foreign Agent。

MSR 的活動

在 MSR 跟 Sender 之間是正常的 TCP,但是 MSR 跟 Receiver 之間的是「wireless TCP」。

  • 首先 Sender 會將要傳送的訊息傳給 MSR,而 MSR 收到訊息後就會儲存在自己的 Buffer 內,並傳 ACK 給 Sender
  • 接著再將訊息傳給 Receiver
    • 這樣一旦發生 Packets Loss 的時候,Receiver 就可以直接向 MSR 請求,而非跟 Sender 請求。

如此一來 Sender 可以有更穩定的連接,並且更快的恢復 packets faster,還能夠處理 mobility。

下面是 Protocol Stack

優點

  • 不會動到有線網路
  • 可能需要在無線網路有特殊的 TCP 設計
    • 可能會更輕量、更節能

缺點

  • 不難發現,擔任 MSR 的就是 BS ,所以一樣會需要修改 BS
  • 並且用的是 Hard State
    • 因為資料會直接儲存在 MSR 裡面
  • Sender 收到了 ACK 不代表 Receiver 收的到訊息
    • 畢竟這些東西已經都由 MSR 負責了
  • 破壞了端到端的設計
    • 因為 MSR 負責接收所有 Sender 的資料,然後再傳給 Receiver
    • 也就是阻斷了 Receiver 跟 Sender 之間的連線
  • 使用者的 Mobility 會造成問題
    • 也就是換手的問題

可以注意到,Snoop 就是為了避免破壞 End-to-End 的特性,而對 I-TCP 做的改進

M-TCP

  • 這個方法使用了一個酷東西叫做 TCP Persist Mode;並且一樣有一個中介角色叫做 Supervisor Host / SH。
  • 這個 SH 的用途是跟之前 Snoop 一樣,監測 Sender 送來的資料,以及 receiver 發送回的 ACK。
  • 如果 SH 沒有收到 ACK,就會回傳一個訊息叫做「advertised window = 0」
    • Sender 就會進入 Persist Mode;那個 window 就是前面提到的 window
      • 但是這邊特地設成 0,就是有特殊的意義
    • 直到 Persist Mode 結束之前,Sender 不會發送任何資料
    • 並且會保持跟原先一樣的 RTT 和 CWND,也就是說依舊保持原先的速度
  • 當收到「advertised window > 0」Sender 就會離開 Persist Mode
    • 然後恢復 RTT 跟 cwnd 的值

會這樣做的原因是因為,M-TCP 假設的環境都是很好的,所以如果沒有收到 ACK 就是預設發生換手。

若發生 Packets Loss,由於 SH 只會將收到的 ACK 轉給 Sender,所以是交由 Sender 處理,也就是說保持 End-to-End 的特性。

不像 I-TCP 的 MSR 的 ACK 代表了 Receiver,在 M-TCP 中 BS 要先收到 MH(Receiver) 的 ACK 才會發送 ACK。

要記得發生 Packet Loss 也會回傳 ACK

Compressed M-TCP

Compression 是 header 的 compression

End-to-End Approaches

或許我們可以在端到端做些事情來解決問題。

Explicit Loss Notification (ELN)

這個東西叫 ELN,他是一個 TCP 的 ACK 中的選項。如果發生 bit loss,也就是跳號的時候,那個選項就會被開啟,這樣 sender 也就可以知道發生跳號了。

這樣 window 就不會呈現鋸齒狀,降低傳輸速率,而是單純重新傳一遍來解決問題。

但是要注意的是,那個 bit 只代表了「猜測」環境不是由堵塞造成的,因為實際上到底發生了甚麼,我們依舊是不知道。

而判斷的方法,只能從有限的資訊推導,像是從網卡的資訊綜合判斷,也就是從 Link Layer 的狀態來判斷;但是畢竟資訊太有限,所以 tradeoff 就是也可能判斷錯誤。

好處

  • 他可以很容易的分辨是不是由堵塞發生的。

  • 如果是移動的情景下,例如上次的 Multihop,這個東西蠻好猜中的,畢竟那個情景就是在討論很多人且移動的環境。

缺點

  • 但是他不容易分辨是不是兩個同時都有發生
  • 需要修改有線端的 TCP,且從 loss packets 復原很慢

跟 Snoop 比較

  • 相同之處是都可以偵測到無線端的 packet loss
  • 但是缺點是一樣都要修改 BS
  • 不同之處是
    • Snoop 是設計一個新的 link layer,不會動到 TCP
      • 也就是 Protocol dependent (TCP-aware)
    • ELN 則是修改了 TCP

總結

TCP in “Wireless” Networks

這裡強調的是解決環境造成的 Packet loss 問題

  • Link Layer Approach
    • FEC, ARQ
  • Split Approach
    • Link Layer Split (Snoop)
    • Transport Layer Split (I-TCP)
  • End-to-End Approach
    • Modify TCP (TCP SACK)
    • Change ACK algorithm
    • New Transport Layer Protocol
  • New protocol suite (e.g. WAP)

TCP in “Mobile” Networks

這裡強調的是 Handoff 換手造成的 Packet loss 問題,所以上面的方法可能會不適用。
像是上面的兩個 Split Approach 都不行。

如果要減輕換手造成的 Packet loss,我們可以「無縫換手」

  • 減少換手延遲
  • 使用 Packets forwarding
    • 情境是如果換手之後,在原先基地台較晚的到的資料,會被轉送 forwarding 到新的基地台
    • 也因此有可能會發生重複 ack 的問題
      • 但如果有設閾值那就還好

其他問題?

對於 802.11 來說,TCP 的 Data 跟 ACK,通通都只是「要傳的資料」,也就是說他並不知道優先順序,而剛好在 802.11 的環境是,搶到就是你的,所以會有一種很尷尬的情形,就是 A 傳了 TCP 的 Data 給 B,理論上 B 應該要在時間內傳送 TCP 的 ACK 回去。

但是對 802.11 來說,這兩個都只是要傳的資料,所以有可能 TCP 的 ACK 在時間內都傳不過去,因為都被搶走了,也就因此 ACK 超時了。