HackMD
感覺好像少吃很多仙貝，總覺得聽下來不是很懂，老師也有說上過的人當複習。
可以修 電腦網路導論
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。
兩個階段如下圖：
可以看到各個點對應的值跟上面敘述符合。
減少
說到減少，要先提在有線環境下的情況。
TCP 在有線的環境下，偵測到封包損失 packet loss 就會開始減少 windows。
因為在有線環境下，封包損失就代表負責轉運的路由器被塞爆了；所以現在在無線環境也以這個為基礎，覺得封包損失原因是自己把網路塞爆了。
但是…
其實有可能是因為傳輸環境不好 (BER 很高)，造成封包損失，或是傳輸速度很慢，ACK 來不及回來等等，也就是說無線環境多了很多其他因素造成封包損失，並非全都是由堵塞造成的。
傳輸速度降低的方法，有兩種，一個是直接歸零，一個是砍半。
TCP是一個端到端的協議
行動與無線
老師說回到第一堂課講的，對每個系統都要去注意，無線跟有線的差異，以及行動跟固定的差異。
在現在這個例子可以發現兩大問題：
- 無線的環境可能會不好，也就是 BER 很大，造成誤判
- 所以高 BER 就很像是懲罰兩次
- 環境就已經不好傳輸了，還會被誤判為堵塞，造成傳輸速率下降，不就越來越慢
- 移動可能會造成換手的封包損失，也會被誤判
總結來說就是「環境問題」跟「換手問題」。
Round Trip Time / RTT
一次的傳輸時間，也就是「傳遞出去」到「收到 ack」 的時間。
所以一段 RTT 之間可以傳的量就是我的 throughout，而沒有收到 ACK 就會假設是發生封包損失，也就是假設發生堵塞。
Packet Loss
收不到 ACK 在無線 TCP 有兩種情況：
- 超時，也就是超過預估時間沒有收到
- 會有個 Retransmission TimeOuts / RTO timer 來計時
- 收到重複的ACK
- 重複 ACK 的來源是一個避免措施
在 TCP 當中，收到東西就一定會傳 ACK。如果正確的話，就會照著順序回傳 number；
但是如果接收方沒有照著順序收到封包，例如下圖中的 4 可能傳一傳不見了，當接收方收到的時候，發現跳號了，他就知道有可能是中間有人不見了，所以會回傳當前收到的最大 number 回去，也就是 3。
在無線的環境可能又會有多條路，所以可能有些人會超車。
所以會設定收到幾個重複的號碼以上才視為真的有人不見了。
無線傳輸的情形
- 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 而分類。
Link Layer
- Robust link layer
就是加強環境，使用 FEC 和 ARQ。
- TCP-Aware Link Layer solution
就是有名的 Snoop 方法
- 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。
Hide Wireless Link Error from TCP
前面有提到，TCP 會誤判的原因之一就是環境太差，那我們就不要讓 TCP 去知道環境差的錯誤就好了。
- 方法一就是模擬出有線環境，也就是使用 FEC 降低 BER。
- 方法二是減少頻段的錯誤率，例如使用
- Automatic Repeat Request (ARQ)
- ARQ 就是 retransmission
- Forward Error Correction (FEC)
- 就是校正碼
- Hybrid FEC/ARQ scheme
- 是將 ARQ 的部分搭配 coding 技巧
- Automatic Repeat Request (ARQ)
TCP-aware Link Layer Solution
就是待會的重頭戲 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 回來
- 收到重複的 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，也就是說依舊保持原先的速度
- Sender 就會進入 Persist Mode；那個 window 就是前面提到的 window
- 當收到「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
- Snoop 是設計一個新的 link layer，不會動到 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 超時了。
