Virtual Stationary¶
While applications like in-orbit data processing (§3.3) can be opportunistically used on satellite-servers, for some of the use cases for in-orbit compute, such as multi-user interactivity (§3.2), the dynamic behavior of LEO constellations poses a challenge: a particular meetup-server is only reachable by clients for a few minutes, after which a hand-off is needed to a different satellite. This hand-off is different from cellular or WiFi hand-off due to the additional mobility of the network infrastructure — highly dynamic yet predictable. For applications that need to persist state over a specific geography, like for games and co-immersion involving a particular set of users, this requires careful migration of application state before a handoff. If this can be accomplished, a series of LEO meetup-servers expose to clients an abstraction similar to GEO satellites: stationary operation at (roughly) the same location over time.
尽管像在轨数据处理（§3.3）这样的应用可以机会性地在卫星服务器上使用，但对于在轨计算的某些用例，例如多用户交互（§3.2），LEO星座的动态特性构成了一个挑战： 一个特定的汇合点服务器仅在几分钟内可被客户端访问，之后便需要切换到另一颗不同的卫星 。
由于网络基础设施本身也在移动 —— 一种高度动态但可预测的移动 —— 这种切换不同于蜂窝网络或WiFi的切换。
对于需要在特定地理区域上保持状态的应用，例如涉及特定用户群体的游戏和共同沉浸式体验，这要求在切换前仔细地迁移应用状态。如果能够实现这一点，一系列LEO汇合点服务器就能向客户端呈现一种类似于GEO卫星的抽象： 在（大致）相同的位置上随时间推移进行静止操作。
The naive approach for selecting a meetup-server picks the latency-optimal satellite at each instant. We refer to this as “MinMax”, as it minimizes the maximum latency across a set of clients connected.
选择汇合点服务器的朴素方法是在每个瞬间选择延迟最优的卫星 。我们称之为“MinMax”方法，因为它最小化了所连接的一组客户端中的最大延迟。
Warning
这个 MinMax 的思路就很像 CSGI(infocom22) 里提到的 NSH, NSH 是永远连接 "distance min" 者
However, MinMax suffers from two problems: potentially frequent hand-offs to successor meetup-servers, and potentially large latency for some hand-offs. We thus propose an alternative heuristic, “Sticky”, that prioritizes stationarity by planning ahead leveraging predictable satellite motions, as follows:
(1) Compute the set of meetup-servers that provide latency within 10% of MinMax.
(2) For each of these candidate meetup-servers, compute the time until the next hand-off. Pick the 5 candidates with the longest time until a hand-off.
(3) Among these 5, pick one which would result in the least latency for hand-off to its successor.
然而， “MinMax”存在两个问题：可能需要频繁地切换到后继的汇合点服务器，以及某些切换可能导致较大的延迟 。
因此，我们提出了一种替代的启发式策略，名为 “Sticky”，它通过利用可预测的卫星运动进行提前规划，优先考虑静止性 ，具体如下：
(1) 计算出延迟在 “MinMax” 方法10%以内的汇合点 服务器集合。
(2) 对每一个候选汇合点服务器，计算其到下一次切换发生前的时间。选出距离切换时间最长的5个候选者。
(3) 在这5个候选者中，选择那个在向其后继者切换时能产生最低延迟的服务器。
Sticky 策略
先把条件放宽点: 得到“候选人”
候选人里再进一步筛选:
- 距离下一次切换 越远越好
- 最好延迟也最低
We find that Sticky results in slightly higher latency for the user-group, e.g., by 1.4 ms in the West Africa (3 users) example in Fig. 3. For this small price, Sticky substantially decreases the frequency of hand-offs, while the latency for state transfer to the successor remains similar across Sticky and MinMax.
Fig. 6 shows the distribution of times between satellite handoffs: the median time between hand-offs is 164 sec for Sticky, i.e., 4× longer than for MinMax. Further, as Fig. 7 shows, the latency incurred in migrating state to the successor server is similar and low for both approaches, with Sticky providing an advantage in the tail. Thus even simple heuristics can help decrease the satellite-churn applications see.
We acknowledge that state migration after every few minutes is still a substantial overhead. However, the high inter-satellite bandwidth could accommodate this. From the application perspective, it may be beneficial to separate session-specific state from generic application state, e.g., the player and game state versus the virtual world of a game, and perform live migration only for the session-specific state, while generic state is replicated even further ahead.
我们发现，“Sticky”方法导致用户群体的延迟略有增加，例如，在图3的西非（3用户）示例中，延迟增加了 1.4 ms。为了这个微小的代价，“Sticky”显著降低了切换频率，而向后继者传输状态的延迟在“Sticky”和“MinMax”两种方法中则保持相似。
图6显示了卫星切换间隔时间的分布：对于“Sticky”方法，切换间隔时间的中位数为 164 秒，比“MinMax”方法长4倍。
此外，如图7所示，两种方法在迁移状态到后继服务器时产生的延迟都相似且较低，而“Sticky”方法在尾部延迟上表现出优势。因此，即使是简单的启发式算法也有助于减少应用所经历的卫星频繁切换问题。
MinMax vs. Sticky
sticky 本质上就是稍微牺牲了“一丢丢” delay, 为 “维持更久的连接” 提供了回旋的空间
这就是为什么它更好（尽管这是一个最最显然的启发式）
我们承认，每隔几分钟进行一次状态迁移仍然是一个巨大的开销。然而，高星间带宽可以容纳这种开销。从应用的角度来看，将会话特定状态（session-specific state）与通用应用状态（generic application state）分开可能是有益的，例如，将玩家和游戏状态与游戏的虚拟世界分离开来，仅对会话特定状态执行实时迁移，而通用状态则可以更早地进行复制。