LEOCraft: Towards Designing Performant LEO Networks¶
本文的写作思路, 和绘图方式非常值得学习.
笔者已经精读完全文, 这里复盘整理一下本文的写作思路与逻辑. 学习并以期看齐!
本文写作功底异常深厚, 非常值得作为系统类型的 template 积累 :)
Introduction¶
(1) 问题背景:
现在工业界关于星座设计、网络配置的信息都是闭源、专有的, 这对于 "多星座协作设计" 问题很不利.
(2) 问题是"新问题":
"星座设计" 的话题很早以前就被提出来了, 上世纪90年代就有一堆人在研究, 但当时针对的是GEO, 任务目标是: "如何用尽可能少的卫星覆盖全球?"
现在的 "LEO星座设计" 任务目标是: "在已知可以全球覆盖的前提下, 如何用尽可能少的卫星构建一个高效的LEO网络?"
因此我们格外关注: 在全球覆盖的前提下, 如何才能让网络性能更好?
Background¶
科普一下, 防止大同行看不懂
"星座设计" 有哪些参数: h, i, n, o, p, e
"星座流量矩阵如何构建?": xxx TM
"网络性能的衡量指标": Throughput, Stretch, Coverage
LEO network design from scratch¶
(1) 我们要解决什么问题:
在已知 卫星总数量, 地面站位置, 地面站之间的流量需求矩阵 的前提下, 寻找一组"最优"的星座设计参数
(2) 为什么 existing solutions 不行:
说白了 existing solutions 都是暴力求解.
朴素的暴力网格搜索法 -> 庞大的计算量 -> 计算资源浪费 + 时间成本过高
(3) 我们的核心洞见是什么, 我们准备如何去解:
利用 Domain knowledge 和 对参数特性的"启发式理解" 来大幅度裁剪搜索空间
- 我们根据不同的参数特性, 得出了几条 Key Insights, 作为 Domain knowledge
- 系统实现设计时:
- 独立"实例"包装
- process-level concurrency
Exploring the search space¶
参数特性有哪些? 得出来哪些 Key Insights?
Shaping an optimization strategy¶
上述的 Key Insights 如何服务于最终的优化搜索算法.
Designing of LEOCraft¶
(1) 现有仿真平台的致命瓶颈:
- StarryNet: Python GIL 限制 + Docker 容器资源限制
- Hypatia: ns-3 queue 未能利用多核 CPU
(2) 核心洞见: 网络计算的天然解耦性
很多组件是相互独立的, 可以作为不同类型的"实例"进行独立计算, 通过格式化的 API 进行数据交换即可.
(3) LEOCraft 为什么这么厉害
- 独立"实例"包装
- process-level concurrency