Automating Cross-Layer Diagnosis of Enterprise Wireless Networks — 繁體中文詳細導讀

出處：ACM SIGCOMM 2007（Kyoto），原文 fp187-cheng.pdf 作者：Yu-Chung Cheng、Mikhail Afanasyev、Patrick Verkaik、Péter Benkö（Ericsson Research）、Jennifer Chiang、Alex C. Snoeren、Stefan Savage、Geoffrey M. Voelker（UCSD） 分類：C. 使用者端 — P3 連上但很慢（Wi-Fi 瓶頸），見 主動式AI網管與報修-總覽 說明：原文有 ACM 版權，本篇是逐章節改寫的導讀，不是逐句翻譯。數據與圖表結論都保留，細節請對照原文。

一句話

企業 802.11 網路的「剛剛網路很卡」，原因常橫跨好幾層，還互相影響。作者用 Jigsaw 的全棟被動監測資料，從實體層一路推到傳輸層，替每個封包重建延遲來源（AP 佇列、退避、競爭、省電緩衝），也替每個使用者算出行動管理（掃描、關聯、DHCP、ARP、DNS）的開銷，讓診斷可以自動化。

摘要重點

• 企業網路複雜到連簡單故障都不好查，短暫斷線或效能變差更難查。802.11 無線網路除了有線網路本身的問題，還多了共享頻譜、使用者移動、認證管理三種挑戰。
• 多數組織缺乏拆解這些問題所需的專業、資料和工具。
• 本文提出一組建模技術，自動找出問題來源，重點放在 802.11 特有的兩類資料傳輸延遲：媒體存取（media access）動態和行動管理延遲。
• 方法是結合量測、推論與建模，重建各層的延遲來源和它們之間的交互作用，並用 UCSD 資工系館的完整無線流量 trace 示範。

1. 引言

背景

• 免授權頻段加上便宜的 802.11 晶片，讓無線網路從家庭普及到辦公室；當時美國超過三分之二的企業提供 Wi-Fi。
• 家裡裝一台 AP 只是延長有線網路；企業部署可能有上百台 AP，要依 RF 場勘規劃位置和設定，盡量減少競爭、提高吞吐量，營造無縫覆蓋的效果。
• 802.11 協定本身不負責管理這一切，負擔落在網管身上：RF、鏈路層變化、動態定址與授權、VLAN，以及有線網路本身。

為什麼無線特別難診斷

1. 共享頻譜：競爭與干擾不一定能直接觀察到，卻會造成明顯的端到端延遲或掉包。
2. 廠商實作差異：802.11 標準在媒體存取上留了很大的彈性，各家「詮釋」不同，很多會明顯影響效能。
3. 無縫漫遊不是 802.11 本身提供的：企業通常靠一個非正式的「layer 2.5」實現，拼湊了 802.11、VLAN、ARP、DHCP，加上常見的專有行動管理與認證系統。這種東拼西湊的機制有自己獨特的故障模式。

現實困境

• 網管被問「十分鐘前網路為什麼不穩？」時，通常只能回答「不確定，現在看起來正常」。
• 同時具備網路行為細節的能見度和廣泛知識的網管很少；就算有，人工診斷也很費工，只有最嚴重、最持久的問題才划算。
• 實例：UCSD 一棟新辦公大樓的無線使用者，遭遇短暫但嚴重的效能問題長達一年以上，在地專家和廠商技師都查不出來。（作者註：他們認為最後找到原因，是 AP 廠商實作中的一個細微 bug，事後看很好懂，但靠試誤法很難找到。）

本文定位

• 作者主張這類診斷必須全自動才有效。第一步是建立從實體層到傳輸層的無線延遲模型，推論鏈路層延遲和行動管理延遲的成因與影響。
• 在四層樓的 UCSD 資工系館 trace 上，發現沒有單一異常、故障或交互作用能解釋所有問題，所以需要整體性的分析。

論文結構：§2 相關研究 → §3 trace 收集 → §4 封包可能遇到的各種阻礙 → §5 媒體存取模型 → §6 行動管理模型 → 結論。

2. 相關研究

監測系統的演進

已被量測／推論過的面向

• 直接量測：應用負載、使用者移動、無線掉包、速率調整、handoff 延遲 [10, 13, 19]，甚至實體層異常 [22]。
• 推論：鏈路層掉包、沒有 MAC 位址的封包是誰送的 [4, 7, 18]；同頻干擾與過度保護的 AP [7]；行為異常／異質裝置 [4, 7, 9]；實體層異常的根因 [22]；覆蓋不良區域 [4]。
• 本文的擴充：對每個封包推論媒體存取的關鍵路徑延遲（critical path delay [3]），例如 AP 佇列延遲、媒體競爭（強制退避與一般退避）；並對每個使用者推論支援間歇性與行動裝置所需的管理延遲。

802.11 分析模型的限制

• 既有模型估計網路容量 [6]、單一 flow 最大吞吐量 [14]、飽和吞吐量與預期存取延遲 [17]，大多是解析模型。
• 為了能解，它們假設：沒有傳輸錯誤、速率與封包大小一致、節點需求無限且持續競爭、碰撞／干擾機率均勻隨機等。
• 所以這些模型適合理解理想條件下的極限，但看不到真實網路的兩件事：突發流量的放大效應（被平均值和期望值掩蓋），以及負載、協定、環境之間相關且出乎意料的交互作用。本文的模型可以推論這些。

三個最相關的系統

3. Trace 收集

• 使用作者先前的 Jigsaw [7]：部署在系館內的分散式無線監測平台，監測正式營運的 802.11 網路。
• 正式網路：40 台 Avaya AP-8（802.11b/g），涵蓋四層樓與地下室；除頻道外設定都相同，不加密。
• 監測硬體：192 個無線電散布在 AP 之間，被動監聽並透過專用有線網路把所有事件回傳到後端儲存伺服器。
• Jigsaw 把各無線電的 trace 合併並做時間同步成一份全域統一 trace，而且是即時處理：一台 2.2 GHz AMD Opteron 伺服器處理一分鐘原始資料不到 15 秒。
• 每個 frame 只擷取前 120 bytes。所有無線電加起來的監測流量約 2–10 Mbps，大約是正式無線流量的 5 倍。一般平日原始 trace 約 80 GB，合併後約 10 GB；分析用合併後的 trace，原始 trace 只用來除錯。

表 1：本文使用的 trace（2007/1/11，星期四）

4. 一個封包的坎坷旅程

作者先簡介 802.11 網路中延遲和掉包的可能來源，說明為什麼需要後面的分析。

4.1 實體層

• 2.4 GHz ISM 頻段上還有很多非 802.11 裝置（無線電話、微波爐…）。封包可能被寬頻干擾破壞，或在接收端被更強的訊號蓋過；發送端也可能偵測到頻道上有能量而延後發送，一直等到干擾消失。
• 圖 1（微波爐干擾）：縱軸是 physical error frame 的時間戳取 16 ms 模數，橫軸是兩分鐘的微波爐使用時間。家用微波爐的倍壓電路讓它在 60 Hz 週期的一半（約 8 ms）發出掃頻寬頻干擾，另一半安靜，所以圖上出現固定的白色空隙。範圍內的 802.11 無線電會延後發送直到媒介閒置，於是佇列累積、延遲增加；微波爐開啟瞬間正在傳的 frame 可能損毀。
• 相鄰頻道干擾：802.11 名目頻寬 22 MHz，很容易和鄰近頻道重疊。一般說美國有三個正交頻道，實際上不一定成立。作者常觀察到相鄰頻道的交互影響，甚至看過發送端和接收端相隔 50 MHz（頻道 1 到頻道 11）仍成功收到封包。
• Capture effect [15]：兩個封包在接收端碰撞時，無線電通常會解出訊號較強的那個。

4.2 鏈路層

AP 負責兩件關鍵工作：媒體存取，以及 client 與 AP 的綁定。兩者都可能造成額外、有時是不必要的延遲。

傳輸延遲的來源

• AP 在無線發送前的佇列等待
• 協定延遲：每次發送後的強制退避、掉包後的指數退避
• 封包傳輸時間（由編碼速率和封包大小決定）
• 使用者與 AP 共用競爭域時的競爭（或前述干擾）
• 一個封包可能同時受上述所有因素影響，重傳時還會重複受影響
• 驅動程式常在掉包後降速編碼，但這可能提高頻道佔用率，反而有副作用

例子：封包在時間 t 抵達 AP 之後

1. 在佇列中等前面的封包送完（每個前面的封包都有自己的存取延遲和重傳開銷）。
2. 到佇列頭後做強制退避：等 0–15 個 slot（802.11b 一個 slot 是 20 µs；802.11g 在某些條件下可用 9 µs 的 short slot）。
3. 退避後要感測頻道一個 DIFS（50 µs）；若頻道忙碌，再做一次退避。
4. 發送，所需時間主要由速率決定。
5. 若沒收到 ACK，每次重傳前都要再退避。

實際情況更複雜：還有省電管理等協定功能的交互影響，以及廠商的不規則行為（例如有些廠商允許在一次 frame exchange 的重傳之間插入特定封包）。麻煩的是，這一層大部分的延遲成分無法直接觀察，因為它們取決於 AP 內部狀態，沒有任何協定機制會揭露。

管理延遲

• client 和 AP 一直在找最佳配對：client 持續掃描找更好的 AP，AP 回應掃描並廣播 beacon。client 換 AP 時，還要做認證和綁定（association）。
• AP 的 client 很異質，雙方要協商需要哪些功能（802.11b 或 g、省電等）。反直覺的是，一台筆電的選擇就可能改變整台 AP 的行為，因為 AP 會遷就能力最低的 client。例如作者先前發現，只要有一台 802.11b client（就算沒在傳資料），AP 常常就會進入 802.11g「保護模式」，拖累所有 802.11g 使用者 [7]。

4.3 基礎設施支援

• AP 本質上是橋接器。client 要上網，還要透過 DHCP 拿 IP、透過 ARP 拿下一跳的 MAC。這些協定本身動態就複雜，失敗時可能讓裝置斷線一段時間。
• 在 802.11 環境中它們用法更特殊：常與 VLAN 綁在一起，搭配專有的行動管理軟體，做單一登入認證，並讓 client 在 AP 間漫遊時維持同一個 IP。這部分沒有標準，故障模式也還不清楚。

4.4 傳輸層

底層的延遲和掉包最後都會傳到傳輸層（通常是 TCP），TCP 可能誤以為是壅塞而放大影響。

整套機制平常運作得意外地好，但出錯時可能錯得很離譜，讓使用者遇到明顯的回應延遲。本文的目標就是把這些問題的分析系統化。

5. 媒體存取模型

模型包含三部分：有線分配網路、AP 內部佇列行為、802.11 MAC 的 frame 傳輸。目標是算出每個被監測到的 frame 在無線路徑各階段遇到的延遲：先求出一連串時間戳，再由時間戳相減得到延遲。部分時間戳可以從有線與無線量測直接取得，其餘要靠推論。這些推論技術，加上推論所需的 AP 佇列與傳輸行為模型，是本文的主要貢獻。

圖 2：示意有線閘道 → AP（Broadcast Q、PowerSave Q、Tx Q）→ 無線發送，標出 t_w、t_i、t_q、t_h、t_s、t_e 的位置，以及 d_ps、d_q、d_mac 對應的區段。

表 2：時間戳與延遲定義

5.1 關鍵路徑時間戳

t_w（量測）：在系館主分配路由器設定 SPAN port，把每個要送往 AP 的封包複製到專用追蹤伺服器打時間戳（假設這段傳播延遲固定）。

有線／無線封包配對

• 在 1 秒視窗內比對正規化後的封包內容（調整 802.11 與 Ethernet II 的格式差異）；1 秒是該網路中有線封包被無線轉送的實測最大延遲。
• 大多是一對一；廣播 frame（例如 ARP request）會一對多，因為每台 AP 都會轉送。
• 偶爾 AP 佇列溢位會掉包（多發生在 client 大量下載時），可從 frame sequence number 偵測。
• 整體配對率 99.95%。

t_i（推論）：沒辦法在 AP 上裝 tap，也無法控制 AP 軟體。t_i 由 AP 的 Ethernet I/O 延遲和閘道到 AP 的傳播延遲決定。對每台 AP 統計 (t_s − t_w) 的分佈，最小值減去 DIFS 就是最小封包的有線延遲加 AP 輸入處理延遲。

AP 佇列模型：依 802.11 標準把 AP 建模成三個 FIFO 佇列：

• 精確建模佇列很重要。例如若沒正確處理省電 client，它們的封包會看起來在 AP 卡了數十毫秒。
• 判斷 client 是否在省電模式的方法：追蹤 client frame 的 PSM bit，或看 beacon 的 TIM 是否顯示 AP 有替該 client 緩衝封包。
• 標準規定：只要有省電 client，AP 就應該在 beacon 間隔送廣播 frame，因為省電 client 只在那時醒來。

t_q 的推定

• 廣播／多播：該 frame 發送前最近一個 beacon 的時間。
• 送往省電 client：client 送出 PSM bit 關閉的 frame（例如 PsPoll）通知已醒來的時間。
• 其他：t_q = t_i（AP 一收到就放進發送佇列）。

t_h 的推定（依前一次 frame exchange 結束時間 t_pe 分三種情況）

1. frame 在前一次傳輸結束前就進佇列 → head-of-line blocked，t_h = t_pe。
2. frame 在 t_pe 之後、超過最大強制退避視窗才進佇列 → 佇列一定是空的，可立即發送，t_h = t_q，標為「非 HOL blocked」。（強制退避是隨機的，無法直接量，但標準有給上限。）
3. frame 落在前一次的最大強制退避視窗內 → 不確定。這個視窗很小（802.11g 約 300 µs），不到 1% 的 frame 落在這裡，假設佇列為空，t_h = t_q。

t_s、t_e（直接量測）：從同步後的 trace 取得。t_s 是第一次發送嘗試的開始，包含 RTS/CTS、CTS-to-self 的控制開銷；t_e 是最後一次嘗試的 ACK 結束，包含所有重傳和競爭。沒有 ACK 的廣播 frame，t_e 取排定的結束時間（NAV end），也就是 data frame 結束後加 60 µs。

AP 自己產生的 frame（掃描回應、關聯／認證回應）：有線 trace 裡看不到它們何時產生。所幸它們通常是回應 client 請求的管理 frame，所以假設 AP 一收到請求就把回應放進發送佇列。

5.2 關鍵路徑延遲

• d_ps = t_q − t_i：省電 client 與廣播 frame 的緩衝延遲。稱為「省電延遲」，因為廣播 frame 是為了在 beacon 間隔醒來的省電 client 而緩衝。
• d_q = t_h − t_q：AP 發送佇列延遲。
• d_mac：frame 到佇列頭後完成 frame exchange 的時間，包含 clear channel assessment、PHY（重）傳和所有指數退避。
• d_ps + d_q + d_mac = 封包在無線分配網路中的總時間。
• 佇列延遲再細分：d_q = d_qb + d_qs + d_qo
  • d_qb：被背景管理 frame（beacon、掃描回應等）擋住
  • d_qs：被送往同一個 client 的 unicast frame 擋住
  • d_qo：被送往其他 client 的 unicast frame 擋住
  • 算法：模擬 AP 佇列內容，找出排在前面的 frame，加總它們的 d_mac。

5.3 驗證模型

理想做法是在 AP 上加量測工具，逐 frame 比對推論值和真實值，但手上沒有能逐 frame 輸出佇列或頻道偵測時間戳的商用 AP 或開源驅動。替代做法是：檢查推論出的延遲是否符合 802.11 MAC 已知運作方式應有的分佈。

圖 3：簡化的 802.11 DCF（unicast）流程

N = CWmin
1. 等待 DIFS 直到頻道閒置
2. 若頻道不忙，跳到步驟 4
3. 一般退避：bo = rand[0, N]
   當 bo > 0：探測頻道 20 µs；若忙碌則等 DIFS 直到閒置；bo 減 1
4. 發送 frame；若沒收到 ACK，N 加倍，從步驟 1 重試
5. N = CWmin，依步驟 3 做強制退避

Avaya AP-8 驗證（圖 4）

• 資料：一小時、一台 Avaya AP 對一個做 bulk TCP 下載的 802.11g client，只看 head-of-line blocked frame 的第一次發送嘗試的 d_t0（因為 802.11 協定讓它的分佈可預測）。
• 強制退避 = bo × 20 µs，Avaya 在 802.11g 隨機取 bo ∈ [0, 15]。之後聽 DIFS，頻道閒置就立刻發送，這時 d_t0 = 強制退避 + DIFS。退避期間若頻道忙碌，bo 會暫停遞減直到頻道閒置一個 DIFS。
• 分佈的形狀可以逐段解釋：
  • 起點 50 µs：每個 frame 至少等一個 DIFS。
  • 第一組階梯（50 到 50 + 15×20 = 350 µs）：強制退避期間沒遇到競爭，每一階對應一個 slot 值；約佔 60%。
  • 第二組階梯（547 到 847 µs）：強制退避期間遇到競爭，主要是 client 回傳的 TCP-ACK。TCP-ACK 的 PHY 傳輸時間 447 µs，加 DIFS 共多 497 µs，所以從 50 + 497 = 547 µs 開始。因為競爭長度不一，這組階梯比較不明顯。
  • 剩下約 10%：遇到更長的競爭，或在步驟 3 做了一般退避。
• 細節：第一組階梯越後面越短，第二組相反。原因是 bo 抽得越大，越可能在退避中輸掉競爭、要等對方送完。強制退避被打斷的機率約 40%，大致對應 TCP 的 delayed ACK（每兩個 TCP-DATA 回一個 ACK）。

Cisco Aironet 350 驗證（圖 5）：證明方法不綁定單一廠商

• 無法在正式網路替換 AP，所以另做對照實驗：client 透過 Cisco AP 用 scp 下載大檔。
• 乍看分佈和 Avaya 差很多，但其實是同一個 802.11 發送流程，只是參數不同：Cisco 只用 802.11b，CWmin = 31（802.11g 是 15）。
• 拆成兩類：若偵測到強制退避期間 AP 有 ACK 其他 frame（主要是 client 的 TCP-ACK），歸為「contention」，形成從約 400 µs 開始的階梯（剛好是 DIFS 加上等 TCP-ACK 傳輸的暫停）；其餘歸為「no contention」，形成從 DIFS 開始的 31 階。兩者合起來就是「all」，與圖 4 對應。
• 另外把 Avaya AP-8 改成 short slot（9 µs）重做，分佈的階寬也跟著改變。

結論：雖然部分事件時間要靠推論，模型在非常細的時間尺度上仍與 802.11 運作一致；換廠商時只要設定參數即可。需要的參數（最小／最大競爭視窗、slot time）在 AP 手冊或設定介面都查得到。

5.4 套用模型

情境：同一台 AP 下三個 client（Xb、Yb：802.11b；Zg：802.11g）同時用 TCP 從同一台網路伺服器下載不同檔案，互相競爭 AP 資源和空中時間。對 Yb 的 flow 套用模型，畫出四分鐘內每個 frame 的延遲拆解（圖 6），疊上 goodput 曲線，並標出無線掉包（三角形）和網際網路掉包（菱形）。

觀察：

1. AP 佇列延遲是主要延遲，比無線傳輸延遲大好幾個數量級；即使三個 client 競爭，d_mac 仍很小。
2. Yb 的佇列等待中，約一半在等自己的 frame，另一半在等其他 client 的 frame；其中大多是 Xb，少數是 Zg。
3. Yb 偶爾有無線掉包，但對 goodput 影響不大。
4. 14:39:38 發生一波網際網路掉包，goodput 明顯下降；Yb timeout 並恢復期間，AP 佇列被清空。
5. 14:40:00 之後出現階段轉變：其他 client 下載完，Yb 不用再分享頻道，AP 佇列佔用下降，goodput 大幅超過競爭時的水準。

5.5 TCP 吞吐量診斷

目標：用媒體存取模型找出無線使用者 TCP 吞吐量受限的根因，讓網管看到各類問題的分佈，優先處理主要瓶頸。

步驟 1：找出「TCP transaction」

• TCP flow 可能有閒置期（例如 persistent HTTP 的 think time），所以只取 bulk 傳輸期間：從出現新的未確認資料開始，到所有未完成資料都被確認為止。
• 期間大部分封包須為 MSS 大小（最後一個除外）。
• 只分析傳輸量 ≥ 150 KB 的 transaction，因為夠大才有機會吃滿無線頻道。

步驟 2：依序過濾（假設單一根因、各因素大致獨立）

補充：

• 嚴重無線掉包通常也會造成很多指數退避，但這些在第 5 步已濾掉。被退避限制的 transaction 通常有很多 802.11 本地重傳，但 TCP 層沒掉包。例如有些廠商最多重試 15 次，frame 最後送得出去，但指數退避可能花超過 220 ms。
• 過度保護：一台閒置的慢速 802.11b client，讓所有 802.11g client 傳資料的時間最多變成正常的兩倍。

結果（圖 7）

• 資料：864 位使用者、1,375 個 TCP flow、2,605 個 bulk transaction，85% 是 HTTP 或 SCP 下載。
• 有 28% 因模型與實測差距超過 10% 被剔除；例如解析模型會高估低頻寬 flow 的吞吐量，作者還在改進。
• 剩下 transaction 的四個重點：
  1. 原因非常多元：要診斷某個使用者的 TCP 慢，就得把所有可能原因都建模檢查。
  2. 超過 20% 受無線掉包限制：主因是系館 AP 的 802.11g 鏈路層重試策略有缺陷。AP 在保護模式下用 802.11g 速率時只重試一次就放棄，自然拖累 TCP。
  3. 超過 22% 受過度保護限制：AP 太保守地啟用 802.11g 保護模式。 → 第 2、3 點都只要改 AP 軟體就能解決；廠商已承認作者回報的問題並開始研究解法。
  4. 近 27% 受 receiver window 限制：雖然大家先懷疑無線，瓶頸其實可能只是 client 的 TCP 堆疊設定。診斷時也要懷疑無線以外的原因。

圖 7 的類別：Misc、Exp Backoff、Prot. Mode、QD Same User、QD Other User、QD BG、Wrls Loss、Ideal、Internet、Recv Window。

6. 行動管理

802.11 的第二類開銷是各種行動管理：掃描 AP、關聯、ARP、DHCP、認證等。例如第一次加入網路要等 IP，或因為掃描其他 AP 打斷正常傳輸。本節說明如何建模這些延遲，並套用到 trace。

6.1 開銷分析

• 把管理相關封包分成 8 類：掃描、PSM sleep、關聯（含認證、關聯、重新認證、重新關聯請求）、DHCP、DNS、ARP、TCP、misc。misc 包含 WEP/WPA（AP 都不支援加密，但 client 偶爾會送）、IPv6、mDNS、Windows 網路及其他 IP 流量。
• 把分類後的封包組成連續的 span。只看 client 送出的封包，忽略送進 client 的封包；例外是 AP 送的 deauthorization，它會結束目前的 span。
• 圖 8：活躍 client 在各類 span 的平均時間比例（5 秒一格、1 分鐘平均）。只畫佔比大的 TCP、省電、掃描，其他（關聯、DHCP、DNS、ARP、misc）合併為 Other。每一格只計算該格內有送封包的 client，並依 client 數正規化。
  • 絕對比例會隨格子大小改變（client 很突發，取樣期越長，活動密度越低），但各類 span 的相對長度大致不變。
  • 結論：client 活躍時間約三分之一花在掃描或其他維護活動（ARP、DHCP、關聯等），這些都是行動管理直接造成的開銷。

6.2 掃描的影響

• 802.11 client 一直在掃描有沒有更好的 AP。若 client 本來閒置，影響不大；若介面正忙，就會造成可觀察到的延遲。
• 為了只計算 client 忙碌時發生的掃描，採保守判定：5 秒格內 TCP 吞吐量 > 100 bps 視為「active」，否則為「idle」。
• 約 40% 的裝置完全沒被打斷：可能是判定太嚴、網卡夠聰明會避開，或監測期間不夠活躍。
• 其餘 60% 的打斷時長分佈（圖 9）：
  • 平均約 250 ms，超過 20% 的打斷長於 1 秒。
  • 多數由掃描造成，但也有不少是進入省電模式（送出 power save 開啟的 NULL 封包，之後再送關閉的 NULL 封包）。PSM 打斷可能比掃描短很多，但平均時長相近，且不太會超過 1 秒。
• 打斷頻率（圖 10）差異很大：平均每 10 秒左右被打斷一次，這種程度不太影響吞吐量，所以在圖 7 歸入 misc；但 10% 被打斷的主機每秒不只一次，比較可能讓 SSH 等互動式應用的使用者不耐煩。
• 掃描還會加劇 hidden terminal 問題：一個 probe 可能被多台彼此聽不到的 AP 收到，它們同時回應，在 client 端互相干擾。
  • 偵測法：比較每個送往同一 AP 的封包的開始時間和前一個封包的結束時間，有重疊就把兩者都標為 hidden terminal 碰撞。
  • 結果：超過一半的裝置送出的 probe 曾與其他裝置的封包碰撞；最嚴重的裝置有超過 10% 的 probe 碰撞。所以主機必須頻繁掃描，才能收到可用 AP 的回應。

6.3 啟動（Startup）

client 剛出現時，要依序完成以下步驟才能在 IP 層通訊：

1. Scan：找候選 AP
2. Associate：嘗試與選定的 AP 關聯
3. DHCP：成功加入 802.11 網路後取得 IP（此環境用動態 IP）
4. ARP：查 DHCP 指定的下一跳路由器 MAC（發出 ARP “who has”）
5. DNS：解析遠端主機名稱，拿到 IP 後才開始送真正的資料

篩選條件：為了只看真正在啟動、而不是閒置後重新關聯的裝置，規定第一個看到的封包必須是 scan request；且只看最後成功關聯、至少送出一個 TCP 封包的裝置。

啟動時間（圖 11）

• 「First to TCP」：從第一個 probe request 到第一個 TCP segment 的實際時間。多數主機超過 10 秒才開始通訊，平均將近 1 分鐘。
• 作者推測大部分時間是閒置（機器沒在積極推進）。驗證方法是判斷每個 span 成功與否：
  • 掃描後沒接著再掃描 = 掃描成功；關聯、DHCP、DNS 若 span 最後一個封包是 AP 送給 client（例如 ACK）= 成功。
  • 成功 span 之間的空檔歸因於終端（OS 尚未初始化網路堆疊）；失敗 span 之間的空檔歸因於網路 timeout。
• 「Without OS delay」：扣掉成功 span 之間的閒置時間。平均主機約有 8 秒在閒置，推測是開機或從省電中恢復。
• 「Good only」：只加總成功 span 的時長，代表各階段之間零閒置的最佳情況。平均主機有超過 20 秒花在失敗的 span 期間或之後。

成功 span 各階段時間（圖 12，只算 span 本身，不算 span 之間）

失敗 span 的 timeout 代價（圖 13）

• DNS、關聯常在約 10 ms timeout，但最壞情況要數十秒。
• DHCP 最小 timeout 似乎是 100 ms，之後越來越長。
• 失敗的掃描非常昂貴（至少 7 秒）：掃描失敗多半代表附近沒有合適的 AP，短時間重試沒意義，多數裝置會等至少 10 秒再掃。
• 有些主機會掃描非常久，推測是一直找不到想加入的 AP，也就是在找一個不存在的 SSID。

6.4 動態位址分配（DHCP）

DHCP 對使用者和網管都方便，但上面的結果顯示，它可能讓想快速上網的使用者感受到明顯延遲。

client 發起 DHCP 的原因（表 3，一整個平日）

（一筆 transaction 可能同時符合多個原因。）

• 最主要的原因是租約續約。網路裡大部分租約是 3 小時，所以穩定連線的 client 一整天都會不斷發起 DHCP。

DHCP 耗時（圖 14）

• 75% 在 6 秒內完成。
• 但當天超過 10% 的 DHCP transaction 超過 1 分鐘；對當天第一次連線的使用者來說很明顯。

作業系統差異

• 用 MAC 位址的廠商代碼和 DHCP 的「Vendor Class」選項，幾乎能辨識 trace 中全部 186 台裝置的 OS 與網卡廠商。Windows 系列 118 台，Apple 硬體 51 台。
• Apple client 的 DHCP 一直比 Windows 久：OS X 預設使用 Zeroconf，啟動時多花約 10 秒。它們會樂觀地嘗試續用最近一次的租約（常是使用者家裡私有網路的租約），在校園環境裡這個租約無效。

7. 結論

• 企業網路複雜到簡單故障都難診斷，短暫斷線或效能下降更難，802.11 無線網路尤其明顯。
• 作者認為診斷必須自動化，而網路最終要能在沒有人參與的情況下處理短暫故障。
• 第一步：一組以無線 trace 為輸入的模型，能準確判斷實體層到傳輸層的協定行為對每次傳輸的影響。
• 部分延遲可直接量測，但 AP 佇列、退避、競爭等很多成分要推論。為此建立了詳細的 MAC 行為模型，同時涵蓋 802.11 規格的描述和廠商硬體的實際實作。
• 也探討了 802.11 行動管理的固有開銷：掃描、關聯、ARP、DHCP、認證等。
• 在四層樓辦公大樓的 trace 上驗證：沒有單一異常、故障或交互作用是唯一原因，要涵蓋真實網路的各種問題，可能必須做整體性分析。

與主動式網路報修的關聯（個人筆記）

• **「十分鐘前為什麼卡？」**正是報修情境的核心問題。本文示範只靠事後 trace，就能把一次體感變慢拆成可歸責的成分（AP 佇列、退避、無線掉包、Internet 掉包、client receiver window、保護模式…）。
• **根因過濾鏈（§5.5）**可以直接當成報修自動分流的規則骨架：先排除 Ideal 和 client 端問題（receiver window），再分 Internet 和無線，最後細分無線內部原因。
• 近 27% 是 client 自己的 TCP 設定、超過 20% 和 22% 是 AP 軟體策略問題，代表報修系統不能預設「是無線訊號不好」。
• 行動管理數據（活躍時間約 1/3 是管理開銷、DHCP 超過 10% 要 1 分鐘、ARP-to-self 約 1 秒、Apple Zeroconf 多 10 秒）可以當成「連上了但一開始很慢」類報修的基準值。
• 限制：需要 Jigsaw 等級的全棟密集監測（192 個無線電）加 SPAN port，部署成本高。後來的 WiFiSeer 改用既有 SNMP 資料，是比較輕量的路線。

參考文獻（原文 23 篇，列出相關者）

• [1] Bahl et al. DAIR. HotNets 2005.
• [3] Barford & Crovella. Critical path analysis of TCP transactions. SIGCOMM 2000.
• [4] Chan et al. Location-based management system for enterprise WLANs. NSDI 2007.
• [5] Chandra et al. WiFiProfiler: Cooperative diagnosis in wireless LANs. MobiSys 2006.
• [7] Cheng et al. Jigsaw: Solving the puzzle of enterprise 802.11 analysis. SIGCOMM 2006.
• [18] Mahajan et al. Analyzing the MAC-level behavior of wireless networks in the wild. SIGCOMM 2006.
• [20] Padhye et al. Modeling TCP Reno performance. IEEE/ACM ToN 2000.
• [22] Sheth et al. MOJO: physical layer anomaly detection for 802.11 WLANs. MobiSys 2006.