Characterizing the Configuration of Starlink Queuing

Unknown

Conceptio › Archive › arXiv CS

arXiv CSopen access

Characterizing the Configuration of Starlink Queuing

Unknown · 2026 · arxiv_cs

arXiv CS · Papers · License: Open Access · 2026

Open Source ↗Direct PDF ↓

distributedsystems protocols

networking, internet, protocols, distributed systems

Characterizing the Configuration of Starlink Queuing Johan Garcia

Simon Sundberg

Anna Brunstrom

Karlstad University Karlstad, Sweden [email protected]

arXiv:2605.27717v1 [cs.NI] 26 May 2026

Abstract In all networking systems, queuing is important to ensure appropriate resource utilization in the presence of bursty traffic and varying traffic demands. The Starlink access network is additionally also dynamic in terms of the capacity it can provide, and thus queuing plays an even greater role to ensure appropriate communication performance for the end-users while maintaining high resource utilization. However, for Starlink most system design details, along with the setup of the internal queuing, is private information and not publicly available. To address this we have developed a highprecision, burst-pattern controlled, traffic generation approach allowing us to precisely measure the one-way delay for Starlink. By analyzing the delay and loss in conjunction with a queue simulator we find that Starlink does not employ per-flow fair queuing or droptail buffers, but it does use drop-front buffer management. While drop-front reduces delay, it may also interfere with the assumptions made by loss-based congestion controls, potentially contributing to throughput degradation.

CCS Concepts • Networks → Network measurement; Network performance modeling; Network simulations; Wireless access networks.

Keywords Starlink, Queuing, Network Measurements, Satellite Network, LEO ACM Reference Format: Johan Garcia, Simon Sundberg, and Anna Brunstrom. 2026. Characterizing the Configuration of Starlink Queuing . In Proceedings of the 2026 ACM Internet Measurement Conference (IMC ’26), October 12–16, 2026, Karlsruhe, Germany. ACM, New York, NY, USA, 10 pages. https://doi.org/10.1145/ 3777912.3809153

The queuing behavior is of considerable importance, as it can have a large influence both on latency, and on the congestion control (CC) behavior of the forwarded traffic. In this study, we perform a comprehensive examination of Starlink queuing utilizing two geographically separated user terminals. To have detailed control of the generated probing traffic, a custom traffic generator is utilized. We design a probe pattern encompassing some 325000 UDP probe packets, which are grouped into 120 distinct traffic burst types, where the burst types vary in terms of burst send rate and burst length. Through repeated experiments this results in more than 10 million probe packets, which are analyzed to infer details about the queuing configuration. We find evidence indicating that Starlink queues are not set up with per-flow fair queuing, but instead all flows of a user share a single queue. Perhaps most interestingly, we find that the buffer management strategy, in terms of deciding which packets to drop, is not the commonly used drop-tail, but rather a drop-front strategy. While drop-front reduces latency in that its average queuing delay is lower, drop-front may interact with CC dynamics. This finding is quite significant, as it provides additional background to the poor Starlink throughput performance observed by CCs that use packet loss as their main congestion signal. Severe underutilization of the potentially available communication resources occurs when a single flow is transferred using a loss-sensitive CC such as Cubic [14, 26, 30, 38]. As Cubic is the default CC in the Linux kernel, a large fraction of all traffic traversing Starlink can be expected to be Cubic traffic, and this traffic can attain considerably lower throughput possibly linked to the queuing characteristics uncovered in this investigation. This work provides the following main contributions: • A flexible queue characterization methodology employing precise pattern-controlled traffic generation. • A queuing simulator allowing insights to be drawn by fitting against the empirical observations. • A detailed characterization of the Starlink queuing configuration, including the likely queue size. • Additional insight into the low-throughput anomaly that has been observed for loss-based CCs, such as Cubic, over the Starlink network.

Introduction

Starlink currently provides Internet access to more than 8 million users [46] and is an important connectivity provider to remote and under-served areas. Despite its importance in the Internet ecosystem as a connectivity provider with extremely wide coverage, many technical details of the Starlink network configuration, and the resulting performance, are not publicly known. While there have been a number of studies aiming to better understand the characteristics of various components of the Starlink network [12, 31, 42, 43] and the service it provides [15, 22, 26, 39], so far there has been no study focusing on the queuing behavior of Starlink.

This work is licensed under a Creative Commons Attribution 4.0 International License. IMC ’26, Karlsruhe, Germany © 2026 Copyright held by the owner/author(s). ACM ISBN 979-8-4007-2327-8/2026/10 https://doi.org/10.1145/3777912.3809153

To allow further analyses we provide our data and the queuing simulator developed for this research [10].

Background and related work

It is well known that the Starlink network characteristics vary over time in terms of available capacity, round-trip time and packet loss [15, 30, 39]. Previous work has established that Starlink uses a

IMC ’26, October 12–16, 2026, Karlsruhe, Germany

15-second reconfiguration interval [15, 39] and schedules transmissions in 1.33 ms link layer frames [12, 21]. The short term throughput of Starlink is dependent on the physical transmission rate, and the allocation structure of the link layer frames [9, 11]. Potential queuing within the user-facing edge router is examined in [17], but as this router is not the end-to-end bottleneck no significant buffer buildup was identified. In contrast, our work concerns the queue at the actual end-to-end bottleneck, and provides a detailed characterization of its behavior. In terms of approaches for evaluating queuing configuration, the Tada approach [25] intends to detect if a bottleneck router uses active queue management (AQM) or not, while being robust to shared background traffic and potentially multiple bottlenecks. Our setting here is more constrained, while also having a wider analysis objective. A method for detecting FIFO, PIE and FQ-CoDel AQM in the context of DASH-like streaming is described in [28]. Detecting the presence of fair queuing is covered in [1]. The queuing configuration interacts with the CC, and there have been several studies evaluating CCs specifically for Starlink. In [6] 10-flow measurements show that BBR performs better than Cubic, while [30] examines several CCs and finds that Cubic achieves a quarter of the uplink throughput compared to BBRv1. Other measurement studies include [39], which provides global throughput results based on 10s long single flow measurements from a large number of servers with unspecified CC configuration. In [20] TCP throughput is evaluated for single, four, and eight flows with an unspecified CC variant, likely Cubic. An early work [26] compared 5 CCs, including BBR and Cubic, using an unspecified number of flows, finding that BBRv1 achieves much higher throughput than Cubic. In [38] Iperf3 is used with Cubic, with an unspecified duration and number of flows. That work also measures throughput with UDP, and reports TCP achieving 39 % of the UDP throughput, which indicates considerable underutilization for the Cubic CC. A recent comparison between Cubic, BBR and several other CCs highlighted that single flow Cubic on average reached less than a quarter of the BBR throughput [14]. There are also several studies focusing on LEO-specific CC improvements, including LeoCC [29] which also considers the impact of buffer management on their proposed scheme. LEO-adapted CC for QUIC is examined in [24, 51], while SaTCP is proposed and evaluated against Cubic in [4]. Some studies have used simulation or emulation to evaluate CC performance over Starlink [2, 19, 23, 27, 30, 41]. The correct queuing configuration is important for simulation and emulation fidelity, and can have considerable impact on CC performance. Thus, the results presented here will be beneficial when setting up simulation or emulation studies aiming to faithfully represent Starlink connectivity. Other measurement studies explicitly consider effects such as weather [31, 34, 38], the impact of mobility [3, 16, 20, 32, 33, 48], the use of multi-connectivity [3, 20, 36, 37], CC for video streaming [7, 22, 52], and backbone/PoP aspects [42, 43].

Measurement setup

To collect measurements, we develop a new measurement utility, nanoprobe [47], capable of recording hardware timestamps from the NIC for both incoming and outgoing packets. Nanoprobe is based on nanoping [49], a simple UDP ping client and echo server with

Johan Garcia, Simon Sundberg, and Anna Brunstrom

support for hardware timestamps. However, nanoprobe includes extensive modifications to improve the accuracy of the targeted inter-packet delay. We have previously used nanoprobe to measure and model the baseline one-way delay (OWD) of Starlink using low rate probing traffic [13]. A novel feature is the nanoprobe support for sending traffic according to a probe schedule, a functionality not provided by previous tools such as IRTT [18]. In the probe schedule, each packet transmission is defined in terms of the number of microseconds of delay relative to the previous packet and the packet size for that probe packet. This functionality allows for very flexible generation of probing traffic. For our queuing experiments, we define a specific probe schedule where each measurement run consists of 120 traffic bursts, each with different burst characteristics in terms of number of packets and send rate within the burst. Our measurement campaign collects OWD data for traffic in the downlink in May 2025. Each 120-burst measurement run is replicated 30 times to allow for the capture of aggregate behavior and account for Starlink’s inherent variability. Our primary set of measurements is performed from a Gen-2 Starlink Standard Actuated user terminal mounted on a rooftop at Karlstad University, Sweden, offering an unobstructed view of the sky. We utilize both software timestamps with tcpdump, and nanoprobe hardware timestamps from the dual-port Intel X550 NIC. The nanoprobe client is attached to a NIC port connected to the Starlink user terminal, while the server is attached to the second NIC port, which has a public IP address on the university network. We avoid clock drift and other issues with clock synchronization as both the client and the server rely on a common oscillator. The traffic is carried over a well-provisioned academic network and then a large international carrier (Twelve99) to the Starlink point of presence (PoP) in Frankfurt, where it enters the Starlink backbone to be forwarded on to a ground station and the LEO segment. The approximate non-Starlink delay between our measurement server and client is 12 ms. Additionally, we repeat the measurements in October 2025 at a second vantage point with a Starlink terminal at the University of Malaga, Spain. The Malaga setup also runs both the client and the server on the same host, but relies solely on software timestamps. The network path is also similar, with traffic going through an academic network and then the Twelve99 network before reaching the Starlink PoP in Madrid. Traceroute printouts for both the Karlstad and Malaga routes are provided in Appendix C. The analysis is primarily based on the more precise measurements from Karlstad, while the Malaga measurements are used to verify that the observed behavior generalizes to other Starlink connections.

Per-flow or per-user queues

We initially study the queuing setup from a flow-separation viewpoint, and find that Starlink does not use per-flow fair queuing. To arrive at this result, some specific measurements are performed using TCP and Iperf3. First, 10 primary TCP flows with Cubic as CC are started. After 30 seconds, 10 additional TCP flows with the BBRv1 CC are started, and the 20 flows then run concurrently for the last 30 seconds. These measurement flows carry no features that would allow Starlink to directly distinguish between BBR and Cubic flows. Varying radio conditions, varying intensity of traffic from other users, and scheduling considerations can all contribute

Characterizing the Configuration of Starlink Queuing

IMC ’26, October 12–16, 2026, Karlsruhe, Germany

500

1000

2000

3000

4000

5000

6000

96 150 200 240 279 300 324 353 375 400 429 462 500 545 Send rate (Mbps)

One-way Delay | 1500 byte packets | mean across runs

50 40 30 20 10 0

(a) Packet-loss

200

500

1000

101 105 108 107

2000

106 108 109 100 104 111 111 118 106 116 110

3000

101 109 119 109 107 102 101 105 109 101

4000

101 107

5000

6000

96 150 200 240 279 300 324 353 375 400 429 462 500 545 Send rate (Mbps)

100

Mean One-way delay (ms)

Burst size (pkts)

Loss fraction (%)

Burst size (pkts)

Packet Loss | 1500 byte packets | mean across runs 200

(b) One-way delay

Figure 1: Packet loss and one-way delay across 30 replications of burst size and burst send rate combinations. to variations in the Starlink capacity available to a user, or here, to the measurement flows. However, if per-flow queuing is present, each different flow will be allocated to its own queue, and a typical per-flow configuration is for each queue to be served an equitable fraction of the overall capacity over time. In such a case, one of the flows will thus not be able to, over time, capture a substantially larger fraction than any competing capacity-seeking flow. Consequently, per-flow fair queuing with round-robin allocation will enforce approximate max-min fairness among the flows. BBRv1 Cubic

Throughput (Mbps)

30 Time (s)

Figure 2: Per-flow throughput for 10 parallel Cubic and BBRv1 flows. BBRv1 flows start at 30 s. If we now consider the throughput evolution graphs for these competing TCP connections as shown in Figure 2, they suggest that such per-flow fair queuing is not employed in Starlink. In the later part of the transfer, it is clear that BBR takes a much larger fraction than Cubic, and that Cubic has a much lower throughput in the later part than in the first part of the transfer. Such behavior is not compatible with max-min fairness, and thus we can assume that per-flow fair queuing is not used.

Queuing behavior overview

To provide an overview of queuing dynamics we present heat maps for the loss rate and the mean within-burst one-way delay (OWD) in Figure 1, based on our UDP burst-probe measurements. The heat maps show the mean behavior over the 30 replications for each of the 120 combinations of burst size and burst send rate. While the mean behavior as shown in the figure is representative, there are also individual variations as will be exemplified later.

Several noteworthy aspects are present in these heat maps. Considering the loss fraction shown in Figure 1a, it can be observed that we have practically zero loss for burst sizes of 1,000 packets or less, regardless of the sending rate. This gives us an indication for a lower bound of the queue size. Furthermore, we can see that for burst rates of 48 and 96 Mbps, there is also practically no loss regardless of the burst size. This indicates that the available capacity on Starlink for our location at the time of the UDP measurement was lower-bounded by a value not too far from 96 Mbps. In the remaining part of the loss rates subplot, it is clear that the loss rate increases proportionally as the send rate and the burst size increase. This is consistent with the expected behavior of a queuing system where the incoming rate exceeds the drain rate. Additional insights can be gained by studying Figure 1b which shows the within-burst mean OWD. First, considering the low send rates of 48 and 96 Mbps, which had no packet losses, we can see that for 48 Mbps, there is a small tendency of increased latency when going from burst sizes of 200 to 2,000, and then a reduction in mean OWD as the burst sizes increase further. This trend can also be seen for the 96 Mbps send rate. Given that no losses were occurring for these send rates, one plausible explanation is that the underlying communications capacity that Starlink provides is sometimes increased for the longer bursts, thus driving down the mean OWD over the full burst. This indicates that Starlink can employ load-based allocation of the transmission resources, where a user initially gets some allocation of the 1.33 millisecond Starlink link layer frames that results in a particular rate. If the sender continuously transmits above this rate, Starlink can respond by increasing the resource allocation to the user, thus providing more capacity. Considering the remainder of the OWD graph, it can be noted that the overall trend is different to what is seen for the loss rate, where losses increased corresponding to increases in send rate and burst size. For the OWD graph, the maximum delay instead appears for burst sizes of 2,000 packets and then actually reduces as the burst size increases. One potential partial explanation for this could be the load-dependent resource allocation discussed above, where larger bursts receive greater capacity in the later part of the burst, thus driving down the OWD. However, a more significant explanation for this behavior is the particular drop-front buffer management scheme used, as discussed next.

IMC ’26, October 12–16, 2026, Karlsruhe, Germany

150 125 100 75 50 Replication nr: 7

25 0

100

120

Burst size: 6000 pkts

Rate: 500 Mbps

Pkt size: 1500 b

Burst size: 6000 pkts

Rate: 500 Mbps

200

6000

2500

5000 2000

Send seq nr

175

Pkt size: 1500 b Receive count (pkts)

Downlink OWD (ms)

Pkt size: 1500 b Burst size: 6000 pkts Rate: 500 Mbps Empirical:: loss rate: 55 %, Mean delay: 87 ms

Johan Garcia, Simon Sundberg, and Anna Brunstrom

1500 1000 500

3000 2000 1000

Replication nr: 7

140

4000

100

Send time (ms)

150

200

Replication nr: 7

250

100

Receive time (ms)

(a) One-way delay and loss

150

250

Receive time (ms)

(b) Received packet count

Figure 3: Queue and packet receive dynamics for one illustrative Starlink burst measurements run with a burst size of 6000 (UDP) packets of 1500 bytes, and a constant send rate of 500 Mbps. Jittered red marks are packet losses.

175

150 125 100 75 50 25

One-Way Delay (ms)

Pkt size: 1500 b Burst size: 6000 pkts Rate: 500 Mbps Simulated:: loss rate: 52 %, Mean delay: 84 ms Drop-front queue: 1500 pkts, Drain rate: 124 Mbps

One-Way Delay (ms)

Pkt size: 1500 b Burst size: 6000 pkts Rate: 500 Mbps Simulated:: loss rate: 52 %, Mean delay: 85 ms Drop-front queue: 1500 pkts, Drain rate: 124 Mbps

One-Way Delay (ms)

Pkt size: 1500 b Burst size: 6000 pkts Rate: 500 Mbps Simulated:: loss rate: 52 %, Mean delay: 122 ms Drop-tail queue: 1500 pkts, Drain rate: 124 Mbps

150 125 100 75 50 25

100

120

140

125 100 75 50 25

Send time (ms)

(a) Drop-tail

150

Send time (ms)

(b) Drop-front

100

120

140

100

120

140

Send time (ms)

Figure 4: One-way delay and loss dynamics obtained from queuing simulator for different configurations.

Buffer management

In terms of buffer management approaches, we find that Starlink uses drop-front as opposed to the commonly employed drop-tail approach. To initiate the study of queue dynamics, and exemplify from the aggregated results of Figure 1, we consider the behavior within one individual illustrative burst measurement. Figure 3a shows the evolution of the per-packet OWD on the y-axis, as related to the send time on the x-axis. Within a burst, all packets are sent with a fixed inter-packet distance, which corresponds to a particular constant sending rate. From the figure it is clear that the OWD initially increases. As the queue becomes full, packet losses start to occur, as marked with red marks with added y-axis jitter for clarity. Between the losses, there are also packets that are forwarded to the client. At the end of the transmission, there is an increase in the OWD, which is typical of a drop-front queue. We can see that the send time duration is somewhat larger than 140 milliseconds. This time corresponds to the particular burst size and burst sending rate that were used for this particular burst measurement run, i.e. 1500 × 8 × 6000/500 · 106 ⪅ 0.144 seconds. Figure 3b provides an alternative view of the queue and link dynamics. It shows the client perspective and illustrates the effective reception rate, i.e. the effective capacity provided by Starlink. The yaxis shows the number of received packets, while the x-axis shows the reception time in relation to the first received packet. From the y-axis numbering, it is clear that a bit more than 2500 packets were received out of the 6000 packets sent in this particular burst. For the given burst size and send rate, the loss fraction observed in this particular replication (1 − (2711/6000) ≈ 55%) can be compared to

the mean across all replications (50 %) from Figure 1. This particular replication thus has a slightly higher loss rate compared to the mean over all replications. Within the graph, the slope of an imagined interpolated line between the received small bursts of packets, corresponds to the received traffic rate, i.e., the provided Starlink capacity. In this particular run, we can see that initially the rate is lower, then it increases around the 50 ms receive time mark, and increases again at approximately 230 ms. Thus, in this particular run, the provided underlying Starlink capacity was adjusted two times. In Figure 3c, the data is again viewed from the client perspective. However, the y-axis now shows the sequence number of the packet that is received, rather than just the count of packets. The shape of the graph is similar to Figure 3b, with some notable differences in terms of the slope. Here, the slope becomes steeper after the 50 millisecond mark. This is due to the packet losses that occur in this period, where the packets actually received will have a stepwise increase in their sent sequence number corresponding to the lost packets. There is also a noteworthy kink in the slope located slightly before the 150 millisecond mark. This kink appears at the same time as the sending of packets stops, which is slightly after 140 milliseconds, as seen in Figure 3a. There is also a second kink around the 230 millisecond mark, which is caused by the capacityadjustment change seen in Figure 3b, although here it is not as visually pronounced. To further analyze the OWD evolution observed in Figure 3a, we implemented a time-slot based Python queuing simulator with 1 𝜇s

Characterizing the Configuration of Starlink Queuing

IMC ’26, October 12–16, 2026, Karlsruhe, Germany

200 150

125

q: 1720 pkts, loss: 59 % delay: 129 ms q: 1120 pkts, loss: 69 % delay: 76 ms rate: 54 Mbps, loss: 67 % delay: 130 ms rate: 81 Mbps, loss: 62 % delay: 85 ms

100 50 Replication nr: 10

0 0

100

Pkt size: 1500 b Burst size: 6000 pkts Rate: 500 Mbps Empirical:: loss rate: 52 %, Mean delay: 48 ms Simulated:: loss rate: 42 %, Mean delay: 42 ms Drop-front queue: 1400 pkts, Drain rate: 182 Mbps

120

140

150

Queueing delay (ms)

250

Pkt size: 750 b Burst size: 6000 pkts Rate: 250 Mbps Empirical:: loss rate: 51 %, Mean delay: 66 ms Simulated:: loss rate: 52 %, Mean delay: 60 ms Drop-front queue: 1500 pkts, Drain rate: 124 Mbps Queueing delay (ms)

Queueing delay (ms)

Pkt size: 1500 b Burst size: 6000 pkts Rate: 500 Mbps Empirical:: loss rate: 63 %, Mean delay: 110 ms Simulated:: loss rate: 64 %, Mean delay: 102 ms Drop-front queue: 1420 pkts, Drain rate: 67 Mbps

100

Replication nr: 29 0

Send time (ms)

(a) Simulator parameter sensitivity

100

120

140

Send time (ms)

100 75 50 25 0

Replication nr: 24 0

100

120

140

Send time (ms)

(b) Smaller packet size

Figure 5: Per-packet measured queuing-induced OWD for 3 different runs (black), and per-packet OWD from a drop-front queuing simulator configured with queue size and drain rate to fit empirical measurements (blue). resolution. The simulator takes traffic burst, queue, and drain characteristics as input, and generates traces of the resulting per-packet delay and loss for the configured drop strategy. We implemented the common drop-tail and the more rare drop-front strategies. Figure 4a shows the OWD evolution from the simulator for the same burst characteristics as shown in Figure 3a when using drop-tail. This can be compared to the drop-front OWD evolution shown in Figure 4b, which clearly provides a much better macroscopic match to Figure 3a. Note that the configured queue size and drain rate are the same in 4a and 4b, as is the resulting loss rate. The resulting mean delay is, however, considerably lower for drop-front. This is because with drop-front, packets are dropped from the front of the queue, meaning that the dropped packets are the ones which have waited the longest in the queue. This also results in the losses starting at a lower send time as compared to the drop-tail case. Notable is that when a packet is dropped at the front, the other packets in the queue are moved forward, thus lowering the total queuing delay for the packets that end up not being dropped at the front but delivered to the receiver. The difference in mean OWD provides a measure of the average effect on latency, and it is clear that drop-front is preferable from the perspective of keeping the queuing delay, and thus the OWD, low. As seen, the mode of the queuing-induced OWD is several times larger for drop-tail than for drop-front in this example run. Interestingly, for the drop-front case, the OWD will actually increase for the shorter bursts compared to longer bursts. While initially counterintuitive, this makes sense as the last phase where OWD has a rising slope (i.e. where the queuing delay is no longer reduced by the packet drops), is relatively longer. Thus, part of the explanation for the Figure 1 behavior of decreasing OWD with larger bursts clearly lies with drop-front buffer management. In Figure 4c we further extended the simulator to not use smooth draining, but instead mimic the Starlink-specific 1.33 ms frame-time resource allocation, here with 1 frame-time with access, followed by 3 frame-times without access. This 1:3 pattern of allocation has been observed in previous empirical measurements [9]. The resulting matching of microscopic behavior in terms of loss placement between the empirical results in Figure 3a and the simulated Starlink-specific results in Figure 4c shows that the observed buffering occurs at the queue in front of the Starlink resource-allocating bottleneck, and not somewhere else along the end-to-end path. If

queuing, and thus loss generation, were to occur in a queue before Starlink, there would be losses also during the Starlink send-burst periods as the draining of a pre-Starlink queue would be independent of the Starlink send periods. So while we can conclude that queuing happens in a queue which is synchronized with Starlink’s 1.33 ms frame time, it is not possible to pinpoint the exact location of this queue since there is very limited IP layer visibility into the internal Starlink network. Although there have been some recent efforts [50] to study the Starlink terrestrial network, many details remain unknown. There are however also potential drawbacks to using drop-front buffer management. Cubic is the default congestion control (CC) in Linux, and as such it is widely deployed across Internet servers. Many loss-based CCs such as Cubic are designed with the assumption of the queue being drop-tail, or some drop-tail based variation. A drop-front behavior will send the congestion signal earlier to the sender, possibly leading to underutilization of the available capacity. For Starlink, such underutilization has been reported in several works [6, 30, 38]. Another potential issue with drop-front is that it tends to synchronize multiple flows. If one flow feeds a high-rate burst of ten packets into a full drop-tail queue, the resulting 10 packet losses will affect only itself. For the drop-front case, the ten packets will be fed into the queue and instead ten packets at the front of the queue will be dropped. It is highly likely that these packets will not all belong to the same flow that generated the highrate burst. More likely, the ten packets will belong to some wider subset of all the competing flows, and this common loss occurrence will serve as a nudge towards flow synchronization for these flows. Thus, in many cases it will not be the flow that caused a packet loss that actually receives the congestion signal.

Queue sizing

By leveraging our queuing simulator we also investigate queue sizing, and find the typical queue size to be in the 1400 to 1600 packet range. Three example burst measurements are shown in Figure 5. The graphs are adjusted with the minimum observed OWD to display only the queuing-induced OWD increase, and are shown without packet losses. For figure clarity, we employ the smooth rather than the Starlink-specific draining configuration. In Figure 5a we provide an illustration of the impact of varying the

IMC ’26, October 12–16, 2026, Karlsruhe, Germany Pkt size: 1500 b

Burst size: 3000 pkts

Rate: 353 Mbps

Johan Garcia, Simon Sundberg, and Anna Brunstrom Pkt size: 1500 b

Rate: 353 Mbps

Pkt size: 1500 b

1500 1000 500 Replication nr: 8

0 0

100

150

200

Receive time (ms)

Burst size: 1000 pkts

Rate: 500 Mbps

1000

Receive count (pkts)

Burst size: 3000 pkts

3000

2000

2500 2000 1500 1000 500

800 600 400 200

Replication nr: 11

0 0

100

120

140

160

Receive time (ms)

Replication nr: 14

0 0

100

120

140

160

Receive time (ms)

Figure 6: In-burst rate increase examples from two different burst sizes. Steeper slope indicates higher received rate. simulator parameters for queue size or drain rate when searching for a fit between empirical results and simulator output. For the fits shown in this paper, we performed manual fitting as no suitable and robust error metric could be immediately determined, and we thus leave automated fitting to future work. Figure 5b instead considers an auxiliary measurement run with traffic bursts using a smaller packet size. This run, and the corresponding fit, showed a similar queue size to the other runs with 1500 byte packets. This indicates that the queue is limited in terms of packets rather than bytes. If the queue had a byte limitation, then the fitted queue size value would be expected to be approximately double when the packet size is halved. In Figure 5c we show a result obtained from measurements performed at Malaga, which is located several thousand kilometers away from Karlstad. While these measurement locations varied in terms of obtained throughput and latency, they both exhibited the typical drop-front OWD evolution and similar queue size. Thus, these measurements confirm that the observed behavior is Starlinkspecific, and not an artifact of some specific measurement setup or end-to-end path. Additional examples of measurement runs and simulator fits are provided in Figure 7 of Appendix D. As the displayed runs were randomly selected, they can be seen to provide a representative view of the amount of between-run variation present in our measurements. While the simulator parameters leading to the best fit typically will not yield identical values for loss rate and mean OWD as empirically observed, the fit is nevertheless quite good. Also, note that the simulator does not model the rate adjustments that may occur in the empirical data. From the perspective of queue sizing, the fitted parameters of the queuing simulator indicate a typical queue size of 1,400 to 1,600 packets. The variation in the OWD values at the plateaus in the different graphs goes from approximately 30 to 60 ms, suggesting that drop decisions are related to queue size and not CoDel-like [40] delay bounds.

Load-based rate adaptation

As discussed in Section 5, the decreasing mean OWD for the nonlossy burst rates of 48 and 96 Mbps indicated that there could be demand-based rate adaptation. In Figure 6, we provide three additional receive count graphs using two smaller burst sizes: 3,000 and 1,000 packets. In these examples, it is clear that rate adaptation covers a larger fraction of all packets when the burst size is larger, whereas for the smaller burst size, rate adaptation covers a smaller fraction of all packets. With the rate adaptation affecting a larger proportion of the packets in large bursts, the average OWD will

consequently be lower for large bursts, as previously observed and discussed for Figure 1. When examining all replications across a range of burst sizes and send rates, we do not find consistent evidence supporting loadbased rate adaptation in a systematic and deterministic way. Nevertheless, rate adaptation appears in a number of runs and is evident both in the runs shown in Figures 3 and 5a and in many of the runs in Figure 7 of Appendix D, where some additional discussion on rate adaptation is also provided. Note that for the receive count graphs shown here, an increased drain rate from the queue is visible as a steeper slope, while in queuing delay graphs it is visible as a shallower slope.

Conclusions

Starlink is an important Internet access provider to millions of users globally, but many aspects of its underlying network configuration are poorly understood. In this study, we utilize a pattern-controlled traffic generator to characterize the queuing configuration of Starlink through the transmission and analysis of more than 10 million probe packets over a range of burst sizes and burst rates. By employing a queuing simulator we find that drop-tail buffering is not used, but rather a slightly unusual drop-front buffer management approach on a queue with a size of around 1500 packets. While drop-front reduces one-way delay and thus latency, it may interfere with the assumptions made by loss-based congestion controls. Our analysis also shows that Starlink does not employ per-flow fair queuing. We believe that our work contributes with relevant tools and methodology, and to additional insight into the causes behind the Starlink throughput anomaly that has been observed for Cubic and other loss-based congestion controls in several recent Starlink studies. However, this work cannot in itself establish a causal link between drop-front buffer management and poor Cubic performance, prompting future work on this throughput anomaly. We note that SpaceX may change the configuration of the network components, including the queue configuration, over time and has reported doing so [45]. We are currently working on a more complete link characterization measurement setup that can detect and quantify such changes.

Acknowledgments Thanks to Jonas Karlsson at Karlstad and Delia Rico at Malaga for assisting with the measurement infrastructure. This research was partly funded by the Swedish Research Council, the Swedish Knowledge Foundation, and Karlstad Internet Privacy Lab (KIPL).

Characterizing the Configuration of Starlink Queuing

References [1] Maximilian Bachl, Joachim Fabini, and Tanja Zseby. 2020. Detecting Fair Queuing for Better Congestion Control. arXiv preprint arXiv:2010.08362 (2020). [2] George Barbosa, Sirapop Theeranantachai, Beichuan Zhang, and Lixia Zhang. 2023. A comparative evaluation of TCP congestion control schemes over lowEarth-orbit (LEO) satellite networks. In Proceedings of the 18th Asian Internet Engineering Conference. 105–112. [3] Claes Beckman, Johan Garcia, Herman Mikkelsen, and Patrik Persson. 2024. Starlink and Cellular Connectivity under Mobility: Drive Testing Across the Arctic Circle. In 2024 Wireless Telecommunications Symposium (WTS). IEEE, 1–9. [4] Xuyang Cao and Xinyu Zhang. 2023. SaTCP: Link-Layer Informed TCP Adaptation for Highly Dynamic LEO Satellite Networks. In IEEE INFOCOM 2023-IEEE Conference on Computer Communications. IEEE, 1–10. [5] Gregory Detal, Benjamin Hesmans, Olivier Bonaventure, Yves Vanaubel, and Benoit Donnet. 2013. Revealing middlebox interference with tracebox. In Proceedings of the 2013 Conference on Internet Measurement Conference (Barcelona, Spain) (IMC ’13). Association for Computing Machinery, New York, NY, USA, 1–8. doi:10.1145/2504730.2504757 [6] Jörg Deutschmann, Saeid Jahandar, Kai-Steffen Hielscher, and Reinhard German. 2023. Internet via Satellite: GEO vs. LEO, OpenVPN vs. Wireguard, and CUBIC vs. BBR. In Proceedings of the 1st ACM MobiCom Workshop on Satellite Networking and Computing. 19–24. [7] Hao Fang, Haoyuan Zhao, Jianxin Shi, Miao Zhang, Guanzhen Wu, Yi Ching Chou, Feng Wang, and Jiangchuan Liu. 2024. Robust Live Streaming over LEO Satellite Constellations: Measurement, Analysis, and Handover-Aware Adaptation. In Proceedings of the 32nd ACM International Conference on Multimedia. 5958–5966. [8] Sally Floyd, Dr. K. K. Ramakrishnan, and David L. Black. 2001. The Addition of Explicit Congestion Notification (ECN) to IP. RFC 3168. doi:10.17487/RFC3168 [9] Johan Garcia, Matthias Beckerle, Simon Sundberg, and Anna Brunstrom. 2025. Modeling and predicting starlink throughput with fine-grained burst characterization. Computer Communications (2025), 108090. [10] Johan Garcia and Simon Sundberg. 2026. Data set for "Characterizing the Configuration of Starlink Queuing",. doi:10.5281/zenodo.18868451 [11] Johan Garcia, Simon Sundberg, and Anna Brunstrom. 2024. Fine-grained starlink throughput variation examined with state-transition modeling. In 2024 19th Wireless On-Demand Network Systems and Services Conference (WONS). IEEE, 69–76. doi:10.23919/WONS60642.2024.10449629 [12] Johan Garcia, Simon Sundberg, and Anna Brunstrom. 2024. Inferring Starlink Physical Layer Transmission Rates Through Receiver Packet Timestamps. In Proceedings of the 25th IEEE Wireless Communications and Networking Conference (WCNC). [13] Johan Garcia, Simon Sundberg, and Anna Brunstrom. 2025. A detailed characterization of starlink one-way delay. In Proceedings of the 2025 3rd Workshop on LEO Networking and Communication. 43–49. [14] Johan Garcia, Simon Sundberg, and Anna Brunstrom. 2025. TCP Congestion Control Performance over Starlink. In Proceedings of the 2025 Applied Networking Research Workshop. 70–77. [15] Johan Garcia, Simon Sundberg, Giuseppe Caso, and Anna Brunstrom. 2023. MultiTimescale Evaluation of Starlink Throughput. In Proceedings of the 1st ACM Workshop on LEO Networking and Communication. 31–36. [16] Amirreza Ghafoori, Alireza Famili, and Angelos Stavrou. 2024. Stars and towers on the wheels: Global perspective on satellite networks vs. terrestrial 5G. In GLOBECOM 2024-2024 IEEE Global Communications Conference. IEEE, 301–306. [17] Sarah-Michelle Hammer, Vamsi Addanki, Max Franke, and Stefan Schmid. 2024. Starlink performance through the edge router lens. In Proceedings of the 2nd International Workshop on LEO Networking and Communication. 67–72. [18] Pete Heist. [n. d.]. irtt: Isochronous Round-Trip Tester. https://github.com/heistp/ irtt. Accessed November 17, 2025. [19] Cristina Hervella, Luis Diez, Fátima Fernández, Néstor J Hernández Marcano, Rune Hylsberg Jacobsen, and Ramón Agüero. 2022. Realistic Assessment of Transport Protocols Performance over LEO-based Communications. In Proceedings of the 19th ACM International Symposium on Performance Evaluation of Wireless Ad Hoc, Sensor, & Ubiquitous Networks. 91–98. [20] Bin Hu, Xumiao Zhang, Qixin Zhang, Nitin Varyani, Z. Morley Mao, Feng Qian, and Zhi-Li Zhang. 2023. LEO Satellite vs. Cellular Networks: Exploring the Potential for Synergistic Integration. In Companion of the 19th International Conference on Emerging Networking EXperiments and Technologies (CoNEXT 2023). 45–51. [21] Todd E Humphreys, Peter A Iannucci, Zacharias M Komodromos, and Andrew M Graff. 2023. Signal structure of the Starlink Ku-band downlink. IEEE Trans. Aerospace Electron. Systems (2023). [22] Liz Izhikevich, Reese Enghardt, Te-Yuan Huang, and Renata Teixeira. 2024. A Global Perspective on the Past, Present, and Future of Video Streaming over Starlink. Proceedings of the ACM on Measurement and Analysis of Computing Systems 8, 3 (2024), 1–22. [23] Li Jiang, Yihang Zhang, Jinyu Yin, Xinggong Zhang, and Bin Liu. 2023. Leotp: An information-centric transport layer protocol for LEO satellite networks. In 2023

IMC ’26, October 12–16, 2026, Karlsruhe, Germany

IEEE 43rd International Conference on Distributed Computing Systems (ICDCS). IEEE, 579–590. [24] Victor Kamel, Jinwei Zhao, Daoping Li, and Jianping Pan. 2024. StarQUIC: Tuning Congestion Control Algorithms for QUIC over LEO Satellite Networks. In Proceedings of the 2nd International Workshop on LEO Networking and Communication. 43–48. [25] Minoo Kargar Bideh, Andreas Petlund, Carsten Griwodz, Iffat Ahmed, Razieh Behjati, Anna Brunstrom, and Stefan Alfredsson. 2016. Tada: An active measurement tool for automatic detection of AQM. In Proceedings of the 9th EAI International Conference on Performance Evaluation Methodologies and Tools. 55–60. [26] Mohamed M Kassem, Aravindh Raman, Diego Perino, and Nishanth Sastry. 2022. A browser-side view of Starlink connectivity. In 22nd ACM Internet Measurement Conference (IMC ’22). 151–158. [27] Fátima Khan, Cristina Hervella, Luis Diez, Fátima Fernández, Néstor J Hernández Marcano, Rune Hylsberg Jacobsen, and Ramón Agüero. 2023. Realistic assessment of transport protocols performance over LEO-based communications. Computer Networks 236 (2023), 110008. [28] Jonathan Kua, Philip Branch, and Grenville Armitage. 2020. Detecting bottleneck use of pie or fq-codel active queue management during dash-like content streaming. In 2020 IEEE 45th conference on local computer networks (LCN). IEEE, 445–448. [29] Zeqi Lai, Zonglun Li, Qian Wu, Hewu Li, Jihao Li, Xin Xie, Yuanjie Li, Jun Liu, and Jianping Wu. 2025. LeoCC: Making Internet Congestion Control Robust to LEO Satellite Dynamics. In Proceedings of the ACM SIGCOMM 2025 Conference. 129–146. [30] Zeqi Lai, Zonglun Li, Qian Wu, Hewu Li, Weisen Liu, Yijie Liu, Xin Xie, Yuanjie Li, and Jun Liu. 2024. Mind the Misleading Effects of LEO Mobility on End-to-End Congestion Control. In Proceedings of the 23rd ACM Workshop on Hot Topics in Networks. 34–42. [31] Eric Lanfer, Dominic Laniewski, Daniel Otten, and Nils Aschenbruck. 2024. Weather-Based Link Prediction for LEO-Satellite Networks using the WetLinks Dataset. In 2024 IFIP Networking Conference (IFIP Networking). IEEE, 586–588. [32] Dominic Laniewski, Eric Lanfer, and Nils Aschenbruck. 2025. Measuring Mobile Starlink Performance: A Comprehensive Look. IEEE Open Journal of the Communications Society (2025). [33] Dominic Laniewski, Eric Lanfer, Simon Beginn, Jan Dunker, Michael Dückers, and Nils Aschenbruck. 2024. Starlink on the Road: A First Look at Mobile Starlink Performance in Central Europe. arXiv preprint arXiv:2403.13497 (2024). [34] Dominic Laniewski, Eric Lanfer, Bernd Meijerink, Roland van Rijswijk-Deij, and Nils Aschenbruck. 2024. WetLinks: a Large-Scale Longitudinal Starlink Dataset with Contiguous Weather Data. arXiv preprint arXiv:2402.16448 (2024). [35] Hyoyoung Lim, Seonwoo Kim, Jackson Sippe, Junseon Kim, Greg White, Chul-Ho Lee, Eric Wustrow, Kyunghan Lee, Dirk Grunwald, and Sangtae Ha. 2022. A Fresh Look at ECN Traversal in the Wild. arXiv preprint arXiv:2208.14523 (2022). [36] Melisa López, Sebastian Bro Damsgaard, Ignacio Rodríguez, and Preben Mogensen. 2022. An Empirical Analysis of Multi-Connectivity between 5G Terrestrial and LEO Satellite Networks. In 2022 IEEE Globecom Workshops (GC Wkshps). IEEE, 1115–1120. [37] Melisa López, Sebastian Bro Damsgaard, Ignacio Rodríguez, and Preben Mogensen. 2023. Connecting Rural Areas: An Empirical Assessment of 5G TerrestrialLEO Satellite Multi-Connectivity. In IEEE 97th Vehicular Technology Conference (VTC2023-Spring). 1–5. [38] Sami Ma, Yi Ching Chou, Haoyuan Zhao, Long Chen, Xiaoqiang Ma, and Jiangchuan Liu. 2023. Network Characteristics of LEO Satellite Constellations: A Starlink-Based Measurement from End Users. In IEEE INFOCOM Conference on Computer Communications. 1–10. [39] Nitinder Mohan, Andrew E. Ferguson, Hendrik Cech, Rohan Bose, Prakita Rayyan Renatin, Mahesh K. Marina, and Jörg Ott. 2024. A Multifaceted Look at Starlink Performance. In Proceedings of the ACM on Web Conference 2024. 2723–2734. doi:10.1145/3589334.3645328 [40] Kathleen Nichols and Van Jacobson. 2018. Controlled Delay Active Queue Management. RFC 8289. IETF. doi:10.17487/RFC8289 [41] Robin Ohs, Gregory F Stock, Juan A Fraire, Holger Hermanns, and Andreas Schmidt. 2025. PhantomLink: Emulating virtual end-to-end links on ground and in orbit. In Proceedings of the 2025 Applied Networking Research Workshop. 39–46. [42] Jianping Pan, Jinwei Zhao, and Lin Cai. 2023. Measuring a low-earth-orbit satellite network. In IEEE 34th Annual International Symposium on Personal, Indoor and Mobile Radio Communications (PIMRC). 1–6. [43] Jianping Pan, Jinwei Zhao, and Lin Cai. 2024. Measuring the Satellite Links of a LEO Network. In IEEE International Conference on Communications. [44] Constantin Sander, Ike Kunze, Leo Blöcher, Mike Kosek, and Klaus Wehrle. 2023. ECN with QUIC: Challenges in the Wild. In Proceedings of the 2023 ACM on Internet Measurement Conference (Montreal QC, Canada) (IMC ’23). 540–553. doi:10.1145/3618257.3624821 [45] SpaceX. 2024. Improving Starlink’s latency. Retrieved June 25, 2024 from https: //api.starlink.com/public-files/StarlinkLatency.pdf [46] Starlink. 2025. Starlink Stories. https://stories.starlink.com/. Accessed November 17, 2025.

IMC ’26, October 12–16, 2026, Karlsruhe, Germany

[47] Simon Sundberg. 2026. nanoprobe: UDP packet generator with hardware timestamp support based on nanoping. https://github.com/simosund/nanoprobe. [48] Muhammad Asad Ullah, Antti Heikkinen, Mikko Uitto, Marko Höyhtyä, Antti Anttonen, Konstantin Mikhaylov, and Timo Lind. 2025. Starlink in Northern Europe: A New Look at Stationary and In-motion Performance. arXiv preprint arXiv:2502.15552 (2025). [49] Yojiro UO. 2018. nanoping. https://github.com/iij/nanoping Accessed November 17, 2025. [50] Yanbo Wu, Mingxin Cui, Gaopeng Gou, Yuhao Wei, Gang Xiong, Zhen Li, Xinlei Ju, and Wei Xia. 2025. Beneath the Heavens: A Thorough Measurement Study of the Starlink Terrestrial Network. In 2025 IEEE/ACM 33rd International Symposium on Quality of Service (IWQoS). IEEE, 1–10. [51] Wenjun Yang, Lin Cai, Shengjie Shu, and Jianping Pan. 2024. Mobility-aware congestion control for multipath QUIC in integrated terrestrial satellite networks. IEEE Transactions on Mobile Computing (2024). [52] Miao Zhang, Jiaxing Li, Haoyuan Zhao, Linfeng Shen, and Jiangchuan Liu. 2024. StarStream: Live Video Analytics over Space Networking. In Proceedings of the 32nd ACM International Conference on Multimedia. 7909–7917.

Ethics

This work does not raise any ethical issues.

ECN behavior

We also attempted to investigate if Starlink supports using Explicit Congestion Notification (ECN) to mark packets instead of dropping them. We enable ECN for both a TCP sender and receiver (net.ipv4.tcp_ecn=1) before establishing a TCP connection over the Starlink connection, but find that the ECN markings appear to be erased over the network path from Karlstad University. We confirm that the ECN usage is negotiated in the TCP handshake. The ECN-Echo (ECE) and Congestion Window Reduce (CWR) bits in the TCP header are appropriately set and outgoing data packets in both directions have the ECN Capable Transport (ECT(0)) code point set in the IP header in accordance with RFC 3168 [8]. However, all received packets on either side of the connection are marked not-ECT, so the ECN bits are bleached somewhere along the network path. To determine if the ECN bleaching is caused by Starlink or some other element along the network path, we use a methodology similar to [5, 35, 44]. Traceroute is used to send TCP SYN packets with the ECT(0) code point set and ECE flag set and increasing time to live (TTL) values, using the command shown in Listing 1. The returned TTL expired ICMP messages contain a copy of the expired packet header, and by inspecting the ECN bits in the returned header it is possible to infer between which hops the ECN is bleached. From this we find that the ECN markings appear to be able to traverse the Starlink hop, but are erased inside the Twelve99 network connecting us to the Starlink PoP (between hops 8 and 9 in Listing 1). We later repeat these ECN experiments from the vantage point at the University of Malaga, where we find that ECN markings are preserved across the full end-to-end connection over Starlink. Examining how Starlink handles ECN-marked traffic can therefore be an interesting direction for future work.

Network path

Listing 1 shows the route from the Starlink user terminal at Karlstad University over the satellite link to the Frankfurt PoP, and then back over the terrestrial network to the second NIC port at the measurement server. Listing 2 shows a corresponding trace from the vantage point at the University of Malaga. The traceroute command

Johan Garcia, Simon Sundberg, and Anna Brunstrom

uses TCP packets with the ECN bits set to ECT(0) to test for ECN bleaching, as described in Appendix B, but that has no impact on how the trace is printed here.

Example runs randomly selected among runs with loss > 30%

Fifteen randomly selected graphs are shown in Figure 7 to provide examples of the variation observed during our measurement collection. On the macroscopic level, it is clear that the empirical behavior is consistent with drop-front buffering. We found no empirical example consistent with drop-tail. On the microscopic level it is clear that the resource allocation patterns vary between runs. This is also consistent with previous observations of varying resource allocation, i.e. burst patterns [9]. Several graphs show signs of early rate adaptation where the empirical slope at the left-hand side of the plateau is steeper than at the right-hand side. For these queuing-delay graphs, such a steeper slope at the beginning indicates a lower initial draining rate. Thus, if the empirical slopes differ on the two sides of the plateau, this suggests that a rate adaptation has taken place. In the bottom row the middle graph is a clear example of late rate adaptation. Up to around 130 milliseconds, the simulated and empirically observed behavior fits well. After that, the drain rate increases to approximately 200 Mbps. Another example of rate adaptation is present in the right graph of the topmost row. At around 85 milliseconds there is a change in the slope of increase in queuing delay. Since the incoming rate is constant, such a change can only be caused by an increased drain rate. A few other subfigures also have indications of drain rate changes at around the 85 ms time, while others yet have indications of changes at other times. Further work is necessary to better understand the structure of rate adaptations in Starlink. The atypical bottom right graph was subject to continuous packet losses towards the end of the run.

Characterizing the Configuration of Starlink Queuing

IMC ’26, October 12–16, 2026, Karlsruhe, Germany

Listing 1: Traceroute from Starlink terminal at Karlstad University to a public IP address within the university network. $ traceroute -i starlink-uplink -N 1 -t 2 -T -O ecn 193.10.227.25 traceroute to 193.10.227.25 (193.10.227.25), 30 hops max, 44 byte packets 1 _gateway (192.168.1.1) 0.777 ms 0.769 ms 0.523 ms 2 100.64.0.1 (100.64.0.1) 30.888 ms 25.297 ms 26.559 ms 3 172.16.250.10 (172.16.250.10) 26.549 ms 30.666 ms 21.184 ms 4 * * * # Starlink PoP (Frankfurt, Germany) 5 undefined.hostname.localhost (206.224.65.184) 28.401 ms undefined.hostname.localhost (206.224.65.180) 21.823 ms undefined.hostname.localhost (206.224.65.184) 32.280 ms # Twelve99 (Tier 1 ISP) 6 ffm-b11-link.ip.twelve99.net (62.115.37.20) 31.677 ms 20.996 ms 23.831 ms 7 ffm-bb1-link.ip.twelve99.net (62.115.124.116) 21.148 ms 26.354 ms 29.244 ms 8 kbn-bb5-link.ip.twelve99.net (62.115.143.33) 37.141 ms kbn-bb6-link.ip.twelve99.net (62.115.114.94) 45.043 ms kbnbb5-link.ip.twelve99.net (62.115.143.33) 31.697 ms # ECN is bleached past this point 9 kbn-b4-link.ip.twelve99.net (62.115.134.81) 39.634 ms kbn-b4-link.ip.twelve99.net (62.115.136.231) 37.014 ms 42.782 ms # NORDUnet/Sunet (Nordic/Swedish academic network) 10 nordunet-ic-358161.ip.twelve99-cust.net (62.115.11.78) 45.201 ms 44.990 ms 37.202 ms 11 mcen1-r11.sunet.se (109.105.102.105) 39.838 ms 42.363 ms 34.522 ms 12 lund-lnd88-r11.sunet.se (86.104.202.102) 37.177 ms 34.276 ms 37.194 ms 13 halmstad-hsd1-r11.sunet.se (86.104.202.48) 45.300 ms 36.903 ms 45.266 ms 14 goteborg-gbg7-r11.sunet.se (86.104.202.28) 39.827 ms 36.983 ms 50.488 ms 15 goteborg-gbg7-r12.sunet.se (86.104.202.35) 42.537 ms 39.622 ms 55.921 ms 16 trollhattan-trh-r11.sunet.se (86.104.202.37) 42.451 ms 45.040 ms 45.223 ms 17 karlstad-kau-r22.sunet.se (86.104.202.159) 42.480 ms 66.543 ms 50.570 ms 18 sunet-gw2.kau.se (130.242.64.121) 47.916 ms 44.792 ms 50.784 ms 19 monroe1.cs.kau.se (193.10.227.25) 42.606 ms 44.955 ms 50.478 ms

Listing 2: Traceroute from Starlink terminal at University of Malaga to a public IP address within the university network. $ traceroute -i enx5091e353c5df -N 1 -t 2 -T -O ecn www.uma.es traceroute to www.uma.es (150.214.40.97), 30 hops max, 44 byte packets 1 customer.mdrdesp1.isp.starlink.com (169.155.233.1) 16.202 ms 18.809 ms 15.650 ms 2 172.16.251.80 (172.16.251.80) 15.740 ms 18.932 ms 15.712 ms 3 * * * # Starlink PoP (Madrid, Spain) 4 undefined.hostname.localhost (206.224.69.244) 17.418 ms undefined.hostname.localhost (206.224.69.246) 18.254 ms 17.898 ms # Twelve99 (Tier 1 ISP) 5 mad-b3-link.ip.twelve99.net (213.248.89.12) 15.737 ms 19.017 ms 19.705 ms 6 * * * 7 be9697.rcr81.b015537-1.mad05.atlas.cogentco.com (154.54.36.170) 16.945 ms 18.994 ms 15.677 ms 8 149.14.241.18 (149.14.241.18) 15.698 ms 15.161 ms 15.703 ms # RedIRIS (Spanish academic network) 9 telmad-rt1.ethtrunk2.cica.rt2.and.red.rediris.es (130.206.245.126) 31.739 ms 23.522 ms 27.574 ms 10 cica-rt2.ethtrunk4.uv.rt2.val.red.rediris.es (130.206.245.34) 31.716 ms ciemat-rt2.ethtrunk2.uv.rt2.val.red.rediris. es (130.206.245.122) 27.025 ms cica-rt2.ethtrunk4.uv.rt2.val.red.rediris.es (130.206.245.34) 31.441 ms 11 rica-backup-router.red.rediris.es (130.206.211.42) 42.960 ms 34.996 ms 31.726 ms 12 uma-router.red.cica.es (150.214.231.170) 35.821 ms 30.991 ms 31.878 ms 13 palo-tea1001.ruma.uma.es (150.214.47.245) 31.541 ms 35.131 ms 31.709 ms 14 fg-sci-tea1001.uma.es (150.214.47.253) 35.580 ms 34.063 ms 35.561 ms 15 ccuma.sci.uma.es (150.214.40.97) 39.695 ms 33.357 ms 31.654 ms

IMC ’26, October 12–16, 2026, Karlsruhe, Germany

80 60 40 20 Replication nr: 1

0 0

100

120

140

500 400 300 200 100 Replication nr: 2

160

Send time (ms)

100

40 20

100

120

150 100 50

60 40 20 Replication nr: 1

0 75

100

125

150

120

100 50 Replication nr: 22

0 0

200 150 100 50

100

80 60 40 20 Replication nr: 13

120

100

120

Pkt size: 1500.0 b Burst size: 4000.0 pkts Rate: 400.0 Mbps Empirical:: loss rate: 46 %, Mean delay: 93 ms Simulated:: loss rate: 40 %, Mean delay: 82 ms Drop-front queue: 1500 pkts, Drain rate: 98 Mbps

Pkt size: 1500.0 b Burst size: 5000.0 pkts Rate: 375.0 Mbps Empirical:: loss rate: 40 %, Mean delay: 64 ms Simulated:: loss rate: 41 %, Mean delay: 63 ms Drop-front queue: 1400 pkts, Drain rate: 117 Mbps

Pkt size: 1500.0 b Burst size: 5000.0 pkts Rate: 279.0 Mbps Empirical:: loss rate: 53 %, Mean delay: 102 ms Simulated:: loss rate: 35 %, Mean delay: 82 ms Drop-front queue: 1450 pkts, Drain rate: 98 Mbps Queueing delay (ms)

Send time (ms)

Queueing delay (ms)

Send time (ms)

Queueing delay (ms)

Send time (ms)

Pkt size: 1500.0 b Burst size: 5000.0 pkts Rate: 462.0 Mbps Empirical:: loss rate: 50 %, Mean delay: 42 ms Simulated:: loss rate: 37 %, Mean delay: 38 ms Drop-front queue: 1250 pkts, Drain rate: 182 Mbps

Replication nr: 22

0 0

Send time (ms)

250

175

100

150

100

Queueing delay (ms)

Pkt size: 1500.0 b Burst size: 5000.0 pkts Rate: 500.0 Mbps Empirical:: loss rate: 64 %, Mean delay: 130 ms Simulated:: loss rate: 57 %, Mean delay: 114 ms Drop-front queue: 1500 pkts, Drain rate: 67 Mbps Queueing delay (ms)

100

200

Send time (ms)

120

Pkt size: 1500.0 b Burst size: 3000.0 pkts Rate: 429.0 Mbps Empirical:: loss rate: 35 %, Mean delay: 124 ms Simulated:: loss rate: 33 %, Mean delay: 117 ms Drop-front queue: 1550 pkts, Drain rate: 74 Mbps

Replication nr: 5

140

Pkt size: 1500.0 b Burst size: 6000.0 pkts Rate: 400.0 Mbps Empirical:: loss rate: 64 %, Mean delay: 70 ms Simulated:: loss rate: 45 %, Mean delay: 54 ms Drop-front queue: 1400 pkts, Drain rate: 134 Mbps

250

Send time (ms)

200

Replication nr: 29

0 40

Replication nr: 20 0

Queueing delay (ms)

250

100

120

Pkt size: 1500.0 b Burst size: 4000.0 pkts Rate: 462.0 Mbps Empirical:: loss rate: 51 %, Mean delay: 118 ms Simulated:: loss rate: 48 %, Mean delay: 107 ms Drop-front queue: 1500 pkts, Drain rate: 74 Mbps

100

Queueing delay (ms)

150

Send time (ms)

Pkt size: 1500.0 b Burst size: 6000.0 pkts Rate: 500.0 Mbps Empirical:: loss rate: 52 %, Mean delay: 46 ms Simulated:: loss rate: 42 %, Mean delay: 44 ms Drop-front queue: 1400 pkts, Drain rate: 170 Mbps

Queueing delay (ms)

Pkt size: 1500.0 b Burst size: 3000.0 pkts Rate: 300.0 Mbps Empirical:: loss rate: 31 %, Mean delay: 89 ms Simulated:: loss rate: 20 %, Mean delay: 82 ms Drop-front queue: 1400 pkts, Drain rate: 98 Mbps Queueing delay (ms)

100

Pkt size: 1500.0 b Burst size: 3000.0 pkts Rate: 300.0 Mbps Empirical:: loss rate: 42 %, Mean delay: 304 ms Simulated:: loss rate: 37 %, Mean delay: 263 ms Drop-front queue: 1550 pkts, Drain rate: 33 Mbps Queueing delay (ms)

Queueing delay (ms)

Pkt size: 1500.0 b Burst size: 6000.0 pkts Rate: 462.0 Mbps Empirical:: loss rate: 39 %, Mean delay: 48 ms Simulated:: loss rate: 39 %, Mean delay: 49 ms Drop-front queue: 1550 pkts, Drain rate: 170 Mbps

Johan Garcia, Simon Sundberg, and Anna Brunstrom

150

100

150

Replication nr: 26

0 0

100

125 100 75 50 25 Replication nr: 13

120

100

120

140

20 Replication nr: 23 40

Send time (ms)

100

150

100

50 Replication nr: 21

0 0

100

125

Send time (ms)

100

150

200

Pkt size: 1500.0 b Burst size: 4000.0 pkts Rate: 324.0 Mbps Empirical:: loss rate: 53 %, Mean delay: 41 ms Simulated:: loss rate: 42 %, Mean delay: 60 ms Drop-front queue: 1100 pkts, Drain rate: 98 Mbps Queueing delay (ms)

Queueing delay (ms)

Replication nr: 16

Send time (ms)

Pkt size: 1500.0 b Burst size: 5000.0 pkts Rate: 324.0 Mbps Empirical:: loss rate: 38 %, Mean delay: 59 ms Simulated:: loss rate: 38 %, Mean delay: 78 ms Drop-front queue: 1500 pkts, Drain rate: 103 Mbps

Send time (ms)

Pkt size: 1500.0 b Burst size: 5000.0 pkts Rate: 545.0 Mbps Empirical:: loss rate: 35 %, Mean delay: 35 ms Simulated:: loss rate: 33 %, Mean delay: 34 ms Drop-front queue: 1300 pkts, Drain rate: 218 Mbps

100

160

Queueing delay (ms)

Send time (ms)

150

175

125 100 75 50 25 Replication nr: 29

0 0

100

120

140

Send time (ms)

Figure 7: Randomly selected runs showing per-packet queuing-induced delay from measurements (black), and a drop-front queuing simulator configured with queue size and drain rate to fit empirical measurements (blue).

Record · ID 238558 · SHA-256 cd2ab207834b03ee
Retrieved via Conceptio — every document is proof-bundled with source, license, and retrieval metadata.