A First Look at Starlink Performance

François Michel∗ Martino Trevisan

UCLouvain University of Trieste
[email protected] [email protected]

Danilo Giordano Olivier Bonaventure

Politecnico di Torino UCLouvain
[email protected] [email protected]

ABSTRACT combine cellular and xDSL [22, 28]. Given the opportunities o�ered
With new Low Earth Orbit satellite constellations such as Starlink, by these rural areas, several companies nowadays o�er satellite-
satellite-based Internet access is becoming an alternative to tradi- based Internet access solutions.
tional �xed and wireless technologies with comparable throughputs Classical Satellite Communications (SatCom) use geostationary
and latencies. In this paper, we investigate the user-perceived per- satellites with at an orbit of 22 236 miles. A single satellite can cover
formance of Starlink. Our measurements show that latency remains a large portion of the Earth at the price of a latency of several
low and does not vary signi�cantly under idle or lightly loaded hundreds of milliseconds due to their high elevation [18, 30]. Such
links. Compared to another commercial Internet access using a communication technology may provide connectivity to thousands
geostationary satellite, Starlink achieves higher TCP throughput customers with connections easily reaching a speed up to 100 MB,
and provides faster web browsing. To avoid interference from per- with the drawback of a minimum latency of about 600 ms [37].
formance enhancing proxies commonly used in satellite networks, A new approach is to use a constellation of Low Earth Orbit
we also use QUIC to assess performance under load and packet loss. (LEO) satellites to dramatically reduce communications latency.
Our results indicate that delay and packet loss increase slightly The �rst large-scale deployment of this kind is the Starlink con-
under load for both upload and download. stellation, currently operating more than two thousand satellites.
The commercial service started in beta version in October 2020 in
CCS CONCEPTS the United States and from 2021 in European countries. It promises
Internet access with latency on the order of 20 ms and bandwidth
• Networks ! Network measurement; Wireless access networks.
speeds between 100 and 200 Mbps [12]. Being this a newborn ser-
KEYWORDS vice, its operation and performance have not been fully investigated
yet. The only comparable work has been proposed by Kassem et
Starlink, Satellite Communications, Low Earth Orbit, Network Per- al. [34], which shows how Starlink performance changes from dif-
formance, Measurements ferent vantage points. We here focus on how the performance of
ACM Reference Format: a single Starlink vantage point changes when accessing globally
François Michel, Martino Trevisan, Danilo Giordano, and Olivier Bonaven- distributed resources, under high and heavy network loads, with
ture. 2022. A First Look at Starlink Performance. In Proceedings of the 22nd the TCP and QUIC transport protocols.
ACM Internet Measurement Conference (IMC ’22), October 25–27, 2022, Nice, For many years, TCP has been the dominant protocol for In-
France. ACM, New York, NY, USA, 7 pages. https://doi.org/10.1145/3517745.
ternet services [32, 41]. SatCom operators therefore widely adopt
3561416
TCP Performance Enhancing Proxies [23] (PEP) to mitigate the
impact of increased latency on TCP performance. Recently, the
1 INTRODUCTION
Internet Engineering Task Force (IETF) has standardized the QUIC
Internet access technologies and Internet protocols are constantly protocol [26, 31]. In short, QUIC combines the features of TCP and
evolving. Broadband technologies such as xDSL and cable modems TLS [39] into a single protocol above UDP. QUIC is already widely
are prevalent today, but they are being replaced by optical �bers. deployed by major cloud providers and it drives a growing share of
In densely populated areas, such as cities, �ber deployment can Internet tra�c [40, 42, 44]. In contrast with TCP, QUIC cannot be
be pro�table, while in rural or mountainous areas, however, it optimized by using PEPs in satellite networks since QUIC packets
can be much more expensive. For this reason, network operators are encrypted and authenticated. Given the current growth of QUIC
have been working on other Internet access technologies since tra�c, it is important to evaluate new access networks using both
considerable time. Some propose Fixed Wireless Access (FWA) QUIC and TCP.
technologies [15, 17]. Others are deploying hybrid networks that In this paper, we benchmark the Starlink service and compare
∗ François Michel is FNRS Research Fellow it to traditional SatCom networks. We measure the performance
in terms of throughput for QUIC and TCP, latency, and packet
ACM acknowledges that this contribution was authored or co-authored by an employee,
contractor or a�liate of a national government. As such, the Government retains a
loss, and �nd that Starlink delivers on its performance promises
nonexclusive, royalty-free right to publish or reproduce this article, or to allow others and enables the use of demanding services such as high-de�nition
to do so, for Government purposes only. video streaming or cloud gaming. We also �nd that Quality of Ex-
IMC ’22, October 25–27, 2022, Nice, France
© 2022 Association for Computing Machinery.
perience (QoE) for Web browsing with Starlink is far better than
ACM ISBN 978-1-4503-9259-4/22/10. . . $15.00 with traditional SatCom and comes close to wired access. To enable
https://doi.org/10.1145/3517745.3561416
IMC ’22, October 25–27, 2022, Nice, France Michel et al.

the research community to perform experiments with an emu- Table 1: Overview of the datasets.
lated Starlink connection, and compare it with other connection
technologies (included 3G, 4G, and classical geostationary SatCom Measure Network Duration Target
with data from [37]), we have created a data-driven model for Latency Starlink 5 Months 11 Anchors
the ERRANT network emulator tool [43] and make it available at Starlink 4 Months Ookla
Throughput
https://github.com/SmartData-Polito/errant. SatCom 2 Weeks Servers
Starlink 4 Months 120
Web Browsing
SatCom 2 Weeks Websites
2 TESTBED AND MEASUREMENTS QUIC H3 Starlink 5 Months Our server
For our experimental campaign, we use three o�-the-shelf PCs QUIC messages Starlink 5 Months Our server
equipped with 8 cores and 16 GB of memory running Ubuntu 20.04
and Linux kernel version 5.0.4. The two �rst PCs are located in
the UCLouvain campus in Louvain-la-Neuve, Belgium. The �rst York, Fremont) and Asia (Singapore). We also include 4 nodes of
PC (PC-Starlink) is connected to the Internet via Starlink with a the RIPE Atlas project hosted by volunteers in the same country as
regular subscription. The second PC (PC-Wired) is connected to the our Starlink connection (Belgium). Every �ve minutes, we measure
UCLouvain campus network via a 1 Gbit/s Ethernet adapter. The the latency towards the anchors running 3 pings. We also measure
third PC (PC-SatCom) is connected to the Internet via a traditional the link latency under light and heavy network load by studying
SatCom equipment for which we have purchased a regular plan the evolution of the Round-Trip Time (RTT) measured by QUIC
o�ering up to 100 Mbit/s in downlink and 10 Mbit/s in uplink. with our messages and H3 transfers.
The SatCom operator is a reseller and relies on a major European Packet loss. Starlink provides a new kind of wireless network
provider that uses geostationary satellites to provide Internet access. access. In general, packet losses come from two causes: congestion
Our user equipment consists of a dish antenna and a modem that or medium imperfection (e.g., Wi-Fi interferences). We study the
connects the PC to the network. For each setup, the TCP receive packet losses under light and heavy network load using our QUIC
window is the kernel default, i.e. 131072 bytes by default with setup with both bulk H3 transfers and messages variants.
a maximum of 6291456 bytes through automatic bu�er tuning. Throughput. We measure Starlink download and upload through-
The congestion control is Cubic. We use the three PCs to run the put using the command line version of the Ookla SpeedTest ser-
experiments that we describe in detail below and summarize in vice [11]. The application selects the closest test server and probes
Table 1. download and upload capacity by opening several parallel TCP
QUIC measurements. Some of the performance metrics of this connections. We perform a speed test every half an hour using
article are gathered using the QUIC protocol [26]. We assess the PC-Wired from 20 December to April 7 2022. We compare Star-
network performance with two kinds of transfers: (i) bulk HTTP/3 link with SatCom using PC-SatCom, on which we run identical
(H3) [16] 100MB transfers and (ii) light QUIC transfers with regu- measurements, scheduling them at the same pace. Finally, we also
larly sent messages, similar to a real-time video tra�c. The latter measure Starlink throughput using our QUIC H3 setup.
sends 25 variable length messages per second during 2 minutes. Web Browsing. We measure the performance of Starlink for Web
Each message has a size in the 5-25kB range. The average bitrate browsing by running on PC-Starlink automatic visits to websites
of this transfer is 3 Mbit/s, far below both downlink and uplink and collect metrics that can be used as proxy for users’ perceived
capacities announced by Starlink. The QUIC client runs on PC- QoE. We rely on BrowserTime, a tool performing automated visits
Starlink while the server is located in the UCLouvain university to websites [2]. We rely on the rank provided by SimilarWeb [13],
campus. Half of the experiments are transfers from the server to an online ranking service out of which we pick the top-120 website
the client (download) and the other half are from the client to the for Belgium. Among the statistics collected with BrowserTime,
server (upload). Using QUIC instead of TCP ensures that we mea- we focus on two metrics that have been shown to be correlated
sure the end-to-end latency as it forbids the use of middleboxes and with users’ QoE [19]: (i) onLoad: the time when the browser �res
proxies interfering with the tra�c at the transport layer as it can be the onLoad event – i.e., when all elements of the page have been
done for TCP with PEPs. The way QUIC identi�es and retransmits downloaded and parsed; (ii) SpeedIndex: proposed by Google [10],
packets also allows us to exactly point every lost packet and dis- it represents the time at which the visible parts of the page are
ambiguating original packets from retransmissions. The QUIC H3 displayed. It is computed by recording the video of the browser
server is able to provide more than 400Mbps of QUIC tra�c to other screen and tracking the visual progress of the page during rendering.
endpoints connected to wired networks outside our campus. The Every half an hour, we test 30 websites chosen at random and ensure
QUIC implementation used is quiche [1] compiled in release mode they do not overlap with the speed test experiments. We collect
from commit ba87786. Its initial max_data and max_stream_data data from December 20 to April 7 2022. We compare the browsing
transport parameters are set to 10MB and the receive window varies experience o�ered by Starlink with the SatCom link by running the
through automatic bu�er tuning. The congestion control used is same experiments on PC-SatCom and collect the resulting metrics.
Cubic.
Latency. We measure the latency of Starlink by probing a set 3 RESULTS
of 11 anchors using ping. Our set of anchors includes 7 servers In this section, we report our results and �ndings. We �rst discuss
used inside the RIPE Atlas project [8]. The servers are located the measured latency and then focus on packet loss and throughput,
in Europe (Amsterdam ⇥2, Nuremberg ⇥2), North America (New comparing StarLink with traditional SatCom. Finally, we discuss
A First Look at Starlink Performance IMC ’22, October 25–27, 2022, Nice, France

Min RTT [ms] 1.0 1.0

28.4 28.9 24.7 24.7 20.6 20.2 23.5 23.0 237 161
103
0.8 0.8
RTT [ms]

0.6 0.6

CDF
CDF
102
0.4 0.4

0.2 Download 0.2 Download

Upload Upload
101
0.0 0.0
BE-1

BE-2

BE-3

BE-4

DE-1

DE-2

NL-1

NL-2

SG

US
0.05 0.15 0.25 0.05 0.15 0.25
H3 RTT (s) Messages RTT (s)

Figure 1: Distribution of the RTT to the anchors. The top G (a) H3 bulk tra�c. (b) Messages tra�c.
axis reports the distribution minimum. Notice the logarith- Figure 3: Measured per-packet RTT distribution.
mic ~ axis.
would suggest. San Francisco and Singapore are reached in a me-
80
70 dian of 184 and 270ms respectively. Using traceroute, we veri�ed
60 the path taken by packets towards San Francisco and Singapour
RTT [ms]

50 and the exit nodes from the Starlink network were the same as
40
30 for the European anchors (i.e. one exit in the Netherlands and the
20 other in Germany). This suggests that inter-satellite links (ISL) are
10 25th perc. Median 75th perc. Minimum not currently enabled, although ISL-capable satellites have been
0
5 1 5 1 5 1 5 1 5 1 5 launched [5] and ISL activation is planned by the end of 2022 [4].
2/1 1/0 1/1 2/0 2/1 3/0 3/1 4/0 4/1 5/0 5/1
02 1/1 022/0 022/0 022/0 022/0 022/0 022/0 022/0 022/0 022/0 022/0 To investigate how latency evolves over time, we depict in Fig-
2 2 2 2 2 2 2 2 2 2 2
ure 2 various percentiles and the minimum values, focusing on Eu-
ropean anchors. The G-axis spans the �ve months of measurements,
and we compute our statistics using 6-hours bins. The picture is
Figure 2: RTT towards the European anchors.
fairly �at, indicating stable performance and no particular changes
in Starlink infrastructure over this period. The RTT to the European
QoE-related metrics for web browsing and the presence of middle- anchors remains constant around 50 ms in median and ranges from
boxes. 40 ms (25C⌘ percentile) to 60ms (75C⌘ ). The minimum measured
latency is on the order of 20 ms. Interestingly, we observe that the
3.1 Latency distribution takes on slightly smaller values of a few milliseconds
We begin our analysis by looking at the RTT. We �rst measure the from February 11 onwards - see the small step in the middle of the
latency without load on the link, which is the best latency Starlink �gure. We suspect that this improvement is related to new satellites
subscribers could achieve. We then perform QUIC downloads and joining the constellation in early 2022, although we have no direct
uploads, thus generating bandwidth pressure and study how the evidence [9]. Moreover, we observe an increase in RTT during the
RTT evolves under load. last week of April and the �rst week of May. Since, at that time,
we did not run di�erent experiments, we speculate that in this
Latency during inactivity: Figure 1 shows the distribution of
period Starlink was more loaded or going through reorganization,
the measured latencies towards our set of anchors. The ~-axis (in
but we cannot con�rm this. Finally, we observe that distribution
logarithmic scale) represents the distribution of RTT measured by
of RTT is rather �at over the hours of the day. The median RTT is
ping in the form of a boxplot: boxes range from the 25C⌘ to the
around 50 ms and a Mood’s test suggests the samples are drawn
75C⌘ percentile, while whiskers range from the 5C⌘ to the 95C⌘ . The
from distributions with the same median. Similar considerations
black central stroke represents the median, while on the upper G
hold for throughput measurements as well, and this can hint low
axis we indicate the absolute minimum of the distribution. The 4
utilization of the infrastructure as most operator links are impacted
left-most boxes are the four local anchors. In the median case, the
by diurnal patterns.
RTT is in [46, 52]ms and exceeds 70ms in less than 5% of cases.
The minimum observed RTT for these anchors is [24, 28]ms. Sim- Latency under load: We now study the latency evolution un-
ilar considerations apply to the two Dutch anchors. The lowest der link pressure. We perform HTTP/3 downloads and uploads
RTT we observe is for the two German probes, which PC-Starlink towards our server and study the evolution of the RTT during the
reaches in only 42ms in median. The lowest RTT we observe is �le transfer. Figure 3 shows the distribution of the RTT for every
20.5ms, con�rming Starlink’s 20ms latency promise. We observe acknowledged packet during the experiments. We compute the
that these values allow high QoE for voice calls [25] and are compat- downloads curve by running an additional one-week experiments
ible with latency-sensitive services such as cloud gaming. Indeed, session with packets captures on the server as they were too few
GeForce Now, one of the leading platforms, mandates a latency RTTs samples coming from the client capture for download trans-
below 80ms [7]. To reach the most distant anchor points in the fers. Each curve contains more than 2 millions RTT samples. We
U.S. (San Francisco) and Asia (Singapore), the RTT is necessarily note a median, 95C⌘ and 99C⌘ percentiles RTT of 95 (resp. 104), 175
much higher, but not more than the distance between the endpoints (resp 237) and 210 (resp 310) ms for downloads (resp. uploads). We
IMC ’22, October 25–27, 2022, Nice, France Michel et al.

Table 2: QUIC packet loss ratios 1.00 1.00

H3 # H3 " Messages # Messages " 0.75 0.75

1.56% 1.96% 0.40% 0.45%

CDF

CDF
0.50 0.50

0.25 Download 0.25 Download

can see that the RTT increases more for uploads than download. Upload Upload

This di�erence may be explained by the larger available bandwidth 0.00

1 3 5 7 9 11 13 15
0.00
1 3 5 7 9 11 13 15 17 19 21
for downloads allowing emptying the router queues faster than loss burst length loss burst length
for uploads, having thus a smaller impact on queuing delay for
equally-sized queues. (a) H3 transfers (b) Messaging transfers
We �nally study the RTT evolution with the QUIC messages Figure 4: Measured loss bursts distribution. Note that Table 2
transfer. Compared to the H3 tra�c, the RTT stays mostly under shows that packet losses are far less common for messages
100ms, similarly to the values we obtain for ping European anchors. transfers. Thus, loss burst greater frequency is only apparent.
The downloads (resp. uploads) have 50 (resp. 66) ms median RTT,
71 (resp 87) ms 95C⌘ percentile and 87 (resp. 143) ms 99C⌘ percentile
RTT. The larger RTT for uploads relates to quiche not implement- Packet losses during low bitrate transfers: We now focus on
ing packet pacing. The largest messages (25 kB) are thus stacked in the low bitrate messaging use-case. The two last columns of Ta-
the network’s bu�ers making the RTT increase lightly. ble 2 show the packet loss ratios measured during those transfers.
Take Away: The minimum latency of Starlink is in the order of Conversely to the H3 experiments, the computed loss ratio is only
20 ms for close destinations, as publicly advertised. Under tra�c load, slightly smaller for downloads than for uploads. The loss ratio is
it may increase to a few hundreds of milliseconds. also signi�cantly lower compared to H3. Given the low bitrate
of the messaging use-case and the overall low RTT previously
3.2 Characterizing packet losses measured, we can expect that fewer packet losses were caused by
congestion here. Note however that from the transport viewpoint,
Packet losses can be caused by congestion or imperfections on the
there is no known way to distinguish between congestion and
medium. For download, we determine losses by looking at QUIC re-
medium-induced losses. This is why loss-based congestion con-
ceived packet numbers on the client. As in QUIC retransmitted data
trol algorithms such as Cubic [24] interpret every loss event as a
have di�erent packet numbers from the original data and as quiche
congestion signal.
does not introduce packet number gaps, every missing packet num-
Figure 4b shows the loss bursts lengths distribution for the mes-
ber means the packet has been lost. For uploads, we determine the
saging experiments. While packet losses are a lot less frequent
received packets by looking at the ACK frames returned by the
compared to the H3 experiments (see Figure 2), the loss bursts are
server.
in general longer when occurring. We conjecture that most of the
Packet losses during HTTP/3 transfers: We �rst study the loss events occurring during the H3 experiments are due to con-
packet losses encountered during HTTP/3 bulk transfers. In this gestion: they are more frequent and only concern a few packets,
case, losses can be due to both congestion and medium imperfec- while the loss events encountered during the messages transfers
tions. The �rst two columns of Table 2 show the packet losses may be related to the medium, sometimes being even comparable
recorded during the H3 transfers. We can see that uploads su�ered to small network outages with some loss bursts of more than 100
from more loss events than downloads. Nearly 2% of the packets packets (also present for H3 transfers). Concerning the loss events
were lost during uploads while a bit more than 1.5% were lost dur- duration, most events for message transfers were shorter than 1ms.
ing downloads. Figure 4a shows the measured distribution of the However, we noted 95C⌘ and 99C⌘ percentiles of 104 and 127 ms
loss bursts lengths during H3 transfers. The loss burst length is the which are larger than the percentiles for H3 downloads (note that
number of consecutively lost packets for each loss event. As we the loss events for message transfers are a lot more rare than H3 loss
can see, the majority of loss events during uploads concerned only events and that H3 transfers probably mostly encounter congestion-
one packet at a time, while more than 75% of loss events during induced losses). Similarly to H3, we also detected small network
downloads concerned several consecutive packets. We also look outages with loss events lasting more than 1 second.
at the duration of a loss event. Indeed, some wireless technologies Finally, we checked that those losses were neither caused by our
such as 802.11 implement retransmission mechanisms that may network nor our server by running downloads for both H3 and
delay the arrival of subsequent packets, resulting in small silent pe- messages transfers from a machine in Amsterdam (i.e., close to an
riods during the transfer [36]. As packets are captured on the client, exit point of the Starlink network) towards our H3 server. For H3
we can compute the duration of loss events during downloads. We (resp. messages) downloads, over more than 5.8 M (resp. 2.8 M)
identi�ed 244 008 loss events. The median loss event duration is packets sent by our QUIC server, only 10 (resp. 8) were lost, making
49 microseconds. The 75C⌘ and 90C⌘ percentiles are respectively 58 loss events nearly absent outside Starlink.
and 113 microseconds. The 95C⌘ and 99C⌘ percentiles are 1.5 and Take Away: The loss events occurring when the link is loaded
7.5 milliseconds. We also identi�ed a small number of longer loss are more frequent and only a�ect a few consecutive packets. Without
periods lasting more than 1 second identifying a possible loss of link pressure, the loss events are more rare, concern overall more
connectivity. consecutive packets and last longer.
A First Look at Starlink Performance IMC ’22, October 25–27, 2022, Nice, France

1.0 1.0

0.8 0.8

0.6 0.6

CDF
CDF

0.4 Starlink Ookla 0.4 Starlink

Starlink H3 SatCom
0.2 0.2
SatCom Ookla Wired
0.0 0.0
0 100 200 300 400 0 10 20 30 40 50 0 5 10 15 20 25 0 5 10 15 20
Download [Mbit/s] Upload [Mbit/s] OnLoad [s] Speed Index [s]

(a) Download Throughput. (b) Upload Throughput. (a) onLoad. (b) SpeedIndex.
Figure 5: Measured throughput distribution. Figure 6: Web browsing performance.

3.3 Throughput download and upload of 100MB of data in Figure 5. We ran two ex-
Figure 5 shows the throughput distribution for three experiments: periment sessions, one until the 7C⌘ of April and one starting from
Ookla Speedtest on Starlink, H3 bulk download on Starlink and the 25C⌘ of April. We observed a di�erence of download through-
Ookla Speedtest on the regular SatCom access. We �rst discuss the put during the two sessions but the upload throughput stayed the
Ookla speedtests and then the H3 results. same. All the parameters are the same for the two sessions but
we observed an increase of download capacity for QUIC. Figure 5
Speedtest results: By looking at Figure 5a, we can see that Star- thus shows the results for the second session as they represent
link’s download throughput ranges between 100 and 250 Mbit/s. the most up-to-date results for Starlink.1 The download bitrate sits
The median value is 178 Mbit/s, while the maximum is 386 Mbit/s. mostly between 100 and 150 Mbit/s which is in line with what is
This maximum is surprisingly high given the company’s public announced by Starlink but lower than the best results obtained with
statements, i.e., download speeds between 100 Mbit/s and 200 the Ookla TCP speedtests and lower than what our QUIC server
Mbit/s. We note that they enable the use of bandwidth-intensive ser- can deliver to other wired endpoints. We also excluded the possi-
vices, such as High-De�nition video streaming. Net�ix’s 4K videos bility of an incorrect receive window tuning of quiche by running
require a download bandwidth of 15 Mbit/s [6], while Disney+ additional experiments with a 150MB receive window, leading to
recommends 25 Mbit/s [3]. similar results. The di�erence in download throughput may be due
The upload throughput, in Figure 5b, is signi�cantly lower, reach- to the fact that regular speedtests use at least four concurrent TCP
ing a median of 17 Mbit/s. Fewer than 5% of the cases exceed 30 connections while the QUIC download uses one single connection,
Mbit/s and the highest observed rate is 64 Mbit/s. For both metrics, reacting more strongly to losses [21, 35]. It is also possible that
we cannot �nd a seasonality in the measurements. Looking at the Ookla speedtests are prioritized by the operator, similarly to what
di�erent hours of the day, the median throughput varies by less happens for conventional operators. The measured upload through-
than ±10% with no apparent day-night cycle. Furthermore, we have put is similar for the two sessions and is in-line with the Ookla
not observed any increasing or decreasing trend in the measure- speedtest results: they have the same median, although the QUIC
ments over our three months of experiments, and the distributions results are more stable.
assume approximately the same average values and variability. Take Away: In download and upload, Starlink outperforms tradi-
Comparing with traditional SatCom, we �nd that Starlink pro- tional SatCom.The measured throughput with QUIC is lower compared
vides higher throughput in both scenarios. Considering download, to TCP speed tests for downloads but similar and more stable than
with a median value of 178 Mbit/s, Starlink is more than twice TCP speed tests for uploads.
as fast as SatCom (82 Mbit/s). The situation is similar for upload:
the traditional SatCom connection inherently o�ers lower upload 3.4 Browsing Performance
throughput (4.5 Mbit/s in median), as it is limited to a bitrate of 10 We now quantify the Starlink performance for Web browsing. We
Mbit/s. compare the user experience of Starlink users against other access
We can brie�y compare these values with mobile networks look- technologies. We resort to the onLoad and Speed Index metrics
ing at recent related work. Safari et al. [29, 43] conducted a large- that have been shown to correlate with it [19]. We continuously
scale measurement campaign in 2018 involving 4 European MNOs visit a set of 120 popular websites in our country, using PC-Starlink,
in 2 countries. For download, they found that in the best case PC-SatCom and PC-Wired.
(4G with good signal quality), mobile networks provide a median In Figure 6, we show the ECDF of QoE-related metrics. Starting
throughput of 29.5 Mbit/s. For upload, the authors found a median from onLoad (Figure 6a), we �nd that it generally ranges from a few
bitrate of 14 Mbit/s, comparable to Starlink’s 17 Mbit/s. However, to 15-20 seconds, depending on the website and conditions. Starlink
keep in mind that these throughput measurements [29, 43] are al- (solid red line), overall, provides a median onLoad of 2.12s and an
ready 4 years old at the time of writing and thus possibly outdated. interquantile range (IQR) between 1.60s and 2.78s. Experiments
HTTP/3 transfers: We now measure throughput using HTTP/3 with SatCom equipment (blue dashed line) show that onLoad is
with our server located in Belgium, the same country as the Star- 1 Whilenot present on the graph, all packet captures for the �rst session will be
link access. We report the measured throughput distribution for the provided in the artifacts of the article.
IMC ’22, October 25–27, 2022, Nice, France Michel et al.

substantially larger, 10.91s on median. The distribution ranges from phase of low utilization. However, we emphasize the presence of
8.36s (25C⌘ percentile) to 13.59s (75C⌘ percentile). It is likely that this (moderate) packet loss even at low network utilization.
performance is due to the high latency of the SatCom connections, Given the limited time between the commercial launch of Star-
which a�ects the operation of TCP and HTTP. Note that rendering a link and this study, our ping latency measurements are still in
web page requires opening multiple connections to di�erent servers the early stages in terms of temporal and spatial scale. As we aim
to retrieve all page objects. In our dataset, a single visit results at tracking latency evolution over time, the number of anchors
in 15 connections on average. On SatCom, opening a connection we probe is limited and does not allow us to provide a complete
(including the TLS handshake) takes an average of 2 030ms, while picture of latency for a comprehensive set of targets worldwide.
Starlink requires only 167ms. Finally, the green dashed line reports Inter-satellite links do not seem to be enabled, but Starlink plans
the baseline performance of a well-functioning wired network. The to deploy them by the end of 2022. At that time, coverage will be
median onLoad is 1.24s, still considerably lower than the other two signi�cantly expanded, and it will be possible to study how packets
cases. Although we do not run experiment on mobile networks, are routed through the sky and how performance varies around
we mention that Rajiullah et al. [38] use a large testbed of mobile the globe.
nodes to visit a number of popular websites. They measure onLoad Our QUIC measurements reveal additional details about the
time on the order of 2 5s, thus moderately higher than what we RTTs and packet losses under load. During HTTP/3 bulk transfers,
measure on Starlink. RTTs increase more than when applications exchange messages at
Similar considerations apply to the SpeedIndex (Figure 6b). Star- a low rate. Thanks to QUIC’s precise acknowledgments, our mea-
link shows a median performance of 1.82s, outperforming SatCom surements show that packet losses are more frequent during bulk
with a 8.19s median SpeedIndex. Starlink performance is closer to transfers and provide some characterization of the loss patterns.
the Wired setup, with median of 1.0s. At the application level, we have studied QoE for web browsing
Take Away: For Web browsing, Starlink outperforms SatCom and and found it to be radically better than traditional SatCom. Note,
has close performance to regular wired access. Looking at QoE-related however, that we only studied a limited number of websites because
metrics, Starlink is 75 80% faster than traditional SatCom. we wanted to visit them hourly. We did not account for di�erences
in experience that could be due to di�erent browsers, di�erent de-
3.5 Middleboxes and tra�c discrimination vices, or other factors. Also, we only visited landing pages, while
a more realistic campaign should include internal pages [14]. Fi-
SatCom solutions often deploy PEPs to alleviate the problems due
nally, further measurements should assess QoE for a wider range
to the high link latency. Some operators also apply Tra�c Discrimi-
of services, since in many cases (e.g. video calls) there are well-
nation (TD) to control the bandwidth used by applications on their
established performance indicators to study. However, we believe
network. In this section, we analyze the presence of middleboxes
that the results in this article give a good insight to researchers of
and TD on the Starlink network.
what they can expect in terms of throughput, latency and packet
PEPs and middleboxes: We �rst use traceroute and Trace- losses when developing solutions that may be used together with
box [20] to detect PEPs and middleboxes. Traceroute shows us Starlink network accesses.
the presence of two levels of NAT at the two �rst nodes: the Star-
link access point (192.168.1.1) and a carrier-grade NAT node A ARTEFACTS
(100.64.0.1) at the exit of the satellite link. Tracebox does not All the data gathered to compute the results discussed in this paper
show the presence of any PEP: the TCP handshake is correctly are publicly available. This includes pings, traceroute, Tracebox,
performed in the destination network. Only the TCP and UDP speed test and BrowserTime results as well as more than 530 Giga-
checksums are altered by the NATs. bytes of QUIC packet captures along with their encryption keys.
Tra�c discrimination: We employ Wehe [33], a state-of-the-art The data can be found online at https://smartdata.polito.it/a-�rst-
tool to detect Tra�c Discrimination (TD). It replays packet traces of look-at-starlink-performance-open-data/.
22 popular service including video streaming (e.g., Net�ix, YouTube)
and video call (e.g., Zoom, Skype). It then replays the same traces
B ETHICAL CONSIDERATIONS
with randomized bytes to prevent the operator from correlating Our work does not employ data coming from individuals as it is
this tra�c to the original service. In case of Starlink, we launched based uniquely on active measurements. During our experiments,
ten times the complete Wehe tests but could not �nd any TD policy we took care to avoid harming the destination servers, anchors and
in place, at least for these popular services. crawled webpages. We run ping measurements towards anchors
every �ve minutes and perform speed test approximately every
4 DISCUSSION AND FUTURE STEPS hour. We believe such a workload cannot harm the proper operation
of the targets. Regarding web measurements, we contacted each
This study presents an initial characterization of Starlink from the website approximately once per hour. Considering that the target
perspective of a single site in Western Europe. Our TCP and QUIC of our analysis were some of the most popular websites in Western
measurements show that Starlink delivers on its promised low la- countries, our belief is not to have caused an overload on the servers
tency and high throughput. It enables the use of latency-sensitive or any undesirable side e�ect.
services that struggle with traditional SatCom. Interestingly, early
simulations of LEO constellations (see Hypatia [27], among oth-
ers) predicted similarly low values for RTT, especially in this �rst
A First Look at Starlink Performance IMC ’22, October 25–27, 2022, Nice, France

REFERENCES [31] Adam Langley, Alistair Riddoch, Alyssa Wilk, Antonio Vicente, Charles Krasic,
[1] 2022. Savoury implementation of the QUIC transport proto- Dan Zhang, Fan Yang, Fedor Kouranov, Ian Swett, Janardhan Iyengar, et al. 2017.
col and HTTP/3. https://github.com/cloud�are/quiche/tree/ The quic transport protocol: Design and internet-scale deployment. In Proceedings
ba87786836ab4ecfadf9f80a95e3da34ef0e1886 of the conference of the ACM special interest group on data communication. 183–
[2] 2022-05-13. Browsertime. https://www.sitespeed.io/documentation/browsertime/ 196.
[3] 2022-05-13. Disney+ - Internet speed recommendations. https: [32] DongJin Lee, Brian E Carpenter, and Nevil Brownlee. 2010. Observations of UDP
//help.disneyplus.com/csp?id=csp_article_content&sys_kb_id= to TCP ratio and port numbers. In 2010 Fifth International Conference on Internet
bb07d3cd1b8d0010b8651f861a4bcbfd Monitoring and Protection. IEEE, 99–104.
[4] 2022-05-13. @ElonMusk, Twitter, on ISL activation. https://twitter.com/elonmusk/ [33] Fangfan Li, Arian Akhavan Niaki, David Cho�nes, Phillipa Gill, and Alan Mislove.
status/1535394359373443073 2019. A large-scale analysis of deployed tra�c di�erentiation practices. In
[5] 2022-05-13. @ElonMusk, Twitter, on the launch of ISL-enabled satellites. https: Proceedings of the ACM Special Interest Group on Data Communication. 130–144.
//twitter.com/elonmusk/status/1436541063406264320 [34] Mohamed M. Kassem, Aravindh Raman, Diego Perino, and Nishanth Sastry. 2022.
[6] 2022-05-13. Net�ix - Internet connection speed recommendations. https://help. A Browser-side View of Starlink Connectivity. In Proceedings of the 2022 Internet
net�ix.com/en/node/306 Measurement Conference. https://doi.org/10.1145/3517745.3561457
[7] 2022-05-13. NVIDIA GeForce Now System Requirements. https://www.nvidia. [35] Kyle MacMillan, Tarun Mangla, James Saxon, Nicole P Marwell, and Nick Feam-
com/it-it/geforce-now/system-reqs ster. [n.d.]. A Comparative Analysis of Ookla Speedtest and Measurement Labs
[8] 2022-05-13. RIPE Atlas. https://atlas.ripe.net/ Network Diagnostic Test (NDT7). ([n. d.]).
[9] 2022-05-13. Space.com - SpaceX lofts 49 Starlink internet satellites to orbit in 1st [36] François Michel and Olivier Bonaventure. 2021. Packet delivery time as a tie-
launch of 2022. https://www.space.com/spacex-starlink-launch-success-january- breaker for assessing Wi-Fi access points. IAB Workshop on Measuring Network
2022 Quality for End-Users (2021).
[10] 2022-05-13. Speed Index. https://web.dev/speed-index/ [37] Daniel Perdices, Gianluca Perna, Martino Trevisan, Danilo Giordano, and Marco
[11] 2022-05-13. Speedtest CLI. https://www.speedtest.net/it/apps/cli Mellia. 2022. When Satellite is All You Have When Satellite is All You Have:
[12] 2022-05-13. Starlink. https://www.starlink.com/ Watching the Internet from 550 ms. In Proceedings of the 2022 Internet Measure-
[13] 2022-05-13. Website Tra�c Analysis & Competitive Intelligence, SimilarWeb. https: ment Conference. https://doi.org/10.1145/3517745.3561432
//www.similarweb.com/ [38] Mohammad Rajiullah, Andra Lutu, Ali Safari Khatouni, Mah-Rukh Fida, Marco
[14] Waqar Aqeel, Balakrishnan Chandrasekaran, Anja Feldmann, and Bruce M Maggs. Mellia, Anna Brunstrom, Ozgu Alay, Stefan Alfredsson, and Vincenzo Mancuso.
2020. On landing and internal web pages: The strange case of jekyll and hyde in 2019. Web experience in mobile networks: Lessons from two million page visits.
web performance measurement. In Proceedings of the ACM Internet Measurement In The world wide web conference. 1532–1543.
Conference. 680–695. [39] Eric Rescorla. 2018. The Transport Layer Security (TLS) Protocol Version 1.3.
[15] "AT&T". [n.d.]. Fixed Wireless Internet. https://www.att.com/internet/�xed- RFC 8446. https://doi.org/10.17487/RFC8446
wireless/. [40] Jan Rüth, Ingmar Poese, Christoph Dietzel, and Oliver Hohlfeld. 2018. A First
[16] Mike Bishop. 2021. Hypertext Transfer Protocol Version 3 (HTTP/3). Internet-Draft Look at QUIC in the Wild. In International Conference on Passive and Active
draft-ietf-quic-http-34. Internet Engineering Task Force. https://datatracker.ietf. Network Measurement. Springer, 255–268.
org/doc/html/draft-ietf-quic-http-34 Work in Progress. [41] Kevin Thompson, Gregory J Miller, and Rick Wilder. 1997. Wide-area Internet
[17] Ranveer Chandra and Thomas Moscibroda. 2019. Perspective: White space net- tra�c patterns and characteristics. IEEE network 11, 6 (1997), 10–23.
working with Wi-Fi like connectivity. ACM SIGCOMM Computer Communication [42] Martino Trevisan, Danilo Giordano, Idilio Drago, Maurizio Matteo Munafò, and
Review 49, 5 (2019), 107–109. Marco Mellia. 2020. Five years at the edge: Watching internet from the isp
[18] Paolo Chini, Giovanni Giambene, and Sastri Kota. 2010. A survey on mobile satel- network. IEEE/ACM Transactions on Networking 28, 2 (2020), 561–574.
lite systems. International Journal of Satellite Communications and Networking [43] M. Trevisan, A. S. Khatouni, and D. Giordano. 2020. ERRANT: Realistic emulation
28, 1 (2010), 29–57. of radio access networks. Computer Networks 176 (2020), 107289.
[19] Diego Neves da Hora, Alemnew Sheferaw Asrese, Vassilis Christophides, Renata [44] Johannes Zirngibl, Philippe Buschmann, Patrick Sattler, Benedikt Jaeger, Juliane
Teixeira, and Dario Rossi. 2018. Narrowing the gap between QoS metrics and Aulbach, and Georg Carle. 2021. It’s over 9000: analyzing early QUIC deployments
Web QoE using Above-the-fold metrics. In International Conference on Passive with the standardization on the horizon. In Proceedings of the 21st ACM Internet
and Active Network Measurement. Springer, 31–43. Measurement Conference. 261–275.
[20] Gregory Detal, Benjamin Hesmans, Olivier Bonaventure, Yves Vanaubel, and
Benoit Donnet. 2013. Revealing middlebox interference with tracebox. In Pro-
ceedings of the 2013 conference on Internet measurement conference. 1–8.
[21] Nick Feamster and Jason Livingood. 2020. Measuring internet speed: current
challenges and future recommendations. Commun. ACM 63, 12 (2020), 72–80.
[22] "Broadband Forum". 2016. "TR-348 Hybrid Access Broadband Network Architec-
ture".
[23] Jim Griner, John Border, Markku Kojo, Zach D. Shelby, and Gabriel Montene-
gro. 2001. Performance Enhancing Proxies Intended to Mitigate Link-Related
Degradations. RFC 3135. https://doi.org/10.17487/RFC3135
[24] Sangtae Ha, Injong Rhee, and Lisong Xu. 2008. CUBIC: a new TCP-friendly
high-speed TCP variant. ACM SIGOPS operating systems review 42, 5 (2008),
64–74.
[25] ITU-T. 2003. Recommendation G.114: One-way transmission time. Technical
Report.
[26] Jana Iyengar and Martin Thomson. 2021. QUIC: A UDP-Based Multiplexed and
Secure Transport. RFC 9000. https://doi.org/10.17487/RFC9000
[27] Simon Kassing, Debopam Bhattacherjee, André Baptista Águas, Jens Eirik Saethre,
and Ankit Singla. 2020. Exploring the" Internet from space" with Hypatia. In
Proceedings of the ACM Internet Measurement Conference. 214–229.
[28] Nicolas Keukeleire, Benjamin Hesmans, and Olivier Bonaventure. 2020. In-
creasing broadband reach with hybrid access networks. IEEE Communications
Standards Magazine 4, 1 (2020), 43–49.
[29] Ali Safari Khatouni, Marco Mellia, Marco Ajmone Marsan, Stefan Alfredsson,
Jonas Karlsson, Anna Brunstrom, Ozgu Alay, Andra Lutu, Cise Midoglu, and
Vincenzo Mancuso. 2017. Speedtest-like measurements in 3g/4g networks: The
monroe experience. In 2017 29th International Teletra�c Congress (ITC 29), Vol. 1.
IEEE, 169–177.
[30] Oltjon Kodheli, Eva Lagunas, Nicola Maturo, Shree Krishna Sharma, Bhavani
Shankar, Jesus Fabian Mendoza Montoya, Juan Carlos Merlano Duncan, Danilo
Spano, Symeon Chatzinotas, Steven Kissele�, et al. 2020. Satellite communications
in the new space era: A survey and future challenges. IEEE Communications
Surveys & Tutorials 23, 1 (2020), 70–109.