Network Migration 专题¶
互联网中有很多站在“过渡与变革期”的时刻, 包括但不限于:
- 3 -> 4 -> 5G
- IPv4 -> IPv6
- WiFi <-> Cellular
- Transport Layer Mechanism
- 比如 MPTCP, QUIC 相较于传统 TCP
本模块我们计划汇总整理这些"过渡期"重要时刻, 哪些团队站了出来, 发现了什么问题, 采用什么样的方法解决
(1) 3/4/5G
- [MediaTek WhitePaper 20] 5G NR and 4G LTE Coexistence
- [SIGCOMM 20] Understanding Operational 5G: A First Measurement Study on Its Coverage, Performance and Energy Consumption
- [NSDI 16] iCellular: Device-Customized Cellular Network Access on Commodity Smartphones
- [SIGCOMM 14] Control-Plane Protocol Interactions in Cellular Networks
- [MobiCom 24] M2HO: Mitigating the Adverse Effects of 5G Handovers on TCP
- [MobiCom 20] iCellSpeed: Increasing Cellular Data Speed with Device-Assisted Cell Selection
| 论文 | 核心 | 推荐系数 | 亮点与评价 |
|---|---|---|---|
| MediaTek 4to5G | 4/5G过渡期的频段设计 | 0 | 没啥看点, 主要聚焦物理层和频段, 适合搞通信的 |
| CrossLayer 5G | NSA/SA 的"初代" 5G 测量 | 2 | 纯测量, 记点结论得了 5G NSA 状态机画的不错; 半实物仿真图画的也可以 |
| iCellular | UE 基于底层蜂窝信息, 进行 多运营商 (Multi-PLMN) 的"无缝"+"正确"切换 | 5 | 惊为天人, yuan神大作, 膜拜了! 实测发现：多运营商的潜力没有被充分发挥 (固执不切/切错/超时) 根因：终端拿不到底层蜂窝信息 + 单个 运营商 没有全局视图，全局视图只能在 终端 上构建 |
| CNetVerifier | 3G/4G 控制面信令交互"耦合"导致的问题分析 | 5 | yuan神大作, 继续膜拜! (1) cross-layer, cross-domain, cross-system 交互导致的问题 (2) 问题出在交互本身: 必要的协作没有做好 + 不必要的耦合却被引入 (3) 非常适合入门学习 3/4G 控制层信令 |
| M2HO | TCP 利用 UE 链路层信息, 进行rwnd调节. 确保无缝切换+高带宽 | 5 | 深度好文! 切换问题 -> 需要跨层优化 问题: 5G 网络 TCP CUBIC 带宽利用率低 根因: 切换过程中链路层与 TCP 的三种不当交互 解法: "链路层+传输层"跨层优化 |
| iCellSpeed | UE 基于底层蜂窝信息做"HACK", 对网络侧选择逻辑进行引导, 实现切换至 "Good Performance Cell" 而不是 "Good Radio Cell" | 5 | 跟 iCellular 一脉相承. 二者本质差异: - iCellular 选的是哪家运营商（跨运营商，改造 PLMN selection） - iCellSpeed 选的是同一家运营商内的哪几个小区（运营商内部，绕过连接态 handoff） Key Insight: 手机改变不了网络的选择逻辑，但能改变它的输入! 通过在UE侧"HACK"实现对网络侧选择的"引导" iProfile离线/在线维护画像; iCustomize在信令交互之间做"HACK" |
(2) WiFi-Cellular
- [MobiCom 14] A Practical Traffic Management System for Integrated LTE-WiFi Networks
- [CellNet 12] Exploring Mobile/WiFi Handover with Multipath TCP
- [SIGCOMM 21] XLINK: QoE-Driven Multi-Path QUIC Transport in Large-scale Video Services
- [IMC 14] WiFi, LTE, or Both? Measuring Multi-Homed Wireless Internet Performance
- [SIGCOMM 17] Wi-Fi Goes to Town: Rapid Picocell Switching for Wireless Transit Networks
- [NSDI 15] Towards Wifi Mobility without Fast Handover
- [CoNEXT 10] Mobile Data Offloading: How Much Can WiFi Deliver?
| 论文 | 核心 | 推荐系数 | 亮点与评价 |
|---|---|---|---|
| ATOM | WiFi-LTE 做动态调度+无缝切换 | 5 | 超级好文章! 大道至简! 依旧是"任何系统问题都可以通过中间层解决" Key Insight: 不必维持IP, 维持完整的HTTP应用层session即可 做法: 在核心网侧, 建立 ATOM: 为网络侧和用户终端侧均建立 HTTP Proxy |
| WiFi MPTCP | MPTCP 在 WiFi→3G 下的实测性能分析 | 1 | 偏实测分析, 而不是提出架构解决实际问题, 参考意义不大 |
| XLINK | |||
| Multihome | 只用 WiFi? 只用 LTE? 用 MPTCP 同时跑两条链路? | 3 | 实测分析. 重要结论: (1) 两条链路速度相差很大时, 无论流多大, MPTCP 都不如最快的那条单径 TCP (2) 两条链路速度相当时, 大流用 MPTCP 能超过单径 TCP (3) 小流对网络选择更敏感，大流对拥塞控制更敏感 |
| WiFi GoTown | 汽车在密集WiFi区, 应保持多连接, 由 AP Controller 集中式负责 切换等机制 | 3 | 属于 "企业网中的切换优化(无线控制器)" 类别. 个人认为不一定有用 优点: 本文 系统架构图/半实物仿真图 绘制的不错 |
| WiFi FastHandover | 现有的WiFi坚持"单AP连接+FastHandover"是根本上错误的, 应该 MPTCP 进行"多AP同时连接" | 5 | 好文章: 启发: 借助 MPTCP，把 L2 切换问题交给 L4 解决 |
| 3G WiFi Deliver | WiFi Offloading 两种方式卸掉多少流量最好? | 2 | DTN 思想太重要了! MobiCom23-CosMAC 估计就是仿照这个思想的 Offloading方式: On-the-spot offloading + Delayed offloading |
(3) IPv4 -> IPv6
- [IMC 25] Towards a Non-Binary View of IPv6 Adoption
- [SIGCOMM 14] Measuring IPv6 adoption
- [RFC 4213] Basic Transition Mechanisms for IPv6 Hosts and Routers
- [RFC 6877] 464XLAT: Combination of Stateful and Stateless Translation
- [RFC 8305] Happy Eyeballs Version 2: Better Connectivity Using Concurrency
- [RFC 8170] Planning for Protocol Adoption and Subsequent Transitions
| 论文 | 核心 | 推荐系数 | 亮点与评价 |
|---|---|---|---|
| TBD | |||
| TBD | |||
| TBD | |||
| TBD | |||
| TBD | |||
| TBD |
(4) Transport Layer
- [IMC 11] Is it Still Possible to Extend TCP? (MPTCP)
- [NSDI 12] How Hard Can It Be? Designing and Implementing a Deployable Multipath TCP (MPTCP)
- [SIGCOMM 17] The QUIC Transport Protocol: Design and Internet-Scale Deployment (QUIC)
| 论文 | 核心 | 推荐系数 | 亮点与评价 |
|---|---|---|---|
| IMC-MPTCP | 实测说明"MPTCP需要重点考虑MiddleBox" (实测) | 3 | NSDI12-MPTCP 的前作. 给3分是因为笔者不喜欢看测量类型的文章 |
| NSDI-MPTCP | 现实中的网络需要考虑MiddleBox, MPTCP究竟应如何设计? (标准化设计) | 5 | 巅峰之作! M.Handley 真 NetSys 祖师爷 一条 MPTCP 连接由多个 subflow 组成, 每个子流在网络上看起来就是一条完全正常的 TCP 连接: (1) token 是 sessionID (2) DSN 是 subflow 的ACK (3) Data ACK 是全局 ACK (4) recv 所有 subflow 共享 shared buffer |
| TBD |