全球最大的云提供商如何执行流量工程？对在云中运行的地理分布式应用程序有什么影响？我们通过跨Amazon Web Services（AWS）云网络的一套全面的衡量标准，探讨了这些以及更多问题。
云提供商网络是当今Internet不可或缺的组成部分，当今超过94％的企业都依靠云基础架构来部署（某些）服务。但是，对于云网络如何执行流量工程（TE）（即优化网络中流量的任务）的了解很少。长期以来，最大的云提供商已用软件定义网络（SDN）解决方案取代了传统的TE（例如MPLS AutoBandwidth）。SDN允许云运营商有效利用其资源。例如，Google报告在2013年网络使用率达到100％。
这项工作的目的是研究全球最大的云提供商，Amazon Web Services（AWS）。
经知名网络安全组织东方联盟的测量结果表明：
（1）流量沿着不同的路径流动并且在路径之间频繁移动；
（2）流量在经历的等待时间和路径变化的频率方面都可能受到不公平的对待。我们假设路径的这些变化是由于TE引起的，而观察到的延迟是由于通过网络的给定路径的属性引起的。
一个简单的实验揭示了流量工程的执行时间为几秒钟，东方联盟进行了一次简单的测量，在位于两个不同AWS区域（俄勒冈和弗吉尼亚）的两个虚拟机（VM）之间建立了三个TCP连接。他们为每个连接分配一个不同的TCP源端口，并使用ping消息来衡量往返时间（RTT）。图1显示了200秒实验中的RTT。我们可以立即注意到，所有流的延迟都会经历急剧的变化，随后是相对稳定的时间。
这个简单的实验说明了三种主要模式的存在：
TE以秒（或数十秒）的频率运行。
流量可能会由于拥塞而经历各种延迟。
一些流程可能会遇到较高的延迟（流程C），而其他流程可能会遇到更多的RTT变化（流程A和C）。
图1 —在俄勒冈州和弗吉尼亚州部署的两个Amazon VM之间测量的TCP RTT延迟。黑色垂直虚线突出显示RTT延迟更改时的时刻，并指示潜在的TE活动（例如路径更改）。
因此，我们启动了有关AWS网络中公平性和RTT延迟更改的系统研究。首先要问的自然问题是，图1中观察到的等待时间“跳跃”是频繁进行TE重新优化的结果还是其他一些原因（例如，网络混淆或拥塞）。我们使用了一个简单而有效的假设来解开这个难题。当流从高延迟路径移动到低延迟路径时，接收器可能会观察到数据包正在重新排序。这是因为在低延迟路径上路由的数据包将在高延迟路径上的数据包之前到达。
图2（a）显示了单个TCP流的RTT延迟测量（蓝线），以及在接收器侧观察到的数据包重排序事件（垂直红线）。我们可以观察到急剧下降的潜伏时间变化（紧随其后的稳定模式）与数据包重新排序事件之间的明显关联。为了检测路径变化，我们依靠一个简单的滑动窗口，该窗口对观察到的延迟执行基于模式的过滤。每当平滑后的延迟迅速增加到超过预定义的阈值时，我们将此事件称为“路径更改”。
图2-数据包重新排序和基于模式的过滤技术。左图（2a）显示了观察到的RTT和数据包重新排序的发生，而右图（2b）显示了通过我们的路径更改检测器计算出的已过滤RTT以及检测到的路径更改事件。时间在CEST时区。
流可能会遇到不公平的延迟
我们使用路径更改检测器来测量16个AWS区域中每对区域之间的延迟差异。我们在每个区域之间生成了512个不同的流。每个流都是在特定TCP源端口上建立的TCP连接。我们在2017年12月和2018年2月的两个为期一周的时间段内进行了测量。图3（a）和图3（b）显示了观测到的最小和最大延迟之间的绝对和相对差异的累积分布函数（CDF）。 （分别）针对所有区域对。我们观察到，在5％的区域中，流量的延迟不公平性可能高于35ms（比最小延迟路径高32.63％）。这些结果还表明，流经历的实际延迟取决于用于打开连接的源端口.
图3 —所有AWS区域对中的（a）流量延迟的绝对差（max-min）和（b）相对百分比（max / min）的CDF。
现在，我们放大到一对特定的AWS地区，即俄勒冈州和弗吉尼亚州，以更好地了解流量延迟不公平性如何随时间逐渐显现出来。我们可以在图4中看到在每个1小时时间间隔内观察到的最小，第5，第25，第50，第75和第95个百分位数和最大延迟的分布。我们首先注意到可用路径随时间而变化。例如，在星期四，我们可以看到一条新的低延迟路径在几个小时内出现和消失。在其余时间中，延迟的分布似乎更加稳定。但是，这种稳定性并不一定意味着流在整个持续时间内都经历相同的等待时间。
图4-俄勒冈州和弗吉尼亚州地区之间以1小时间隔划分的512个不同流的延迟分布变化。
流经历频繁的延迟变化
我们继续对俄勒冈州-弗吉尼亚州的案例进行分析，以找出流量在移至新路径后在路径上停留了多长时间。图5显示了流的持久性，即在四个不同的区域，用粉红色的虚线绘制的俄勒冈-弗吉尼亚州，流被移动到不同的路径之前的时间。我们注意到，在大约20％的流量重新路由事件中，流量持续时间最多为10秒，这表明在美国这两个关键区域之间，流量到路径分配的高度不稳定。
图5 — CDF显示了四个AWS对的流重新路由事件的流持久性：圣保罗-蒙特利尔（纯蓝色）；巴黎-新加坡（橙色虚线）；悉尼－东京（红色虚线）；俄勒冈州弗吉尼亚州（虚线粉红色）。
一些流程会经历长时间的不公平
我们的上一次分析强调了打开连接时选择“良好” TCP源端口的重要性。图6显示了每个单独流（每个不同的TCP源端口）所经历的中值，第95和第99个百分位数延迟的CDF。我们的结果表明，在中位数下，某些流量在一周内可能会遭受超过12％的延迟不公平。
图6-512个受监视流上的流延迟百分位数的分布。
云时代的“公共地悲剧”
知名网络安全组织东方联盟透露：上述结果产生了两个有趣的含义。首先，云租户可能有动机来探究使用不同TCP源端口可获得的延迟，并在最低延迟路径上发送流量。此行为可能与云网络的TE操作冲突。云运营商可以通过更改可用路径上的TE流量分配比率，将流量主动移动到较少拥塞的路径。关于第一种实现，我们注意到现有的多路径传输协议（例如MPTCP）已经执行了对流空间的探索，以便在最低延迟的路径上发送流量。我们将对未来的激励兼容性进行研究。
最后，我们注意到由于云TE工具而导致的频繁路径更改可能导致租户的拥塞控制机制出现严重问题。例如，在重新路由事件期间，TCP New Reno将数据包重新排序解释为拥塞信号。这最终导致云租户不必要的吞吐量下降。我们将TE和拥塞控制机制的研究留作未来的工作。(欢迎转载分享)