重写前总结
This commit is contained in:
Binary file not shown.
BIN
bachelor-thesis拷貝.pdf
Normal file
BIN
bachelor-thesis拷貝.pdf
Normal file
Binary file not shown.
@@ -11,7 +11,7 @@
|
||||
|
||||
对于跨区域的实时音视频通话业务，通话服务的服务商需要建立一条连接通话用户两端的双向连接。如图\ref{fig:云网络转发拓扑}，通常，通话服务商选择使用云网络为进行通话的用户建立连接。通话的用户各自选择距离自己最近云网络接入网关接入云网络，数据经由云网关进入云网络进行转发，再从接收端用户接入的云网关发至接收端用户。对于实时通信业务来说，传输的延迟以及传输视频的卡顿率极大地影响用户体验（Quality of Experience, QoE）\cite{kataria2024titan}，因此为了维持优秀的用户体验，云网络提供商必须确保云网络提供低延迟、低丢包率的转发链路。
|
||||
|
||||
\begin{figure}[htbp]
|
||||
\begin{figure}[H]
|
||||
\centering
|
||||
\includegraphics[width=\linewidth]{cloud_network_rtc.drawio.pdf}
|
||||
\caption{云网络为音视频通话提供服务}
|
||||
|
||||
@@ -10,7 +10,7 @@
|
||||
|
||||
覆盖网络（Overlay Network）是一种广泛应用于云网络结构的网络虚拟化设计，它基于物理的底层网络（Underlay Network）上通过对资源的逻辑整合而形成的逻辑网络。如图\ref{fig:overlay网络示意}，覆盖网络在已有的硬件网络上构建一个虚拟的网络层，使得使用云网络服务的企业和用户可以获得更灵活与稳定的虚拟网络连接。近年来，企业对虚拟化和云网络的需求不断增长，因而将分布在全球各地的云资源进行互联的需求也不断提升。不同的云资源所处的基础设施可能出现异构的情况，使用覆盖网络可以有效地将这些区别隐藏在相同的虚拟网络层抽象之后，极大地简化了部署和配置网络的成本。
|
||||
|
||||
\begin{figure}[htbp]
|
||||
\begin{figure}[H]
|
||||
\centering
|
||||
\includegraphics[width=\linewidth]{overlay_network_from_underlay.drawio.pdf}
|
||||
\caption{覆盖网络基于底层网络，将各类物理网络资源抽象为一个虚拟的覆盖网络}
|
||||
@@ -29,7 +29,7 @@ Geneve（Generic Network Virtualization Encapsulation，通用虚拟化网络封
|
||||
|
||||
低质量的互联网链路由于负载较大出现拥塞或部分设备运行故障，容易出现丢包或者延迟波动。在这些低质量的链路上进行传输时，即使链路还有可用的传输带宽，也会出现丢包或是延迟波动。即使TCP\cite{rfc9293tcp}等可靠传输协议通过重传确保了所有数据都能可到送达，但性能较差。这是因为TCP协议依靠超时重传来在确保所有数据都最终送达至接收端，即使使用了基于重复ACK的快速重传机制，如图\ref{fig:TCP丢包恢复缓慢}，恢复单个丢失的包也至少要经历接收端检测丢包——请求发送端重传——发送端重传包送达恢复的过程，至少需要一个往返时延（Round Trip Time, RTT）才能恢复。对于一条在云网络中的跨域链路，往返时延可能达到\SI{300}{ms}或更长，如此缓慢的丢包恢复不仅会阻塞后续数据包的发送，也会极大地影响实时媒体服务如影视直播、视频通话等应用的用户体验。
|
||||
|
||||
\begin{figure}[htbp]
|
||||
\begin{figure}[H]
|
||||
\centering
|
||||
\includegraphics[width=\linewidth]{tcp_slow_recovery.drawio.pdf}
|
||||
\caption{即使启用了快速重传机制，TCP仍旧需要一个往返时延才能恢复丢包}
|
||||
@@ -44,7 +44,7 @@ Geneve（Generic Network Virtualization Encapsulation，通用虚拟化网络封
|
||||
|
||||
早期的FEC工作主要通过对时间敏感的数据包进行简单地复制和多次传输进行错误恢复。如图\ref{fig:早期FEC}所示，通过将每个数据包复制多份，每次发送新的数据的同时，在同一个数据包中同时捎带发送之前已经发送过的一些数据包，这样可以在一部分数据包丢失的同时仍旧确保接收端收到了所有数据。Bolot等人\cite{bolot1999adaptivefec}基于此思路提出可以利用实时语音通话应用中已经存在的平均丢包率监控字段对传输链路的丢包模式和丢包律进行估计，从而动态地选重复发送包的发送间隔和次数，优化通话用户的用户体验。之后Gandikota等人\cite{gandikota2008multipathfec}在此基础上提出可以通过多路径传输，进一步提升冗余包和原始数据包中至少有一个送达的概率。Gandikota等人在工作中提出通过估算网络中的丢包率，动态地调整冗余参数以实现对语音流中的重要子流进行保护，同时再将编码后的数据包以及其他次要子流经过两个最大程度节点不相交路径在网络上与重要数据流分开传输，以降低数据传输丢失概率、提升用户体验。Huang等人\cite{huang2010skypefec}通过测量Skype应用在不同丢包网络条件下的行为，印证了相关冗余编码在提升实时语音通话用户体验方面的积极作用。
|
||||
|
||||
\begin{figure}[htbp]
|
||||
\begin{figure}[H]
|
||||
\centering
|
||||
\includegraphics[width=\linewidth]{fec_copy_based.drawio.pdf}
|
||||
\caption{早期FEC工作将冗余信息附加在后续发出的包中进行发送}
|
||||
@@ -55,7 +55,7 @@ Geneve（Generic Network Virtualization Encapsulation，通用虚拟化网络封
|
||||
|
||||
通过重复发送数据包的方式添加冗余虽然简单，但是会带来较高的冗余开销，为了提高冗余信息的恢复效率，研究者们进一步提出了基于分组冗余码的前项纠错机制。XOR码和R-S码是较为主要的冗余纠错恢复机制。如图\ref{fig:分组码示意}，这两种编码都是线性分组码，将原始数据分为$n$个数据包一组，对于每一组数据再加入$k$个冗余数据包并将$n + k$个数据一并发送，接收端同样以组为单位进行丢包的恢复。
|
||||
|
||||
\begin{figure}[htbp]
|
||||
\begin{figure}[H]
|
||||
\centering
|
||||
\includegraphics[width=.7\linewidth]{grouped_code.drawio.pdf}
|
||||
\caption{分组码为$n$个数据包附加$k$个冗余包}
|
||||
@@ -64,11 +64,11 @@ Geneve（Generic Network Virtualization Encapsulation，通用虚拟化网络封
|
||||
|
||||
在XOR编码中，$n$可以为任意值，而固定$k = 1$，冗余包通过将所有组内的数据包按位进行异或运算得到。如果接收端只接收到了一组数据包共$n + 1$个包中的$n$个，则丢失的包可以通过对已经接收到的包按位进行异或运算恢复得到。XOR编码可以在一组数据共$n + 1$个包丢失任意一个时通过剩余的$n$个包将丢失的包恢复，但是如果丢失了两个或更多包，则完全不能恢复丢失的数据。XOR码的计算简单，冗余包生成和丢失数据包恢复都只需要使用异或运算即可完成，运算开销小，但是只能恢复固定模式的少量丢包，面对组内多个丢包的情况效果有限。
|
||||
|
||||
为应对XOR编码的缺点，在1960年，Reed与Solomon提出了R-S编码\cite{reed1960rscode}，通过对一组共$n$个数据包在有限域上进行运算，计算出$k$个额外的冗余包。R-S编码保证，对于$n$个数据包和$k$个计算出的冗余包共$n + k$个数据包，接收端只要接收到了其中的任意$n$个，就能完整地恢复出所有的原始数据包。相较于XOR编码，R-S编码的恢复能力有较大的提升，能够在同一个编码组里出现较多的丢包的恶劣情况下进行恢复，从能承受最多1个丢包增加至能承受最多$k$个丢包。RS编码被广泛用于传输音视频流媒体，Lin等人\cite{lin2012apfec}通过在无线局域网链路上对数据包进行FEC编码，提升了视频传输的效果。更多的其他研究者选择结合视频编码自身以帧和画面组（Group of Pictures, GOP）进行编码的特性，进行FEC编码以提升视频传输质量。Shih等人\cite{shih2016framefec}通过对视频中的关键帧进行FEC保护，提升了关键帧以及后续多个依赖关键帧的画面质量，有效提升了视频传输质量。Xiao等人\cite{xiao2012subgopfec}使用贪心算法动态决定每个冗余组需要包含的帧数量及冗余度，在不牺牲延迟的情况下提升了视频质量。Yang等人\cite{yang2003qualitygopfec}通过估算不同的数据包丢包后对解码视频的影响时间，动态选择FEC参数以提升用户的视频观看体验。Kurdoglu等人\cite{kurdoglu2017fecwithquantation}则将FEC冗余率与编码帧率、编码量化参数及编码方式等联合优化，以最佳化用户观看体验而非追求更高的单一量化指标。总体而言，XOR码和R-S编码相比简单复制冗余具有更高的冗余恢复效率，因此被广泛应用于实时音视频传输等场景。
|
||||
为应对XOR编码的缺点，在1960年，Reed与Solomon提出了R-S编码\cite{reed1960rscode}。R-S编码保证，对于$n$个数据包和$k$个在有限域上计算出的冗余包共$n + k$个数据包，接收端只要接收到了其中的任意$n$个，就能完整地恢复出所有的原始数据包。相较于XOR编码，R-S编码的恢复能力有较大的提升，能够在同一个编码组里出现较多的丢包的恶劣情况下进行恢复，从能承受最多1个丢包增加至能承受最多$k$个丢包。RS编码被广泛用于传输音视频流媒体，Lin等人\cite{lin2012apfec}通过在无线局域网链路上对数据包进行FEC编码，提升了视频传输的效果。更多的其他研究者选择结合视频编码自身以帧和画面组（Group of Pictures, GOP）进行编码的特性，进行FEC编码以提升视频传输质量。Shih等人\cite{shih2016framefec}通过对视频中的关键帧进行FEC保护，提升了关键帧以及后续多个依赖关键帧的画面质量，有效提升了视频传输质量。Xiao等人\cite{xiao2012subgopfec}使用贪心算法动态决定每个冗余组需要包含的帧数量及冗余度，在不牺牲延迟的情况下提升了视频质量。Yang等人\cite{yang2003qualitygopfec}通过估算不同的数据包丢包后对解码视频的影响时间，动态选择FEC参数以提升用户的视频观看体验。Kurdoglu等人\cite{kurdoglu2017fecwithquantation}则将FEC冗余率与编码帧率、编码量化参数及编码方式等联合优化，以最佳化用户观看体验而非追求更高的单一量化指标。总体而言，XOR码和R-S编码相比简单复制冗余具有更高的冗余恢复效率，因此被广泛应用于实时音视频传输等场景。
|
||||
|
||||
然而，R-S编码通常以数据组为单位进行编码与恢复，其恢复能力依赖于单个编码组中的丢包数量不超过冗余包数量$k$。实际网络上的丢包并不是独立的，在部分链路上可能由于链路拥塞、无线信号衰减等原因出现连续的突发丢包。在这些场景下如果使用R-S编码进行丢包恢复，为了能成功恢复数据，必须按照最差的可能情况决定$n$与$k$的相对取值，而这通常使得算法对网络的状况产生过于悲观的估计，为了应对短暂出现的连续丢包而将$k$的值始终维持在较高水平。这导致在其他未遭遇连续丢包的数据组中，大量的冗余包被浪费，占用了传输带宽而未能有效地提升传输质量。为解决此问题，研究者们提出了交织（Interleave）技术。如图\ref{fig:交织示意图}所示，交织技术将多个编码组交替地在网络上发出，使得当传输过程中出现了连续丢包时，丢包被分散在多个不同的编码组中分别应对，使得单个编码组需要应对的丢包比例大大下降，从而降低了整体需要的冗余率。
|
||||
|
||||
\begin{figure}[htbp]
|
||||
\begin{figure}[H]
|
||||
\centering
|
||||
\includegraphics[width=.7\linewidth]{interleaved_fec.drawio.pdf}
|
||||
\caption{交织编码示意}
|
||||
@@ -83,7 +83,7 @@ Liu等人\cite{liu2017opticalinterleave}提出了一种在开放光通信场景
|
||||
|
||||
XOR、R-S等分组码结合交织已经能较好地应对网络中的丢包问题，但是这些编码仍旧不能满足一些实时性需求高的应用。如图\ref{fig:RS编码等待恢复延迟}，由于分组码的冗余包通常是通过对所有的组内的数据包进行计算得到，因此冗余信息必须在所有数据包已经发出后才能够计算并在网络中发出，这导致如果接收端在接收数据包时如果检测到了丢包且需要利用冗余信息进行恢复，为了保证数据包数据包按发送顺序连续交付至上层应用，接收端通常需要暂停后续数据的解码输出，直至对应的冗余包到达并完成恢复。由此产生的恢复等待时间会显著增加端到端时延。对于实时性要求较高的应用，即使最终能够恢复出丢失数据，其对应的视频帧或音频数据也可能已经错过播放时限，从而无法有效改善用户体验。
|
||||
|
||||
\begin{figure}[htbp]
|
||||
\begin{figure}[H]
|
||||
\centering
|
||||
\includegraphics[width=.7\linewidth]{rs_code_slow_recovery.drawio.pdf}
|
||||
\caption{分组码需要暂停解码输出等待冗余包到来才能恢复丢包并继续解码过程}
|
||||
@@ -100,21 +100,14 @@ XOR、R-S等分组码结合交织已经能较好地应对网络中的丢包问
|
||||
|
||||
软件定义网络（Software defined networking, SDN）指的是将网络中各个转发设备的数据平面与控制平面解耦，集中进行控制的网络。SDN网络大大简化了网络的管理和控制流程。对于跨域云网络及其中部署的虚拟网络，尽管有部分的网络设备由SDN统一控制，但是各个设备间的跨域互联通常仍仍旧由传统的网络设备提供连接，形成了混合形软件定义网络（hybrid SDN network），如图\ref{fig:混合SDN网络}\cite{amin2018hybridsdnsurvey}。
|
||||
|
||||
\begin{figure}[htbp]
|
||||
\begin{figure}[H]
|
||||
\centering
|
||||
\includegraphics[width=.8\linewidth]{sdn_overview.drawio.pdf}
|
||||
\caption{混合SDN网络}
|
||||
\label{fig:混合SDN网络}
|
||||
\end{figure}
|
||||
|
||||
随着云计算与实时互联网应用的发展，现代云网络中的跨域流量规模持续增长，用户对于传输质量与服务稳定性的要求也不断提高。在跨地域云网络场景中，不同节点之间通常并非只存在单一的物理连接路径，而是可能存在多种不同质量、不同价格的传输链路。例如，许多云服务商同时提供公网链路互联与专线链路互联\cite{azure_bandwidthcost,gcp_bandwidthcost}。其中，专线链路通常具有更稳定的传输性能、更低的丢包率与时延，但部署成本与使用成本较高；而公网链路虽然成本较低，却容易受到网络拥塞、跨域路由波动等因素影响，出现高丢包、时延抖动等问题\cite{kataria2024titan}。与此同时，链路质量与网络负载往往还会随着时间动态变化，使得不同链路在不同时间段内呈现出不同的性能特征。为了进一步观察跨域公网链路的动态变化情况，本文作者对某企业使用的一条跨国公网链路进行了持续一天的测量，统计了链路时延与丢包率随时间的变化情况。如图\ref{fig:跨国公网链路随时间变化}所示，该公网链路在一天内存在明显的性能波动现象，其中丢包率在部分时间段内显著升高，并伴随着时延抖动的增加。这表明公网链路的传输质量具有较强的时间相关性与动态变化特征，链路状态可能随着网络拥塞、跨域路由调整以及区域性流量变化而快速变化。
|
||||
|
||||
\begin{figure}[htbp]
|
||||
\centering
|
||||
\includegraphics[width=.8\linewidth]{hongkong-jinan.pdf}
|
||||
\caption{某企业跨国公网链路RTT与丢包率在一天内的变化}
|
||||
\label{fig:跨国公网链路随时间变化}
|
||||
\end{figure}
|
||||
随着云计算与实时互联网应用的发展，现代云网络中的跨域流量规模持续增长，用户对于传输质量与服务稳定性的要求也不断提高。在跨地域云网络场景中，不同节点之间通常并非只存在单一的物理连接路径，而是可能存在多种不同质量、不同价格的传输链路。例如，许多云服务商同时提供公网链路互联与专线链路互联\cite{azure_bandwidthcost,gcp_bandwidthcost}。其中，专线链路通常具有更稳定的传输性能、更低的丢包率与时延，但部署成本与使用成本较高；而公网链路虽然成本较低，却容易受到网络拥塞、跨域路由波动等因素影响，出现高丢包、时延抖动等问题\cite{kataria2024titan}。与此同时，链路质量与网络负载往往还会随着时间动态变化，使得不同链路在不同时间段内呈现出不同的性能特征。
|
||||
|
||||
在这种场景下，仅依赖传统网络静态地选择固定传输路径，难以同时满足不同业务对吞吐、时延、可靠性以及成本控制等方面的需求。相比之下，基于SDN的覆盖网络能够通过集中控制的方式，对网络中的链路状态、节点负载以及业务需求进行统一管理，并动态地对流量进行调度与路径选择，从而更灵活地利用不同网络资源，在传输性能、可靠性与成本之间取得平衡。因此，如何基于覆盖网络与SDN架构实现高效的网络调度，逐渐成为跨域云网络与实时媒体传输领域的重要研究方向。
|
||||
|
||||
@@ -132,13 +125,14 @@ XOR、R-S等分组码结合交织已经能较好地应对网络中的丢包问
|
||||
|
||||
现有FEC相关工作大多将发送端到接收端之间的网络路径视为一条整体链路，并基于端到端测得的丢包率、突发丢包长度或应用层质量指标选择冗余策略。这种建模方式适用于端到端路径不可控的普通互联网应用，但并不完全适用于跨域云网络。云网络中的一条端到端连接通常由多个云节点接力转发形成，逻辑上的端到端路径可以拆分为若干相邻云节点之间的链路片段。不同片段的物理距离、跨运营商情况和跨境路由情况不同，其丢包率和时延抖动可能存在显著差异。
|
||||
|
||||
本文的测量显示，端到端质量下降并不意味着路径上的每一段公网链路都同样低质。相反，许多域内或近距离公网链路的质量较高，丢包率低且时延稳定；端到端丢包往往集中出现在少数跨域或跨境链路片段上。图\ref{fig:公网链路分段质量差异}展示了这一现象：在节点分布于全球多地的云网络中，不同链路片段的质量差异明显，低质量片段通常只占所有互联路径的一部分。
|
||||
本文的测量显示，端到端质量下降并不意味着路径上的每一段公网链路都同样低质。相反，许多域内或近距离公网链路的质量较高，丢包率低且时延稳定；端到端丢包往往集中出现在少数跨域或跨境链路片段上。图\ref{fig:公网链路分段质量差异}展示了这一现象：在节点分布于全球多地的真实云网络中，不同链路片段的质量差异明显，低质量片段通常只占所有互联路径的一部分。
|
||||
|
||||
\begin{figure}[htbp]
|
||||
\begin{figure}[H]
|
||||
\centering
|
||||
\fbox{\parbox{0.88\linewidth}{\centering\small\vspace{2em}%
|
||||
图片占位：展示一条端到端云网络路径被拆分为多个链路片段，并对比各片段的丢包率或RTT抖动。图中应突出域内/近距离片段质量较好，而跨域/跨境片段质量明显下降。%
|
||||
\vspace{2em}}}
|
||||
% \fbox{\parbox{0.88\linewidth}{\centering\small\vspace{2em}%
|
||||
% 图片占位：展示一条端到端云网络路径被拆分为多个链路片段，并对比各片段的丢包率或RTT抖动。图中应突出域内/近距离片段质量较好，而跨域/跨境片段质量明显下降。%
|
||||
% \vspace{2em}}}
|
||||
\includegraphics[width=.8\linewidth]{cross_region_low_quality.jpg}
|
||||
\caption{跨域云网络路径中的链路分段质量差异}
|
||||
\label{fig:公网链路分段质量差异}
|
||||
\end{figure}
|
||||
@@ -153,11 +147,12 @@ XOR、R-S等分组码结合交织已经能较好地应对网络中的丢包问
|
||||
|
||||
这一假设在成本优化场景下会带来明显限制。实时音视频等业务的用户访问量具有明显的时间规律，用户高峰时段通常也是区域网络负载较高、跨域公网质量更容易下降的时段。即系统最希望利用低成本公网分担流量的时间，往往正是公网链路质量最不稳定的时间。图\ref{fig:用户高峰与公网劣化重合}展示了用户使用量与公网链路质量变化之间的关系：公网链路丢包或时延抖动升高的时段，与用户流量高峰存在较强重合。
|
||||
|
||||
\begin{figure}[htbp]
|
||||
\begin{figure}[H]
|
||||
\centering
|
||||
\fbox{\parbox{0.88\linewidth}{\centering\small\vspace{2em}%
|
||||
图片占位：展示用户使用量随时间变化与公网链路质量随时间变化的对比。图中应突出用户流量高峰与公网丢包率升高或RTT抖动增加的时段重合。%
|
||||
\vspace{2em}}}
|
||||
% \fbox{\parbox{0.88\linewidth}{\centering\small\vspace{2em}%
|
||||
% 图片占位：展示用户使用量随时间变化与公网链路质量随时间变化的对比。图中应突出用户流量高峰与公网丢包率升高或RTT抖动增加的时段重合。%
|
||||
% \vspace{2em}}}
|
||||
\includegraphics[width=\linewidth]{hongkong-jinan-withbd.pdf}
|
||||
\caption{用户流量高峰与公网链路质量下降时段的重合}
|
||||
\label{fig:用户高峰与公网劣化重合}
|
||||
\end{figure}
|
||||
|
||||
64
data/chap03-outline.md
Normal file
64
data/chap03-outline.md
Normal file
@@ -0,0 +1,64 @@
|
||||
# 第三章 提纲与叙事设计备忘
|
||||
|
||||
## 最终版本的结构（已写入 chap03.tex）
|
||||
|
||||
### 叙事主线：三个挑战 → 三个设计
|
||||
|
||||
章节的核心叙事逻辑是"先提出挑战，再逐一用设计解决"：
|
||||
|
||||
1. **3.1 系统总体架构**（简要）：Coordinator-Node架构、TUN/UDP隧道/per-flow线程，一段话说完。
|
||||
2. **3.2 设计挑战**：先提出三个核心挑战，让读者带着问题读后续设计。
|
||||
3. **3.3 交织XOR前向纠错编码设计**（解决挑战一）：
|
||||
- 编码方案选择：为何选XOR分组码——分组码的冗余包是独立包，不嵌入用户数据包，所以不存在MTU溢出问题。流式编码需要预留冗余空间，不适用。
|
||||
- 交织编码矩阵结构、编码器/解码器工作流程。
|
||||
4. **3.4 基于丢包统计的自适应参数调整**（解决挑战二）：
|
||||
- 三状态丢包模型（先建模 → 再估计 → 再搜索参数）。
|
||||
- 解码端丢包检测与统计。
|
||||
- 模型参数估计（从loss_1/loss_2/loss_3推导p21/p23/p33）。
|
||||
- 编码参数搜索算法（延迟约束20ms + 残余丢包率约束1%）。
|
||||
5. **3.5 解码端输出速率控制设计**（解决挑战三）：
|
||||
- 问题：FEC突发输出 → ACK密集 → CCA误判带宽 → 速率震荡 → 影响FEC参数估计。
|
||||
- PI控制器：Passthrough（直通+测速）→ Controlling（PI控制）。
|
||||
- 协同关系：Pacing稳定CCA → CCA稳定发包 → 编码器稳定填组 → 参数估计更准。
|
||||
6. **3.6 本章小结**。
|
||||
|
||||
### 三个挑战与设计的对应关系
|
||||
|
||||
| 挑战 | 核心问题 | 对应设计 |
|
||||
|------|---------|---------|
|
||||
| 挑战一 | 通用转发场景下用户包大小可变，冗余不能嵌入包内导致MTU溢出 | 分组XOR编码（冗余包独立发送）+ 交织 |
|
||||
| 挑战二 | 需满足流媒体延迟需求，同时结合实时丢包数据自适应调整 | 三状态丢包模型 + 约束搜索算法 |
|
||||
| 挑战三 | FEC解码突发输出导致CCA误判带宽 | PI速率控制器（Pacer） |
|
||||
|
||||
## 叙事衔接机制
|
||||
|
||||
1. **挑战尾部的策略预告 + 前向链接**：3.2中每个挑战的末尾都用1–2句话概括了解决策略，并通过 `\ref{sec:xxx}` 前向链接到对应的设计小节，例如"本文采用交织XOR分组编码方案应对此挑战（详见第\ref{sec:fec编码}节）"。
|
||||
2. **设计开头的挑战重述**：3.3/3.4/3.5每个设计节的第一句话都以"本节针对挑战X"开头，回指3.2中提出的挑战，形成闭环。
|
||||
|
||||
## 叙事逻辑要点
|
||||
|
||||
1. **挑战先行**：3.2节先把三个挑战全部摆出来，读者带着问题读后续设计，每个设计开篇回指对应的挑战。
|
||||
|
||||
2. **挑战一的论述重点**：不是"XOR计算简单"（这只是bonus），核心论点是"分组码的冗余包独立于数据包，不受用户包大小影响"，而流式编码需要内嵌冗余空间，不适用于通用转发。
|
||||
|
||||
3. **先建模再设计**：3.4的叙事顺序是"先提出三状态丢包模型 → 再说如何从观测量估计模型参数 → 再说如何基于模型做FEC参数拟合"。这比直接说"我们用了什么公式"更有说服力，也更容易和参考论文区分开。
|
||||
|
||||
4. **Pacing是独立于FEC的设计**：3.5独立成节，核心目的是"为CCA服务"而非"为FEC服务"。
|
||||
|
||||
5. **消融实验暂缺**：pacer对CCA行为的正面影响目前没有专门的对比实验，chap03中先论述设计动机和机制，chap04再想办法补充。
|
||||
|
||||
6. **排版约定**：代码标识符使用 `\texttt{}` 排版（如 `\texttt{flow\_id}`），这是标准LaTeX做法，不需要额外宏包。
|
||||
|
||||
## 代码对应关系（写作时参考）
|
||||
|
||||
- FEC编解码器：`code/bifrost/src/node/udp_relay/algorithm/fec.rs`
|
||||
- Pacer：`code/bifrost/src/node/udp_relay/algorithm/pacer.rs`
|
||||
- 参数计算：`code/bifrost/src/coordinator/core.rs` 中的 `fern_parameter_calc` 函数
|
||||
- 转发机制：`code/bifrost/src/node/udp_relay/mod.rs`
|
||||
- TUN管理：`code/bifrost/src/node/udp_relay/tun_manager.rs`
|
||||
- 协调器核心：`code/bifrost/src/coordinator/core.rs`
|
||||
|
||||
## 注意事项
|
||||
|
||||
- **不涉及fern**：所有内容仅基于fec和pacer，fern是未完成的项目，不在论文讨论范围内。
|
||||
- **参数估计的查重问题**：3.4的模型和估计方法从代码出发重新推导和表述，不直接照搬参考论文的叙述方式。
|
||||
118
data/chap03.tex
118
data/chap03.tex
@@ -2,15 +2,121 @@
|
||||
|
||||
\chapter{跨域云网络传输性能提升研究}
|
||||
|
||||
\section{设计总览}
|
||||
\section{设计目标与总体思路}
|
||||
|
||||
\section{转发机制设计}
|
||||
前两章的分析表明，跨域云网络中的核心矛盾在于：专线链路能够提供稳定的传输质量，但使用成本较高；公网链路成本低廉、覆盖灵活，却在部分跨域片段上存在明显的丢包和抖动。若继续沿用“公网质量良好时走公网、质量恶化时切回专线”的以资源调度为中心的策略，系统在用户需求高峰期仍将大量依赖专线，成本优化空间十分有限，而已有的前向纠错编码等链路质量优化类工作则又将传输链路当作不可改变的低质量链路，只进行端到端的冗余添加与丢包恢复，没有考虑网络传输过程中不同分段的网络质量不同，需要不同程度的丢包恢复。因此，本文提出，依靠云网络配置灵活、路由选择多样的特点，通过冗余编码对云网络中的部分低质量链路进行针对性的质量修复，以达到传输性能与运营成本的平衡。
|
||||
|
||||
\section{FEC编码选择及恢复机制设计}
|
||||
在可变的用户包大小下设计FEC编码方案->使用block code
|
||||
|
||||
\subsection{编码选择}
|
||||
在网络质量动态变化的情况下，自适应地选择FEC参数->使用markov链估计网络参数
|
||||
|
||||
\subsection{编码参数估计}
|
||||
FEC解码时出现burst造成速率测量不准，干扰CCA决策->使用PI控制器稳定发送速率
|
||||
|
||||
\subsection{包输出速率控制设计}
|
||||
% 因此，本研究设计的传输优化系统遵循两项设计原则。第一，云网络节点间的连接全部使用公网链路建立，不再使用专线，从而降低跨域互联的资源使用成本。第二，FEC冗余不在整条端到端路径上无差别启用，而是以链路片段为粒度进行针对性修复。对于质量良好的公网片段，系统保持普通转发，以避免引入额外带宽开销；对于丢包集中、连续丢包显著的低质量片段，系统在该片段的发送端加入冗余编码，并在接收端恢复丢包，从而提升该片段的有效传输质量。
|
||||
|
||||
% 为实现上述原则，系统既需保持覆盖网络对应用的透明性，又需在具体链路片段上插入可自适应的编码与恢复逻辑。为此，本文采用集中控制、分布转发的软件定义网络架构实现该目标：控制面负责连接管理、路径配置和编码参数调整，数据面负责按链路片段执行普通转发或FEC优化。
|
||||
|
||||
\section{系统总体架构}
|
||||
|
||||
系统由一个中心控制器（Coordinator）和多个部署在不同地域的转发节点（Node）组成，如图\ref{fig:系统总体架构}所示。中心控制器维护节点和连接状态，为端到端连接分配流标识，向相关节点下发转发表项，并根据解码端上报的丢包统计调整低质量链路片段上的FEC编码参数。转发节点负责数据面的实际转发，在本地根据控制器下发的配置，对不同流分别执行普通转发、FEC编码或FEC解码。
|
||||
|
||||
\begin{figure}[htbp]
|
||||
\centering
|
||||
\fbox{\parbox{0.95\textwidth}{\centering\small\vspace{1.5em}%
|
||||
图片内容：系统总体架构。上方Coordinator通过TCP连接（控制面，虚线）连接多个Node。Node之间通过UDP隧道互联（数据面，实线）。标注一条端到端路径：用户A → TUN → Node1（FEC编码器）→ UDP隧道 → Node2（FEC解码器 + Pacer）→ TUN → 用户B。Coordinator标注"FEC参数计算"，数据面上标注编码后数据包传输，控制面上标注丢包统计上报与参数下发。%
|
||||
\vspace{1.5em}}}
|
||||
\caption{系统总体架构}
|
||||
\label{fig:系统总体架构}
|
||||
\end{figure}
|
||||
|
||||
每个转发节点上为每条端到端连接创建独立的TUN虚拟网络设备，用户应用只感知到一条普通IP链路，而不需要感知底层覆盖网络和FEC机制。节点之间通过UDP隧道传输数据包，每个数据包的头部携带\texttt{flow\_id}以标识所属的数据流。系统为每个\texttt{flow\_id}创建独立的处理线程，线程中包含入方向解码器和出方向编码器：当流量进入一个需要修复的低质量链路片段时，出方向编码器添加FEC冗余；当流量离开该链路片段时，入方向解码器根据收到的数据包和冗余包恢复丢包。对于不需要修复的链路片段，编码器和解码器退化为普通转发逻辑。
|
||||
|
||||
\section{设计挑战}
|
||||
|
||||
在“全公网承载、差链路修复”的总体目标下，系统设计需要进一步回答三个具体问题。首先，FEC机制必须能够插入通用覆盖网络转发路径，而不能改变用户报文本身的大小假设；其次，低质量公网链路的丢包程度会随时间变化，系统需要决定何时启用冗余以及使用多少冗余；最后，FEC解码按组恢复数据会改变报文交付节奏，如果不加处理，可能反过来干扰端系统的拥塞控制。由此，本文需要解决以下三个核心设计挑战。
|
||||
|
||||
\textbf{挑战一：如何在用户包大小可变的场景下设计链路片段级FEC编码方案。}
|
||||
系统作为通用转发平台，承载的上层应用可能产生任意大小的数据包。当用户数据包接近MTU时，若FEC编码产生的冗余信息追加在用户数据包内一同发送，则封装后的数据包可能超出MTU，导致IP层分片或传输失败。因此，FEC编码方案必须能够在不影响用户数据包大小的情况下独立添加冗余信息。同时，由于本文只在低质量公网片段上进行修复，编码方案还需要在单个链路片段上有效应对连续突发丢包，而不是依赖端到端重传。本文采用交织XOR分组编码方案应对此挑战（详见第\ref{sec:fec编码}节）。
|
||||
|
||||
\textbf{挑战二：如何判断差链路所需的冗余强度并自适应地选择编码参数。}
|
||||
全公网方案不能简单地对所有链路长期使用高冗余率，否则低成本公网节省下来的费用会被额外流量开销抵消。系统承载的应用中又包含实时音视频流媒体等对延迟敏感的业务，FEC编码引入的冗余包不仅占用额外带宽，也会引入解码等待延迟。因此，系统需要根据链路片段上的实时丢包统计，在丢包恢复能力、额外带宽开销和恢复延迟之间取得平衡。由于公网链路的丢包率与丢包模式随时间动态变化，固定的编码参数无法同时适应不同质量状态的链路。本文通过建立丢包信道模型并据此进行约束搜索来解决此挑战（详见第\ref{sec:参数调整}节）。
|
||||
|
||||
\textbf{挑战三：如何消除FEC解码按组突发输出对拥塞控制算法的干扰。}
|
||||
FEC解码器按编码组为单位批量恢复和交付数据包。当一个编码组恢复完成后，组内的所有数据包被一次性连续交付给上层应用。这种突发式的输出模式会使得上游的拥塞控制算法收到密集的ACK确认包，从而错误地估计链路可用带宽，引发发送速率的震荡。速率震荡不仅影响应用的传输性能，还会使FEC编码器的输入节奏不稳定，进一步干扰吞吐量统计和参数估计的准确性。本文在解码端设计了基于PI控制器的输出速率控制器来消除此问题（详见第\ref{sec:pacer}节）。
|
||||
|
||||
\section{交织XOR前向纠错编码设计}
|
||||
\label{sec:fec编码}
|
||||
|
||||
本节针对挑战一，介绍链路片段级交织FEC编码方案的设计。核心需求是：FEC冗余信息必须以独立包的形式发送，不嵌入用户数据包内部，从而避免影响用户数据包的大小；同时编码方案需能在低质量公网片段上有效应对连续突发丢包。
|
||||
|
||||
如第二章所述，现有的前向纠错编码方案主要包括简单复制冗余、XOR码、R-S码以及流式编码等。本文选择基于XOR运算的分组编码结合交织技术作为FEC编码方案，其核心考量如下。
|
||||
|
||||
分组码天然适应可变包大小的场景。在分组码中，冗余包是独立于数据包的单独包：编码器先将用户数据包逐个作为数据包发出，在编码组填满或超时后再生成独立的冗余包并追加发送。由于冗余信息不嵌入在用户数据包内部，用户数据包的大小不受FEC编码的影响，因此即使数据包本身已接近MTU，也不会因为FEC而产生封装溢出的问题。相比之下，流式编码将同一时刻的冗余信息分散嵌入后续多个数据包中，要求在数据包内部预留冗余空间，在用户包大小不可控的通用转发场景下难以适用。分组码的另一个优势是边界清晰：编码器和解码器可以部署在某一段公网链路的两端，只修复该链路片段，而不会要求整条端到端路径都采用同一种传输机制。
|
||||
|
||||
在多种分组码中，本文选择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$个不同的列中，每个列至多丢失一个数据包，因此每个列都可以独立恢复。
|
||||
|
||||
\begin{figure}[htbp]
|
||||
\centering
|
||||
\fbox{\parbox{0.85\textwidth}{\centering\small\vspace{1.5em}%
|
||||
图片内容：交织编码矩阵示意。以$d=4, k=3$为例，矩阵为4列、4行（3行数据+1行冗余）。数据包标注为$D_{0,0}, D_{1,0}, D_{2,0}, D_{3,0}, D_{0,1}, D_{1,1}, \ldots, D_{3,2}$，冗余包标注为$F_0, F_1, F_2, F_3$。其中$F_j = D_{j,0} \oplus D_{j,1} \oplus D_{j,2}$。下方用箭头展示实际发送顺序：$D_{0,0}, D_{1,0}, D_{2,0}, D_{3,0}, D_{0,1}, D_{1,1}, \ldots, F_0, F_1, F_2, F_3$。右侧用虚线框标注一个连续丢包的例子：假设连续丢失$D_{1,0}$和$D_{2,0}$，由于交织深度$d=4$，两个丢包分别落在第1列和第2列，每列恰好只丢失一个包，各自可用$F_1$和$F_2$恢复。%
|
||||
\vspace{1.5em}}}
|
||||
\caption{交织编码矩阵结构示意（$d=4, k=3$）}
|
||||
\label{fig:交织编码矩阵}
|
||||
\end{figure}
|
||||
|
||||
编码参数（$d$和$k$）可以在编码组之间动态切换，编码器在结束当前组时加载最新收到的参数配置，下一编码组立即使用新参数。
|
||||
|
||||
\section{基于丢包统计的自适应参数调整}
|
||||
\label{sec:参数调整}
|
||||
|
||||
本节针对挑战二，介绍如何根据实时丢包统计自适应地选择编码参数。如前所述，本文并不希望在所有公网链路上持续加入固定冗余，而是希望仅在差链路上使用足够但不过量的冗余。因此，FEC编码参数需要同时满足流媒体应用的延迟需求、控制额外带宽开销，并适应链路质量的动态变化。本文的解决思路是：首先为公网链路的丢包行为建立一个数学模型，然后从接收端的丢包观测量中估计模型参数，最后在延迟与残余丢包率的约束下搜索最优编码参数。
|
||||
|
||||
\subsection{丢包信道模型}
|
||||
|
||||
根据第一章中对公网链路丢包特性的分析，公网链路上的丢包行为可以大致分为两类：一类是偶发的孤立丢包，丢失一个包后链路随即恢复正常；另一类是连续的突发丢包，由于链路拥塞等原因连续丢失多个数据包。基于这一观察，本文提出一个简化的三状态丢包信道模型，如图\ref{fig:三状态丢包模型}所示。模型定义三个状态：$S_0$（正常状态，当前数据包正常接收）、$S_1$（孤立丢包状态，丢失一个包后立即恢复）、$S_2$（突发丢包状态，连续丢失多个包）。模型通过三个参数$p_{21}$（孤立丢包触发概率）、$p_{23}$（突发丢包触发概率）和$p_{33}$（突发延续概率）完整描述链路的丢包行为。
|
||||
|
||||
\begin{figure}[htbp]
|
||||
\centering
|
||||
\fbox{\parbox{0.8\textwidth}{\centering\small\vspace{1.5em}%
|
||||
图片内容：三状态马尔科夫丢包模型状态转移图。三个状态：$S_0$（正常接收），$S_1$（孤立丢包），$S_2$（突发丢包）。转移概率标注。%
|
||||
\vspace{1.5em}}}
|
||||
\caption{三状态丢包信道模型}
|
||||
\label{fig:三状态丢包模型}
|
||||
\end{figure}
|
||||
|
||||
\subsection{参数估计与编码参数搜索}
|
||||
|
||||
解码端通过全局序列号间隔检测丢包，维护一个滑动窗口统计近期的丢包事件，并将统计量定期上报至中心控制器。中心控制器收到统计量后，首先根据丢包事件的突发长度分布估计三状态模型的参数$p_{21}$、$p_{23}$和$p_{33}$，进而得到丢包事件的总发生率$\lambda = p_{21} + p_{23}$。
|
||||
|
||||
在估计出模型参数后，中心控制器在给定的性能约束下搜索最优的编码参数$(d, k)$。算法考虑交织深度$d \in \{1, 2, 3, 4\}$的候选值，对于每个$d$，确定满足以下两个约束的最大保护包数$k$：
|
||||
|
||||
\begin{enumerate}
|
||||
\item \textbf{延迟约束}：编码组引入的额外等待延迟不应超过阈值，以满足流媒体应用的实时性需求。
|
||||
\item \textbf{残余丢包率约束}：编码后未被恢复的随机丢包率应低于阈值，确保应用层的丢包率在可接受范围内。
|
||||
\end{enumerate}
|
||||
|
||||
最终在所有可行的$(d, k)$组合中，选择$k$值最大的组合作为最优编码参数，以提供最强的冗余保护。上述参数调整过程构成了一个完整的反馈闭环：解码端持续检测丢包并上报统计信息，中心控制器计算最优参数并下发至编码端，编码端在下一编码组生效新参数。
|
||||
|
||||
\section{解码端输出速率控制设计}
|
||||
\label{sec:pacer}
|
||||
|
||||
本节针对挑战三，介绍解码端的输出速率控制器（Pacer）设计。如前所述，FEC解码器按编码组为单位批量交付数据包，这种突发输出会使上游CCA收到密集的ACK，导致错误的带宽估计和速率震荡。本文通过在解码端引入PI速率控制器，将突发输出平滑为匀速流来解决此问题，其控制模型如图\ref{fig:pacer控制模型}所示。
|
||||
|
||||
\begin{figure}[htbp]
|
||||
\centering
|
||||
\fbox{\parbox{0.85\textwidth}{\centering\small\vspace{1.5em}%
|
||||
图片内容：Pacer控制模型框图。左侧"数据包输入"（来自FEC解码器，标注"突发式到达"）→ 进入"输出缓冲区"（buffer）→ 受控输出paced数据包（标注"匀速输出"）。缓冲区下方有一个"PI控制器"模块，输入为error = depth - target，输出为pacing rate。%
|
||||
\vspace{1.5em}}}
|
||||
\caption{Pacer控制模型}
|
||||
\label{fig:pacer控制模型}
|
||||
\end{figure}
|
||||
|
||||
Pacer的核心是一个基于缓冲区深度的PI（比例-积分）控制器。FEC解码器恢复后的数据包首先进入一个输出缓冲区，Pacer根据缓冲区的当前深度与目标深度的偏差计算出发包速率，并按照该速率匀速地从缓冲区中取出数据包交付给上层应用。比例项提供快速的瞬态响应：缓冲区超过目标时加快发包消耗积压，低于目标时减慢发包等待新数据。积分项消除稳态误差：即使数据包到达速率发生变化，积分项也能逐步学习新的稳态速率，确保缓冲区深度收敛到目标值。启动时，Pacer先以直通模式运行并测量实际的到达速率，待积累足够的观测后切换到PI控制模式，切换时将测量速率编码为积分项的初始值以实现平滑过渡。
|
||||
|
||||
Pacer与FEC编码的自适应参数调整形成了协同关系。Pacer将突发输出平滑为匀速流，使得CCA能够基于稳定的ACK反馈正确估计带宽，维持稳定的发送速率。稳定的发送速率使得FEC编码器以稳定的节奏填满编码组，进而使吞吐量统计值更加准确，提升了参数调整的准确性。
|
||||
|
||||
\section{本章小结}
|
||||
|
||||
本章围绕“全公网承载、差链路修复”的总体思路，介绍了本文提出的跨域公网链路传输优化方法。首先明确了本文不依赖专线兜底，而是在公网覆盖网络中针对低质量链路片段进行FEC修复；随后介绍了集中控制、分布转发的系统总体架构，并将总体目标细化为三个设计挑战。针对通用转发场景下可变包大小与MTU约束的挑战，本文选择了交织XOR分组编码方案，冗余包作为独立包发送不影响用户数据包大小，交织技术则将连续丢包分散到不同的恢复列中。针对满足实时应用延迟需求的同时自适应选择编码参数的挑战，本文提出了三状态丢包信道模型，介绍了从丢包观测量估计模型参数以及在延迟与残余丢包率约束下搜索最优编码参数的方法。最后，针对FEC解码突发输出干扰拥塞控制算法的挑战，本文设计了解码端PI速率控制器，将突发输出平滑为匀速流，并与FEC参数调整机制形成协同。
|
||||
|
||||
BIN
figures/cross_region_low_quality.jpg
Normal file
BIN
figures/cross_region_low_quality.jpg
Normal file
Binary file not shown.
|
After Width: | Height: | Size: 188 KiB |
BIN
figures/hongkong-jinan-withbd.pdf
Normal file
BIN
figures/hongkong-jinan-withbd.pdf
Normal file
Binary file not shown.
94
调研.md
Normal file
94
调研.md
Normal file
@@ -0,0 +1,94 @@
|
||||
我在进行一项针对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