第三章提纲与叙事设计备忘

最终版本的结构（已写入 chap03.tex）

章节的核心叙事逻辑是"先提出挑战，再逐一用设计解决"：

3.1 系统总体架构（简要）：Coordinator-Node架构、TUN/UDP隧道/per-flow线程，一段话说完。
3.2 设计挑战：先提出三个核心挑战，让读者带着问题读后续设计。
3.3 交织XOR前向纠错编码设计（解决挑战一）：
- 编码方案选择：为何选XOR分组码——分组码的冗余包是独立包，不嵌入用户数据包，所以不存在MTU溢出问题。流式编码需要预留冗余空间，不适用。
- 交织编码矩阵结构、编码器/解码器工作流程。
3.4 基于丢包统计的自适应参数调整（解决挑战二）：
- 三状态丢包模型（先建模 → 再估计 → 再搜索参数）。
- 解码端丢包检测与统计。
- 模型参数估计（从loss_1/loss_2/loss_3推导p21/p23/p33）。
- 编码参数搜索算法（延迟约束20ms + 残余丢包率约束1%）。
3.5 解码端输出速率控制设计（解决挑战三）：
- 问题：FEC突发输出 → ACK密集 → CCA误判带宽 → 速率震荡 → 影响FEC参数估计。
- PI控制器：Passthrough（直通+测速）→ Controlling（PI控制）。
- 协同关系：Pacing稳定CCA → CCA稳定发包 → 编码器稳定填组 → 参数估计更准。
3.6 本章小结。

挑战	核心问题	对应设计
挑战一	通用转发场景下用户包大小可变，冗余不能嵌入包内导致MTU溢出	分组XOR编码（冗余包独立发送）+ 交织
挑战二	需满足流媒体延迟需求，同时结合实时丢包数据自适应调整	三状态丢包模型 + 约束搜索算法
挑战三	FEC解码突发输出导致CCA误判带宽	PI速率控制器（Pacer）

挑战尾部的策略预告 + 前向链接：3.2中每个挑战的末尾都用1–2句话概括了解决策略，并通过 \ref{sec:xxx} 前向链接到对应的设计小节，例如"本文采用交织XOR分组编码方案应对此挑战（详见第\ref{sec:fec编码}节）"。
设计开头的挑战重述：3.3/3.4/3.5每个设计节的第一句话都以"本节针对挑战X"开头，回指3.2中提出的挑战，形成闭环。

挑战先行：3.2节先把三个挑战全部摆出来，读者带着问题读后续设计，每个设计开篇回指对应的挑战。
挑战一的论述重点：不是"XOR计算简单"（这只是bonus），核心论点是"分组码的冗余包独立于数据包，不受用户包大小影响"，而流式编码需要内嵌冗余空间，不适用于通用转发。
先建模再设计：3.4的叙事顺序是"先提出三状态丢包模型 → 再说如何从观测量估计模型参数 → 再说如何基于模型做FEC参数拟合"。这比直接说"我们用了什么公式"更有说服力，也更容易和参考论文区分开。
Pacing是独立于FEC的设计：3.5独立成节，核心目的是"为CCA服务"而非"为FEC服务"。
消融实验暂缺：pacer对CCA行为的正面影响目前没有专门的对比实验，chap03中先论述设计动机和机制，chap04再想办法补充。
排版约定：代码标识符使用 \texttt{} 排版（如 \texttt{flow\_id}），这是标准LaTeX做法，不需要额外宏包。