摘要

  • RFC 10054 的示例中，计算最快的站点端到端耗时为 22.4 毫秒；网络最快的站点为 23.4 毫秒，两者都超过示例的 20 毫秒目标。
  • 第三个站点将 5 毫秒计算时延与 5 毫秒网络时延合并，文中总时延为 19.4 毫秒。这些是场景假设，并非现场测量。

处理器最快的站点输了。RFC 10054 的云端 VR 示例里，站点 1 用 4 毫秒完成计算，三者之中最快；但繁忙的网络路径又增加 9 毫秒，RFC 给出的完整运动到显示时延是 22.4 毫秒。示例的服务预算只有 20 毫秒。单看计算指标很漂亮，用户拿到的结果却没达到要求。

只看网络也会选错。站点 2 的网络路径最轻，耗时 4 毫秒，可它在高负载下需要 10 毫秒计算。文中端到端总数是 23.4 毫秒。站点 3 两项都很普通：计算 5 毫秒，网络 5 毫秒，加起来是 19.4 毫秒，也是唯一低于示例 20 毫秒门槛的选择。三四毫秒的差距，足以把满足应用需求与错过需求分开。

这正是“计算感知流量调度”要处理的问题。服务实例不会因为离用户近就自动合适，也不会因为处理器空闲就自动合适。用户感受到的是整条链：设备处理、传输、服务器渲染，再到返回路径。RFC 将 20 毫秒拆为传感器采样（低于 1.5 毫秒）、显示刷新（7.9 毫秒）、服务器渲染（5.5 毫秒）和往返网络（5.1 毫秒）。算力和网络各自占据预算的重要部分。只优化其中一项，忽略另一项，很可能把请求送往错误的站点。

RFC 10054 是一份说明问题和提出要求的 Informational 文档，场景范围限定为单一管理域。它没有证明某个部署已经按此方式选址。更实用的判断是：调度器的排序标准应对应应用端到端目标，而不是仪表板里最好看的一列数字。

Source: IETF RFC 10054.