A Distributed Data Store in Orbit

Emerging Low Earth Orbit (LEO) satellite constellations have been considered for uses beyond plain Internet access, including content caching and edge computing. Assuming satellites are equipped with inter-satellite links, we propose using these links and thus the space in-between satellites, paired with a dedicated satellite queuing system, to “store” data and provide access by keeping data in constant flux around the globe. We describe the properties and explore the capabilities of such a system and discuss some potential uses.

新兴的低地球轨道（LEO）卫星星座已被考虑用于超越普通互联网接入之外的应用，包括内容缓存和边缘计算。假设卫星配备了星间链路，我们提出利用这些链路以及卫星之间的空间，并结合专用的卫星排队系统，通过 使数据在全球范围内持续流动的方式来“存储”数据并提供访问。

我们描述了该系统的特性，探索了其能力，并讨论了一些潜在的应用场景。

Introduction

As Low-Earth Orbit (LEO) satellite megaconstellations extend the reach of the Internet, speculations about further use beyond plain Internet access arise. These include ideas about caching content in space [7, 13], CDNs [4], computation in orbit [2, 11], edge computing in space [5, 8], and application-specific data aggregration, e.g., in the context of scientific data sensing from space [5]. Building satellite-based content delivery systems would usually require some control plane to locate content objects, route requests, perform load balancing, etc. and possibly actively manage content caches [4].

In this paper, we take a different route: we continuously move content objects, represented as a series of packets, around in the orbital shell, i.e., across all satellites on all orbits at the same altitude of a megaconstellation, one orbit at a time, so that satellites can just wait for objects, eliminating the need for active discovery. We leverage the large distances in space and the high data rate of intersatellite laser links, which together yield a substantial bandwidthdelay-product, to “store” content as data in flight between satellites in addition to providing extra storage on each satellite. In a sample configuration (see fig. 3 and 4), a single content object would traverse all 1,584 satellites (22 in each of 72 orbits) of the lowest Starlink orbital shell at 550 km altitude approximately every 11 seconds, covering a total distance of 3.27M kilometers.

We present our assumptions and system model in §2 along with the resulting basic system properties, especially the tradeoffs between storage capacity, content replication, and access latency. We discuss mechanisms for adding, replicating, deleting, and routing content objects in §3 and show via simulations how far simple local algorithms with limited state and a lightweight protocol can carry in §4. We conclude with a sample usages and a discussion of possible directions in §5.

随着低地球轨道（LEO）巨型星座扩展了互联网的覆盖范围，超越普通互联网接入的进一步应用设想随之出现。这些设想包括太空内容缓存[7, 13]、内容分发网络（CDN）[4]、在轨计算[2, 11]、太空边缘计算[5, 8]，以及特定应用的数据聚合（例如，在太空科学数据传感的背景下）[5]。构建基于卫星的内容分发系统通常需要一个控制平面来定位内容对象、路由请求、执行负载均衡等，并可能需要主动管理内容缓存[4]。

在本文中，我们另辟蹊径：我们将表示为一系列数据包的 内容对象，在轨道壳层中（即在巨型星座同一高度的所有轨道上的所有卫星之间）持续移动，每次一个轨道，这样卫星只需等待对象的到达，从而无需进行主动发现

我们利用太空中的巨大距离和星间激光链路的高数据速率——这两者共同产生了巨大的带宽延迟积——从而将内容作为卫星间传输中的数据进行“存储”，这补充了每颗卫星上额外的存储空间。在一个示例配置中（见图3和图4），单个内容对象将遍历位于550公里高度的星链最低轨道壳层上的所有1,584颗卫星（72个轨道，每个轨道22颗），大约每11秒完成一次，总距离达327万公里。

我们在第2节中介绍了我们的假设和系统模型，以及由此产生的基本系统特性，特别是存储容量、内容复制和访问延迟之间的权衡。我们在第3节中讨论了添加、复制、删除和路由内容对象的机制，并在第4节中通过仿真展示了状态有限的简单本地算法和轻量级协议能达到何种效果。最后，我们在第5节中以一些应用示例和对未来可能方向的讨论作结。

Design

We assume a LEO satellite constellation in a single orbital shell that covers the inhabited Earth surface with sufficient satellite density that each point on the ground within the coverage area is served by at least one satellite at any given instant. Each LEO satellite is equipped with four lasers to establish ISLs at data rates of \(R_{ISL}\) = 100 Gbps. Two of the ISLs connect each satellite to its preceding and succeeding neighbors in the same orbital plane, the remaining two connect to satellites in adjacent orbits, creating a +grid topology [3]. We assume that the satellites have sufficient power to operate their ISLs continuously, which appears reasonable as current LEO deployments use ISLs. We only consider the operation of a single orbital shell but our considerations can be extended to multiple shells.

Each user terminal connects to exactly one satellite at a time. The terminal reaches the Internet via a bent pipe to a ground station and point of presence (PoP) of the satellite operator. We assume that Internet traffic is routed to the closest ground station and does not traverse many ISLs, minimizing ISL use by end user traffic, so that the satellite operator may bound end user ISL traffic and dedicate an ISL capacity share to storage traffic \(f_s\).

Satellites of an orbital shell O are at an altitude \(a\) and at an inclination \(\gamma_0\). The shell is comprised of \(N_p\) orbital planes with \(N_0\) satellites per orbital plane (or: orbit), assumed to be evenly spaced at an angular distance of \(\alpha = 360°/N_o\). With a mean Earth radius of \(r\) = 6371 km, this yields a distance (line of sight) of \(d = 2(r+a)sin(\frac{1}{2}\alpha)\) as shown in figure 1a. The distance between satellites on adjacent orbital planes varies, being largest at the equator. Figure 1b illustrates the maximum distance \(d_s\) between the closest satellites on neighboring planes: the planes are spaced an equal angles of \(\beta = 360°/N_p\), yielding a distance of \(d_p = 2(r+a)sin(\frac{1}{2}\beta)\) (at the equator), and the satellites are at a maximum phase shift relative to each other, i.e., at an offset of \(\frac{d}{2}\) within their respective orbits. The resulting maximum distance at the equator is then \(d_s \approx \sqrt{\frac{1}{4}d_p^2 + d_p}\). To reduce the system dynamics to be accounted for and to obtain a conservative estimate, we assume the maximum distance \(d_s\) for computing the propation delay and we ignore that storage capacity of the links across planes.

Consider the Starlink orbital shell at \(a\) = 550 km altitude with \(N_p\) = 72 orbital planes at an inclination of \(\gamma_0\) = 53° and \(N_0\) = 22 satellites per orbit. The satellites on an orbital plane are spaced \(d\) = 1969.72 km apart, at the equator, the distance between two adjacent orbital planes is \(d_p\) = 603.78 km, and the max distance between the closest satellites on neighboring orbital planes is \(d_s\) = 1155.29 km.

我们假设在一个单一轨道壳层中部署一个LEO卫星星座，该星座以足够的卫星密度覆盖地球上有人居住的表面，确保地面上任意一点在任何时刻都至少被一颗卫星服务。每颗LEO卫星都配备四个激光器，以 \(R_{ISL}\) = 100 Gbps 的数据速率建立星间链路（ISL）。其中两条ISL将每颗卫星与其在同一轨道平面上的前后邻居相连，其余两条则连接到相邻轨道上的卫星，从而形成一个+网格拓扑[3]。我们假设卫星有足够的功率来持续运行其ISL，鉴于当前的LEO部署已在使用ISL，这一假设是合理的。我们仅考虑单个轨道壳层的运行，但我们的思路可以扩展到多个壳层。

每个用户终端在同一时间只连接一颗卫星。终端通过“弯管”模式连接到地面站和卫星运营商的接入点（PoP）来访问互联网。我们假设互联网流量被路由到最近的地面站，并且不穿越过多的ISL，从而最大限度地减少终端用户对ISL的使用。这样，卫星运营商就可以限制终端用户的ISL流量，并将一部分ISL容量份额 \(f_s\) 专门用于存储流量。

轨道壳层O中的卫星位于高度 \(a\) 和倾角 \(\gamma_0\)。该壳层由 \(N_p\) 个轨道平面组成，每个轨道平面（或轨道）有 \(N_0\) 颗卫星，并假设它们以 \(\alpha = 360°/N_o\) 的角距离均匀分布。以地球平均半径 \(r\) = 6371 km 计算，如图1a所示，这产生的（视线）距离为 \(d = 2(r+a)sin(\frac{1}{2}\alpha)\)。相邻轨道平面上卫星之间的距离是变化的，在赤道处最大。图1b展示了相邻轨道平面上最近卫星间的最大距离 \(d_s\)：这些平面以相等的角度 \(\beta = 360°/N_p\) 隔开，产生（在赤道处的）距离 \(d_p = 2(r+a)sin(\frac{1}{2}\beta)\)，并且卫星之间存在最大相位偏移，即在各自轨道内有 \(\frac{d}{2}\) 的偏移量。由此产生的在赤道处的最大距离为 \(d_s \approx \sqrt{\frac{1}{4}d_p^2 + d_p}\)。为了简化需要考虑的系统动态并获得一个保守的估计值，我们假设在计算传播延迟时使用最大距离 \(d_s\)，并忽略跨轨道平面链路的存储容量。

以星链轨道壳层为例，其高度 \(a\) = 550 km，轨道平面数 \(N_p\) = 72，倾角 \(\gamma_0\) = 53°，每轨道卫星数 \(N_0\) = 22。在同一轨道平面上的卫星间距 \(d\) = 1969.72 km，在赤道处，两个相邻轨道平面间的距离 \(d_p\) = 603.78 km，而相邻轨道平面上最近卫星间的最大距离 \(d_s\) = 1155.29 km。

2.1 System model

Figure 2 sketches part of a single satellite system focusing on the ISLs, i.e., not including the radio links to the ground stations and terminals. Each satellite, at a minimum, provides two send queues of different sizes per interface: one for regular (= Internet) traffic of size \(Q_I\) and one for storage traffic of size \(Q_S\). The queues receive proportional treatment when scheduling packets for transmission on an ISL with a share \(f_s\) reserved for storage traffic, e.g., using weighted fair queuing.

A content object maintained in the data store comprises a sequence of packets, each packet including at least the content id (e.g., a hash) and total size, its data offset into the object, its expiration time, the total number of replicas and the replica instance number, and a (cryptographic) checksum. A meta data table on the satellite records per content object the id (32 bytes), size (6 bytes), expiration time (6 bytes), sojourn time (6 bytes), and the storage queue (Q, 1 byte), plus internal maintence data, yielding some 64 bytes per record, so that 1M entries would only consume \(\approx\)60 MB of memory.

The figure also shows packets incoming from ISL 2 that are classified into Internet and data store traffic and then handled by independent forwarding units that determine their respective next hops, e.g., ISL 0 or 1: the Internet forwarder implements regular L2 switching or IP routing while the data store forwarding logic comprises algorithms to ensure that content object packets circle through all satellites of an orbital shell, to insert, possibly replicate, and delete packets, and to perform error control. We will return such algorithm in §3 and assume for now that a simple one exists that forwards each packet along one orbit at a time and then shifts to the next plane, as illustrated in figure 3.

The data store access unit interfaces to all storage queues and responds to content object requests from satellite terminals (not shown). The data store forwarder records which content objects are in which ISL storage queue along with its expected sojourn time. Given sufficient capacity, a record could be kept for all objects in orbit until they expire and hold the # replicas per object (cf. §2.2) and when it last passed through this satellite. This tells the data store access unit from which queue to fetch the content object, whether it would be feasible to retrieve it from a nearby satellite, or to predict when its next pass through this satellite is expected.

Content requests would, by default, arrive via the radio interfaces to the ground, but they could also be forwarded by neighbors if those cannot satisfy a request immediately or in the near future. We leave this cooperative caching-style optimization using known techniques for future work.

2.1大多数都不用看, 注意一下dataflow就行

图2描绘了单个卫星系统专注于ISL的部分，即不包括与地面站和终端的无线电链路。每颗卫星的每个接口至少提供两个不同大小的发送队列：一个用于大小为 \(Q_I\) 的常规（=互联网）流量，另一个用于大小为 \(Q_S\) 的存储流量。在调度数据包以在ISL上传输时，这些队列会得到按比例的处理，其中一部分份额 \(f_s\) 保留给存储流量，例如使用加权公平排队。

数据存储中维护的内容对象包含一系列数据包，每个数据包至少包括内容ID（例如哈希值）和总大小、其在对象中的数据偏移量、过期时间、副本总数和副本实例编号，以及一个（加密的）校验和。卫星上的元数据表为每个内容对象记录ID（32字节）、大小（6字节）、过期时间（6字节）、停留时间（6字节）和存储队列（Q，1字节），外加内部维护数据，每条记录约64字节，因此100万条目仅消耗约60 MB的内存。

该图还显示了从ISL 2传入的数据包被分类为互联网流量和数据存储流量，然后由独立的转发单元处理以确定其各自的下一跳，例如ISL 0或1：互联网转发器实现常规的L2交换或IP路由，而数据存储转发逻辑则包含确保内容对象数据包环绕整个轨道壳层所有卫星的算法，用于插入、可能地复制和删除数据包，并执行错误控制。我们将在第3节中回到该算法，并暂时假设存在一个简单的算法， 该算法将每个数据包先沿着一个轨道转发，然后再切换到下一个平面 ，如图3所示。

数据存储访问单元与所有存储队列接口，并响应来自卫星终端（未显示）的内容对象请求。数据存储转发器记录哪些内容对象位于哪个ISL存储队列中及其预期的停留时间。在容量充足的情况下，可以为轨道中的所有对象保留一条记录，直到它们过期，并记录每个对象的副本数（参考§2.2）以及它最后一次经过该卫星的时间。这告诉数据存储访问单元从哪个队列中获取内容对象，是否可以从附近的卫星检索，或者预测它下一次经过该卫星的预期时间。

默认情况下，内容请求将通过无线电接口到达地面，但如果邻近卫星无法立即或在不久的将来满足请求，它们也可以转发请求。我们把这种使用已知技术的协作式缓存优化留作未来的工作。

2.2 Basic properties and trade-offs

We now take a brief look at the theoretical properties of our design. With content objects in constant flux around the globe, two performance metrics are of particular interest: the total storage capacity, \(C_o\), of the orbital shell and the content periodicity, \(t_a\). The periodicity \(t_a\) is defined as the time elapsing between a given content object (or one of its replicas) passing twice through the same satellite and serves as a rough approximation of the worst case access latency from a terminal connected to that satellite.

For storage capacity, we consider: 1) the storage queue for each ISL transmitter, \(Q_s\), and 2) the data in flight on each ISL, \(F_s = \frac{d}{c} \times f_s \times R_{ISL}\), as per the link’s bandwidth-delay product for the traffic share \(f_s\), with \(c\) = 299,792.458 km/s. This yields a capacity per satellite (including one outgoing ISL within its orbit) of \(C_s = Q_s + F_s\), per orbital plane of \(C_p = C_s \times N_o\), and per orbital shell of \(C_o = C_p \times N_p\). Due to their potential variability, we do not account for the capacity added by links across orbital planes. If K replicas of content objects are kept, the effective storage capacity of the shell is \(C_e = \frac{C_o}{K}\).

For the latter, access latency, we compute how long it takes a single content item to pass through the entire orbital shell, \(t_o\). We consider the processing and queuing delays per satellite, \(t_f\) and \(t_q\), respectively, as well as the propagation delay for each link within an orbital plane, \(t_p\), and across orbital planes \(t_s\). We assume \(t_f\) = 0.1 ms for each content object, which roughly matches the interarrival time of 1 MB sized objects at \(R_{ISL} \times f_s\) = 80 Gbps and allows for sufficient local processing and state management. We obtain the maximum \(t_q = \frac{f_r \times Q_s}{R_{ISL} \times f_s}\) and the propagation delays as \(t_p = \frac{d}{c}\) and the worst case \(t_s = \frac{d_s}{c}\). This yields the maximum time for a content object to pass through all satellites of a shell, the rotation time, \(t_o\), as

\(t_o = N_o \times (t_f + t_q + t_p) + N_p \times (t_f + t_q + t_s)\)

for the above simple propagation pattern (fig. 3). As for storage capacity, we may assume K replicas of a content item evenly spaced across all satellites, which would reduce the periodicity, i.e., the effective access latency to \(t_a = \frac{t_o}{K}\).

Figure 4 shows the effective storage capacity \(C_o\) (left) and effective periodicity \(t_a\) (\(\approx\) access latency, right) for the Starlink orbital shell 1 at 550 km altitude. Assuming a target access latency of <10 s, we see that up to 20 replicas would be needed, whereas staying below 30 s 1–8 replicas suffice.

There is an obvious tradeoff between capacity and periodicity. Combining both, we may set a target periodicity and derive the necessary number of replicas for a given storage queue size, from which we can then compute the effective storage capacity. Doing this for all megaconstellations as per table 2 in Appendix B, we show the effective capacity of the data store for a target periodicity of 10 s as a function of the queue size in figure 5 (top). We find that increasing the storage queue size yields an increasing capacity, albeit not monotonically. The capacity growth is expectedly more pronounced for shells with fewer orbits (Starlink 3, 4, 5 use just 8, 5, and 6 orbits, respectively) as less data is “in flight” between satellites on fewer orbits. Fluctuation appears stronger for those shells with fewer satellites. As increasing queue capacity leads to longer object rotation times \(t_o\), this needs to be compensated by additional replicas so that we observe diminishing (if any) returns. The capacity grows roughly linearly as a step function with increasing periodicity (figure 5, bottom). Overall, we obtain some 40–80 GB storage capacity for a periodicity of 10 s pretty much independent of the megaconstellation.

Above, we assume sending the content objects into one direction through the orbital plane, hence only considering half the available transmission and storage capacity. Using both directions would thus duplicate the available capacity and further reduce the latency; however, the intervals at which content objects pass through a satellite would no longer be uniformly distributed; this is left for future study.

我们现在简要探讨我们设计的理论属性。由于内容对象在全球范围内持续流动，我们特别关注两个性能指标：轨道壳层的总存储容量 \(C_o\) 和内容周期性 \(t_a\)。周期性 \(t_a\) 定义为给定内容对象（或其副本之一）两次经过同一颗卫星之间所耗费的时间，它可作为从连接到该卫星的终端进行访问的最坏情况延迟的粗略近似。

对于存储容量，我们考虑：1）每个ISL发射器的存储队列 \(Q_s\)，以及2）每个ISL上的在途数据 \(F_s = \frac{d}{c} \times f_s \times R_{ISL}\)，这是根据链路的带宽延迟积和流量份额 \(f_s\) 计算得出的，其中 \(c\) = 299,792.458 km/s。这得出了每颗卫星的容量（包括其轨道内的一个出向ISL）为 \(C_s = Q_s + F_s\)，每个轨道平面的容量为 \(C_p = C_s \times N_o\)，以及每个轨道壳层的容量为 \(C_o = C_p \times N_p\)。由于其潜在的可变性，我们不计算跨轨道平面链路增加的容量。如果内容对象保存K个副本，则壳层的有效存储容量为 \(C_e = \frac{C_o}{K}\)。

对于后者，即访问延迟，我们计算单个内容项穿过整个轨道壳层所需的时间 \(t_o\)。我们考虑每颗卫星的处理和排队延迟 \(t_f\) 和 \(t_q\)，以及在轨道平面内每个链路的传播延迟 \(t_p\) 和跨轨道平面的传播延迟 \(t_s\)。我们假设每个内容对象的 \(t_f\) = 0.1 ms，这大致匹配1 MB大小的对象在 \(R_{ISL} \times f_s\) = 80 Gbps速率下的到达间隔，并允许足够的本地处理和状态管理。我们得到最大排队延迟 \(t_q = \frac{f_r \times Q_s}{R_{ISL} \times f_s}\)，以及传播延迟 \(t_p = \frac{d}{c}\) 和最坏情况下的 \(t_s = \frac{d_s}{c}\)。由此，我们得出内容对象穿过壳层所有卫星的最长时间，即旋转时间 \(t_o\)，为：

\(t_o = N_o \times (t_f + t_q + t_p) + N_p \times (t_f + t_q + t_s)\)

这是基于上述简单的传播模式（图3）。至于存储容量，我们可以假设一个内容项的K个副本均匀分布在所有卫星上，这将减少周期性，即有效访问延迟为 \(t_a = \frac{t_o}{K}\)。

图4显示了在550公里高度的星链轨道壳层1的有效存储容量 \(C_o\)（左）和有效周期性 \(t_a\)（约等于访问延迟，右）。假设目标访问延迟小于10秒，我们看到可能需要多达20个副本，而若要保持在30秒以下，1-8个副本就足够了。

容量和周期性之间存在明显的权衡。结合两者，我们可以设定一个目标周期性，并为给定的存储队列大小推导出必需的副本数量，然后由此计算出有效存储容量。我们对附录B表2中所有巨型星座进行了此项计算，并在图5（顶部）中展示了在目标周期性为10秒的情况下，数据存储的有效容量随队列大小变化的函数。我们发现，增加存储队列大小会带来容量的增加，尽管并非单调增长。对于轨道较少的壳层（星链3、4、5分别仅使用8、5和6个轨道），容量增长预计更为明显，因为在较少轨道间的卫星之间“在途”的数据更少。对于那些卫星较少的壳层，波动似乎更强。由于增加队列容量会导致更长的对象旋转时间 \(t_o\)，这需要通过增加副本来补偿，因此我们观察到收益递减（如果存在的话）。容量随着周期性的增加大致呈阶跃函数线性增长（图5，底部）。总体而言，我们获得了约40–80 GB的存储容量，其周期性为10秒，这几乎与具体的巨型星座无关。

以上，我们假设内容对象在轨道平面内沿一个方向发送，因此只考虑了一半的可用传输和存储容量。使用两个方向将使可用容量加倍并进一步减少延迟；然而，内容对象经过卫星的时间间隔将不再是均匀分布的；这留待未来研究。

Discussion and Conclusion

In this paper, we take an unconventional approach to distributed data handling: we exploit the vast distances in space between satellites to store data “in flight” and have objects constantly rotate through all access locations so that requesting nodes just have to wait for them to pass by—rather than fixing the (replicated) storage locations and maintaining an index to find the data via a control plane. The availability of powerful ISLs in LEO satellite megaconstellations could provide a foundation for such design. While our strawman algorithm makes full use of ISLs within an orbital plane and largely spared those interconnecting different orbital planes, other configurations are conceivable, including mixing different shells to differentiate on latency and capacity needs.

But what to do with a modest amount of distributed storage capacity of some 40–80 GB at an access latency of <10s (or more with additional delay)? Anything requiring large volumes such as CDNs [4] would need different mechanisms but other interesting uses come to mind: One option is building a global user directory (a key-value store) with entries exclusively updated by their owners, e.g., along the lines of a Minimal Global Broadcast [10]: 128 B per user would just require 675 MB of storage and be hardly noticeable, leaving room for growth; extending this to today’s 5.5 bn Internet users would require 670 GB and thus 512 MB storage queues. Another idea is using space as a backup for critical infrastructure data, such as the globale BGP routing tables: the 1.5 GB data (Sep 2024, from routeviews.org) would fit easily and need only a very small link capacity share.

While we explored storage queues of various sizes, an interesting case is an effectively queueless system for global broadcasting with memory: as shown in table 3, small content objects of a total volume of 7–100 GB could circulate once per 1–11 s. We may exploit these properties to efficiently distribute state synchronization messages in global consensus protocols where individual transactions are rather small. This may allow for a small high-priority traffic share 𝑓 𝑠 , in some cases, even LEDBAT-style scavenging traffic may suffice: both could be a start to explore this concept further.

在本文中，我们采用了一种非常规的分布式数据处理方法：我们利用卫星间广阔的空间距离来“在途”存储数据，并让数据对象持续循环经过所有接入点，这样请求节点只需等待它们经过即可——而不是固定（复制的）存储位置，并通过控制平面维护索引来查找数据。LEO巨型卫星星座中强大的星间链路（ISL）的可用性，可为此类设计提供基础。尽管我们的草案算法充分利用了轨道平面内的ISL，并在很大程度上避免了使用连接不同轨道平面的链路，但其他配置也是可以设想的，包括混合使用不同的轨道壳层，以根据延迟和容量需求进行区分。

但是， 对于约40–80 GB的有限分布式存储容量，以及小于10秒的访问延迟（或在有额外延迟时更长），我们能用它来做什么呢？任何需要像CDN [4]那样巨大容量的应用都需要不同的机制， 但我们能想到其他一些有趣的用途：一个选择是构建一个全球用户目录（一个键值存储），其条目仅由其所有者更新，例如，类似于“最小全球广播”[10]的思路：每个用户128字节将仅需675 MB的存储空间，几乎可以忽略不计，并为未来的增长留下了空间；若将其扩展到当今55亿互联网用户，则需要670 GB的存储空间，即512 MB的存储队列。另一个想法是将太空用作关键基础设施数据的备份，例如全球BGP路由表：这1.5 GB的数据（2024年9月，来自routeviews.org）可以轻松容纳，并且仅需占用极小的链路容量份额。

虽然我们探讨了不同大小的存储队列，但一个有趣的案例是用于带记忆的全球广播的“有效无队列”系统：如表3所示，总容量为7–100 GB的小型内容对象可以每1–11秒循环一次。我们可以利用这些特性，在全球共识协议中高效地分发状态同步消息，因为在这些协议中单个事务的规模通常相当小。这可能允许一小部分高优先级流量份额 \(f_s\) 存在，在某些情况下，甚至LEDBAT式的“机会性”流量就足够了：这两者都可以作为进一步探索此概念的起点。