remake完成加校对
This commit is contained in:
3
.gitignore
vendored
3
.gitignore
vendored
@@ -11,6 +11,9 @@
|
||||
*.synctex(busy)
|
||||
*.toc
|
||||
*.xdv
|
||||
*.ilg
|
||||
*.nls
|
||||
*.nlo
|
||||
**/.DS_Store
|
||||
/code/
|
||||
/.venv/
|
||||
Binary file not shown.
@@ -3,9 +3,9 @@
|
||||
% 中英文摘要和关键字
|
||||
|
||||
\begin{abstract}
|
||||
跨域覆盖网络需要为用户提供稳定的低延迟、高带宽和低丢包传输服务的同时降低运营成本。传统方案通常依赖专线链路保证服务质量，但专线根据带宽成本计算，且成本较高。已有的成本优化方法主要分为两类，链路调度方法尝试在公网质量较好时使用公网分流，但实际测量表明，公网链路质量下降时段往往与用户流量高峰重合，难以有效削减专线峰值成本。已有端到端冗余编码方法能够缓解丢包影响，但未区分不同链路片段的质量差异，容易在质量良好的片段上引入额外带宽开销。
|
||||
跨域覆盖网络需要为用户提供稳定的低延迟、高带宽和低丢包传输服务的同时降低运营成本。传统方案通常依赖专线链路保证服务质量，但专线根据带宽成本计算，且成本较高。已有的成本优化方法主要分为两类，链路调度方法尝试在公网质量较好时使用公网分流，而端到端方法尝试通过调整发送策略或网络编码应对链路质量下降，但实际测量表明，公网链路质量下降时段往往与用户流量高峰重合，难以有效削减专线峰值成本。已有端到端方法能够缓解丢包影响，但未区分不同链路片段的质量差异，容易在质量良好的片段上引入额外带宽开销，造成带宽浪费。
|
||||
|
||||
针对上述问题，本文提出一种面向跨域公网覆盖网络的分段链路质量修复方法。该方法在全部使用公网连接的前提下，仅对低质量链路片段启用前向纠错编码。本文设计了交织XOR分组编码方案，以承载各类数据流并降低连续丢包的影响；建立三状态丢包信道模型，根据解码端上报的丢包统计动态选择编码参数；同时设计基于PI控制器的输出速率控制机制，缓解FEC解码按组恢复导致的突发输出问题。
|
||||
针对上述问题，本文提出一种面向跨域公网覆盖网络的分段链路质量修复方法。该方法在全部使用公网连接的前提下，仅对低质量链路片段启用交织XOR分组编码。文本对链路建立三状态丢包信道模型，根据解码端上报的丢包统计动态选择编码参数；同时设计基于PI控制器的输出速率控制机制，缓解FEC解码按组恢复导致的突发输出问题。
|
||||
|
||||
本文使用Rust语言实现了原型系统，并在模拟跨域低质量链路的实验环境中进行验证。实验结果表明，本文方法能够正确识别低质量链路片段并启用FEC修复，在无丢包链路片段上保持普通转发。在0至~\SI{2}{\percent} 链路丢包率范围内，与直接转发方案相比，本文方法最高达到约3.6倍吞吐提升，验证了分段链路质量修复方法的有效性。
|
||||
|
||||
@@ -16,9 +16,9 @@
|
||||
\end{abstract}
|
||||
|
||||
\begin{abstract*}
|
||||
Cross-domain overlay networks need to provide users with stable low-latency, high-bandwidth, and low-loss transmission services while reducing operational costs. Traditional approaches usually rely on dedicated links to guarantee service quality, but such links are expensive. Existing traffic scheduling methods try to offload traffic to public Internet links when their quality is good. However, real-world measurements show that quality degradation of public Internet links often overlaps with user traffic peaks, making it difficult to effectively reduce the peak bandwidth cost of dedicated links. Existing end-to-end redundancy coding methods can mitigate packet loss, but they do not distinguish quality differences among individual link segments and may introduce unnecessary bandwidth overhead on high-quality segments.
|
||||
Cross-domain overlay networks need to provide users with stable low-latency, high-bandwidth, and low-loss transmission services while reducing operational costs. Traditional approaches usually rely on dedicated links to guarantee service quality, but dedicated links are often charged by bandwidth and incur high costs. Existing cost optimization methods mainly fall into two categories. Link scheduling methods try to offload traffic to public Internet links when their quality is good, while end-to-end methods try to cope with link quality degradation by adjusting sending strategies or applying network coding. However, real-world measurements show that quality degradation of public Internet links often overlaps with user traffic peaks, making it difficult to effectively reduce the peak bandwidth cost of dedicated links. Existing end-to-end methods can alleviate packet loss, but they do not distinguish quality differences among individual link segments. As a result, they may introduce unnecessary bandwidth overhead on high-quality segments and waste bandwidth resources.
|
||||
|
||||
To address these problems, this thesis proposes a segment-level link quality repair method for cross-domain public-Internet overlay networks. Under an all-public-Internet interconnection setting, the method applies forward error correction only to low-quality link segments. It consists of three key components. First, an interleaved XOR block code generates independent repair packets and spreads burst losses across different recovery groups, making the scheme suitable for diverse traffic flows. Second, a three-state packet loss channel model estimates link conditions from decoder-side loss statistics and guides the adaptive selection of coding parameters. Third, a PI-controller-based pacer smooths the bursty packet output introduced by group-based FEC recovery before the packets are delivered to upper-layer protocols.
|
||||
To address these problems, this thesis proposes a segment-level link quality repair method for cross-domain public-Internet overlay networks. Under an all-public-Internet interconnection setting, the method enables interleaved XOR block coding only on low-quality link segments. This thesis builds a three-state packet loss channel model for each link and dynamically selects coding parameters according to packet loss statistics reported by the decoder. It also designs an output rate control mechanism based on a PI controller to mitigate the bursty output caused by group-based FEC recovery.
|
||||
|
||||
This thesis implements a prototype system in Rust and evaluates it in an experimental environment that emulates low-quality cross-domain links. The results show that the proposed method correctly identifies low-quality link segments and enables FEC repair on them, while keeping normal forwarding on loss-free segments. With link loss rates from 0 to \SI{2}{\percent}, the proposed method achieves up to about 3.6x throughput improvement compared with direct forwarding, demonstrating the effectiveness of segment-level link quality repair.
|
||||
|
||||
|
||||
@@ -5,5 +5,5 @@
|
||||
|
||||
感谢实验室的沈逸昕师兄，他几年来毫无保留地将自己的经验与知识与我分享，让我少走了很多弯路。还需要感谢佟海轩师兄、李骋昊师兄、张皓晨同学和谢雨桐同学，他们在我的研究过程中与我的讨论开拓了我的思路，也让我收益匪浅。
|
||||
|
||||
四年的本科时光随着一本毕业论文行至致谢也已行至结尾。四年里我在清华园中遇到了的各位的老师与同学，感谢他们对我的帮助与支持！
|
||||
四年的本科时光也已行至结尾。四年里，我在清华园中遇到了许许多多的老师与同学，他们一路给我了许多帮助与鼓励，让我能顺利地完成这一段旅程。感谢他们对我的帮助与支持。
|
||||
\end{acknowledgements}
|
||||
|
||||
@@ -5,14 +5,14 @@
|
||||
|
||||
\section{研究背景}
|
||||
|
||||
近年来，实时音视频通信、跨地域文件传输、企业远程办公和云上应用访问等互联网服务快速发展\cite{applogic2026gipr}，网络所承载的业务类型更加多样，它们都需要高质量的网络以维持优秀的用户体验（Quality of Experience, QoE）。例如，在高清实时音视频通讯业务中，参会用户之间存在频繁的实时互动，视频和音频帧必须按时送达，维持稳定的端到端延迟、减少抖动和丢包才能维持优秀的用户体验；相对地，文件下载业务对延迟并不敏感，可用带宽才是影响用户体验的主要因素。尽管这些应用的用户体验评价指标各不相同，但是它们都需要网络提供高吞吐、稳定低延迟且低丢包的高服务质量（Quality of Service, QoS）链路，以维持优秀的用户体验。
|
||||
近年来，实时音视频通信、跨地域文件传输、企业远程办公和云上应用访问等互联网服务快速发展\cite{applogic2026gipr}，这些应用都需要优质的网络服务质量（Quality of Service, QoS）以提升用户体验（Quality of Experience, QoE）。随着网络应用类型变得更加多样，不同业务对用户体验的关注重点并不完全相同：实时交互类应用更关注稳定的音视频低时延、低卡顿率传输，文件传输类应用则更关注可用带宽和传输完成时间。尽管评价指标存在差异，这些应用都要求底层网络提供高吞吐、低时延和低丢包的高服务质量，以支撑稳定的用户体验。
|
||||
|
||||
\nomenclature{QoE}{用户体验（Quality of Experience）}
|
||||
\nomenclature{QoS}{服务质量（Quality of Service）}
|
||||
|
||||
然而，随着互联网应用的服务对象从局部区域逐渐扩展到全球范围，新增的大量跨域传输场景中网络状况复杂，使得维持优秀用户体验更加困难。跨国企业协作、跨地域云服务访问、国际在线会议和全球内容分发等场景使得通信双方经常位于不同国家和地区，用户连接不再局限于较短距离的本地网络，而是成为需要跨越多个自治系统、运营商网络和广域互联网链路的跨域连接。用户距离的增加和网络路径的拉长会放大底层网络状态变化对应用体验的影响，例如跨域链路中的拥塞、路由变化和链路质量波动都可能造成延迟升高、带宽下降或丢包增加。端到端优化方法可以在一定程度上缓解网络质量波动，例如通过拥塞控制算法调整发送速率、通过多路径传输绕开部分拥塞路径，但它们无法适配所有跨域网络中可能的情况，在大部分条件下仍旧无法提供优秀的服务质量，进而无法保证优秀用户体验。
|
||||
随着互联网服务的对象从局部区域扩展到全球范围，跨地域、跨运营商和跨自治系统的传输场景不断增加，网络质量保障变得更加困难。相比本地或域内连接，跨域连接通常路径更长、经过的网络实体更多，也更容易受到拥塞、路由变化和链路质量波动等因素影响，进而造成延迟升高、带宽下降或丢包增加。虽然端到端优化方法可以在一定程度上缓解网络质量波动，但仅依赖端到端调节难以在复杂跨域网络中持续提供稳定的高服务质量，因此需要进一步利用更可控的网络组织方式来改善传输质量。
|
||||
|
||||
为了给各种网络环境下的用户提供一致的高质量服务，网络服务商通常利用覆盖网络（Overlay Network）为跨地域用户建立连接。覆盖网络是一种建立在物理网络之上的逻辑网络，其各部分通常由软件系统统一管理，因而具有部署灵活、扩展方便和易于集中化管理等特点。服务商将底层复杂且动态变化的跨域传输过程隐藏于覆盖网络下，利用覆盖网络灵活可控的转发能力提升用户连接质量。跨域连接的用户需要利用覆盖网络建立连接时，发送端就近通过互联网接入最近的覆盖网络接入网关，数据经由覆盖网络转发至接收端就近接入的覆盖网络网关，经过互联网送达接收端用户，如图~\ref{fig:云网络转发拓扑}。这种转发方式可以使连接的大部分路径，特别是跨域传输阶段，由服务商可管理的覆盖网络承载，服务商也就能够通过优化覆盖网络内的转发节点、转发路径和链路质量来提升用户体验。
|
||||
为了给各种复杂多变的网络环境下的用户提供一致的高质量服务，网络服务商通常利用覆盖网络（Overlay Network）为跨地域用户建立连接。覆盖网络是一种建立在物理网络之上的逻辑网络，其各部分通常由软件系统统一管理，因而具有部署灵活、扩展方便和易于集中化管理等特点。服务商将底层复杂且动态变化的跨域传输过程隐藏于覆盖网络下，利用覆盖网络灵活可控的转发能力提升用户连接质量。跨域连接的用户需要利用覆盖网络建立连接时，发送端就近通过互联网接入最近的覆盖网络接入网关，数据经由覆盖网络转发至接收端就近接入的覆盖网络网关，经过互联网送达接收端用户，如图~\ref{fig:云网络转发拓扑}。这种转发方式可以使连接的大部分路径，特别是跨域传输阶段，由服务商可管理的覆盖网络承载，服务商也就能够通过优化覆盖网络内的转发节点、转发路径和链路质量来提升用户体验。
|
||||
|
||||
\begin{figure}[H]
|
||||
\centering
|
||||
@@ -21,34 +21,34 @@
|
||||
\label{fig:云网络转发拓扑}
|
||||
\end{figure}
|
||||
|
||||
当今的覆盖网络通常构建在云网络资源之上，云网络服务商提供多种资源供服务商按需选择。随着云计算和跨地域互联网服务的发展，服务商在构建覆盖网络时通常不再自行建设底层基础设施，而是租用云服务商在全球多个地区提供的服务器、网关和链路等计算与网络资源，并将这些资源抽象为覆盖网络中的转发节点、接入网关和逻辑链路。由于这些资源可以通过软件配置进行申请、扩展和调整，服务商能够根据业务覆盖范围、用户分布和流量需求快速构建跨地域覆盖网络。例如，当服务商需要连接不同地区的数据中心或接入点时，可以在相应区域租用计算节点作为转发网关，并在节点之间选择合适的网络链路，从而形成一条面向用户连接的覆盖网络转发路径。因此，覆盖网络的灵活性在很大程度上来自云网络资源的可配置性，而覆盖网络的服务质量也受到所选云资源质量的直接影响。
|
||||
当今服务商建立的覆盖网络通常构建在云网络资源之上，云网络服务商提供多种资源供服务商按需选择。随着云计算和跨地域互联网服务的发展，服务商在构建覆盖网络时通常不再自行建设底层基础设施，而是租用云服务商在全球多个地区提供的服务器、网关和链路等计算与网络资源，并将这些资源抽象为覆盖网络中的转发节点、接入网关和逻辑链路。由于这些资源可以通过软件配置进行申请、扩展和调整，服务商能够根据业务覆盖范围、用户分布和流量需求快速构建跨地域覆盖网络。例如，当服务商需要连接不同地区的数据中心或接入点时，可以在相应区域租用计算节点作为转发网关，并在节点之间选择合适的网络链路，从而形成一条面向用户连接的覆盖网络转发路径。
|
||||
|
||||
不同云资源的质量与定价有所区别，维持高网络服务质量同时降低成本是当今研究的重点。覆盖网络中同一条逻辑链路的连接通常可以由多条物理链路抽象而成，云网络服务商往往同时提供专线链路和公网链路等不同选择。专线链路通常延迟、丢包率都较低且稳定，能够提供较好的传输质量和用户体验，但其价格较高，且常按照流量峰值计费，大规模使用会给服务商带来较高的运营成本；公网链路价格较低，计费方式也更灵活，但容易受到其他用户流量的影响，在拥塞和竞争下出现延迟升高、丢包增加和带宽波动等问题，质量不稳定。全部使用专线链路可以较好地满足业务服务质量需求，但成本难以控制；完全依赖公网链路又可能导致服务质量无法稳定满足用户体验要求。因此，如何在保证覆盖网络高服务质量的同时尽可能降低资源使用成本，成为覆盖网络优化中亟须解决的问题。
|
||||
覆盖网络的灵活性在很大程度上来自云网络资源的可配置性，而覆盖网络的服务质量和运营成本也受到所选云资源质量和定价的直接影响，维持高网络服务质量同时降低成本是当今研究的重点。覆盖网络中同一条逻辑链路的连接通常可以由多条不同的物理链路抽象而成，云网络服务商往往同时提供专线链路和公网链路等不同选择。专线链路通常延迟、丢包率都较低且稳定，能够提供较好的传输质量和用户体验，但其价格较高，且常按照流量峰值计费，大规模使用会给服务商带来较高的运营成本；公网链路价格较低，计费方式也更灵活，但容易受到其他用户流量的影响，在拥塞和竞争下出现延迟升高、丢包增加和带宽波动等问题，质量不稳定。现代服务商为确保高质量服务而选择全部使用专线链路可以较好地满足业务服务质量需求，但成本难以控制；完全依赖公网链路又可能导致服务质量无法稳定满足用户体验要求。因此，如何在保证覆盖网络高服务质量的同时尽可能降低资源使用成本，成为覆盖网络优化中亟须解决的问题。
|
||||
|
||||
\section{研究现状}
|
||||
|
||||
现有的研究方案主要从两类视角审视覆盖网络传输，并对其进行优化。一些工作从覆盖网络的角度对覆盖网络的调度、链路选择等进行优化；另外一些工作从端到端的角度进行优化，对发送速率、发送内容等进行调控和编码。
|
||||
现有的研究方案主要从两类视角审视覆盖网络传输，并对其进行优化。一些工作从覆盖网络管理者的角度对覆盖网络的调度、链路选择等进行优化；另外一些工作从端到端用户的角度进行优化，对发送速率、发送内容等进行调控和编码。
|
||||
|
||||
链路调度类的工作从覆盖网络管理者的角度出发，通过网络路径选择等手段，利用低成本链路质量较好的时间窗口分担流量。这些工作在对连接两端用户透明的前提下，利用覆盖网络中同一链路可由质量价格不同的多个链路抽象而来的特点，通过不断监控同一逻辑链路下的公网链路与专线链路的质量，并在公网质量优秀可以为用户提供优质服务的时段将部分流量经由公网链路发送。这些工作利用公网上分担部分流量，降低了在专线上发送的数据流量，从而降低使用专线的成本\cite{kataria2024titan,wu2023xron}。
|
||||
链路调度类的工作从覆盖网络管理者的角度出发，通过网络路径选择等手段，利用低成本链路质量较好的时间窗口分担高成本链路流量。这些工作在对连接两端用户透明的前提下，利用覆盖网络中同一链路可由质量价格不同的多个链路抽象而来的特点，通过不断监控同一逻辑链路下的公网链路与专线链路的质量，并在公网质量优秀可以为用户提供优质服务的时段将部分流量经由公网链路发送。这些工作利用低价公网对高价专线分流，降低了在专线上发送的数据流量，从而降低使用专线的成本\cite{kataria2024titan,wu2023xron}。
|
||||
|
||||
% 然而实际上，本研究的测量表明用户的高需求时段与公网链路质量下降时段基本重合，有大量流量需要提供服务时恰逢公网链路质量下降不能满足用户体验需求，公网链路的分流效果有限，大量流量仍旧通过专线转发，不能有效削减专线峰值流量，而专线链路恰恰通过峰值流量计费，实际成本下降效果有限。
|
||||
|
||||
冗余编码类的工作从端到端用户的角度出发，在对转发覆盖网络透明的前提下，将发送端的发送策略随网络进行调整，以提升传输性能。一些工作通过主动探测网络状态调整发送速率，以充分利用网络带宽\cite{ha2008cubiccca,cardwell2016bbrcca,arun2018copacca}。另外一些工作通过在发送端设计特殊的网络编码以应对传输过程中可能的丢包。这些工作大多应用前向纠错编码等编码，通过发送额外的冗余信息，使接收端从冗余信息恢复丢失包，从而降低上层应用感知到的丢包，提升了用户感知到的链路质量\cite{bolot1999adaptivefec,huang2010skypefec,holmer2013webrtcfec}。
|
||||
冗余编码类的工作从端到端用户的角度出发，在对转发覆盖网络透明的前提下，将发送端的发送策略随网络进行调整，以提升传输性能。一些工作通过主动探测网络状态调整发送速率，以充分利用网络带宽\cite{ha2008cubiccca,cardwell2016bbrcca,arun2018copacca}。另外一些工作通过在发送端设计针对性的网络编码以应对传输过程中可能的丢包。这些工作大多应用前向纠错编码等编码，通过发送额外的冗余信息，使接收端从冗余信息恢复丢失包，从而降低上层应用感知到的丢包，提升了用户感知到的链路质量\cite{bolot1999adaptivefec,huang2010skypefec,holmer2013webrtcfec}。
|
||||
|
||||
% 这些工作将传输链路看作一个不可变的黑盒，为了充分应对可能发生的丢包只能尽可能多地加入冗余信息，导致在一些链路质量良好的片段上也需要发送冗余包，产生了对优质链路带宽的浪费。
|
||||
|
||||
然而，这两类方法在跨域公网链路场景下仍存在局限。链路调度类工作希望在公网链路质量较好时利用其分担部分流量，但这种方法依赖低成本链路在业务高峰时段仍能提供足够稳定的服务质量；而在实际网络中，用户需求较高的时段往往也伴随着公网链路拥塞和质量下降，导致公网链路难以承载大量高质量传输，专线峰值流量仍然难以有效降低。端到端优化类工作则将整条传输路径视为不可区分的整体，只能根据端到端观测结果调整发送速率或加入冗余信息，难以判断性能瓶颈究竟来自路径中的哪一段链路。为了应对可能发生的丢包，这类方法通常需要对整条路径上的流量统一加入冗余，即使部分链路片段质量良好也会产生额外带宽开销；同时，单纯降低发送速率虽然可以缓解拥塞，却无法直接修复低质量链路上的丢包问题。上述局限表明，现有方法要么从覆盖网络层面规避低质量公网链路，要么从端到端层面被动适应路径质量变化，尚未充分利用覆盖网络中路径可拆分、链路可感知和节点可控的特点。
|
||||
然而，这两类方法在跨域公网链路场景下仍存在局限。链路调度类工作希望在公网链路质量较好时利用其分担部分流量，但这种方法依赖低成本链路在业务高峰时段仍能提供足够稳定的服务质量；而在实际网络中，用户需求较高的时段往往也伴随着公网链路拥塞和质量下降，导致公网链路难以实现大流量的高质量传输，专线峰值流量仍然难以有效降低。端到端优化类工作则将整条传输路径视为不可区分的整体，只能根据端到端观测结果调整发送速率或加入冗余信息，难以判断性能瓶颈究竟来自路径中的哪一段链路。为了应对可能发生的丢包，这类方法通常需要对整条路径上的流量统一加入冗余，即使部分链路片段质量良好也会产生额外带宽开销；同时，单纯降低发送速率虽然可以缓解拥塞，却无法直接修复低质量链路上的丢包问题，且浪费了可用的带宽资源。上述局限表明，现有方法要么从覆盖网络层面规避低质量公网链路，要么从端到端层面被动适应路径质量变化，尚未充分利用覆盖网络中路径可拆分、链路可感知和节点可控的特点。
|
||||
|
||||
\section{研究思路与贡献}
|
||||
|
||||
本文的核心观察是覆盖网络中的不同公网链路片段的性质差异大，应分段进行优化。覆盖网络中，部分跨域链路由于竞争激烈、延迟高，导致性能低下，而部分域内链路性能优秀，与专线质量接近，已有的工作没有考虑到覆盖网络中不同链路片段的性质差异，导致优化效果不佳。本文提出应该站在链路层级上，对不同质量的链路分别进行针对性的传输优化。为实现对网络中不同链路的针对性质量提升，本文需要解决以下两个挑战：
|
||||
本文的核心观察是覆盖网络中的不同公网链路片段的性质差异大，应分段进行优化。覆盖网络中，部分跨域链路由于竞争激烈、延迟高，导致性能低下，而部分域内链路性能优秀，与专线质量接近，已有的工作没有考虑到覆盖网络中不同链路片段的性质差异，导致优化效果不佳。本文提出应该站在覆盖网络的链路层级上，对不同质量的链路分别进行针对性的传输优化。为实现对网络中不同链路的针对性质量提升，本文需要解决以下两个挑战：
|
||||
\begin{enumerate}
|
||||
\item \textbf{如何应对各个链路片段频繁且不可预测的链路质量变化。} 公网链路的丢包率和连续丢包模式会随时间变化，若长期对所有链路使用固定冗余，会带来不必要的带宽开销；若冗余不足，又无法有效修复低质量链路。因此，系统需要根据实时链路状态判断是否启用冗余，并动态选择合适的编码参数。
|
||||
\item \textbf{如何在对传输两端透明的前提下提升部分链路的传输质量。} 覆盖网络承载的上层业务类型多样，传输两端通常并不知道中间覆盖网络的转发细节，也难以配合覆盖网络内部的链路优化。因此，优化机制不能依赖修改应用报文、改变端到端协议语义或要求发送端与接收端协同，而需要能够在覆盖网络内部的单个低质量链路片段上独立完成质量修复。同时，链路片段级修复还必须保持端到端数据包的正常传输节奏，避免因中间节点处理造成突发交付、乱序或额外时延，从而干扰上层拥塞控制和实时应用体验。
|
||||
% FEC解码通常以编码组为单位恢复数据包，可能造成数据包在解码端集中输出。这种突发式交付会影响接收端的包到达节奏，并进一步干扰拥塞控制、速率估计和实时应用的播放稳定性。因此，系统还需要在完成丢包恢复的同时保持平滑的数据交付节奏。
|
||||
\end{enumerate}
|
||||
|
||||
基于此，本文设计了一套基于交织前向纠错编码（Interleaved Forward Error Correction, Interleaved FEC）的跨域公网链路优化方法。本文提出的方法使用公网实现覆盖网络中所有节点的互联，对覆盖网络中的每一段链路，通过监控链路上的丢包情况，利用马尔科夫链建模网络丢包模型，对低质量的链路动态选择FEC编码参数，并利用交织XOR编码进行编码和丢包恢复，并在解码时对输出速率利用比例-积分控制器进行动态平滑处理。本方法不需要使用专线连接，极大地降低了链路的使用成本，同时又有选择性地在低质量链路上使用冗余编码，避免了在高质量链路上添加额外带宽。另外，应用交织编码技术，将冗余包与数据包间隔其它数据包发送，极大地降低了链路连续丢包对丢包恢复的影响。
|
||||
基于此，本文设计了一套基于交织前向纠错编码（Interleaved Forward Error Correction, Interleaved FEC）的跨域公网链路优化方法。本文提出的方法使用公网实现覆盖网络中所有节点的互联，对覆盖网络中的每一段链路，通过监控链路上的丢包情况，利用马尔科夫链建模网络丢包模型，对低质量的链路动态选择FEC编码参数，并利用交织XOR编码进行编码和丢包恢复，最后在解码时对输出速率利用比例-积分控制器进行动态平滑处理。本方法不需要使用专线连接，极大地降低了链路的使用成本，同时又有选择性地在低质量链路上使用冗余编码，避免了在高质量链路上添加额外冗余造成带宽浪费。另外，应用交织编码技术，将冗余包与数据包间隔其它数据包发送，极大地降低了链路连续丢包对丢包恢复的影响。
|
||||
|
||||
\nomenclature{FEC}{前向纠错编码（Forward Error Correction）}
|
||||
|
||||
@@ -67,7 +67,7 @@
|
||||
|
||||
第~\ref{chap:引言} 章为引言。本章介绍跨域云网络中覆盖网络传输的应用背景，分析专线链路成本高、公网链路质量不稳定所带来的矛盾，概述现有链路调度与冗余编码方法的不足，并给出本文的研究思路与主要贡献。
|
||||
|
||||
第~\ref{chap:背景介绍与研究动机} 章为背景介绍与研究动机。本章介绍云网络、覆盖网络以及前向纠错编码等必要背景，结合真实测量结果分析现有方法在跨域公网链路场景下的局限，指出低质量公网链路不应仅被规避，而应结合覆盖网络的分段转发能力进行针对性质量修复。
|
||||
第~\ref{chap:背景介绍与研究动机} 章为背景介绍与研究动机。本章介绍云网络、覆盖网络以及前向纠错编码等研究背景，结合真实测量结果分析现有方法在跨域公网链路场景下的局限，指出低质量公网链路不应在调度时被舍弃，而应结合覆盖网络的分段转发能力进行针对性质量修复。
|
||||
|
||||
第~\ref{chap:相关工作} 章为相关工作。本章分别介绍覆盖网络与隧道技术、链路质量优化方法以及软件定义网络与网络调度相关研究，并分析这些工作与本文研究问题之间的联系和差异。
|
||||
|
||||
|
||||
@@ -3,16 +3,18 @@
|
||||
\chapter{背景介绍与研究动机}
|
||||
\label{chap:背景介绍与研究动机}
|
||||
|
||||
本章首先在~\ref{sec:背景介绍} 节中介绍覆盖网络和网络编码的基本信息，介绍在维持高服务质量前提下进行成本优化这一核心问题。之后在~\ref{sec:实验观察与已有工作不足} 节介绍已有工作在实际场景下的不足。最后，在~\ref{sec:basic idea} 节介绍本文提出的通过对云网络公网进行分段质量修复的基本思路及面临的挑战。
|
||||
本章首先在~\ref{sec:背景介绍} 节中介绍覆盖网络和网络编码的基本信息，介绍在维持高服务质量前提下进行成本优化这一核心问题。之后在~\ref{sec:实验观察与已有工作不足} 节介绍本文对公网性质的观察及已有工作在实际场景下的不足。最后，在~\ref{sec:basic idea} 节介绍本文提出的通过对云网络公网进行分段质量修复的基本思路及面临的挑战。
|
||||
|
||||
\section{背景介绍}
|
||||
\label{sec:背景介绍}
|
||||
|
||||
\subsection{覆盖网络}
|
||||
|
||||
覆盖网络（Overlay Network）是一种已经获得广泛应用的网络虚拟化设计，它是基于物理的底层网络（Underlay Network）上通过对资源的逻辑整合而形成的逻辑网络。如图~\ref{fig:overlay网络示意}，覆盖网络在已有的硬件网络上构建一个虚拟的网络层，使得使用覆盖网络服务的企业和用户可以获得更灵活与稳定的虚拟网络连接。近年来，企业对虚拟化和云网络的需求不断增长，因而将分布在全球各地的云资源进行互联的需求也不断提升。企业构建覆盖网络以承载业务时，通常不选择自己搭建基础设施，而是选择向云服务商按需租用计算和网络资源，并利用这些云网络资源组成覆盖网络。
|
||||
近年来，实时音视频通信、跨地域文件传输、企业远程办公和云上应用访问等互联网服务快速发展\cite{applogic2026gipr}，网络所承载的业务类型更加多样，它们都需要高服务质量的网络以维持优秀的用户体验。例如，在高清实时音视频通讯业务中，参会用户之间存在频繁的实时互动，视频和音频帧必须按时送达，才能提供高清、低延迟、低卡顿率的使用体验，需要维持稳定的端到端延迟、减少抖动和丢包才能提供优秀的用户体验；相对地，文件下载业务对延迟并不敏感，可用带宽才是影响用户体验的主要因素。尽管这些应用的用户体验评价指标各不相同，但是它们都需要网络提供高吞吐、稳定低延迟且低丢包的高服务质量链路，以维持优秀的用户体验。
|
||||
|
||||
从用户和业务方的角度看，覆盖网络的价值不只在于完成两端连通，还在于屏蔽底层网络路径、运营商和云区域差异带来的复杂性。用户只需要接入邻近的覆盖网络网关，后续路径选择、故障绕行、链路切换和质量优化由覆盖网络统一完成，因而能够在不直接管理底层网络资源的情况下获得更可控的跨地域传输服务。
|
||||
然而，随着互联网应用的服务对象从局部区域逐渐扩展到全球范围，新增的大量跨域传输场景中网络状况复杂，使得维持优秀用户体验更加困难。跨国企业协作、跨地域云服务访问、国际在线会议和全球内容分发等场景使得通信双方经常位于不同国家和地区或是通过不同的网络运营商接入网络，用户连接不再局限于本地网络或域内网络，而是成为需要跨越多个自治系统、运营商网络和广域互联网链路的跨域连接。用户距离的增加和网络路径的拉长会放大底层网络状态变化对应用体验的影响，例如跨域链路中的拥塞、路由变化和链路质量波动都可能造成延迟升高、带宽下降或丢包增加。端到端优化方法可以在一定程度上缓解网络质量波动，例如通过拥塞控制算法调整发送速率、通过多路径传输绕开部分拥塞路径，但它们无法适配所有跨域网络中可能的情况，在大部分条件下仍旧无法提供优秀的服务质量，进而无法保证优秀用户体验。
|
||||
|
||||
为了将复杂多变的底层网络情况与上层的应用传输解耦，实现更优秀的网络服务质量，服务商通常使用覆盖网络对底层网络进行抽象。覆盖网络是一种已经获得广泛应用的网络虚拟化设计，它是基于物理的底层网络（Underlay Network）上通过对资源的逻辑整合而形成的逻辑网络。如图~\ref{fig:overlay网络示意}，覆盖网络在已有的硬件网络上构建一个虚拟的网络层，使得使用覆盖网络服务的企业和用户可以获得更灵活与稳定的虚拟网络连接。从用户和业务方的角度看，覆盖网络的价值不只在于完成两端连通，还在于屏蔽底层网络路径、运营商和云区域差异带来的复杂性。用户只需要接入邻近的覆盖网络网关，后续路径选择、故障绕行、链路切换和质量优化由覆盖网络统一完成，因而能够在不直接管理底层网络资源的情况下获得更可控的跨地域传输服务。
|
||||
|
||||
\begin{figure}[H]
|
||||
\centering
|
||||
@@ -21,15 +23,19 @@
|
||||
\label{fig:overlay网络示意}
|
||||
\end{figure}
|
||||
|
||||
在覆盖网络中，不同节点之间通常存在多条物理连接路径，这些物理链路具有不同的链路质量和不同的链路价格及计费方式。例如，许多云服务商同时提供公网链路互联与专线链路互联\cite{azure_bandwidthcost,gcp_bandwidthcost}。其中，专线链路通常具有更稳定的传输性能、更低的丢包率与时延，但部署成本与使用成本较高；而公网链路虽然成本较低，却容易受到网络拥塞、跨域路由波动等因素影响，出现高丢包、时延抖动等问题\cite{kataria2024titan}。与此同时，链路质量与网络负载往往还会随着时间动态变化，使得不同链路在不同时间段内呈现出不同的性能特征。
|
||||
随着企业的服务范围扩展至全球，企业通常选择使用云网络资源构建覆盖网络。由于覆盖网络的服务对象可能遍布全球，企业构建覆盖网络以承载业务时，通常不选择自己搭建基础设施，而是选择向云服务商按需租用计算和网络资源，并利用这些云网络资源组成覆盖网络。使用云网络资源免去了在全球布设和维护覆盖网络的成本，降低了前期部署成本。同时企业可以利用云网络按使用量付费的特点，按需选择与当前业务需求最匹配的计算资源和网络资源，并随时按业务需求变化而增加或减少资源使用，节省了硬件的部署和维护成本。
|
||||
|
||||
随着云计算与实时互联网应用的发展，现代云网络中的跨域流量规模持续增长，用户对于传输质量与服务稳定性的要求也不断提高。传统的覆盖网络服务商为了为用户提供高质量的传输服务，确保能为用户持续稳定提供低延迟、高带宽、低丢包的转发路径，选择尽可能多地使用专线链路构建覆盖网络，而这对运营成本带来了较大的压力。如何在维持网络服务质量保持高带宽、低丢包、低延迟的前提下，尽可能减少构建和运营云网络所需的成本，是各服务商关注的重点。
|
||||
在覆盖网络中可以通过选择不同价格和质量和资源实现网络服务质量和成本的权衡。例如，许多云服务商同时提供公网链路互联与专线链路互联\cite{azure_bandwidthcost,gcp_bandwidthcost}。其中，专线链路通常具有更稳定的传输性能、更低的丢包率与时延，但部署成本与使用成本较高；而公网链路虽然成本较低，却容易受到网络拥塞、跨域路由波动等因素影响，出现高丢包、时延抖动等问题，导致质量不稳定\cite{kataria2024titan}。与此同时，链路质量与网络负载往往还会随着时间动态变化，使得不同链路在不同时间段内呈现出不同的性能特征。基于云网络的覆盖网络可以利用云网络按需付费和部署的特点，随时切换使用的链路，以达成成本和传输质量之间的权衡。
|
||||
|
||||
一些工作意识到了公网链路与专线链路在经常存在定价差异，因而尝试在维持覆盖网络服务质量的前提下，利用覆盖网络易于实时配置的特性，将部分流量转移至质量优秀的公网链路上，以减少专线链路的压力\cite{kataria2024titan,wu2023xron}。这些工作在公网链路质量较好时，利用低价的公网链路为部分用户提供服务，降低了高价专线需要承载的流量，从而在服务流量总量不变的情况下，降低了高价流量的占比，进而降低了链路部署的总成本。
|
||||
% 随着云计算与实时互联网应用的发展，现代云网络中的跨域流量规模持续增长，用户对于传输质量与服务稳定性的要求也不断提高。传统的覆盖网络服务商为了为用户提供高质量的传输服务，确保能为用户持续稳定提供低延迟、高带宽、低丢包的转发路径，选择尽可能多地使用专线链路构建覆盖网络，而这对运营成本带来了较大的压力。如何在维持网络服务质量保持高带宽、低丢包、低延迟的前提下，尽可能减少构建和运营云网络所需的成本，是各服务商关注的重点。
|
||||
|
||||
一些工作意识到了公网链路与专线链路在经常存在定价差异，他们尝试通过主动调度的方法降低整理使用成本。这些工作在维持覆盖网络服务质量的前提下，利用覆盖网络易于实时配置的特性，将部分流量转移至质量优秀的公网链路上，以减少专线链路的压力\cite{kataria2024titan,wu2023xron}。这些工作在公网链路质量较好时，利用低价的公网链路为部分用户提供服务，降低了高价专线需要承载的流量，从而在服务流量总量不变的情况下，降低了高价流量的占比，进而降低了链路部署的总成本。
|
||||
|
||||
\subsection{网络编码}
|
||||
|
||||
公网链路质量下降最直接的表现之一是数据包丢失。对于可靠传输协议而言，丢包通常需要依赖重传机制恢复；然而在跨地域云网络中，端到端往返时延较高，重传一次丢失的数据包往往需要等待一个完整的往返时延，容易造成吞吐下降和实时业务卡顿。因此，在低质量链路上仅依赖端到端重传机制，难以满足实时音视频、交互式应用等业务对低延迟和稳定性的需求。
|
||||
除了使用覆盖网络对网络进行抽象并调度以外，另外一些工作从端到端的视角出发，将网络视为一个不可改变的黑盒，尝试通过端到端方法对低质量的公网链路进行优化。
|
||||
|
||||
公网链路质量下降最直接的表现之一是数据包丢失。对于可靠传输协议而言，丢包通常需要依赖重传机制恢复；然而在跨域网络中，端到端往返时延较高，重传一次丢失的数据包往往需要等待一个完整的往返时延，容易造成吞吐下降和实时业务卡顿。因此，在低质量链路上仅依赖端到端重传机制，难以满足实时音视频、交互式应用等业务对低延迟和稳定性的需求。
|
||||
|
||||
为了应对网络中的丢包，一些工作针对不同的应用类型和需求设计了不同的网络编码承载应用数据。前向纠错编码（Forward Error Correction, FEC）是一类常见的用于优化链路质量的网络编码，其基本思想是在发送原始数据的同时加入一定数量的冗余信息，使接收端在部分数据包丢失时，可以利用已经收到的数据包和冗余包直接恢复丢失内容，而不必等待发送端重传。与重传机制相比，FEC通过额外带宽开销换取更短的丢包恢复时间，因而适合用于对时延敏感、但又需要在不稳定网络上持续传输的场景。
|
||||
|
||||
@@ -40,11 +46,14 @@
|
||||
\section{观察与已有工作不足}
|
||||
\label{sec:实验观察与已有工作不足}
|
||||
|
||||
针对覆盖网络成本控制和网络服务质量优化，已有的工作主要从两个视角进行优化。一些工作从覆盖网络调度的视角进行优化，通过在低价链路质量优秀的时间段对高价链路进行分流，尝试降低总体的链路使用成本；另外一些工作从端到端的角度出发，在端到端网络编码方面进行尝试，通过端到端的方式对低质量链路的传输质量进行优化。然而，本文对云网络的公网链路性质进行了调研和测量，产生了三点观察，他们揭示了公网链路的一些特殊性质，这些性质导致已有的方法不能有效地降低覆盖网络的部署成本：
|
||||
|
||||
\begin{enumerate}
|
||||
\item \textbf{公网链路质量下降与用户流量高峰重合，基于公网分流的调度方法难以削减专线峰值成本。}
|
||||
\item \textbf{公网链路质量下降时段与用户流量高峰重合。}
|
||||
\end{enumerate}
|
||||
|
||||
已有的链路调度类工作没有考虑到公网链路质量下降的时间段与用户流量高峰有明显的相关性，公网链路的实际分流能力有限。如图~\ref{fig:用户高峰与公网劣化重合}，在某企业的某条公网连接中，用户流量带宽提升的时段与丢包率提升、延迟波动的时段有较强的相关性，只在公网丢包低、延迟稳定的时段使用公网链路只能削减专线上承载的一小部分流量。进一步地，由于用户流量带宽较大的时段公网持续恶化，这些方法也不能利用公网链路削减专线需要承载的峰值带宽，使得专线链路仍然在传输流量时起主导作用，链路使用成本的削减程度有限。另外，与公网链路通常可以灵活选用按量付费与按峰值带宽付费不同，专线链路通常只能按一段时间内的峰值带宽或95分位带宽付费\cite{aliyun_bandwidthcost,tencent_bandwidthcost}，这些方法不能有效地削减专线上承载的峰值带宽就意味着专线的使用成本不会由于公网的部分分流而显著降低。因此，这些工作对链路使用成本的削减十分有限，甚至可能由于专线链路成本没有明显下降，反而由于额外使用公网链路而导致链路使用成本增加。
|
||||
公网链路质量下降与用户流量出现高峰不是孤立的事件，随着更多用户访问网络服务，网络中出现拥塞和竞争的可能性不断提升，公网链路的质量就会出现下降，表现出不稳定的特性。如图~\ref{fig:用户高峰与公网劣化重合}，在某企业的某条公网连接中，一天时间内用户流量带宽提升的时段与丢包率提升、延迟波动的时段有较强的相关性，用户流量提升的时间段恰好也是公网链路出现延迟波动、丢包率提升的时间段。
|
||||
|
||||
\begin{figure}[H]
|
||||
\centering
|
||||
\includegraphics[width=\linewidth]{hongkong-jinan-withbd.pdf}
|
||||
@@ -52,12 +61,20 @@
|
||||
\label{fig:用户高峰与公网劣化重合}
|
||||
\end{figure}
|
||||
|
||||
% 已有的链路调度类工作没有考虑到公网链路质量下降的时间段与用户流量高峰有明显的相关性，公网链路的实际分流能力有限。如图~\ref{fig:用户高峰与公网劣化重合}，在某企业的某条公网连接中，用户流量带宽提升的时段与丢包率提升、延迟波动的时段有较强的相关性，只在公网丢包低、延迟稳定的时段使用公网链路只能削减专线上承载的一小部分流量。进一步地，由于用户流量带宽较大的时段公网持续恶化，这些方法也不能利用公网链路削减专线需要承载的峰值带宽，使得专线链路仍然在传输流量时起主导作用，链路使用成本的削减程度有限。另外，与公网链路通常可以灵活选用按量付费与按峰值带宽付费不同，专线链路通常只能按一段时间内的峰值带宽或95分位带宽付费\cite{aliyun_bandwidthcost,tencent_bandwidthcost}，这些方法不能有效地削减专线上承载的峰值带宽就意味着专线的使用成本不会由于公网的部分分流而显著降低。因此，这些工作对链路使用成本的削减十分有限，甚至可能由于专线链路成本没有明显下降，反而由于额外使用公网链路而导致链路使用成本增加。
|
||||
|
||||
\begin{enumerate}[resume]
|
||||
\item \textbf{公网链路不同分段质量差异显著，端到端进行网络编码带宽浪费严重。}
|
||||
\item \textbf{专线链路只能按峰值带宽计价，而公网链路计价方式更为灵活。}
|
||||
\end{enumerate}
|
||||
|
||||
云服务商只对专线链路的质量提供服务质量保证（Service level agreement, SLA），而对公网的具体性能没有任何形式的保证。尽管服务商不对公网的性能做出任何保证，所有的公网链路在所有的时间段质量都劣于专线链路。如图~\ref{fig:公网片段热力图} 所示，部分公网链路有着较低的平均丢包率，质量几乎与专线相当，而只有部分链路，特别是跨域链路的丢包率较高，链路质量较差，与低丢包的专线有较大差距。覆盖网络对用户流量进行转发时，通常将多个不同的网络片段相连组成连接两侧接入网关的路径。由于覆盖网络的内部转发机制通常对端到端的传输透明，两端的客户端只能感知到由多个链路的丢包级联而成的最终丢包率，只要组成转发路径的链路中包含了至少一条丢包率较高的跨域公网链路，端到端感知到的丢包率就会明显上升。这导致在跨域连接的场景下，网络编码类工作只能以感知到的高丢包率对在整个路径上转发的包加入大量的冗余，造成了较大的带宽浪费，造成链路使用成本上升。
|
||||
例如，一条端到端的连接可能分别由AB、BC、CD三段链路组成，其中三段链路的丢包率分别为$0, 0.2, 0$, 如果使用端到端的冗余，为了应对其中一条高丢包链路带来的丢包，必须在整条链路上加入额外约~\SI{20}{\percent} 的冗余，导致在从A发往D的流量中，AB、BC两段都承载了相比有效数据多~\SI{20}{\percent} 的数据量。在这种场景下，AB段网络本身质量优秀，但是却由于后段质量较差的网络呃额外承载了流量，导致了链路使用成本上升。
|
||||
与公网链路通常可以灵活选用按量付费与按峰值带宽付费不同，专线链路通常只能按一段时间内的峰值带宽或95分位带宽付费\cite{aliyun_bandwidthcost,tencent_bandwidthcost}。服务商在使用公网链路时，可以在使用较少流量时选择按流量计费，而在总流量较多但是对带宽上限需求较小时选择按峰值带宽收费。与之不同的是，专线链路只能按照计费周期内使用的峰值带宽或者95分位带宽计费，即使服务商只在一个计费周期内短暂地使用专线资源，如果其承载的峰值流量较高，则仍旧需要支付较高的使用费用。
|
||||
|
||||
\begin{enumerate}[resume]
|
||||
\item \textbf{公网链路不同分段质量差异显著。}
|
||||
\end{enumerate}
|
||||
|
||||
云服务商只对专线链路的质量提供服务质量保证（Service level agreement, SLA），而对公网的实际性能没有任何保证\cite{aliyun_sla}。尽管服务商不对公网的性能做出任何保证，但这不代表所有的公网链路在所有的时间段质量都劣于专线链路。如图~\ref{fig:公网片段热力图} 所示，部分公网链路有着较低的平均丢包率，质量几乎与专线相当，而只有部分链路，特别是跨域链路的丢包率较高，链路质量较差，与低丢包的专线有较大差距。覆盖网络对用户流量进行转发时，通常将多个不同的网络片段相连，组成连接两侧接入网关的路径。由于覆盖网络的内部转发机制通常对端到端的传输透明，两端的客户端只能感知到由多个链路的丢包级联而成的最终丢包率，只要组成转发路径的链路中包含了至少一条丢包率较高的跨域公网链路，端到端感知到的丢包率就会明显上升。
|
||||
|
||||
\begin{figure}[H]
|
||||
\centering
|
||||
\includegraphics[width=.8\linewidth]{loss_avg_heatmap.pdf}
|
||||
@@ -65,23 +82,31 @@
|
||||
\label{fig:公网片段热力图}
|
||||
\end{figure}
|
||||
|
||||
基于这几点观察，本文认为已有的方法都不能有效地减少覆盖网络的链路成本。链路调度类方法只在公网链路质量高的时段利用公网分流，由于公网链路质量只能在用户流量不大的时段维持优秀质量，在用户流量较大的时段这些方法将仍旧选择使用专线来承载大量流量，公网实际的分流作用有限，且不能有效地降低专线承载的峰值流量，这导致即使使用了这些调度类算法，专线链路的使用成本仍旧没有明显的下降。端到端的链路优化类算法则没有考虑到一条连接在覆盖网络内部的多段连接质量不同的问题，只要转发路径中出现一个片段质量较低，则端到端感知到的链路质量就急剧下降，在所有链路上都加入冗余，导致可能的带宽浪费。例如，设想A经由B转发至C的链路中，AB段链路质量较差但带宽较高，存在 \SI{50}{\percent} 的丢包，带宽 \SI{100}{Mbps}；BC段质量较好但带宽较低，不存在丢包，带宽 \SI{50}{Mbps}，如图~\ref{fig:全链路冗余浪费带宽}。在这种情况下，端到端算法测量得到AC间实际的丢包率也为 \SI{50}{\percent}，因此为了避免丢包，需要即使在最理想的编码恢复情况下也需要在发送应用数据的基础上额外发送一倍冗余数据才能使得接收端通过冗余数据恢复丢包。然而，由于BC段的带宽的带宽较低，实际端到端能感受到的最高有效带宽只有 \SI{25}{Mbps}，导致AB链路上也只承载了 \SI{50}{Mbps}的带宽，有 \SI{50}{Mbps}的传输能力被浪费。实际上，如果只在链路较差的AB这一段加入一倍冗余，而在BC段直接传输，则可充分利用两端链路的传输能力，并将端到端感知有效带宽提升至 \SI{50}{Mbps}。
|
||||
|
||||
\begin{figure}[H]
|
||||
\centering
|
||||
\includegraphics[width=\linewidth]{all_redundent_waste.drawio.pdf}
|
||||
\caption{在全链路上引入相同冗余造成带宽资源浪费}
|
||||
\label{fig:全链路冗余浪费带宽}
|
||||
\end{figure}
|
||||
|
||||
\section{研究动机}
|
||||
\label{sec:basic idea}
|
||||
|
||||
前文的观察表明，现有方法在跨域云网络场景下仍然存在局限。一方面，链路调度类方法主要利用公网质量较好时的机会窗口，将部分流量从专线迁移到公网；但当用户流量进入高峰期时，公网链路也更容易出现丢包和抖动，系统仍然需要依赖专线承载主要流量，因而难以真正降低按峰值带宽计费的专线成本。另一方面，网络编码类方法虽然能够修复丢包，但通常将端到端路径视为一条整体链路，在整条路径上统一添加冗余，没有区分不同链路片段之间的质量差异，容易在质量良好的片段上引入不必要的带宽开销。
|
||||
% 前文的观察表明，现有方法在跨域云网络场景下仍然存在局限。一方面，链路调度类方法主要利用公网质量较好时的机会窗口，将部分流量从专线迁移到公网；但当用户流量进入高峰期时，公网链路也更容易出现丢包和抖动，系统仍然需要依赖专线承载主要流量，因而难以真正降低按峰值带宽计费的专线成本。另一方面，网络编码类方法虽然能够修复丢包，但通常将端到端路径视为一条整体链路，在整条路径上统一添加冗余，没有区分不同链路片段之间的质量差异，容易在质量良好的片段上引入不必要的带宽开销。
|
||||
|
||||
因此，本文的基本思路是：不再将低质量公网链路视为只能由调度算法规避的不可用资源，而是利用覆盖网络中间节点可控、路径可分段的特点，对公网转发路径进行链路粒度的质量修复。具体而言，系统完全基于成本较低的公网链路构建覆盖网络，并持续监控各个链路片段的传输质量；对于质量良好的片段，系统保持普通转发，避免引入额外开销；对于丢包率较高或存在连续突发丢包的低质量片段，系统在该片段两端加入前向纠错编码，将质量修复限制在真正发生问题的链路范围内。通过这种方式，本文希望在不依赖专线链路的条件下，使全公网覆盖网络在用户高需求时段仍能提供接近专线链路的传输质量，同时避免端到端统一冗余带来的带宽浪费。
|
||||
因此，针对公网链路片段间质量不同、随时间波动大的特点，本文的基本思路是：全部使用公网链路组成覆盖网络，并对每个链路片段独立动态调整冗余修复强度。本文提出不应再将低质量公网链路视为只能由调度算法规避的不可用资源，而是利用覆盖网络中间节点可控、路径可分段的特点，对公网转发路径进行链路粒度的质量修复。具体而言，本文提出的方法完全基于成本较低的公网链路构建覆盖网络，并持续监控各个链路片段的传输质量；对于质量良好的片段，系统保持普通转发，避免引入额外开销；对于低质量片段，系统在该片段两端加入前向纠错编码，将质量修复产生的冗余限制在真正发生问题的链路范围内。通过这种方式，本文希望在不依赖高成本链路的条件下，使用低价的公网构建的覆盖网络在用户高需求时段仍能提供接近专线链路的传输质量，同时避免端到端统一冗余带来的带宽浪费。
|
||||
|
||||
围绕这一思路，系统设计需要进一步解决以下三个核心挑战。
|
||||
围绕这一思路，系统设计需要进一步解决以下两个核心挑战。
|
||||
|
||||
\begin{enumerate}
|
||||
\item \textbf{如何在通用覆盖网络转发路径中透明地加入片段级冗余编码。} 覆盖网络承载的上层业务类型多样，用户数据包大小和发送节奏并不固定，部分数据包可能已经接近最大传输单元。因此，编码机制不能依赖修改用户报文内容或在用户包内部预留冗余空间，而需要以独立、透明的方式插入相邻覆盖网络节点之间的链路片段，并有效应对该片段上的连续丢包。
|
||||
\item \textbf{如何根据链路质量变化自适应选择冗余强度。} 公网链路的丢包率和突发丢包模式会随时间变化，固定冗余参数难以同时适应不同链路和不同时间段的网络状态。冗余不足会降低丢包恢复能力，冗余过高则会消耗额外带宽并增加解码等待时间。因此，系统需要根据实时链路观测动态决定是否启用FEC以及相应的冗余保护强度。
|
||||
\item \textbf{如何避免片段级丢包恢复影响端到端传输节奏。} FEC解码通常以编码组为单位恢复数据包，恢复完成后可能在短时间内集中交付多个数据包。这种突发式输出会改变接收端观测到的数据到达节奏，并进一步影响拥塞控制算法的速率估计和实时应用的播放稳定性。因此，系统在修复丢包的同时，还需要对解码后的输出过程进行平滑控制。
|
||||
\item \textbf{如何应对各个链路片段频繁且不可预测的链路质量变化。} 公网链路的丢包率和连续丢包模式会随时间变化，固定冗余参数难以同时适应不同链路和不同时间段的网络状态。冗余不足会降低丢包恢复能力，冗余过高则会消耗额外带宽并增加解码等待时间。因此，系统需要根据实时链路观测判断是否启用冗余，并动态选择合适的编码参数。
|
||||
\item \textbf{如何在对传输两端透明的前提下提升部分链路的传输质量。} 覆盖网络承载的上层业务类型多样，传输两端通常并不了解中间覆盖网络的转发细节，也难以配合覆盖网络内部的链路优化。因此，优化机制不能依赖修改应用报文、改变端到端协议语义或要求发送端与接收端协同，而需要能够在覆盖网络内部的单个低质量链路片段上独立完成质量修复。同时，链路片段级修复还必须保持端到端数据包的正常传输节奏，避免因中间节点处理造成突发交付、乱序或额外时延，从而干扰上层拥塞控制和实时应用体验。
|
||||
\end{enumerate}
|
||||
|
||||
\section{本章小结}
|
||||
|
||||
本章围绕跨域云网络中的传输质量与链路成本问题，介绍了云网络、覆盖网络以及前向纠错编码等背景知识。首先，覆盖网络为跨地域云资源互联提供了灵活的虚拟网络抽象，但公网链路质量不稳定、专线链路成本较高，使得服务商需要在传输质量和运营成本之间进行权衡。其次，FEC等网络编码技术能够通过冗余信息恢复部分丢包，为改善低质量公网链路提供了基础。
|
||||
本章围绕跨域云网络中的传输质量与链路成本问题，介绍了云网络、覆盖网络以及前向纠错编码等研究背景。首先，覆盖网络为跨地域云资源互联提供了灵活的虚拟网络抽象，但公网链路质量不稳定、专线链路成本较高，使得服务商需要在传输质量和运营成本之间进行权衡。其次，FEC等网络编码技术能够通过冗余信息恢复部分丢包，为改善低质量公网链路提供了基础。
|
||||
|
||||
在此基础上，本章结合真实网络测量指出现有方法的两点不足：一方面，公网链路质量下降时段与用户流量高峰存在明显重合，使得仅依赖公网分流的链路调度方法难以削减专线峰值成本；另一方面，不同公网链路片段之间质量差异显著，端到端统一添加冗余会在高质量片段上造成额外带宽浪费。基于这些观察，本文提出利用覆盖网络路径可分段、中间节点可控的特点，在全公网互联的前提下对低质量链路片段进行针对性质量修复，并进一步总结了该思路在编码透明性、参数自适应和解码输出平滑等方面面临的设计挑战。
|
||||
在此基础上，本章结合真实网络测量指出现有方法的两点不足：一方面，公网链路质量下降时段与用户流量高峰存在明显重合，使得仅依赖公网分流的链路调度方法难以削减专线峰值成本；另一方面，不同公网链路片段之间质量差异显著，端到端统一添加冗余会在高质量片段上造成额外带宽浪费。基于这些观察，本文提出利用覆盖网络路径可分段、中间节点可控的特点，在全公网互联的前提下对低质量链路片段进行针对性质量修复，并进一步总结了该思路在链路质量变化下的自适应冗余，以及对传输两端透明的片段级质量修复与传输节奏保持方面面临的设计挑战。
|
||||
|
||||
@@ -76,7 +76,7 @@ FEC的基本思想是，在发送数据时直接加入一部分冗余信息，
|
||||
|
||||
\begin{figure}[H]
|
||||
\centering
|
||||
\includegraphics[width=.7\linewidth]{interleaved_fec.drawio.pdf}
|
||||
\includegraphics[width=.6\linewidth]{interleaved_fec.drawio.pdf}
|
||||
\caption{交织编码示意}
|
||||
\label{fig:交织示意图}
|
||||
\end{figure}
|
||||
@@ -91,7 +91,7 @@ XOR、R-S等分组码结合交织已经能较好地应对网络中的丢包问
|
||||
|
||||
\begin{figure}[H]
|
||||
\centering
|
||||
\includegraphics[width=.7\linewidth]{rs_code_slow_recovery.drawio.pdf}
|
||||
\includegraphics[width=.6\linewidth]{rs_code_slow_recovery.drawio.pdf}
|
||||
\caption{分组码需要暂停解码输出等待冗余包到来才能恢复丢包并继续解码过程}
|
||||
\label{fig:RS编码等待恢复延迟}
|
||||
\end{figure}
|
||||
|
||||
@@ -19,40 +19,33 @@
|
||||
|
||||
\section{系统总体架构}
|
||||
|
||||
为了实现在全公网互联结构下对低质量链路片段进行针对性修复，本工作主要需要解决三个挑战：
|
||||
跨域云网络中的公网链路并非整体全部低质，而是不同链路片段之间质量差异显著，并且单条链路的丢包率和连续丢包模式也会随时间变化。因此，本文不再依赖专线链路或端到端统一冗余来保证传输质量，而是在全公网覆盖网络中对各个链路片段进行独立监控，并只在低质量片段上执行针对性的丢包修复。为了使这种片段级优化能够服务于不同类型的上层应用，系统还需要保持对传输两端透明，避免改变端到端协议语义或破坏原有的数据包到达节奏。围绕这一目标，本文的系统设计需要解决以下两个挑战。
|
||||
|
||||
\textbf{挑战一：如何在用户包大小可变的场景下设计链路片段级FEC编码方案。}
|
||||
系统作为通用转发平台，承载的上层应用可能产生任意大小的数据包。当用户数据包接近MTU时，若FEC编码产生的冗余信息追加在用户数据包内一同发送，则封装后的数据包可能超出MTU，导致IP层分片或传输失败。因此，FEC编码方案必须能够在不影响用户数据包大小的情况下独立添加冗余信息。同时，由于本文只在低质量公网片段上进行修复，编码方案还需要在单个链路片段上有效应对连续突发丢包，而不是依赖端到端重传。本文在~\ref{sec:fec编码} 节设计了交织XOR分组编码方案应对此挑战。
|
||||
\textbf{挑战一：如何应对各个链路片段频繁且不可预测的链路质量变化。}
|
||||
全公网方案不能简单地对所有链路长期使用高冗余率，否则低成本公网节省下来的费用会被额外流量开销抵消，且会造成部分可用带宽的浪费。系统承载的应用中又包含实时音视频流媒体等对延迟敏感的业务，FEC编码引入的冗余包不仅占用额外带宽，也会引入解码等待延迟。因此，系统需要根据链路片段上的实时丢包统计，在丢包恢复能力、额外带宽开销和恢复延迟之间取得平衡。由于公网链路的丢包率与丢包模式随时间动态变化，固定的编码参数无法同时适应不同质量状态的链路。本文在~\ref{sec:参数调整} 节通过建立丢包信道模型并据此进行约束搜索，动态判断链路片段是否需要启用冗余以及应使用的编码参数。
|
||||
|
||||
\textbf{挑战二：如何判断差链路所需的冗余强度并自适应地选择编码参数。}
|
||||
全公网方案不能简单地对所有链路长期使用高冗余率，否则低成本公网节省下来的费用会被额外流量开销抵消。系统承载的应用中又包含实时音视频流媒体等对延迟敏感的业务，FEC编码引入的冗余包不仅占用额外带宽，也会引入解码等待延迟。因此，系统需要根据链路片段上的实时丢包统计，在丢包恢复能力、额外带宽开销和恢复延迟之间取得平衡。由于公网链路的丢包率与丢包模式随时间动态变化，固定的编码参数无法同时适应不同质量状态的链路。本文在~\ref{sec:参数调整} 节通过建立丢包信道模型并据此进行约束搜索来解决此挑战。
|
||||
|
||||
\textbf{挑战三：如何消除FEC解码按组突发输出对拥塞控制算法的干扰。}
|
||||
FEC解码器按编码组为单位批量恢复和交付数据包。当一个编码组恢复完成后，组内的所有数据包被一次性连续交付给上层应用。这种突发式的输出模式会使得上游的拥塞控制算法收到密集的ACK确认包，从而错误地估计链路可用带宽，引发发送速率的震荡。速率震荡不仅影响应用的传输性能，还会使FEC编码器的输入节奏不稳定，进一步干扰吞吐量统计和参数估计的准确性。本文在~\ref{sec:pacer} 节中，在解码端设计了基于PI控制器的输出速率控制器来消除此问题。
|
||||
\textbf{挑战二：如何在对传输两端透明的前提下提升部分链路的传输质量。}
|
||||
覆盖网络承载的上层业务类型多样，传输两端通常并不了解中间覆盖网络的转发细节，也难以配合覆盖网络内部的链路优化。因此，片段级质量修复不能依赖修改应用报文、改变端到端协议语义或要求发送端与接收端协同，而需要由覆盖网络内部的相邻节点独立完成。本文通过集中控制、分布转发的系统架构，在控制面为连接下发路径和链路修复配置，在数据面由相邻转发节点完成冗余编码、解码和普通转发的切换。同时，由于FEC解码可能造成数据包集中输出，系统还需要在完成丢包恢复后保持端到端数据包的正常传输节奏。本文在~\ref{sec:pacer} 节中设计了解码端输出速率控制器，对恢复后的数据包进行平滑交付，避免中间节点处理干扰上层拥塞控制和实时应用体验。
|
||||
|
||||
本系统的整体架构如图~\ref{fig:系统总体架构} 所示。系统由一个中心控制器（Coordinator）和多个部署在不同地域的转发节点（Node）组成。中心控制器维护节点和连接状态，为端到端连接分配流标识，向相关节点下发转发表项，并根据解码端上报的丢包统计调整低质量链路片段上的FEC编码参数。转发节点负责数据面的实际转发，在本地根据控制器下发的配置，对不同流分别执行普通转发、FEC编码或FEC解码。
|
||||
|
||||
\begin{figure}[H]
|
||||
\centering
|
||||
\includegraphics[width=\linewidth]{system_overview.drawio.pdf}
|
||||
\includegraphics[width=.9\linewidth]{system_overview.drawio.pdf}
|
||||
\caption{系统总体架构}
|
||||
\label{fig:系统总体架构}
|
||||
\end{figure}
|
||||
|
||||
每个转发节点上为每条端到端连接创建独立的TUN虚拟网络设备，用户应用只感知到一条普通IP链路，而不需要感知底层覆盖网络和FEC机制。节点之间通过UDP隧道传输数据包，每个数据包的头部携带\texttt{flow\_id}以标识所属的数据流。系统为每个\texttt{flow\_id}创建独立的处理线程，线程中包含入方向解码器和出方向编码器：当流量进入一个需要修复的低质量链路片段时，出方向编码器添加FEC冗余；当流量离开该链路片段时，入方向解码器根据收到的数据包和冗余包恢复丢包。对于不需要修复的链路片段，编码器和解码器退化为普通转发逻辑。
|
||||
每个转发节点上为每条端到端连接创建独立的TUN虚拟网络设备，用户应用只感知到一条普通IP链路，而不需要感知底层覆盖网络和FEC机制。节点之间通过UDP隧道传输数据包，当流量进入一个需要修复的低质量链路片段时，出方向编码器添加FEC冗余；当流量离开该链路片段时，入方向解码器根据收到的数据包和冗余包恢复丢包。对于不需要修复的链路片段，编码器和解码器退化为普通转发逻辑。
|
||||
|
||||
\section{交织XOR前向纠错编码设计}
|
||||
\label{sec:fec编码}
|
||||
|
||||
% 本节针对挑战一，介绍链路片段级交织FEC编码方案的设计。核心需求是：FEC冗余信息必须以独立包的形式发送，不嵌入用户数据包内部，从而避免影响用户数据包的大小；同时编码方案需能在低质量公网片段上有效应对连续突发丢包。
|
||||
现有的前向纠错编码方案主要包括简单复制冗余、XOR码、R-S码以及流式编码等。本文选择基于XOR运算的分组编码结合交织技术作为FEC编码方案，其核心考量如下。
|
||||
|
||||
由于覆盖网络中承载的流量种类多样，
|
||||
分组码天然适应可变包大小的场景。在分组码中，冗余包是独立于数据包的单独包：编码器先将用户数据包逐个作为数据包发出，在编码组填满或超时后再生成独立的冗余包并追加发送。由于冗余信息不嵌入在用户数据包内部，用户数据包的大小不受FEC编码的影响，因此即使数据包本身已接近MTU，也不会因为FEC而产生封装溢出导致IP分片的问题。相比之下，流式编码将同一时刻的冗余信息分散嵌入后续多个数据包中，要求在数据包内部预留冗余空间，在用户包大小不可控的通用转发场景下难以适用。分组码的另一个优势是边界清晰：编码器和解码器可以部署在某一段公网链路的两端，只修复该链路片段，而不会要求整条端到端路径都采用同一种传输机制。
|
||||
|
||||
如第二章所述，现有的前向纠错编码方案主要包括简单复制冗余、XOR码、R-S码以及流式编码等。本文选择基于XOR运算的分组编码结合交织技术作为FEC编码方案，其核心考量如下。
|
||||
|
||||
分组码天然适应可变包大小的场景。在分组码中，冗余包是独立于数据包的单独包：编码器先将用户数据包逐个作为数据包发出，在编码组填满或超时后再生成独立的冗余包并追加发送。由于冗余信息不嵌入在用户数据包内部，用户数据包的大小不受FEC编码的影响，因此即使数据包本身已接近MTU，也不会因为FEC而产生封装溢出的问题。相比之下，流式编码将同一时刻的冗余信息分散嵌入后续多个数据包中，要求在数据包内部预留冗余空间，在用户包大小不可控的通用转发场景下难以适用。分组码的另一个优势是边界清晰：编码器和解码器可以部署在某一段公网链路的两端，只修复该链路片段，而不会要求整条端到端路径都采用同一种传输机制。
|
||||
|
||||
在多种分组码中，本文选择XOR编码而非R-S码，理由是结合交织技术的XOR编码已足以应对公网链路上观察到的丢包模式。根据第一章的分析，公网链路的主要丢包特征是偶发的孤立丢包和有限长度的连续突发丢包。交织技术将连续的突发丢包分散到不同的恢复列中，使得每列至多丢失一个数据包，恰好匹配XOR编码"每列可恢复一个丢包"的能力。同时，XOR编码的编码和解码均只需要按位异或运算，无需有限域上的矩阵运算，计算开销极低，适合高吞吐量的转发场景。
|
||||
在多种分组码中，本文选择XOR编码而非R-S码，理由是结合交织技术的XOR编码已足以应对公网链路上观察到的丢包模式。根据第一章的分析，公网链路的主要丢包特征是偶发的孤立丢包和有限长度的连续突发丢包。交织技术将连续的突发丢包分散到不同的恢复列中，使得每列至多丢失一个数据包，恰好匹配XOR编码“每列可恢复一个丢包”的能力。同时，XOR编码的编码和解码均只需要按位异或运算，无需有限域上的矩阵运算，计算开销极低，适合高吞吐量的转发场景。
|
||||
|
||||
具体地，本文提出的交织FEC编码将数据包组织为一个二维矩阵结构，如图~\ref{fig:交织编码矩阵} 所示。设交织深度为$d$，保护包数为$k$，则每个编码组包含$d \times k$个数据包和$d$个冗余包。矩阵共有$d$列、$k+1$行，其中前$k$行为数据包，第$k+1$行为冗余包。每个数据包在矩阵中的位置由其组内序列号唯一确定：对于序列号为$s$的数据包，其所在列号为$s \bmod d$，行号为$\lfloor s / d \rfloor$。每个冗余包通过对同一列中所有数据包进行按位异或运算得到。交织技术的关键优势在于：当网络上发生长度不超过$d$的连续丢包时，由于相邻数据包被分配到不同的列中，这些丢失的数据包被分散到最多$d$个不同的列中，每个列至多丢失一个数据包，因此每个列都可以独立恢复。以图~\ref{fig:交织编码矩阵} 为例，当$d = 4$时，即使出现了连续四个丢包，由于四个丢包位于四个不同的编码组中（图中以虚线框标出），在每个编码组内部只有一个包丢失，因此接收端仍旧可以完全恢复所有的丢包内容。
|
||||
|
||||
@@ -62,7 +55,7 @@ FEC解码器按编码组为单位批量恢复和交付数据包。当一个编
|
||||
|
||||
\begin{figure}[H]
|
||||
\centering
|
||||
\includegraphics[width=.7\linewidth]{fec_interleave_loss.drawio.pdf}
|
||||
\includegraphics[width=.6\linewidth]{fec_interleave_loss.drawio.pdf}
|
||||
\caption{交织编码矩阵结构示意（$d=4, k=3$）}
|
||||
\label{fig:交织编码矩阵}
|
||||
\end{figure}
|
||||
@@ -110,7 +103,7 @@ FEC解码器按编码组为单位批量恢复和交付数据包。当一个编
|
||||
\section{解码端输出速率控制设计}
|
||||
\label{sec:pacer}
|
||||
|
||||
本节针对挑战三，介绍解码端的输出速率控制器（Pacer）设计。如前所述，FEC解码器按编码组为单位批量交付数据包，这种突发输出会使上游CCA收到密集的ACK，导致错误的带宽估计和速率震荡。本文通过在解码端引入PI速率控制器，将突发输出平滑为匀速流来解决此问题，其控制模型如图~\ref{fig:pacer控制模型} 所示。
|
||||
本节针对片段级质量修复中的传输节奏保持问题，介绍解码端的输出速率控制器（Pacer）设计。如前所述，FEC解码器按编码组为单位批量交付数据包，这种突发输出会使上游CCA收到密集的ACK，导致错误的带宽估计和速率震荡。本文通过在解码端引入PI速率控制器，将突发输出平滑为匀速流来解决此问题，其控制模型如图~\ref{fig:pacer控制模型} 所示。
|
||||
|
||||
\begin{figure}[H]
|
||||
\centering
|
||||
@@ -126,7 +119,7 @@ FEC解码器按编码组为单位批量恢复和交付数据包。当一个编
|
||||
|
||||
\nomenclature{PI控制器}{比例-积分控制器}
|
||||
|
||||
具体来说，控制器内部维护一个目标缓冲区深度$h_0$，它是5个数据包的深度或是按当前释放速率计算~\SI{5}{ms} 能排空的缓冲区大小，取二者较大者。同时，控制器内部维护了一个积分值$I$，它在从直通模式切换至PI控制模式时初始化为在直通模式下估计的包到来速率。每次有数据包从缓冲区中释放时，控制器计算当前的缓冲区深度$h$与目标深度的差值：
|
||||
具体来说，控制器内部维护一个目标缓冲区深度$h_0$，它的深度是5个数据包或是按当前释放速率计算~\SI{5}{ms} 能排空的缓冲区大小，取二者较大者。同时，控制器内部维护了一个积分值$I$，它在从直通模式切换至PI控制模式时初始化为在直通模式下估计的包到来速率。每次有数据包从缓冲区中释放时，控制器计算当前的缓冲区深度$h$与目标深度的差值：
|
||||
\begin{equation}
|
||||
\increment h = h - h_0
|
||||
\end{equation}
|
||||
@@ -156,4 +149,4 @@ FEC解码器按编码组为单位批量恢复和交付数据包。当一个编
|
||||
|
||||
\section{本章小结}
|
||||
|
||||
本章围绕全公网互联、差分片修复的总体思路，介绍了本文提出的跨域公网链路传输优化方法。首先明确了本文不依赖专线互联，而是在公网覆盖网络中针对低质量链路片段进行FEC修复；随后介绍了集中控制、分布转发的系统总体架构，并将总体目标细化为三个设计挑战。针对通用转发场景下可变包大小与MTU约束的挑战，本文选择了交织XOR分组编码方案，冗余包作为独立包发送不影响用户数据包大小，交织技术则将连续丢包分散到不同的恢复列中。针对满足实时应用延迟需求的同时自适应选择编码参数的挑战，本文提出了三状态丢包信道模型，介绍了从丢包观测量估计模型参数以及在延迟与残余丢包率约束下搜索最优编码参数的方法。最后，针对FEC解码突发输出干扰拥塞控制算法的挑战，本文设计了解码端PI速率控制器，将突发输出平滑为匀速流，并与FEC参数调整机制形成协同。
|
||||
本章围绕全公网互联、差分片修复的总体思路，介绍了本文提出的跨域公网链路传输优化方法。首先明确了本文不依赖专线互联，而是在公网覆盖网络中针对低质量链路片段进行FEC修复；随后介绍了集中控制、分布转发的系统总体架构，并将总体目标细化为两个设计挑战。针对链路片段质量频繁变化的问题，本文提出了三状态丢包信道模型，介绍了从丢包观测量估计模型参数以及在延迟与残余丢包率约束下搜索最优编码参数的方法。针对对传输两端透明地提升部分链路质量的问题，本文通过覆盖网络内部相邻节点完成片段级编码与解码，并设计了解码端PI速率控制器，将FEC解码后的突发输出平滑为匀速流，避免片段级修复干扰上层拥塞控制和实时应用体验。
|
||||
|
||||
@@ -3,14 +3,14 @@
|
||||
\chapter{实验验证与分析}
|
||||
\label{chap:实验验证与分析}
|
||||
|
||||
本章主要介绍系统的实现情况及实验结果。\ref{sec:试验环境} 节介绍本文提出的设计方案的实现情况及实验环境与实验设置等基本信息，\ref{sec:实验结果} 节展示了实验结果，并对其进行了简要的分析。
|
||||
本章主要介绍系统的实现情况及实验结果。\ref{sec:实验环境} 节介绍本文提出的设计方案的实现情况及实验环境与实验设置等基本信息，\ref{sec:实验结果} 节展示了实验结果，并对实验现象及其原因进行了分析。
|
||||
|
||||
\section{实验环境}
|
||||
\label{sec:实验环境}
|
||||
|
||||
本文作者使用Rust语言实现了设计的分布式转发与控制系统，实现了动态FEC编解码、丢包统计及参数自动计算等所有核心设计要点。本文实验在一台配备两颗Intel Xeon E5-2620 v3处理器的服务器上进行，整机共提供12个物理核心、24个逻辑CPU。服务器共搭载~\SI{64}{GiB} 运行内存。本文中的实验使用Rattan\cite{wang2025rattan}对网络上的丢包，延迟及带宽限速进行模拟。在实验中，多台不同的虚拟机通过虚拟交换机互联，并在每台虚拟机的虚拟出口使用Rattan对网络流量进行处理，以达成对链路延迟、丢包带宽等不同性质的模拟。如图~\ref{fig:实验拓扑}，在实验中，共使用三台虚拟机（记作A，B，C）作为转发以及用户接入客户端，使用另外一台虚拟机作为控制器。利用控制器建立A经由B到达C的链路，其中AB间的链路为模拟低质量链路，存在丢包，往返时延~\SI{50}{ms}；BC间的链路为模拟高质量链路，为不丢包的链路，往返时延~\SI{50}{ms}。两条链路的带宽均为~\SI{100}{Mbps}。通过调整AB间链路的丢包率并测量AC之间的传输性能，可以测量本文提出的方法与直接进行转发的基准方案的性能，并进行对比。
|
||||
本文使用Rust语言实现了设计的分布式转发与控制系统，实现了动态FEC编解码、丢包统计及参数自动计算等所有核心设计要点。本文实验在一台配备两颗Intel Xeon E5-2620 v3处理器的服务器上进行。服务器共搭载~\SI{64}{GiB} 运行内存。本文中的实验使用Rattan\cite{wang2025rattan}对网络上的丢包，延迟及带宽限速进行模拟。在实验中，多台不同的虚拟机通过虚拟交换机互联，并在每台虚拟机的虚拟出口使用Rattan对网络流量进行处理，以达成对链路延迟、丢包带宽等不同性质的模拟。如图~\ref{fig:实验拓扑}，在实验中，共使用三台虚拟机（记作A，B，C）作为转发以及用户接入客户端，使用另外一台虚拟机作为控制器。利用控制器建立A经由B到达C的链路，其中AB间的链路为模拟低质量链路，存在丢包，往返时延~\SI{50}{ms}；BC间的链路为模拟高质量链路，不存在丢包，往返时延~\SI{50}{ms}。两条链路的带宽均为~\SI{100}{Mbps}。通过调整AB间链路的丢包率并测量AC之间的传输性能，可以测量本文提出的方法与直接进行转发的基准方案的性能，并进行对比。
|
||||
|
||||
实验时，分别选取丢包率取从0至2\%的不同值，分别使用本文提出的动态链路优化算法与直接进行转发的方法在A、C间使用iperf3进行测速，持续~\SI{60}{s}，并记录收端的接收速率。
|
||||
实验时，AB链路分别选取0至2\%范围内的不同丢包率，分别使用本文提出的动态链路优化算法与直接进行转发的方法在A、C间使用iperf3进行测速，持续~\SI{60}{s}，并记录收端的接收速率。
|
||||
|
||||
\begin{figure}[H]
|
||||
\centering
|
||||
@@ -19,10 +19,14 @@
|
||||
\label{fig:实验拓扑}
|
||||
\end{figure}
|
||||
|
||||
该实验拓扑用于模拟跨域覆盖网络中常见的分段质量不均衡场景：端到端路径由多段覆盖网络链路组成，其中只有部分片段存在明显丢包，而其他片段仍保持较好质量。通过仅在AB段注入丢包、保持BC段无丢包，实验可以观察本文方法是否能够将修复行为限制在低质量链路片段上，而不是对整条端到端路径统一加入冗余。直接转发方案作为基准方案，使用与本文方法相同的A-B-C覆盖网络路径和相同的链路参数，但不启用FEC编码、解码和动态参数调整。两种方案的差异仅在于是否使用本文提出的片段级链路质量修复机制，因此可以用于比较该机制对端到端传输性能的影响。
|
||||
|
||||
本文选取端到端吞吐量作为主要评价指标。对于基于TCP的文件传输或可靠数据传输业务，吞吐量能够直接反映链路丢包、恢复机制和额外冗余开销对应用可用带宽的综合影响。若片段级FEC能够有效降低端到端连接感知到的丢包，则发送端可以维持更高的发送速率；反之，若残余丢包较多或冗余开销过大，最终吞吐量仍会下降。因此，端到端吞吐量可以同时体现本文方法的丢包修复效果和额外带宽开销。
|
||||
|
||||
\section{实验结果与分析}
|
||||
\label{sec:实验结果}
|
||||
|
||||
实验结果如图~\ref{fig:实验结果图}所示。图~\ref{fig:吞吐绝对值} 展示了不同丢包率下两种方法的端到端吞吐量，图~\ref{fig:吞吐相对提升} 展示了本文方法相对于直接转发基准方案的吞吐提升程度。
|
||||
实验结果如图~\ref{fig:实验结果图}所示。图~\ref{fig:吞吐绝对值} 展示了不同丢包率下两种方法的端到端吞吐量，图~\ref{fig:吞吐相对提升} 展示了不同丢包率下本文方法相对于直接转发基准方案的吞吐提升程度。
|
||||
|
||||
\begin{figure}[H]
|
||||
\centering
|
||||
@@ -35,11 +39,19 @@
|
||||
\label{fig:实验结果图}
|
||||
\end{figure}
|
||||
|
||||
与基线方法相比，本文方法在较高丢包率下仍旧保持了较高的总体带宽，并达到了最高3.6倍带宽提升。通过查阅控制器日志可以发现，本方法正确识别了两条链路中的不同丢包率，并在丢包严重的AB段链路上启用了FEC，在没有丢包的链路上则始终使用普通转发。
|
||||
从图~\ref{fig:吞吐绝对值} 可以看到，在无丢包链路中，直接转发与本文方法都能够接近实验链路的带宽上限，吞吐量分别为~\SI{92.1}{Mbps} 和~\SI{90.9}{Mbps}。这说明在链路质量良好时，本文系统引入的虚拟网卡、UDP隧道、流标识和普通转发逻辑本身没有造成明显的性能损失。本文方法相比直接转发低约~\SI{1.3}{\percent}，主要来自额外包头和转发处理开销。由于该开销在无丢包场景下已经能够直接观测到，而在存在丢包时本文方法带来的吞吐提升显著大于这一差距，因此可以认为系统基础转发开销不会掩盖后续FEC修复带来的性能收益。
|
||||
|
||||
尽管本方法使用了FEC方法对链路丢包进行了恢复，并有效提升了整体吞吐量，但是相比无丢包时仍旧有较大的吞吐性能差距。这一方面是由于添加冗余信息占用了一部分带宽，导致理想状态下应用可用的带宽下降；另一方面是由于由于冗余参数的选取较为保守，即使添加了FEC也有一定概率会出现丢包，导致发送端仍旧不能保证没有丢包发生，这些丢包会导致发送端丢包降低发送速率。最终，冗余带宽占用和残余丢包两种因素叠加导致即使使用了本方法，传输速率仍旧有所下降。
|
||||
随着AB段链路丢包率升高，直接转发的吞吐量迅速下降。当丢包率为~\SI{0.2}{\percent} 时，直接转发吞吐量已经从~\SI{92.1}{Mbps} 下降至~\SI{42.5}{Mbps}；当丢包率进一步升高到~\SI{1}{\percent} 和~\SI{2}{\percent} 时，吞吐量分别只有~\SI{18.9}{Mbps} 和~\SI{12.7}{Mbps}。这一趋势符合TCP类可靠传输协议对丢包较为敏感的特点：在实验拓扑中，AB链路上的随机丢包会被端到端连接感知为网络拥塞，发送端随之降低拥塞窗口和发送速率；同时，由于A到C的端到端路径包含两个~\SI{50}{ms} 往返时延的链路片段，丢包后的恢复和发送速率回升都需要经历较长反馈周期。因此，即使底层链路的带宽上限仍为~\SI{100}{Mbps}，少量丢包也会明显降低应用层实际可用吞吐。
|
||||
|
||||
值得注意的是，虽然从本方法的吞吐量从无丢包至有丢包有较大下降，但是随着丢包率的增高，吞吐量的下降程度明显小于直接转发行为，这是由于本方法的动态FEC参数决定算法动态根据测量得到的丢包率参数决定了合适的冗余度，从而有效地将修复后的丢包率维持在较为固定的范围内，因而尽管底层链路的丢包率持续恶化，但是上层TCP连接感知的丢包率却始终稳定，使得最终的吞吐量也稳定在较为稳定的范围内。
|
||||
相比之下，本文方法在有丢包条件下能够维持更高的端到端吞吐量。当AB段丢包率为~\SI{0.2}{\percent}、~\SI{0.5}{\percent}、~\SI{1}{\percent} 和~\SI{2}{\percent} 时，本文方法的吞吐量分别为~\SI{61.7}{Mbps}、~\SI{59.8}{Mbps}、~\SI{54.8}{Mbps} 和~\SI{45.3}{Mbps}，均显著高于直接转发。对应地，图~\ref{fig:吞吐相对提升} 表明，本文方法相对于直接转发的吞吐提升从~\SI{0.2}{\percent} 丢包时的约~1.45倍，逐渐提高到~\SI{2}{\percent} 丢包时的约~3.6倍。也就是说，底层公网链路质量越差，直接转发越难以维持稳定吞吐，而片段级FEC修复越能够体现出对低质量链路的补偿效果。
|
||||
|
||||
在丢包率为零的场景下，使用直接转发能达到比使用本方法略高的性能，这主要是由于本方法所使用的FEC算法在不启用冗余时也仍旧需要在数据包中传输少量额外的包头，导致吞吐量相比直接转发有大约~\SI{1}{\percent} 的下降，与存在丢包场景下的性能提升相比影响较小。
|
||||
这一结果验证了本文方法对不同链路片段进行差异化处理的有效性。通过查阅控制器日志可以发现，本文方法正确识别了两条链路中的不同丢包率，并在丢包严重的AB段链路上启用了FEC，在没有丢包的BC段链路上则始终使用普通转发。这一点与本文的设计目标一致：系统并没有将A到C的整条路径都视为一条低质量链路，也没有在质量良好的BC段继续添加冗余流量，而是将额外带宽开销限制在真正发生丢包的AB片段上。因此，实验不仅说明FEC能够提升端到端吞吐，也说明覆盖网络中间节点对链路片段的独立控制能力可以被用于实现更细粒度的质量修复。
|
||||
|
||||
从吞吐曲线的形状还可以看出，本文方法在丢包率升高后的下降程度明显低于直接转发。直接转发曲线随丢包率增加持续陡峭下降，而本文方法在~\SI{0.2}{\percent} 至~\SI{1}{\percent} 的丢包范围内保持在约~\SI{55}{Mbps} 至~\SI{62}{Mbps} 之间。这说明动态FEC参数调整机制能够根据测量得到的丢包统计选择更合适的冗余强度，使修复后的残余丢包率维持在相对稳定的范围内。换言之，虽然底层AB链路的原始丢包率持续恶化，但上层TCP连接实际感知到的丢包变化被片段级修复机制削弱，因此端到端吞吐没有像直接转发一样快速退化。
|
||||
|
||||
不过，本文方法的吞吐量仍然低于无丢包条件下的吞吐量，这反映了FEC修复带来的两类代价。第一，冗余包会占用AB段链路的一部分传输能力，使有效数据能够使用的带宽低于物理链路带宽。丢包率越高，系统为了达到目标残余丢包率需要使用更强的冗余参数，冗余流量占比也会随之上升。第二，FEC并不能保证恢复所有丢包。当同一恢复单元内发生超过编码能力的丢包时，解码端仍然无法恢复全部原始数据包，这些残余丢包最终会被端到端传输协议感知，并触发发送端的发送速率下降逻辑。因此，本文方法的性能上限受到冗余开销和残余丢包的共同影响：较低冗余会留下更多残余丢包，较高冗余又会占用更多带宽，动态参数调整需要在二者之间取得平衡。
|
||||
|
||||
% 实验结果也说明，本文方法更适用于公网链路已经出现明显丢包、直接转发性能受到限制的场景。在无丢包链路上，本文方法只能保持接近直接转发的性能，并不会带来额外吞吐收益；而当链路出现~\SI{0.2}{\percent} 以上丢包时，片段级修复开始显著改善端到端吞吐。该现象与本文的研究动机一致：本文并不是试图在所有链路上无条件启用冗余，而是希望在公网链路质量下降、但仍具有可用带宽时，通过低质量片段上的冗余修复将这部分链路重新转化为可承载高质量传输的资源。
|
||||
|
||||
总体而言，上述实验从两个方面验证了本文提出的方法。首先，系统能够区分同一路径中不同链路片段的质量差异，只在低质量AB段启用FEC修复，在高质量BC段保持普通转发，验证了片段级质量修复的可行性。其次，在链路丢包率从0升高到~\SI{2}{\percent} 的过程中，本文方法能够随链路状态变化调整冗余参数，使端到端吞吐始终显著高于直接转发，验证了自适应参数调整机制的有效性。实验中的最高吞吐提升约为3.6倍，表明在跨域公网链路质量不稳定的场景下，利用覆盖网络内部可控节点进行分段修复能够有效缓解丢包对传输性能的影响。
|
||||
|
||||
|
||||
@@ -5,13 +5,13 @@
|
||||
|
||||
\section{工作总结}
|
||||
|
||||
随着云计算和实时互联网应用的发展，跨地域覆盖网络需要在全球范围内为用户提供稳定的低延迟、高带宽和低丢包传输服务。传统方案通常依赖专线链路保证服务质量，但专线链路价格较高，难以满足大规模跨域覆盖网络的成本优化需求。已有链路调度类方法尝试在公网质量较好时将部分流量迁移至公网链路，以降低专线链路上的承载流量；已有冗余编码类方法则通过端到端前向纠错编码缓解网络丢包对应用体验的影响。然而，本文的测量和分析表明，公网链路质量下降时段往往与用户流量高峰重合，使得基于公网分流的调度方法难以有效削减专线峰值成本；同时，跨域覆盖网络中不同公网链路片段质量差异显著，端到端统一添加冗余会在质量良好的片段上引入不必要的带宽开销。
|
||||
随着实时音视频、跨地域文件传输、远程办公和云上应用访问等业务快速发展，跨域覆盖网络需要在较低成本下为用户提供稳定的高吞吐、低时延和低丢包跨域传输服务。传统方案通常依赖专线链路保证服务质量，但专线链路成本较高，难以满足大规模跨域覆盖网络的长期部署需求。已有链路调度类方法尝试在公网链路质量较好时利用公网分担流量，已有端到端优化方法则通过拥塞控制或冗余编码缓解网络质量波动。然而，本文的测量和分析表明，公网链路质量下降时段往往与用户流量高峰重合，使得公网分流难以有效削减专线峰值成本；同时，跨域覆盖网络中不同公网链路片段质量差异显著，端到端统一添加冗余会在质量良好的片段上造成额外带宽开销。
|
||||
|
||||
针对上述问题，本文提出了一种面向跨域公网链路的分段质量修复方法。本文方法不再依赖专线链路作为后备方案，而是在全公网互联的覆盖网络中识别和修复低质量链路片段。对于质量良好的链路片段，系统保持普通转发，以避免额外开销；对于丢包率较高、存在连续突发丢包的链路片段，系统在片段两端加入前向纠错编码与丢包恢复机制，从而将质量修复限制在真正发生问题的网络范围内。该思路充分利用了覆盖网络中间节点可控、路径可分段的特点，在降低链路成本的同时提升公网链路的有效传输质量。
|
||||
针对上述问题，本文提出了一种面向跨域公网覆盖网络的分段链路质量修复方法。本文利用覆盖网络中间节点可控、路径可分段的特点，在全公网互联的覆盖网络中对不同链路片段进行独立监控和针对性修复。通过只在低质量网络片段两端加入前向纠错编码和丢包恢复机制，将质量修复限制在真正发生问题的网络范围内。
|
||||
|
||||
围绕这一思路，本文设计并实现了一套分布式覆盖网络转发与链路优化系统。系统采用中心控制器和分布式转发节点相结合的架构，由控制器维护连接状态、下发转发表项并计算FEC参数，由转发节点执行普通转发、FEC编码和FEC解码。为适应通用覆盖网络中用户包大小可变的特点，本文设计了交织XOR分组编码方案，使冗余包以独立数据包形式发送，避免修改用户报文内容；为适应公网链路质量的动态变化，本文建立三状态丢包信道模型，并根据接收端上报的丢包统计动态选择交织深度和保护包数；为避免FEC解码按组恢复造成突发输出，本文进一步设计了基于PI控制器的输出速率控制机制，使解码后的数据包以更平滑的节奏交付给上层传输协议。
|
||||
围绕这一思路，本文设计并实现了一套分布式覆盖网络转发与链路优化系统。系统对转发时使用的每个链路单独监测丢包状态，并使用交织XOR分组码进行冗余包编解码。为应对各个链路片段频繁且不可预测的质量变化，本文为网络建立三状态丢包模型，并根据解码端上报的丢包统计动态选择交织深度和保护包数，在丢包恢复能力、冗余开销和恢复延迟之间进行权衡。同时，本文设计了基于PI控制器的解码端输出速率控制机制，对FEC恢复后的突发输出进行平滑交付，降低片段级修复对上层拥塞控制和实时应用体验的影响。
|
||||
|
||||
最后，本文使用Rust语言实现了上述系统，并在模拟跨域低质量链路的实验环境中对本文方法进行了验证。实验结果表明，在0至2\%的链路丢包率范围内，本文方法能够正确识别低质量链路片段并在该片段启用FEC修复，在无丢包链路片段上保持普通转发。与直接转发方案相比，本文方法在存在丢包时显著提升了端到端吞吐量，最高实现了约3.6倍的吞吐提升。实验也表明，本文方法在无丢包场景下仅引入较小的额外开销，而在低质量公网链路场景下能够有效缓解丢包对传输性能的影响，验证了分段链路质量修复思路的有效性。
|
||||
最后，本文使用Rust语言实现了上述系统，并在模拟跨域低质量链路的实验环境中对本文方法进行了验证。实验结果表明，在0至~\SI{2}{\percent} 的链路丢包率范围内，本文方法能够识别端到端路径中的低质量链路片段，并仅在该片段启用FEC修复，在无丢包链路片段上保持普通转发。与直接转发方案相比，本文方法在存在丢包时显著提升了端到端吞吐量，最高实现约3.6倍吞吐提升；在无丢包场景下仅引入较小的额外开销。上述结果验证了本文提出的分段链路质量修复方法能够有效利用覆盖网络的链路可感知和节点可控能力，缓解公网链路丢包对跨域传输性能的影响。
|
||||
|
||||
\section{未来工作展望}
|
||||
|
||||
|
||||
172
figures/all_redundent_waste.drawio
Normal file
172
figures/all_redundent_waste.drawio
Normal file
@@ -0,0 +1,172 @@
|
||||
<mxfile host="app.diagrams.net">
|
||||
<diagram name="Page-1" id="oMBL4PqesfSSdRO5K6tR">
|
||||
<mxGraphModel dx="1111" dy="755" grid="1" gridSize="10" guides="1" tooltips="1" connect="1" arrows="1" fold="1" page="1" pageScale="1" pageWidth="827" pageHeight="1169" math="0" shadow="0">
|
||||
<root>
|
||||
<mxCell id="0" />
|
||||
<mxCell id="1" parent="0" />
|
||||
<mxCell id="jxN1CDXigmQ2T_00Dpx6-40" parent="1" style="shape=cylinder3;whiteSpace=wrap;html=1;boundedLbl=1;backgroundOutline=1;size=15;fillColor=none;rotation=90;" value="" vertex="1">
|
||||
<mxGeometry height="135" width="133.75" x="581.88" y="103.13" as="geometry" />
|
||||
</mxCell>
|
||||
<mxCell id="jxN1CDXigmQ2T_00Dpx6-70" parent="1" style="shape=cylinder3;whiteSpace=wrap;html=1;boundedLbl=1;backgroundOutline=1;size=15;fillColor=none;rotation=90;" value="" vertex="1">
|
||||
<mxGeometry height="135" width="133.75" x="585.0000000000001" y="350.005" as="geometry" />
|
||||
</mxCell>
|
||||
<mxCell id="jxN1CDXigmQ2T_00Dpx6-32" parent="1" style="shape=cylinder3;whiteSpace=wrap;html=1;boundedLbl=1;backgroundOutline=1;size=15;fillColor=none;rotation=90;" value="" vertex="1">
|
||||
<mxGeometry height="135" width="70" x="281.25" y="103.13" as="geometry" />
|
||||
</mxCell>
|
||||
<mxCell id="jxN1CDXigmQ2T_00Dpx6-63" parent="1" style="shape=cylinder3;whiteSpace=wrap;html=1;boundedLbl=1;backgroundOutline=1;size=15;fillColor=none;rotation=90;" value="" vertex="1">
|
||||
<mxGeometry height="135" width="70" x="287.5" y="319.375" as="geometry" />
|
||||
</mxCell>
|
||||
<mxCell id="jxN1CDXigmQ2T_00Dpx6-4" edge="1" parent="1" source="jxN1CDXigmQ2T_00Dpx6-1" style="edgeStyle=orthogonalEdgeStyle;rounded=0;orthogonalLoop=1;jettySize=auto;html=1;exitX=1;exitY=0.5;exitDx=0;exitDy=0;entryX=0;entryY=0.5;entryDx=0;entryDy=0;strokeWidth=2;" target="jxN1CDXigmQ2T_00Dpx6-2">
|
||||
<mxGeometry relative="1" as="geometry" />
|
||||
</mxCell>
|
||||
<mxCell id="jxN1CDXigmQ2T_00Dpx6-1" parent="1" style="rounded=1;whiteSpace=wrap;html=1;fontSize=25;fontFamily=Microsoft YaHei;fillColor=#fff2cc;strokeColor=#d6b656;" value="A" vertex="1">
|
||||
<mxGeometry height="60" width="120" x="80" y="230" as="geometry" />
|
||||
</mxCell>
|
||||
<mxCell id="jxN1CDXigmQ2T_00Dpx6-7" edge="1" parent="1" source="jxN1CDXigmQ2T_00Dpx6-2" style="edgeStyle=orthogonalEdgeStyle;rounded=0;orthogonalLoop=1;jettySize=auto;html=1;exitX=1;exitY=0.5;exitDx=0;exitDy=0;entryX=0;entryY=0.5;entryDx=0;entryDy=0;strokeWidth=2;" target="jxN1CDXigmQ2T_00Dpx6-3">
|
||||
<mxGeometry relative="1" as="geometry" />
|
||||
</mxCell>
|
||||
<mxCell id="jxN1CDXigmQ2T_00Dpx6-2" parent="1" style="rounded=1;whiteSpace=wrap;html=1;fontSize=25;fontFamily=Microsoft YaHei;fillColor=#fff2cc;strokeColor=#d6b656;" value="B" vertex="1">
|
||||
<mxGeometry height="60" width="120" x="414" y="230" as="geometry" />
|
||||
</mxCell>
|
||||
<mxCell id="jxN1CDXigmQ2T_00Dpx6-3" parent="1" style="rounded=1;whiteSpace=wrap;html=1;fontSize=25;fontFamily=Microsoft YaHei;fillColor=#fff2cc;strokeColor=#d6b656;" value="C" vertex="1">
|
||||
<mxGeometry height="60" width="120" x="750" y="230" as="geometry" />
|
||||
</mxCell>
|
||||
<mxCell id="jxN1CDXigmQ2T_00Dpx6-10" parent="1" style="rounded=0;whiteSpace=wrap;html=1;fillColor=#d5e8d4;strokeColor=#82b366;" value="" vertex="1">
|
||||
<mxGeometry height="20" width="20" x="328.75" y="175.63" as="geometry" />
|
||||
</mxCell>
|
||||
<mxCell id="jxN1CDXigmQ2T_00Dpx6-11" parent="1" style="rounded=0;whiteSpace=wrap;html=1;fillColor=#d5e8d4;strokeColor=#82b366;" value="" vertex="1">
|
||||
<mxGeometry height="20" width="20" x="298.75" y="175.63" as="geometry" />
|
||||
</mxCell>
|
||||
<mxCell id="jxN1CDXigmQ2T_00Dpx6-12" parent="1" style="rounded=0;whiteSpace=wrap;html=1;fillColor=#d5e8d4;strokeColor=#82b366;" value="" vertex="1">
|
||||
<mxGeometry height="20" width="20" x="268.75" y="175.63" as="geometry" />
|
||||
</mxCell>
|
||||
<mxCell id="jxN1CDXigmQ2T_00Dpx6-13" parent="1" style="rounded=0;whiteSpace=wrap;html=1;fillColor=#dae8fc;strokeColor=#6c8ebf;" value="" vertex="1">
|
||||
<mxGeometry height="20" width="20" x="328.75" y="145.63" as="geometry" />
|
||||
</mxCell>
|
||||
<mxCell id="jxN1CDXigmQ2T_00Dpx6-14" parent="1" style="rounded=0;whiteSpace=wrap;html=1;fillColor=#dae8fc;strokeColor=#6c8ebf;" value="" vertex="1">
|
||||
<mxGeometry height="20" width="20" x="298.75" y="145.63" as="geometry" />
|
||||
</mxCell>
|
||||
<mxCell id="jxN1CDXigmQ2T_00Dpx6-15" parent="1" style="rounded=0;whiteSpace=wrap;html=1;fillColor=#dae8fc;strokeColor=#6c8ebf;" value="" vertex="1">
|
||||
<mxGeometry height="20" width="20" x="268.75" y="145.63" as="geometry" />
|
||||
</mxCell>
|
||||
<mxCell id="jxN1CDXigmQ2T_00Dpx6-16" parent="1" style="text;html=1;whiteSpace=wrap;strokeColor=none;fillColor=none;align=center;verticalAlign=middle;rounded=0;fontFamily=Microsoft YaHei;fontSize=20;" value="0% loss<div>50Mbps</div>" vertex="1">
|
||||
<mxGeometry height="50" width="115" x="252.5" y="270" as="geometry" />
|
||||
</mxCell>
|
||||
<mxCell id="jxN1CDXigmQ2T_00Dpx6-18" parent="1" style="text;html=1;whiteSpace=wrap;strokeColor=none;fillColor=none;align=center;verticalAlign=middle;rounded=0;fontFamily=Microsoft YaHei;fontSize=20;" value="50% loss<div>100Mbps</div>" vertex="1">
|
||||
<mxGeometry height="50" width="115" x="585" y="270" as="geometry" />
|
||||
</mxCell>
|
||||
<mxCell id="jxN1CDXigmQ2T_00Dpx6-34" parent="1" style="rounded=0;whiteSpace=wrap;html=1;fillColor=#d5e8d4;strokeColor=#82b366;" value="" vertex="1">
|
||||
<mxGeometry height="20" width="20" x="661.25" y="207.5" as="geometry" />
|
||||
</mxCell>
|
||||
<mxCell id="jxN1CDXigmQ2T_00Dpx6-35" parent="1" style="rounded=0;whiteSpace=wrap;html=1;fillColor=#d5e8d4;strokeColor=#82b366;" value="" vertex="1">
|
||||
<mxGeometry height="20" width="20" x="631.25" y="207.5" as="geometry" />
|
||||
</mxCell>
|
||||
<mxCell id="jxN1CDXigmQ2T_00Dpx6-36" parent="1" style="rounded=0;whiteSpace=wrap;html=1;fillColor=#d5e8d4;strokeColor=#82b366;" value="" vertex="1">
|
||||
<mxGeometry height="20" width="20" x="601.25" y="207.5" as="geometry" />
|
||||
</mxCell>
|
||||
<mxCell id="jxN1CDXigmQ2T_00Dpx6-37" parent="1" style="rounded=0;whiteSpace=wrap;html=1;fillColor=#dae8fc;strokeColor=#6c8ebf;" value="" vertex="1">
|
||||
<mxGeometry height="20" width="20" x="661.25" y="177.5" as="geometry" />
|
||||
</mxCell>
|
||||
<mxCell id="jxN1CDXigmQ2T_00Dpx6-38" parent="1" style="rounded=0;whiteSpace=wrap;html=1;fillColor=#dae8fc;strokeColor=#6c8ebf;" value="" vertex="1">
|
||||
<mxGeometry height="20" width="20" x="631.25" y="177.5" as="geometry" />
|
||||
</mxCell>
|
||||
<mxCell id="jxN1CDXigmQ2T_00Dpx6-39" parent="1" style="rounded=0;whiteSpace=wrap;html=1;fillColor=#dae8fc;strokeColor=#6c8ebf;" value="" vertex="1">
|
||||
<mxGeometry height="20" width="20" x="601.25" y="177.5" as="geometry" />
|
||||
</mxCell>
|
||||
<mxCell id="jxN1CDXigmQ2T_00Dpx6-41" parent="1" style="rounded=0;whiteSpace=wrap;html=1;dashed=1;" value="" vertex="1">
|
||||
<mxGeometry height="20" width="20" x="661.25" y="150" as="geometry" />
|
||||
</mxCell>
|
||||
<mxCell id="jxN1CDXigmQ2T_00Dpx6-42" parent="1" style="rounded=0;whiteSpace=wrap;html=1;dashed=1;" value="" vertex="1">
|
||||
<mxGeometry height="20" width="20" x="631.25" y="150" as="geometry" />
|
||||
</mxCell>
|
||||
<mxCell id="jxN1CDXigmQ2T_00Dpx6-43" parent="1" style="rounded=0;whiteSpace=wrap;html=1;dashed=1;" value="" vertex="1">
|
||||
<mxGeometry height="20" width="20" x="601.25" y="150" as="geometry" />
|
||||
</mxCell>
|
||||
<mxCell id="jxN1CDXigmQ2T_00Dpx6-44" parent="1" style="rounded=0;whiteSpace=wrap;html=1;dashed=1;" value="" vertex="1">
|
||||
<mxGeometry height="20" width="20" x="661.25" y="120" as="geometry" />
|
||||
</mxCell>
|
||||
<mxCell id="jxN1CDXigmQ2T_00Dpx6-45" parent="1" style="rounded=0;whiteSpace=wrap;html=1;dashed=1;" value="" vertex="1">
|
||||
<mxGeometry height="20" width="20" x="631.25" y="120" as="geometry" />
|
||||
</mxCell>
|
||||
<mxCell id="jxN1CDXigmQ2T_00Dpx6-46" parent="1" style="rounded=0;whiteSpace=wrap;html=1;dashed=1;" value="" vertex="1">
|
||||
<mxGeometry height="20" width="20" x="601.25" y="120" as="geometry" />
|
||||
</mxCell>
|
||||
<mxCell id="jxN1CDXigmQ2T_00Dpx6-47" parent="1" style="text;html=1;whiteSpace=wrap;align=center;verticalAlign=middle;rounded=0;fontFamily=Microsoft YaHei;fontSize=20;strokeColor=default;dashed=1;" value="浪费50Mbps" vertex="1">
|
||||
<mxGeometry height="50" width="130" x="745" y="105" as="geometry" />
|
||||
</mxCell>
|
||||
<mxCell id="jxN1CDXigmQ2T_00Dpx6-55" parent="1" style="rounded=0;whiteSpace=wrap;html=1;fillColor=#d5e8d4;strokeColor=#82b366;" value="" vertex="1">
|
||||
<mxGeometry height="20" width="20" x="335" y="391.875" as="geometry" />
|
||||
</mxCell>
|
||||
<mxCell id="jxN1CDXigmQ2T_00Dpx6-56" parent="1" style="rounded=0;whiteSpace=wrap;html=1;fillColor=#d5e8d4;strokeColor=#82b366;" value="" vertex="1">
|
||||
<mxGeometry height="20" width="20" x="305" y="391.875" as="geometry" />
|
||||
</mxCell>
|
||||
<mxCell id="jxN1CDXigmQ2T_00Dpx6-57" parent="1" style="rounded=0;whiteSpace=wrap;html=1;fillColor=#d5e8d4;strokeColor=#82b366;" value="" vertex="1">
|
||||
<mxGeometry height="20" width="20" x="275" y="391.875" as="geometry" />
|
||||
</mxCell>
|
||||
<mxCell id="jxN1CDXigmQ2T_00Dpx6-58" parent="1" style="rounded=0;whiteSpace=wrap;html=1;fillColor=#d5e8d4;strokeColor=#82b366;" value="" vertex="1">
|
||||
<mxGeometry height="20" width="20" x="335" y="361.875" as="geometry" />
|
||||
</mxCell>
|
||||
<mxCell id="jxN1CDXigmQ2T_00Dpx6-59" parent="1" style="rounded=0;whiteSpace=wrap;html=1;fillColor=#d5e8d4;strokeColor=#82b366;" value="" vertex="1">
|
||||
<mxGeometry height="20" width="20" x="305" y="361.875" as="geometry" />
|
||||
</mxCell>
|
||||
<mxCell id="jxN1CDXigmQ2T_00Dpx6-60" parent="1" style="rounded=0;whiteSpace=wrap;html=1;fillColor=#d5e8d4;strokeColor=#82b366;" value="" vertex="1">
|
||||
<mxGeometry height="20" width="20" x="275" y="361.875" as="geometry" />
|
||||
</mxCell>
|
||||
<mxCell id="jxN1CDXigmQ2T_00Dpx6-64" parent="1" style="rounded=0;whiteSpace=wrap;html=1;fillColor=#d5e8d4;strokeColor=#82b366;" value="" vertex="1">
|
||||
<mxGeometry height="20" width="20" x="664.37" y="454.375" as="geometry" />
|
||||
</mxCell>
|
||||
<mxCell id="jxN1CDXigmQ2T_00Dpx6-65" parent="1" style="rounded=0;whiteSpace=wrap;html=1;fillColor=#d5e8d4;strokeColor=#82b366;" value="" vertex="1">
|
||||
<mxGeometry height="20" width="20" x="634.37" y="454.375" as="geometry" />
|
||||
</mxCell>
|
||||
<mxCell id="jxN1CDXigmQ2T_00Dpx6-66" parent="1" style="rounded=0;whiteSpace=wrap;html=1;fillColor=#d5e8d4;strokeColor=#82b366;" value="" vertex="1">
|
||||
<mxGeometry height="20" width="20" x="604.37" y="454.375" as="geometry" />
|
||||
</mxCell>
|
||||
<mxCell id="jxN1CDXigmQ2T_00Dpx6-67" parent="1" style="rounded=0;whiteSpace=wrap;html=1;fillColor=#d5e8d4;strokeColor=#82b366;" value="" vertex="1">
|
||||
<mxGeometry height="20" width="20" x="664.37" y="424.375" as="geometry" />
|
||||
</mxCell>
|
||||
<mxCell id="jxN1CDXigmQ2T_00Dpx6-68" parent="1" style="rounded=0;whiteSpace=wrap;html=1;fillColor=#d5e8d4;strokeColor=#82b366;" value="" vertex="1">
|
||||
<mxGeometry height="20" width="20" x="634.37" y="424.375" as="geometry" />
|
||||
</mxCell>
|
||||
<mxCell id="jxN1CDXigmQ2T_00Dpx6-69" parent="1" style="rounded=0;whiteSpace=wrap;html=1;fillColor=#d5e8d4;strokeColor=#82b366;" value="" vertex="1">
|
||||
<mxGeometry height="20" width="20" x="604.37" y="424.375" as="geometry" />
|
||||
</mxCell>
|
||||
<mxCell id="jxN1CDXigmQ2T_00Dpx6-71" parent="1" style="rounded=0;whiteSpace=wrap;html=1;fillColor=#dae8fc;strokeColor=#6c8ebf;" value="" vertex="1">
|
||||
<mxGeometry height="20" width="20" x="664.37" y="396.875" as="geometry" />
|
||||
</mxCell>
|
||||
<mxCell id="jxN1CDXigmQ2T_00Dpx6-72" parent="1" style="rounded=0;whiteSpace=wrap;html=1;fillColor=#dae8fc;strokeColor=#6c8ebf;" value="" vertex="1">
|
||||
<mxGeometry height="20" width="20" x="634.37" y="396.875" as="geometry" />
|
||||
</mxCell>
|
||||
<mxCell id="jxN1CDXigmQ2T_00Dpx6-73" parent="1" style="rounded=0;whiteSpace=wrap;html=1;fillColor=#dae8fc;strokeColor=#6c8ebf;" value="" vertex="1">
|
||||
<mxGeometry height="20" width="20" x="604.37" y="396.875" as="geometry" />
|
||||
</mxCell>
|
||||
<mxCell id="jxN1CDXigmQ2T_00Dpx6-74" parent="1" style="rounded=0;whiteSpace=wrap;html=1;fillColor=#dae8fc;strokeColor=#6c8ebf;" value="" vertex="1">
|
||||
<mxGeometry height="20" width="20" x="664.37" y="366.875" as="geometry" />
|
||||
</mxCell>
|
||||
<mxCell id="jxN1CDXigmQ2T_00Dpx6-75" parent="1" style="rounded=0;whiteSpace=wrap;html=1;fillColor=#dae8fc;strokeColor=#6c8ebf;" value="" vertex="1">
|
||||
<mxGeometry height="20" width="20" x="634.37" y="366.875" as="geometry" />
|
||||
</mxCell>
|
||||
<mxCell id="jxN1CDXigmQ2T_00Dpx6-76" parent="1" style="rounded=0;whiteSpace=wrap;html=1;fillColor=#dae8fc;strokeColor=#6c8ebf;" value="" vertex="1">
|
||||
<mxGeometry height="20" width="20" x="604.37" y="366.875" as="geometry" />
|
||||
</mxCell>
|
||||
<mxCell id="jxN1CDXigmQ2T_00Dpx6-78" parent="1" style="rounded=0;whiteSpace=wrap;html=1;fillColor=#dae8fc;strokeColor=#6c8ebf;" value="" vertex="1">
|
||||
<mxGeometry height="20" width="20" x="67.75" y="95" as="geometry" />
|
||||
</mxCell>
|
||||
<mxCell id="jxN1CDXigmQ2T_00Dpx6-79" parent="1" style="text;html=1;whiteSpace=wrap;align=center;verticalAlign=middle;rounded=0;fontFamily=Microsoft YaHei;fontSize=20;strokeColor=none;dashed=1;" value="冗余信息" vertex="1">
|
||||
<mxGeometry height="50" width="130" x="80.25" y="80" as="geometry" />
|
||||
</mxCell>
|
||||
<mxCell id="jxN1CDXigmQ2T_00Dpx6-80" parent="1" style="rounded=0;whiteSpace=wrap;html=1;fillColor=#d5e8d4;strokeColor=#82b366;" value="" vertex="1">
|
||||
<mxGeometry height="20" width="20" x="67.75" y="130" as="geometry" />
|
||||
</mxCell>
|
||||
<mxCell id="jxN1CDXigmQ2T_00Dpx6-81" parent="1" style="text;html=1;whiteSpace=wrap;align=center;verticalAlign=middle;rounded=0;fontFamily=Microsoft YaHei;fontSize=20;strokeColor=none;dashed=1;" value="应用数据" vertex="1">
|
||||
<mxGeometry height="50" width="130" x="80.25" y="115" as="geometry" />
|
||||
</mxCell>
|
||||
<mxCell id="jxN1CDXigmQ2T_00Dpx6-87" parent="1" style="text;html=1;whiteSpace=wrap;align=center;verticalAlign=middle;rounded=0;fontFamily=Microsoft YaHei;fontSize=20;strokeColor=none;dashed=1;" value="应用感知25Mbps" vertex="1">
|
||||
<mxGeometry height="50" width="175" x="730" y="180" as="geometry" />
|
||||
</mxCell>
|
||||
<mxCell id="jxN1CDXigmQ2T_00Dpx6-89" parent="1" style="text;html=1;whiteSpace=wrap;align=center;verticalAlign=middle;rounded=0;fontFamily=Microsoft YaHei;fontSize=20;strokeColor=none;dashed=1;" value="应用感知50Mbps" vertex="1">
|
||||
<mxGeometry height="50" width="175" x="730" y="300.01" as="geometry" />
|
||||
</mxCell>
|
||||
</root>
|
||||
</mxGraphModel>
|
||||
</diagram>
|
||||
</mxfile>
|
||||
BIN
figures/all_redundent_waste.drawio.pdf
Normal file
BIN
figures/all_redundent_waste.drawio.pdf
Normal file
Binary file not shown.
4
figures/all_redundent_waste.drawio.svg
Normal file
4
figures/all_redundent_waste.drawio.svg
Normal file
File diff suppressed because one or more lines are too long
|
After Width: | Height: | Size: 195 KiB |
@@ -1,15 +1,25 @@
|
||||
<mxfile host="app.diagrams.net" pages="2">
|
||||
<diagram id="Ld0PZ8iOJT0iBC0hIplM" name="Page-2">
|
||||
<mxGraphModel dx="933" dy="648" grid="1" gridSize="10" guides="1" tooltips="1" connect="1" arrows="1" fold="1" page="1" pageScale="1" pageWidth="1169" pageHeight="827" math="0" shadow="0">
|
||||
<mxGraphModel dx="635" dy="431" grid="1" gridSize="10" guides="1" tooltips="1" connect="1" arrows="1" fold="1" page="1" pageScale="1" pageWidth="1169" pageHeight="827" math="0" shadow="0">
|
||||
<root>
|
||||
<mxCell id="0" />
|
||||
<mxCell id="1" parent="0" />
|
||||
<mxCell id="1rsUc46_5Y9y6vJJpw89-23" parent="1" style="rounded=1;whiteSpace=wrap;html=1;fillColor=#e1d5e7;strokeColor=#9673a6;fontFamily=Microsoft YaHei;" value="" vertex="1">
|
||||
<mxGeometry height="225" width="120" x="650" y="237.5" as="geometry" />
|
||||
</mxCell>
|
||||
<mxCell id="1rsUc46_5Y9y6vJJpw89-1" parent="1" style="rounded=1;whiteSpace=wrap;html=1;fillColor=#e1d5e7;strokeColor=#9673a6;fontFamily=Microsoft YaHei;" value="" vertex="1">
|
||||
<mxGeometry height="225" width="120" x="420" y="237.5" as="geometry" />
|
||||
</mxCell>
|
||||
<mxCell id="1rsUc46_5Y9y6vJJpw89-35" edge="1" parent="1" source="4BOI32kT3DeUbctDIWOm-3" style="rounded=0;orthogonalLoop=1;jettySize=auto;html=1;entryX=0.5;entryY=1;entryDx=0;entryDy=0;strokeColor=#FF9933;strokeWidth=2;dashed=1;exitX=0.565;exitY=0.918;exitDx=0;exitDy=0;exitPerimeter=0;" target="1rsUc46_5Y9y6vJJpw89-12">
|
||||
<mxGeometry relative="1" as="geometry">
|
||||
<Array as="points">
|
||||
<mxPoint x="559" y="480" />
|
||||
<mxPoint x="480" y="480" />
|
||||
</Array>
|
||||
<mxPoint x="550" y="320" as="sourcePoint" />
|
||||
<mxPoint x="540" y="220" as="targetPoint" />
|
||||
</mxGeometry>
|
||||
</mxCell>
|
||||
<mxCell id="1rsUc46_5Y9y6vJJpw89-23" parent="1" style="rounded=1;whiteSpace=wrap;html=1;fillColor=#e1d5e7;strokeColor=#9673a6;fontFamily=Microsoft YaHei;" value="" vertex="1">
|
||||
<mxGeometry height="225" width="120" x="650" y="237.5" as="geometry" />
|
||||
</mxCell>
|
||||
<mxCell id="4KGLoNyMlWUnwfG8zy26-1" parent="1" style="rounded=1;whiteSpace=wrap;html=1;fillColor=#e1d5e7;strokeColor=#9673a6;fontFamily=Microsoft YaHei;" value="" vertex="1">
|
||||
<mxGeometry height="180" width="120" x="210" y="260" as="geometry" />
|
||||
</mxCell>
|
||||
@@ -48,7 +58,7 @@
|
||||
<mxCell id="1rsUc46_5Y9y6vJJpw89-26" edge="1" parent="1" source="1rsUc46_5Y9y6vJJpw89-6" style="edgeStyle=orthogonalEdgeStyle;rounded=0;orthogonalLoop=1;jettySize=auto;html=1;exitX=0.5;exitY=1;exitDx=0;exitDy=0;entryX=0.5;entryY=0;entryDx=0;entryDy=0;strokeWidth=2;" target="1rsUc46_5Y9y6vJJpw89-12">
|
||||
<mxGeometry relative="1" as="geometry" />
|
||||
</mxCell>
|
||||
<mxCell id="1rsUc46_5Y9y6vJJpw89-6" parent="1" style="rounded=1;whiteSpace=wrap;html=1;fillColor=#d5e8d4;strokeColor=#82b366;fontSize=20;fontFamily=Microsoft YaHei;" value="FEC解码<div>丢包统计</div>" vertex="1">
|
||||
<mxCell id="1rsUc46_5Y9y6vJJpw89-6" parent="1" style="rounded=1;whiteSpace=wrap;html=1;fillColor=#ffe6cc;strokeColor=#d79b00;fontSize=20;fontFamily=Microsoft YaHei;" value="FEC解码<div>丢包统计</div>" vertex="1">
|
||||
<mxGeometry height="60" width="95" x="432.5" y="287.5" as="geometry" />
|
||||
</mxCell>
|
||||
<mxCell id="1rsUc46_5Y9y6vJJpw89-11" parent="1" style="rounded=1;whiteSpace=wrap;html=1;fillColor=#dae8fc;strokeColor=#6c8ebf;fontSize=20;fontFamily=Microsoft YaHei;" value="速率控制" vertex="1">
|
||||
@@ -63,7 +73,7 @@
|
||||
<mxCell id="1rsUc46_5Y9y6vJJpw89-27" edge="1" parent="1" source="1rsUc46_5Y9y6vJJpw89-18" style="edgeStyle=orthogonalEdgeStyle;rounded=0;orthogonalLoop=1;jettySize=auto;html=1;exitX=0.5;exitY=1;exitDx=0;exitDy=0;entryX=0.5;entryY=0;entryDx=0;entryDy=0;strokeWidth=2;" target="1rsUc46_5Y9y6vJJpw89-25">
|
||||
<mxGeometry relative="1" as="geometry" />
|
||||
</mxCell>
|
||||
<mxCell id="1rsUc46_5Y9y6vJJpw89-18" parent="1" style="rounded=1;whiteSpace=wrap;html=1;fillColor=#d5e8d4;strokeColor=#82b366;fontSize=20;fontFamily=Microsoft YaHei;" value="FEC解码<div>丢包统计</div>" vertex="1">
|
||||
<mxCell id="1rsUc46_5Y9y6vJJpw89-18" parent="1" style="rounded=1;whiteSpace=wrap;html=1;fillColor=#ffe6cc;strokeColor=#d79b00;fontSize=20;fontFamily=Microsoft YaHei;" value="FEC解码<div>丢包统计</div>" vertex="1">
|
||||
<mxGeometry height="60" width="95" x="662.5" y="287.5" as="geometry" />
|
||||
</mxCell>
|
||||
<mxCell id="1rsUc46_5Y9y6vJJpw89-19" edge="1" parent="1" source="1rsUc46_5Y9y6vJJpw89-12" style="rounded=0;orthogonalLoop=1;jettySize=auto;html=1;exitX=1;exitY=0.5;exitDx=0;exitDy=0;entryX=0;entryY=0.5;entryDx=0;entryDy=0;strokeWidth=2;" target="1rsUc46_5Y9y6vJJpw89-18">
|
||||
@@ -91,33 +101,35 @@
|
||||
<mxCell id="1rsUc46_5Y9y6vJJpw89-30" parent="1" style="rounded=1;whiteSpace=wrap;html=1;fillColor=#e1d5e7;strokeColor=#9673a6;fontSize=25;fontFamily=Microsoft YaHei;" value="" vertex="1">
|
||||
<mxGeometry height="100" width="230" x="380" y="100" as="geometry" />
|
||||
</mxCell>
|
||||
<mxCell id="1rsUc46_5Y9y6vJJpw89-31" edge="1" parent="1" source="1rsUc46_5Y9y6vJJpw89-18" style="rounded=0;orthogonalLoop=1;jettySize=auto;html=1;exitX=0.25;exitY=0;exitDx=0;exitDy=0;strokeColor=#FF9933;strokeWidth=2;dashed=1;entryX=0.75;entryY=1;entryDx=0;entryDy=0;" target="4BOI32kT3DeUbctDIWOm-3">
|
||||
<mxCell id="1rsUc46_5Y9y6vJJpw89-31" edge="1" parent="1" style="rounded=0;orthogonalLoop=1;jettySize=auto;html=1;strokeColor=#FF9933;strokeWidth=2;dashed=1;entryX=0.75;entryY=1;entryDx=0;entryDy=0;" target="4BOI32kT3DeUbctDIWOm-3">
|
||||
<mxGeometry relative="1" as="geometry">
|
||||
<Array as="points">
|
||||
<mxPoint x="576" y="320" />
|
||||
</Array>
|
||||
<mxPoint x="664" y="319" as="sourcePoint" />
|
||||
<mxPoint x="510" y="100" as="targetPoint" />
|
||||
</mxGeometry>
|
||||
</mxCell>
|
||||
<mxCell id="1rsUc46_5Y9y6vJJpw89-32" edge="1" parent="1" source="1rsUc46_5Y9y6vJJpw89-6" style="rounded=0;orthogonalLoop=1;jettySize=auto;html=1;exitX=1;exitY=0;exitDx=0;exitDy=0;strokeColor=#FF9933;strokeWidth=2;dashed=1;entryX=0.6;entryY=0.979;entryDx=0;entryDy=0;entryPerimeter=0;" target="4BOI32kT3DeUbctDIWOm-3">
|
||||
<mxCell id="1rsUc46_5Y9y6vJJpw89-32" edge="1" parent="1" style="rounded=0;orthogonalLoop=1;jettySize=auto;html=1;strokeColor=#FF9933;strokeWidth=2;dashed=1;endArrow=none;endFill=0;">
|
||||
<mxGeometry relative="1" as="geometry">
|
||||
<mxPoint x="852" y="378" as="sourcePoint" />
|
||||
<mxPoint x="440" y="100" as="targetPoint" />
|
||||
<Array as="points" />
|
||||
<mxPoint x="527" y="320" as="sourcePoint" />
|
||||
<mxPoint x="577" y="320" as="targetPoint" />
|
||||
</mxGeometry>
|
||||
</mxCell>
|
||||
<mxCell id="1rsUc46_5Y9y6vJJpw89-34" edge="1" parent="1" source="4BOI32kT3DeUbctDIWOm-3" style="rounded=0;orthogonalLoop=1;jettySize=auto;html=1;entryX=0.846;entryY=0.071;entryDx=0;entryDy=0;strokeColor=#FF9933;strokeWidth=2;dashed=1;entryPerimeter=0;exitX=0.25;exitY=1;exitDx=0;exitDy=0;" target="4KGLoNyMlWUnwfG8zy26-4">
|
||||
<mxCell id="1rsUc46_5Y9y6vJJpw89-34" edge="1" parent="1" style="rounded=0;orthogonalLoop=1;jettySize=auto;html=1;entryX=0.5;entryY=1;entryDx=0;entryDy=0;strokeColor=#FF9933;strokeWidth=2;dashed=1;" target="4KGLoNyMlWUnwfG8zy26-4">
|
||||
<mxGeometry relative="1" as="geometry">
|
||||
<mxPoint x="353" y="100" as="sourcePoint" />
|
||||
<Array as="points">
|
||||
<mxPoint x="270" y="480" />
|
||||
</Array>
|
||||
<mxPoint x="480" y="480" as="sourcePoint" />
|
||||
<mxPoint x="540" y="230" as="targetPoint" />
|
||||
</mxGeometry>
|
||||
</mxCell>
|
||||
<mxCell id="1rsUc46_5Y9y6vJJpw89-35" edge="1" parent="1" source="4BOI32kT3DeUbctDIWOm-3" style="rounded=0;orthogonalLoop=1;jettySize=auto;html=1;entryX=0.144;entryY=-0.004;entryDx=0;entryDy=0;strokeColor=#FF9933;strokeWidth=2;dashed=1;entryPerimeter=0;exitX=0.407;exitY=0.958;exitDx=0;exitDy=0;exitPerimeter=0;" target="1rsUc46_5Y9y6vJJpw89-12">
|
||||
<mxGeometry relative="1" as="geometry">
|
||||
<mxPoint x="380" y="70" as="sourcePoint" />
|
||||
<mxPoint x="540" y="220" as="targetPoint" />
|
||||
</mxGeometry>
|
||||
</mxCell>
|
||||
<mxCell id="4BOI32kT3DeUbctDIWOm-1" parent="1" style="text;html=1;whiteSpace=wrap;strokeColor=none;fillColor=none;align=center;verticalAlign=middle;rounded=0;fontSize=25;fontFamily=Microsoft YaHei;" value="控制器" vertex="1">
|
||||
<mxGeometry height="30" width="105" x="445" y="110" as="geometry" />
|
||||
</mxCell>
|
||||
<mxCell id="OVRyA5cAgbwWEsEiYZpN-1" edge="1" parent="1" source="4BOI32kT3DeUbctDIWOm-2" style="rounded=0;orthogonalLoop=1;jettySize=auto;html=1;exitX=0.5;exitY=1;exitDx=0;exitDy=0;entryX=0.5;entryY=0;entryDx=0;entryDy=0;dashed=1;strokeWidth=2;fillColor=#a0522d;strokeColor=#6D1F00;" target="4KGLoNyMlWUnwfG8zy26-1">
|
||||
<mxCell id="OVRyA5cAgbwWEsEiYZpN-1" edge="1" parent="1" source="4BOI32kT3DeUbctDIWOm-2" style="rounded=0;orthogonalLoop=1;jettySize=auto;html=1;exitX=0.5;exitY=1;exitDx=0;exitDy=0;entryX=0.5;entryY=0;entryDx=0;entryDy=0;dashed=1;strokeWidth=2;fillColor=#e51400;strokeColor=#B20000;" target="4KGLoNyMlWUnwfG8zy26-1">
|
||||
<mxGeometry relative="1" as="geometry" />
|
||||
</mxCell>
|
||||
<mxCell id="4BOI32kT3DeUbctDIWOm-2" parent="1" style="rounded=1;whiteSpace=wrap;html=1;fillColor=#f8cecc;strokeColor=#b85450;fontSize=20;fontFamily=Microsoft YaHei;" value="连接管理" vertex="1">
|
||||
@@ -126,13 +138,13 @@
|
||||
<mxCell id="4BOI32kT3DeUbctDIWOm-3" parent="1" style="rounded=1;whiteSpace=wrap;html=1;fillColor=#f8cecc;strokeColor=#b85450;fontSize=20;fontFamily=Microsoft YaHei;" value="编码管理" vertex="1">
|
||||
<mxGeometry height="40" width="95" x="505" y="150" as="geometry" />
|
||||
</mxCell>
|
||||
<mxCell id="OVRyA5cAgbwWEsEiYZpN-2" edge="1" parent="1" source="4BOI32kT3DeUbctDIWOm-2" style="rounded=0;orthogonalLoop=1;jettySize=auto;html=1;exitX=0.5;exitY=1;exitDx=0;exitDy=0;entryX=0.5;entryY=0;entryDx=0;entryDy=0;dashed=1;strokeWidth=2;fillColor=#a0522d;strokeColor=#6D1F00;" target="1rsUc46_5Y9y6vJJpw89-1">
|
||||
<mxCell id="OVRyA5cAgbwWEsEiYZpN-2" edge="1" parent="1" source="4BOI32kT3DeUbctDIWOm-2" style="rounded=0;orthogonalLoop=1;jettySize=auto;html=1;exitX=0.5;exitY=1;exitDx=0;exitDy=0;entryX=0.5;entryY=0;entryDx=0;entryDy=0;dashed=1;strokeWidth=2;fillColor=#e51400;strokeColor=#B20000;" target="1rsUc46_5Y9y6vJJpw89-1">
|
||||
<mxGeometry relative="1" as="geometry">
|
||||
<mxPoint x="473" y="220" as="sourcePoint" />
|
||||
<mxPoint x="330" y="330" as="targetPoint" />
|
||||
</mxGeometry>
|
||||
</mxCell>
|
||||
<mxCell id="OVRyA5cAgbwWEsEiYZpN-3" edge="1" parent="1" source="4BOI32kT3DeUbctDIWOm-2" style="rounded=0;orthogonalLoop=1;jettySize=auto;html=1;exitX=0.5;exitY=1;exitDx=0;exitDy=0;entryX=0.5;entryY=0;entryDx=0;entryDy=0;dashed=1;strokeWidth=2;fillColor=#a0522d;strokeColor=#6D1F00;" target="1rsUc46_5Y9y6vJJpw89-23">
|
||||
<mxCell id="OVRyA5cAgbwWEsEiYZpN-3" edge="1" parent="1" source="4BOI32kT3DeUbctDIWOm-2" style="rounded=0;orthogonalLoop=1;jettySize=auto;html=1;exitX=0.5;exitY=1;exitDx=0;exitDy=0;entryX=0.5;entryY=0;entryDx=0;entryDy=0;dashed=1;strokeWidth=2;fillColor=#e51400;strokeColor=#B20000;" target="1rsUc46_5Y9y6vJJpw89-23">
|
||||
<mxGeometry relative="1" as="geometry">
|
||||
<mxPoint x="593" y="190" as="sourcePoint" />
|
||||
<mxPoint x="450" y="300" as="targetPoint" />
|
||||
@@ -156,7 +168,7 @@
|
||||
<mxPoint x="270" y="120" as="targetPoint" />
|
||||
</mxGeometry>
|
||||
</mxCell>
|
||||
<mxCell id="7D4wQrk56QkGn_iMHcGr-4" edge="1" parent="1" style="rounded=0;orthogonalLoop=1;jettySize=auto;html=1;dashed=1;strokeWidth=2;fillColor=#a0522d;strokeColor=#6D1F00;">
|
||||
<mxCell id="7D4wQrk56QkGn_iMHcGr-4" edge="1" parent="1" style="rounded=0;orthogonalLoop=1;jettySize=auto;html=1;dashed=1;strokeWidth=2;fillColor=#e51400;strokeColor=#B20000;">
|
||||
<mxGeometry relative="1" as="geometry">
|
||||
<mxPoint x="200" y="130" as="sourcePoint" />
|
||||
<mxPoint x="270" y="130" as="targetPoint" />
|
||||
|
||||
Binary file not shown.
File diff suppressed because one or more lines are too long
|
Before Width: | Height: | Size: 345 KiB After Width: | Height: | Size: 345 KiB |
@@ -373,6 +373,15 @@
|
||||
organization = {Aliyun}
|
||||
}
|
||||
|
||||
@onlin{aliyun_sla,
|
||||
autho = {{Aliyun}},
|
||||
title = {阿里云云企业网计费说明},
|
||||
year = {2026},
|
||||
url = {https://help.aliyun.com/zh/cen/product-overview/billing-rules},
|
||||
urldate = {2026-5-27},
|
||||
organization = {Aliyun}
|
||||
}
|
||||
|
||||
@article{roy2009relayplacement,
|
||||
title={On the placement of infrastructure overlay nodes},
|
||||
author={Roy, Sabyasachi and Pucha, Himabindu and Zhang, Zheng and Hu, Y Charlie and Qiu, Lili},
|
||||
|
||||
94
调研.md
94
调研.md
@@ -1,94 +0,0 @@
|
||||
我在进行一项针对RTXGI中DDGI方法的probe的放置进行优化的工作，用pytorch复刻DDGI可微管线，以最小化着色点处间接光照的mse为目标训练优化得到最佳的probe位置参数。请帮我查找有无相似或者相关的工作。
|
||||
|
||||
我查到的结果是：**有不少“probe placement / adaptive probes / differentiable lighting optimization”的相关工作，但我没有找到与你描述完全同构的工作**，即“用 PyTorch 复刻 DDGI/RTXGI 的可微管线，把 probe 位置作为连续可训练参数，并以 shading point 处间接光照 MSE 为目标端到端优化”。最接近的是下面几类。
|
||||
|
||||
## 1. 最接近：light / radiance probe placement 优化
|
||||
|
||||
**Vardis et al., “Illumination-driven Light Probe Placement”, Eurographics 2021**
|
||||
这篇非常接近你的目标函数思想。它先生成一个高密度 light probe 集合，再在 evaluation points 上计算参考 radiance，然后迭代删除对重建误差影响最小的 probe，以保留对间接光照分布最重要的 probe。它的目标明确是“preserves the indirect illumination distribution”，并且用 evaluation points 上的 radiance error 指导简化。区别是：它是**离散 pruning / graph simplification**，不是可微优化；也不是专门针对 DDGI/RTXGI 的 probe gather 与 visibility encoding。([graphics.cs.aueb.gr][1])
|
||||
|
||||
**Wang et al., “Fast Non-uniform Radiance Probe Placement and Tracing”, I3D 2019**
|
||||
这篇是自动非均匀 probe placement。它用 3D scene skeleton 和 gradient-descent-based refinement 来保证几何覆盖、减少 grazing angle sampling bias，并通过非均匀 probe 结构改善 tracing 性能。与 DDGI 很相关，因为 NVIDIA DDGI 文档和 presentation 也把它列为 probe placement 的相关工作。区别是它主要围绕**几何/可见性采样覆盖与运行时 tracing 结构**，不是直接最小化 shading point 的 indirect lighting MSE，也不是 PyTorch 可微端到端训练。([cs.mcgill.ca][2])
|
||||
|
||||
**Chajdas et al., “Assisted Environment Map Probe Placement”, SIGRAD 2011**
|
||||
这是较早的 artist-assisted probe placement。它从预计算 irradiance volume 中找 irradiance gradient field 的重要位置，再聚类候选 probe，目的是减少手工放置 environment map probes 的工作量。它显式提到 probe placement 在游戏开发中 tedious and time-consuming，并通过候选点辅助 artist。区别是它针对 environment map/reflection probes，更偏启发式和工具流，不是 DDGI，也不是可微优化。
|
||||
|
||||
**Teuber et al., “Geometry-based light probe placement for realtime lighting in Gaussian Splatting environments”, The Visual Computer 2025**
|
||||
这是较新的 light probe placement 工作，针对 AR/VR/3D Gaussian Splatting 环境，提出 realtime geometry-based probe placement，并与 ground-truth ray tracing 比较。它强调“careful placement of a minimal number of probes”可以复现复杂环境中的 realistic lighting。区别是它是 geometry-based realtime placement，不是 DDGI 的可微 MSE 训练。([Springer][3])
|
||||
|
||||
**“Improving Probe and Surfel Placement for Dynamic Diffuse Global Illumination”, 2024 MSc thesis**
|
||||
这篇直接针对 DDGI / probe-and-surfel placement。它把原本 dense regular grid 改成基于 octree 的层次化 probe 分布，根据 probe 周围几何复杂度自适应放置 probe，以减少 probe 数量并保持视觉质量。区别是它仍然是**几何复杂度驱动的 adaptive placement**，不是把 probe 坐标作为可训练参数进行 differentiable optimization。
|
||||
|
||||
## 2. DDGI / RTXGI 本身及其扩展
|
||||
|
||||
**Majercik et al., “Dynamic Diffuse Global Illumination with Ray-Traced Irradiance Fields”, JCGT 2019**
|
||||
DDGI 原始工作本身强调 uniform-grid probe placement 已经可以使用，甚至说 naive uniform-grid probe placement 可避免大量传统手工 probe placement 问题。它也明确提到 probe count/density 比 probe angular resolution 更影响结果，低 probe density 会导致 subtle light leaking；并把 optimized probe selection / adaptive probe updates 留作 future work。你的工作可以直接把这里的 future direction 推进一步：不是简单 selection/update，而是对 probe 位置做可微优化。([jcgt.org][4])
|
||||
|
||||
**Majercik et al., “Scaling Probe-Based Real-Time Dynamic Global Illumination for Production”, 2021**
|
||||
这是 RTXGI 生产化方向的扩展，贡献包括 self-shadow bias、probe state machine、cascaded volumes、transition heuristics 等，目标是改进质量、性能、内存和 artist control。它与 RTXGI/DDGI 工程实现高度相关，但核心不在连续 probe placement 优化。([arXiv][5])
|
||||
|
||||
**Adaptive Dynamic Global Illumination, 2023**
|
||||
这篇做的是 DDGI 的 adaptive extension，重点是在检测到 lighting/geometry/radiosity 动态变化的区域更高效地放置/分配 samples，并更新 irradiance/visibility cache。它更接近“probe update / sampling budget allocation”，不是直接优化 probe 坐标。([arXiv][6])
|
||||
|
||||
**Importance-Based Ray Strategies for DDGI, I3D 2023**
|
||||
这篇 IS-DDGI 针对的是 DDGI 中 probe ray tracing 的 ray allocation，用 MIS 和 temporal/history 分析来把 ray 资源分配到更重要的地方，报告了 DDGI 总时间和 probe ray tracing 时间的加速。它与你的工作互补：它优化的是**每个 probe 如何发 ray**，你优化的是**probe 放在哪里**。([allenliuzihao.github.io][7])
|
||||
|
||||
**Dynamic Diffuse Global Illumination Resampling, 2021**
|
||||
这篇把 screen-space reservoir resampling 和 sparse world-space probes 结合，用于提高 diffuse transport 的 sample efficiency。它和 DDGI/probe representation 相关，但不是 probe placement 优化。([arXiv][8])
|
||||
|
||||
## 3. 可微渲染 / 可微 GI 优化方向
|
||||
|
||||
**Lipp et al., “View-Independent Adjoint Light Tracing for Lighting Design Optimization”, TOG 2024**
|
||||
这是最值得你在“可微优化目标”层面对比的工作。它通过 differentiable light tracing 连续优化 luminaire arrangement，可以直接在 3D scene 上定义 illumination target，而不是只在 image-space 定义 loss，并且考虑 global illumination。它优化的是 light source 的位置、方向、强度等，不是 probe 位置；但它与你的共同点是：**以场景中表面/空间上的照明误差为目标，优化连续空间中的位置参数**。([arXiv][9])
|
||||
|
||||
**Mitsuba differentiable rendering / inverse rendering 系列**
|
||||
Mitsuba 的可微渲染文档展示了如何枚举并优化 scene parameters，例如材质、发光体 radiance、mesh vertex positions 等。它是方法论上的背景，但没有直接处理 DDGI probe placement。([mitsuba2.readthedocs.io][10])
|
||||
|
||||
**Inverse Global Illumination using a Neural Radiometric Prior, SIGGRAPH 2023**
|
||||
这篇关注 inverse rendering under global illumination，用 neural radiometric prior 避免对大量 path integrals 直接 auto-diff，降低噪声和计算成本。它与“可微 GI”相关，但目标是恢复 scene parameters，不是优化 irradiance probes。([arXiv][11])
|
||||
|
||||
**Differentiable Light Transport with Gaussian Surfels via Adapted Radiosity, 2025**
|
||||
这篇把 Gaussian surfels 和 radiosity-style differentiable light transport 结合，推导 backward pass，用于 relighting 和 geometry reconstruction。它说明近年的趋势是把 GI 近似结构本身做成可微计算图；但它不是 DDGI probe placement。([arXiv][12])
|
||||
|
||||
## 4. 可以怎么定位你的创新点
|
||||
|
||||
你的工作最容易和现有工作的差异表述为：
|
||||
|
||||
**已有 probe placement 工作大多是启发式、几何驱动、illumination-driven pruning、artist-assisted 或 adaptive sampling；而你的方法把 DDGI/RTXGI 的 probe gather、visibility weighting、interpolation 等过程复刻为可微管线，直接对最终 shading point 的 indirect illumination MSE 反传，优化 probe 的连续位置参数。**
|
||||
|
||||
更具体地说：
|
||||
|
||||
| 方向 | 代表工作 | 和你工作的关系 | 关键差异 |
|
||||
| ------------------------------------ | ---------------------------- | ------------- | -------------------------------------------------- |
|
||||
| DDGI uniform grid | Majercik et al. 2019 / RTXGI | 你的基础算法 | 它强调 uniform grid 可用，未做端到端位置优化 |
|
||||
| Non-uniform placement | Wang et al. 2019 | 很相关 | 几何/visibility 驱动，不是 indirect-lighting MSE 可微训练 |
|
||||
| Illumination-driven pruning | Vardis et al. 2021 | 最接近 loss 思想 | 删除 probe 的离散简化，不是连续坐标优化 |
|
||||
| Artist-assisted placement | Chajdas et al. 2011 | 早期相关 | 工具流/候选点，不是 DDGI |
|
||||
| DDGI adaptive sampling/update | ADGI, IS-DDGI | 与 DDGI 性能优化互补 | 优化 sample/ray/update budget，不优化 probe 坐标 |
|
||||
| Differentiable lighting optimization | Lipp et al. 2024 | 方法论相似 | 优化 luminaire，不优化 probe cache / DDGI representation |
|
||||
|
||||
## 5. 结论
|
||||
|
||||
我建议你重点引用并对比这几篇：
|
||||
|
||||
1. **DDGI 原始论文**：说明 uniform grid baseline、probe density 影响、以及 adaptive/optimized probe selection 的开放性。
|
||||
2. **Wang et al. 2019**：代表非均匀 radiance probe placement。
|
||||
3. **Vardis et al. 2021**：代表以 illumination/radiance error 为目标的 probe set simplification，是最接近你的“用照明误差指导 probe 配置”的工作。
|
||||
4. **Chajdas et al. 2011**：代表早期 assisted probe placement。
|
||||
5. **Lipp et al. 2024**：代表可微 lighting design / continuous spatial parameter optimization。
|
||||
6. **ADGI / IS-DDGI**：说明 DDGI 后续优化主要集中在 adaptive sampling、ray allocation、update 策略，而不是可微 probe coordinate optimization。
|
||||
|
||||
从我查到的公开资料看，你的题目有比较明确的新意：**把 probe placement 从启发式/离散选择问题改写成 DDGI 渲染误差上的端到端连续优化问题**。
|
||||
|
||||
[1]: https://graphics.cs.aueb.gr/graphics/docs/papers/Illumination_driven_Light_Probe_Placement.pdf "Illumination-driven Light Probe Placement"
|
||||
[2]: https://www.cs.mcgill.ca/~ywang411/ProjectPage/radiancei3d2019.md.html "www.cs.mcgill.ca"
|
||||
[3]: https://link.springer.com/article/10.1007/s00371-025-04124-z "Geometry-based light probe placement for realtime lighting in Gaussian Splatting environments | The Visual Computer | Springer Nature Link"
|
||||
[4]: https://www.jcgt.org/published/0008/02/01/paper-lowres.pdf "Dynamic Diffuse Global Illumination with Ray-Traced Irradiance Fields"
|
||||
[5]: https://arxiv.org/abs/2009.10796 "[2009.10796] Scaling Probe-Based Real-Time Dynamic Global Illumination for Production"
|
||||
[6]: https://arxiv.org/abs/2301.05125 "[2301.05125] Adaptive Dynamic Global Illumination"
|
||||
[7]: https://allenliuzihao.github.io/IS-DDGI/ "Importance-Based Ray Strategies for Dynamic Diffuse Global Illumination"
|
||||
[8]: https://arxiv.org/abs/2108.05263 "[2108.05263] Dynamic Diffuse Global Illumination Resampling"
|
||||
[9]: https://arxiv.org/html/2310.02043v2 "View-Independent Adjoint Light Tracing for Lighting Design Optimization"
|
||||
[10]: https://mitsuba2.readthedocs.io/en/latest/src/inverse_rendering/diff_render.html "Differentiable rendering — mitsuba2 0.1.dev0 documentation"
|
||||
[11]: https://arxiv.org/abs/2305.02192 "[2305.02192] Inverse Global Illumination using a Neural Radiometric Prior"
|
||||
[12]: https://arxiv.org/abs/2509.18497 "[2509.18497] Differentiable Light Transport with Gaussian Surfels via Adapted Radiosity for Efficient Relighting and Geometry Reconstruction"
|
||||
Reference in New Issue
Block a user