跳转至

WiFi, LTE, or Both? Measuring Multi-Homed Wireless Internet Performance

本文是一篇 IMC, 纯测量文章, 而不是提出架构解决实际问题

论文要回答的问题是: 一台同时有 WiFi 和 LTE 的手机，应用应该只用 WiFi、只用 LTE，还是用 MPTCP 同时跑两条链路？

当时 Android 的默认策略是"有 WiFi 就用 WiFi"，作者想用实测数据检验这个策略是否合理，并找出影响 MPTCP 性能的关键因素。

方法：三个层次的测量

① 众包单路径 TCP 测量（§2）

作者开发并发布了 Android 应用 Cell vs WiFi。每一轮测量的流程是：先连 WiFi，做 1 MB 上传和 1 MB 下载并抓 tcpdump；然后关闭 WiFi，切到蜂窝网络做同样的测试；最后上传数据和位置信息。服务器在 MIT。数据规模约 750 名用户、16 个国家。过滤掉只测了一种网络的轮次，并且只保留 LTE/HSPA+ 的数据后，剩下 1606 个完整轮次。下文提到的"LTE"都包含 HSPA+

② 手动 MPTCP 测量（§3）

  • 配置：
    • 客户端是一台笔记本（Ubuntu 13.10，Linux MPTCP v0.88），通过 USB 接两部手机
      • 一部只开 WiFi，一部只开 LTE（Verizon 或 Sprint）
      • alt text
    • 服务器在 MIT，只有一个网卡
  • 每轮测四种配置：
    • TCP-LTE
    • TCP-WiFi
    • MPTCP（LTE 做 primary）
    • MPTCP（WiFi 做 primary）

③ 应用层 record-and-replay（§4–5）

  • 用 Mahimahi 录制 App 的 HTTP 流量，App 包括 CNN、IMDB、Dropbox。作者还新写了 MpShell，用于模拟多条链路
  • 链路模型直接使用第 ② 部分在 20 个地点采到的单路径 TCP trace（trace-driven），共 20 种网络条件
    • 每种条件下跑 6 种配置：WiFi-TCP、LTE-TCP，以及 MPTCP 的 {coupled, decoupled} × {WiFi, LTE 做 primary}
  • 评价指标是 app response time，即第一个 HTTP 连接开始到最后一个 HTTP 连接结束的时间，不包含 App 本地的计算时间

需要先理解的几个 MPTCP 概念

  • Subflow / primary subflow：
    • MPTCP 连接中的每条 TCP 连接叫一个 subflow，最先建立的那条叫 primary subflow
    • 在 Linux 实现里，primary 走的是默认路由所在的接口。primary 建好之后，才会在其他接口上加入新的 subflow
  • Decoupled 拥塞控制：每个 subflow 各自独立跑 TCP Reno，彼此互不影响
  • Coupled 拥塞控制：各个 subflow 的拥塞窗口增长会同时参考其他 subflow 的 ACK（即 LIA 类算法）
    • 设计目的是对单路径 TCP 公平，代价是往往不如 decoupled 激进
  • Full-MPTCP 与 Backup 模式：
    • Full-MPTCP 模式：同时使用所有接口传数据
    • Backup 模式：只有一个接口传数据，另一个接口只在主接口断开时才接手
Tip

再次提醒笔者要去深入学一下 MPTCP 了...

主要结论与关键数据

1. LTE 胜过 WiFi 的比例比预期高（§2）

  • 按吞吐比较，LTE 更快的比例是上行 42%、下行 35%，合计 40%。两者吞吐差在任一方向上都可能超过 10 Mbps
  • 按 RTT 比较，有 20% 的轮次 LTE 的 ping RTT 比 WiFi 更低
  • 地区差异很大：Boston 只有 10% 的轮次 LTE 更快，Spain 和 Thailand 达到 80%
  • 由此得出的推论是，"有 WiFi 就用 WiFi"的静态策略并不合理

2. MPTCP 不一定比"选对网络的单路径 TCP"更好（§3.3）

alt text

  • 当两条链路速度相差很大时（图 7a），无论流多大，MPTCP 都不如最快的那条单路径 TCP
  • 当两条链路速度相当时（图 7b），大流用 MPTCP 能超过单路径 TCP
  • 两种情况下，小流都是"选对网络跑单路径 TCP"更好

3. Primary subflow 选哪个网络，对小流影响最大（§3.4）

  • 用 LTE 做 primary 和用 WiFi 做 primary，吞吐的相对差异中位数为：10 KB 时 60%，100 KB 时 49%，1 MB 时 28%
  • 原因在于：第二条 subflow 加入之前，整条连接的性能完全由 primary 决定，包括 SYN-ACK 的 RTT 和慢启动阶段的速度。在图 9a 中，WiFi 的 SYN-ACK 用了约 1 秒。小流在这段时间里就已经传完大半
  • 绝对吞吐差随流变大而增加，但相对比值随流变大而缩小。例如在图 11 中，100 KB 时比值为 2.2×，1 MB 时为 1.5×

4. 大流时拥塞控制的选择同样重要（§3.5，图 13、14）

  • 小流对网络选择更敏感，大流对拥塞控制更敏感
  • 工程上的考量：primary 网络由发起连接的一端单方面决定就行；而更换拥塞控制需要两端都支持，所以前者更容易落地

...