移动技术的出现导致了终端用户新型服务的发展,这些服务具有严格的需求和要求。在5G及超5G系统范围内,非地面网络正在被考虑满足这些需求,特别强调高速率和低延迟。QUIC 是一种新的传输协议,旨在通过多种方式减少通信延迟。除其他功能外,它还可以使用多个流来有效管理通过其底层 UDP 套接字发送的数据流。本文介绍了基于优先级的流调度器的实现以及灵活接口的设计。利用所提出的方法,应用程序能够设置所需的调度方案以及流优先级。所提出的方法的可行性通过广泛的实验活动得到了验证,该实验活动结合了 Docker 容器和 ns-3 模拟器来模拟不同的连接。特征。结果表明,在不可靠的条件下,适当的流调度程序确实可以将严格时间敏感的应用程序的延迟降低高达 36%。
作者:Ikerlan Technology Research Center Arrasate/Mondragón, Spain
来源:PE-WASUN’23: Proceedings of the Int’l ACM Symposium on Performance Evaluation of Wireless Ad Hoc, Sensor, & Ubiquitous Networks
标题:Flexible Priority-based Stream Schedulers in QUIC
链接: https://dl.acm.org/doi/10.1145/3616394.3618267
内容整理:鲁君一
简介
新兴的无线网络,特别是5G和超越5G(B5G)系统,推动了移动通信的发展,特别是在新应用和服务方面。这些技术允许高传输速率(增强的移动宽带,eMBB)和低延迟(超可靠和低延迟通信,URLLC)。此外,它们还促进了生成和收集信息的设备的大规模互联(大规模机器型通信,mMTC)。这导致了物联网(IoT)范式的巩固和快速传播。
实时应用对时间要求非常严格,这些要求可以通过结合高速移动技术如5G、适当的网络拓扑结构和合适的通信协议等实现。例如,触觉互联网中考虑的触觉应用要求往返时间低于大约10毫秒。无人机控制流量对延迟和可靠性有非常严格的要求。2018年,Ferranti等人预测,到2021年,78%的总流量将来自视频服务。这实际上得到了移动技术的加强,因为它们使得更多设备之间的互连成为可能,包括无人机。当无人机承载不同类型的流量,例如视频和控制流时,重要的是后者能够以尽可能低的延迟到达目的地。在本文中,我们提出利用QUIC中的多个流作为一种手段,通过单独的流发送控制流量,优先于承载大量数据的流。
在实时应用中,某些流可能比其他流更加对时间敏感。为了有效管理QUIC流,这些流可能需要被优先处理,因为它们对前述物联网应用的许多过程至关重要。在这项工作中,我们提出使用基于用户定义的优先级的QUIC流多路复用和流传输调度,以确保对时间敏感的流量低延迟。
总结来说,本文的主要贡献包括:
- 在遵循IETF QUIC规范(RFC 9000、RFC 9001、RFC 9002)的QUIC实现中集成新的流调度器(使用GO编程语言)。
- 这些包括基线解决方案,如加权公平排队(WFQ),以及旨在确保关键流量低延迟的绝对优先级策略。
- 我们进行了广泛的测量活动,使用结合真实节点(Docker容器)和ns-3的方法来模拟不同的连接特性。
- 我们利用这种方法评估了一个特定物联网场景的延迟,该场景涉及真实流量,使用了从控制器到无人机的控制流量跟踪。
- 所有代码已在公共git仓库中提供,以确保所展示结果和实验的可重复性。
背景
很少有工作分析了QUIC内的流调度器。文献中发现的绝大多数调度器针对的是连接的其他方面,而不是多流传输,特别是多路径。传输层多路径(MP)包括同时使用多个网络接口。MP和流调度器处理不同的挑战:MP通过不同且肯定是异构的网络路径发送数据,而没有MP的流则通过同一路径。QUIC的一个MP扩展目前正在开发中。此外值得一提的是,一些工作显示流感知实际上会改善MP调度的行为。Shi等人为 MPQUI C提出了一种基于优先级的在线流调度机制。路径调度是根据流属性执行的。作者表明,所提出的调度器可以减少在路径可能具有非常不同特性的环境中的下载时间。Viernickel等人还为 MPQUIC 提供了一种流到路径的调度策略,显示了减少HOL效应,并减少了建立子流所需的时间。其他工作比较了MP调度器,而没有考虑在传输协议内如何处理流。MP不在本文的范围内,本文关注的是在单一路径上的多流传输。
Chiariotti 等人也研究了在一条路径上使用多个流。他们只关注如何将应用数据映射到底层流。作者假设应用程序定义了每个流中数据与相应服务要求的关系。他们的调度器试图在接收节点最大化这种相关性。他们使用两个特定的用例评估他们的方法:车辆间通信和触觉通信。Hervella等人比较了QUIC在真实卫星网络上的性能与TCP所展示的性能。他们修改了ns-3网络模拟器以模拟具有不同特性的卫星链路。他们还进行了对 QUIC 中多流传输影响的分析,使用了默认的轮询调度器。他们的结果表明,这种调度策略并没有带来较低的延迟。此外,Cui等人也在QUIC中使用了多个流来传输MPEG-DASH协议(DASH)。在这种情况下,调度器根据每个视频段的截止日期来做出决策,这些视频段是通过每个流自适应发送的,或者根据缓冲状态。如果在规定的时间内没有接收到段,或者播放缓冲区不满,多流调度器就会切换到单纯模式,接收第一个请求的段,并暂停剩余的流。作者还使用ns-3进行了实验。结果表明,相比于其他方法,QUIC上的DASH(DASH+)通过多流传输实现了更高的吞吐量和更好的视频质量。然而,作者并没有修改QUIC协议的调度策略。
在QUIC实现quic-go中,默认行为反映了传统的轮询(Round Robin)策略。这个算法基于先到先得的原则平等地分配资源。这意味着即使某个流携带敏感数据,也不会为其分配任何优先级。我们提出了两种基于优先级的调度器:加权公平排队(Weighted Fair Queuing,WFQ)和绝对优先级(Absolute Prioritization,ABS)。一方面,WFQ为每个流分配一个特定的权重,这个权重对应于相应的时间比例。另一方面,绝对优先级会将所有时间分配给最高优先级的流,只要它有数据要传输。最后,作为选择的QUIC实现的结果,优先级覆盖了流的传输和重传队列。
实现
quic-go的流管理主要包括处理流队列。因此,我们修改了队列管理机制以实现新的流调度器:绝对优先级(ABS)和加权公平排队(WFQ)。图1展示了默认的队列管理和引入的修改。
在这个示例中,我们为ID为“ID0”的流分配了更高的优先级。这意味着在这个流中发送的消息将首先被处理。一开始,流队列被填充了ID(StreamQueue Init.)。对于WFQ验证,我们为“ID0”分配了75%的传输时间,而“ID1”则分配了25%。这是通过在队列中复制相应的流来实现的。
然后,根据调度器类型和流是否有更多数据要发送(stream.hasMoreData),检查流队列。从队列中的第一个流中取出数据进行传输后,如果流中还有数据要发送,它就返回到队列中。对于WFQ和轮询,流被移动到队列的末尾,而对于ABS,它保持在队列的头部。如果没有更多数据要发送,流就不会被发送回队列,并且其所有副本都被移除。
结果
环境设置
为了进行实验,我们利用了ns-3离散事件模拟器和Docker容器。Docker容器通过ns-3连接,后者通过改变带宽和延迟参数模拟了底层连接的特性。此外,丢包率也可以调整以考虑不同的条件。我们连接了两个交换真实应用流量的容器。每个容器托管一个由客户端和使用QUIC的服务器组成的应用程序。这些应用程序在各自的操作系统上的独立网络中相互隔离,拥有自己的网络堆栈,并与专用的网络设备交互。为了建立网络拓扑,每个容器都连接到一个桥接设备,该设备连接到一个tap设备,然后连接到一个特殊的ns-3 NetDevice。这些NetDevices将每个仿真节点(Docker容器)连接到一个网络路由器。两个网络路由器通过点对点链接连接,该链接用于通过修改带宽和往返时间来模拟不同的网络技术。此外,连接到边缘路由器的链接具有非常高的容量和零延迟,确保瓶颈在网络上。
实验中的带宽和往返时间分别为1 Mbps和40毫秒。我们还使用了不同的数据包丢失率来评估在可靠和不可靠的链接条件下的性能(0%,5%,和10%)。
性能评估
使用在5G网络上控制器和无人机之间的真实通信获得的追踪数据。这些追踪数据包括通过UDP传输的微型空中车辆链接(MAVLink3)数据包 在物联网节点之间建立了一个QUIC连接,然后打开了十个流,模拟了十种不同的数据流,以更好地评估所提出方案的优先级划分能力的好处。一个流被分配给控制流量(无人机-控制器追踪数据),其余流被分配给优先级较低的背景流量。我们通过大量传输来模拟这种非必要流量,以模仿底层QUIC连接的密集使用。然后分析对延迟敏感的控制流量,测量从消息写入流套接字到完全传递到接收方所经历的时间。WFQ被配置为将25%的传输时间分配给优先级流,其余时间分配给另外九个流。
使用箱线图表示了每个调度器的消息延迟。可以看出,由于消息长度的大变化,尤其是在轮询调度器下,结果显示出显著的离散性。这个调度器的操作假设应用程序立即发送信息,而流管理器以规律且相等的速度从每个流中获取数据。因此,信息可能会排队等待传输。一些优先级消息在它们的流接近传输时到达队列,从而减少了这些消息的延迟,而其他消息需要穿过整个队列。绝对优先级调度器的性能比轮询更好
在优先级流上发送更长的消息:创建一个QUIC连接并打开两个流。我们增加了优先级消息的长度,以确保每个消息对应于不止一个数据包。更具体地说,我们传输了2、4和8个数据包的消息。下图显示了使用相同网络参数的这种方法观察到的延迟。与上一个实验一样,WFQ将75%的时间资源分配给优先级流。可以看出,随着消息长度的增加,基于优先级的流调度变得更有利,因为收益更加显著。当生成两个QUIC数据包时,使用优先级方案处理的时间更短。使用ABS在没有丢失的情况下,传输时间大约减少了20毫秒。这种差异随着消息长度的增加而增加。当消息包含8个数据包时,可以看到 WFQ 相对于轮询至少减少了50毫秒的延迟,如果使用绝对优先级,则减少约80毫秒。在错误频发的通道中也看到了相同的行为,当生成8个数据包时,ABS和轮询之间的差异几乎为85毫秒。
总结
在本文中,作者设计并实现了一个新的流管理器,包括两种调度策略,以对 QUIC 中的流量进行优先级排序。使用基于 GO 的实现(quic-go),其中添加了用户选择调度器的可能性,如以及分配给每个流的优先级。本文使用一种方法,利用包含 ns-3 模拟器和 Docker 容器的环境来进行实验并评估所提出技术的性能。为了验证我们基于优先级的流队列提议,我们使用了两种场景:第一个使用时间敏感的流量,与其他背景流量竞争。第二个重点关注不同消息长度的影响。我们观察到,我们提出的方案的增益很大程度上取决于优先消息的大小。对具有相对长消息(多个 QUIC 数据包)的流进行优先级排序的应用程序表现出比基线调度程序低得多的延迟。
版权声明:本文内容转自互联网,本文观点仅代表作者本人。本站仅提供信息存储空间服务,所有权归原作者所有。如发现本站有涉嫌抄袭侵权/违法违规的内容, 请发送邮件至1393616908@qq.com 举报,一经查实,本站将立刻删除。