Exploring Mobile/WiFi Handover with Multipath TCP

本文是一篇 workshop paper, 偏实测分析, 而不是提出架构解决实际问题

3G 容量吃紧，运营商希望把流量卸载到 WiFi。但当时终端同一时刻只用一个网络，WiFi↔3G 切换会改变 IP 地址。普通 TCP 连接由四元组标识，IP 一变连接就断，应用必须重连。

MPTCP 把"连接"和"IP 地址"解耦：一条 MPTCP 连接由多条 TCP 子流（subflow）组成，子流可以增删而连接本身不受影响。这一点理论上天然支持垂直切换，但此前只有仿真评估。

本文的定位是首次在真实 WiFi/3G 网络、用真实应用实测 MPTCP 垂直切换

Tip

这倒是提醒笔者了: 抓紧时间熟悉一下 MPTCP

---

1. 背景

3G 网络难以承载暴涨的移动流量，运营商希望把流量卸载到 WiFi。但当时终端同一时刻只用一个网络，WiFi↔3G 切换会改变 IP 地址，导致所有 TCP 连接断开重连。

2. 问题与动机

问题是：MPTCP 在协议设计上支持子流增删，理论上能实现对应用透明的垂直切换，但它在真实无线网络和真实应用下能否平滑切换、代价多大，此前只有仿真结论。

这件事值得做，是因为切换中断直接损害用户体验，而应用层方案（如 HTTP Range 断点续传）需要改应用，且只有 39% 的网站支持，无法通用。

3. 方法论

• KeyInsight：
  • MPTCP 把"连接"与"IP 地址"解耦，切换就变成"增删子流"
  • 真正的瓶颈不在 TCP 握手，而在 3G 接口的唤醒延迟和不可靠的地址信令（REMOVE_ADDR）
• Methodology：
  • 在 Linux MPTCP 上实现三种切换模式，即：
    • Full-MPTCP（全用）
    • Backup（3G 子流建好但不传数据）
    • Single-Path（断了再建）
  • 在真实 WiFi/3G 网络中实测吞吐、应用时延、Skype 通话效果，并在 Nokia N950 上测能耗，给出"性能—能耗"权衡下的模式选择建议
• Design Overview：
  • 针对实测发现的 REMOVE_ADDR 丢失问题（会导致 Backup 模式卡死、Full-MPTCP 模式要等 RTO），用选项中的空闲位作为 echo bit 做确认重传，使地址信令可靠送达