通过机器学习进行快速、早期的大象流检测，改善广播观众体验

IBC2023：本技术论文提出了一种在 500ms 内为广播网络 SDN 控制器检测 EF 的新方法，从而允许 SDN 控制器重新路由 EF 并减少数据包丢失。

摘要

保持较低的广播 IP 网络延迟对于保持身临其境的观看体验至关重要，尤其是在通过互联网或广播 IP 数据中心传输高质量广播媒体时。具有高数据传输速率和时间持久性的重型广播媒体流对网络和资源的需求与对延迟敏感的短数据流的需求相冲突，导致交换机缓冲区超载和网络拥塞，造成数据包丢失，并因 TCP-RTO（传输控制协议重传超时）而增加延迟。在广播数据中心内，媒体流通常属于大象流（EF）分类，而短数据流则被归类为老鼠流（MF）。对 EF 的快速和早期检测可使 SDN 控制器对其进行重新路由，减少其对广播 IP 网络中 MF 的影响。这样可以减少数据包丢失，从而不会触发 TCP- RTO，从而降低延迟，改善身临其境的观看体验。尽管对 EF 检测进行了广泛研究，但本文提出了一种新方法，可在 500 毫秒内为广播网络 SDN 控制器检测 EF，从而使 SDN 控制器能够重新路由 EF 并减少数据包丢失。该方法使用集合 LSTM（长短期记忆）神经网络进行机器学习，每个 LSTM 的长度不同，因此集合可以捕捉不同流量大小的非线性特征。

然后将 LSTM 的输出集合起来，由神经网络进一步处理。通过神经网络和每个 LSTM 的反向传播实现训练，从而提高广播 IP 网络的推理 EF 检测精度。与其他方法不同的是，我们的方法在行业标准数据集上进行了测试，无需依赖网络交换机提供的统计信息，即可在 500 毫秒内完成 EF 检测，从而进一步减少了延迟，改善了身临其境的观看体验。

简介

由于互联网协议（IP）数据包是异步随机分发的，因此网络中可用数据包的数量在任何时候都会出现统计上的高峰和低谷。虽然 IP 数据包丢失是网络中固有的现象，但传输控制协议（TCP）提供了可靠的 IP 数据包传输。不过，由于 TCP 是面向客户端和服务器之间的连接，并依靠重发策略来处理丢失的数据包，因此它还是以延迟为代价[2]。发起连接的客户端将等待服务器确认请求，然后客户端发送与要传输的媒体相关的 IP 数据包。所有数据发送完毕后，客户端将关闭连接。

TCP 被广泛用于向智能电视和移动设备上的观众传输视频、音频和元数据流。因此，TCP 流量的普及率持续大幅增长，导致需要动态重新路由以降低观众延迟风险的 EF 数量增加，尤其是当观众交换社交媒体信息时。此外，随着广播 IP 网络基础设施复杂性的增加（如果 IP 要实现其承诺的灵活性，这种复杂性是不可避免的），TCP 的普遍性不容忽视，尤其是当广播公司将未压缩的 UDP 流（如 ST2110）与压缩的 TCP 视频和音频流集成在一起时。

大象 TCP 流量由于数据速率高且稳定，往往会暂时较长并占满交换机内的缓冲区，特别是当出口端口被大量订阅时，如果大部分缓冲区都用于这些 “高稳定状态”，那么就会导致短数据包突发时的数据包丢失，从而造成延迟增加和用户体验不佳。网络中通常采用基于哈希值的 ECMP（等价多路径）来选择最短的路由路径，因为它实施简单，而且不需要交换机提供每流信息。ECMP 无法区分 MF 和 EF，而且存在哈希碰撞问题，有时会导致多个 EF 被错误地发送到同一链路上，从而进一步加剧缓冲区溢出和数据包丢失 [37]。因此，有必要消除大量订阅的出口端口的拥塞，并降低滞留短期和时间敏感的 MF 的风险 [1]。为了解决这个问题，Liu [6] 提出了一种基于 SDN 的负载平衡机制，通过获取整个网络的拓扑和状态来路由 EF。然后，他们根据链路状态参数，通过多条路径拆分和发送 EF。然而，要使 SDN 重路由有效，EF 检测必须尽可能快；这正是我们的工作所建议的。与其他需要数秒 TCP 流量数据才能建立 EF 的方法不同，我们的方法可在 500 毫秒内实现 EF 检测。这降低了缓冲区溢出和丢包的风险，从而改善沉浸式观看体验。

数据中心的测量[22][23]表明，网络中 80% 的总流量长度不超过几毫秒，大小不超过 10KB。大部分流量都集中在前 10%的大流量（EF）中，任何重要的带宽流量（例如大于 1MBps）通常都被视为 EF [26]。MF 和 EF 之间对网络资源的竞争往往会导致 MF 缺乏带宽，从而导致数据包丢失和延迟增加 [25]。此外，对 EF 进行重新路由以允许 MF 获得更大的带宽，有可能提高网络吞吐量 [24]。SDN 控制器无需处理所有 EF，只需处理对网络性能有重大影响的 EF。低效管理会使网络缓冲区充满 EF，从而导致排队延迟和丢包。因此，快速 EF 检测对减少网络拥塞至关重要 [27]。

图 1 展示了如何利用 EF 检测，通过动态重新路由 EF 来阻止 EF 和 MF 冲突。然而，早期 EF 检测对于降低交换机缓冲区溢出的风险至关重要。缓冲区溢出会丢弃数据包，进而导致 TCP 流量的延迟大幅增加。

EF 检测可能显得相对微不足道，因为网络运营商可能认为任何低于 250 毫秒阈值的 TCP 流（例如）都是 MF，任何大于阈值的都是 EF。然而，只有那些对网络性能有显着影响的EF才需要重新路由，即大于10s的EF[28]，而等待10s来检测EF在现实世界的网络中是不可行的。因此，我们的建议可以在 500 毫秒内检测到 EF，并在 500 毫秒内将 TCP 流分类为 MF 或 EF。

先前已经提出了几种 EF 检测技术方法 [24]、[25]、[29]-[35]。然而，它们依赖于开关中的短流量阈值，这可能导致误报和漏报率较高。一些方法需要定期提取从网络交换机到SDN控制器的流量统计数据[24]、[25]、[33]、[34]，这本身可能会增加网络流量，从而导致拥塞。这进一步导致流量检测和重新路由延迟显着增加。

因此，我们提出了一种更细致的数据驱动方法，具有以下主要贡献：