[Starlink] Ookla's Speedtest results now map the city & PoP where your traffic joins the IXPs as the aircraft moves

[Starlink] Ookla's Speedtest results now map the city & PoP where your traffic joins the IXPs as the aircraft moves

[Frantisek Borsik]

Nice job, Ookla (or rather, Accenture now, lol)

Kudos to Jianping Pan and Jinwei Zhao (University of Victoria).

Original post shared by Luke Kehoe annoucing it on LinkedIn:
https://www.linkedin.com/feed/update/urn:li:activity:7519293982208761856/

*TL; DR;* Now we can trace Starlink packets from the ground (thanks to work
done by Jianping Pan and Jinwei Zhao at University of Victoria - see their
research paper below) AND also from inside the cabin, using passengers’ own
Speedtest results, thanks to Ookla.

If you don't want to go there, here is a copy+paste:

On a Starlink-connected flight, the city and PoP where your traffic joins
the internet changes as the aircraft moves, and passengers’ own Speedtest
results now let us map that from inside the cabin across more than 20
airlines around the world, building on research by Jinwei Zhao and Jianping
Pan at the University of Victoria (who identified more than 900 Starlink
aircraft from the ground).

*Speedtest app results carry a traceroute, and on Starlink those that get a
reply cross Starlink’s routers at the point of presence (PoP) where traffic
meets the internet. We matched those routers to PoPs using Starlink’s own
address records (archived by the UVic team), keeping only passengers with a
fresh GPS fix at airliner speed (April to September 2026).*

Over the North Atlantic, passengers connected through Montreal or New York
until roughly halfway across, then London or Madrid (i.e., directionally
consistent with the mid-ocean handovers UVic observed).

Hawaii has Starlink ground stations but no PoP, so passengers within 1,500
km of Honolulu reached the internet in Los Angeles, nearly 4,000 km away,
at a median multi-server latency of 95 ms (against 43 ms within 750 km of
their PoP).

The most policy-relevant (and interesting) observation here concerns
in-country egress. Starlink places home users in Oman on its Muscat PoP and
in Indonesia on Jakarta, Surabaya or Batam, yet passengers over Oman and
Indonesia connected through Doha and Singapore respectively in our data
(small numbers, but UVic saw the same and hypothesise these PoPs exist for
local egress rules). As more governments mandate in-country egress, how
overflying aircraft are treated is an open question.

Separately, but relevant, passengers measured about twice the median
download speed of Starlink homes in the same areas and months in our data.

The University of Victoria research was able to follow one aircraft for a
whole flight by combining publicly reachable IPv6 addresses, MPLS routing
labels and flight tracking data (e.g., one Qatar Airways flight from Doha
to New York connected through seven cities in turn, at times over 2,000 km
away, as visualised in the film), and the team found aircraft unreachable
over India and Pakistan.

*The research also showed how Starlink's new "anycast users" feature allows
aircraft to retain the same public IP address as traffic moves between
geographically distant PoPs, avoiding the TCP connection disruptions
associated with previous handovers.*

Research paper linked in the comments.

The research by Jinwei Zhao and Jianping Pan (University of Victoria),
*“Measuring
Starlink Aviation Around the World”*, ACM IMC 2026, open access:

doi.org/10.1145/3777912.3839781

*Their method works from the ground.* They identified more than 900
Starlink aircraft by their router addresses, read Starlink’s own routing
labels from a Starlink terminal in Canada, and measured latency from 27
cloud servers over five months. *Our view complements theirs from inside
the cabin, using passengers’ own Speedtest results.*


All the best,

Frank

Frantisek (Frank) Borsik


*In loving memory of Dave Täht: *1965-2025

https://libreqos.io/2025/04/01/in-loving-memory-of-dave/


https://www.linkedin.com/in/frantisekborsik

Signal, Telegram, WhatsApp: +421919416714

iMessage, mobile: +420775230885

Skype: casioa5302ca

frantisek.borsik@gmail.com

[Starlink] Re: Ookla's Speedtest results now map the city & PoP where your traffic joins the IXPs as the aircraft moves

[Inemesit Affia]

SpaceX really needs to stop moving US hurricane electric traffic through Oman.

I'm sure AS8529 has BGP no-export communities.

And it's not just there.

Traffic from Seattle to AT&T 7018 goes through Mexico.

Oct 23, 2026 9:13:20 AM Frantisek Borsik via Starlink <starlink@lists.bufferbloat.net>:

> Nice job, Ookla (or rather, Accenture now, lol)
> 
> Kudos to Jianping Pan and Jinwei Zhao (University of Victoria).
> 
> Original post shared by Luke Kehoe annoucing it on LinkedIn:
> https://www.linkedin.com/feed/update/urn:li:activity:7519293982208761856/
> 
> *TL; DR;* Now we can trace Starlink packets from the ground (thanks to work
> done by Jianping Pan and Jinwei Zhao at University of Victoria - see their
> research paper below) AND also from inside the cabin, using passengers’ own
> Speedtest results, thanks to Ookla.
> 
> If you don't want to go there, here is a copy+paste:
> 
> On a Starlink-connected flight, the city and PoP where your traffic joins
> the internet changes as the aircraft moves, and passengers’ own Speedtest
> results now let us map that from inside the cabin across more than 20
> airlines around the world, building on research by Jinwei Zhao and Jianping
> Pan at the University of Victoria (who identified more than 900 Starlink
> aircraft from the ground).
> 
> *Speedtest app results carry a traceroute, and on Starlink those that get a
> reply cross Starlink’s routers at the point of presence (PoP) where traffic
> meets the internet. We matched those routers to PoPs using Starlink’s own
> address records (archived by the UVic team), keeping only passengers with a
> fresh GPS fix at airliner speed (April to September 2026).*
> 
> Over the North Atlantic, passengers connected through Montreal or New York
> until roughly halfway across, then London or Madrid (i.e., directionally
> consistent with the mid-ocean handovers UVic observed).
> 
> Hawaii has Starlink ground stations but no PoP, so passengers within 1,500
> km of Honolulu reached the internet in Los Angeles, nearly 4,000 km away,
> at a median multi-server latency of 95 ms (against 43 ms within 750 km of
> their PoP).
> 
> The most policy-relevant (and interesting) observation here concerns
> in-country egress. Starlink places home users in Oman on its Muscat PoP and
> in Indonesia on Jakarta, Surabaya or Batam, yet passengers over Oman and
> Indonesia connected through Doha and Singapore respectively in our data
> (small numbers, but UVic saw the same and hypothesise these PoPs exist for
> local egress rules). As more governments mandate in-country egress, how
> overflying aircraft are treated is an open question.
> 
> Separately, but relevant, passengers measured about twice the median
> download speed of Starlink homes in the same areas and months in our data.
> 
> The University of Victoria research was able to follow one aircraft for a
> whole flight by combining publicly reachable IPv6 addresses, MPLS routing
> labels and flight tracking data (e.g., one Qatar Airways flight from Doha
> to New York connected through seven cities in turn, at times over 2,000 km
> away, as visualised in the film), and the team found aircraft unreachable
> over India and Pakistan.
> 
> *The research also showed how Starlink's new "anycast users" feature allows
> aircraft to retain the same public IP address as traffic moves between
> geographically distant PoPs, avoiding the TCP connection disruptions
> associated with previous handovers.*
> 
> Research paper linked in the comments.
> 
> The research by Jinwei Zhao and Jianping Pan (University of Victoria),
> *“Measuring
> Starlink Aviation Around the World”*, ACM IMC 2026, open access:
> 
> doi.org/10.1145/3777912.3839781
> 
> *Their method works from the ground.* They identified more than 900
> Starlink aircraft by their router addresses, read Starlink’s own routing
> labels from a Starlink terminal in Canada, and measured latency from 27
> cloud servers over five months. *Our view complements theirs from inside
> the cabin, using passengers’ own Speedtest results.*
> 
> 
> All the best,
> 
> Frank
> 
> Frantisek (Frank) Borsik
> 
> 
> *In loving memory of Dave Täht: *1965-2025
> 
> https://libreqos.io/2025/04/01/in-loving-memory-of-dave/
> 
> 
> https://www.linkedin.com/in/frantisekborsik
> 
> Signal, Telegram, WhatsApp: +421919416714
> 
> iMessage, mobile: +420775230885
> 
> Skype: casioa5302ca
> 
> frantisek.borsik@gmail.com
> _______________________________________________
> Starlink mailing list -- starlink@lists.bufferbloat.net
> To unsubscribe send an email to starlink-leave@lists.bufferbloat.net

[Starlink] Re: Ookla's Speedtest results now map the city & PoP where your traffic joins the IXPs as the aircraft moves

[Jianping Pan]

Thanks Frank: this is a(nother) example of network users, engineers and researchers interaction and collaboration to make the internet a better place for everyone. it started as user complaints on starlink geoip/content mismatch, our initial investigation, ietf ipgeo workshop, starlink response, our follow-up work, inside-out measurement, wars in middle east, outside-in measurement, and an imc paper award ;-)

a lot of people on the mailing list helped along the way. yes, those 900+ aircraft are part of the dave daht memorial testbed too. thanks!

is https://www.reddit.com/r/StarlinkEngineering/comments/1wtu2d0/ookla_vs_cloudflare_speedtest_on_starlinkequipped/ fixed now?
--
J Pan, UVic CSc, ECS566, 250-472-5796 (NO VM), Pan@UVic.CA, Web.UVic.CA/~pan

________________________________________
From: Frantisek Borsik via Starlink <starlink@lists.bufferbloat.net>
Sent: Friday, October 23, 2026 1:23 AM
To: Dave Taht via Starlink
Subject: [Starlink] Ookla's Speedtest results now map the city & PoP where your traffic joins the IXPs as the aircraft moves

Nice job, Ookla (or rather, Accenture now, lol)

Kudos to Jianping Pan and Jinwei Zhao (University of Victoria).

Original post shared by Luke Kehoe annoucing it on LinkedIn:
https://www.linkedin.com/feed/update/urn:li:activity:7519293982208761856/

*TL; DR;* Now we can trace Starlink packets from the ground (thanks to work
done by Jianping Pan and Jinwei Zhao at University of Victoria - see their
research paper below) AND also from inside the cabin, using passengers’ own
Speedtest results, thanks to Ookla.

If you don't want to go there, here is a copy+paste:

On a Starlink-connected flight, the city and PoP where your traffic joins
the internet changes as the aircraft moves, and passengers’ own Speedtest
results now let us map that from inside the cabin across more than 20
airlines around the world, building on research by Jinwei Zhao and Jianping
Pan at the University of Victoria (who identified more than 900 Starlink
aircraft from the ground).

*Speedtest app results carry a traceroute, and on Starlink those that get a
reply cross Starlink’s routers at the point of presence (PoP) where traffic
meets the internet. We matched those routers to PoPs using Starlink’s own
address records (archived by the UVic team), keeping only passengers with a
fresh GPS fix at airliner speed (April to September 2026).*

Over the North Atlantic, passengers connected through Montreal or New York
until roughly halfway across, then London or Madrid (i.e., directionally
consistent with the mid-ocean handovers UVic observed).

Hawaii has Starlink ground stations but no PoP, so passengers within 1,500
km of Honolulu reached the internet in Los Angeles, nearly 4,000 km away,
at a median multi-server latency of 95 ms (against 43 ms within 750 km of
their PoP).

The most policy-relevant (and interesting) observation here concerns
in-country egress. Starlink places home users in Oman on its Muscat PoP and
in Indonesia on Jakarta, Surabaya or Batam, yet passengers over Oman and
Indonesia connected through Doha and Singapore respectively in our data
(small numbers, but UVic saw the same and hypothesise these PoPs exist for
local egress rules). As more governments mandate in-country egress, how
overflying aircraft are treated is an open question.

Separately, but relevant, passengers measured about twice the median
download speed of Starlink homes in the same areas and months in our data.

The University of Victoria research was able to follow one aircraft for a
whole flight by combining publicly reachable IPv6 addresses, MPLS routing
labels and flight tracking data (e.g., one Qatar Airways flight from Doha
to New York connected through seven cities in turn, at times over 2,000 km
away, as visualised in the film), and the team found aircraft unreachable
over India and Pakistan.

*The research also showed how Starlink's new "anycast users" feature allows
aircraft to retain the same public IP address as traffic moves between
geographically distant PoPs, avoiding the TCP connection disruptions
associated with previous handovers.*

Research paper linked in the comments.

The research by Jinwei Zhao and Jianping Pan (University of Victoria),
*“Measuring
Starlink Aviation Around the World”*, ACM IMC 2026, open access:

doi.org/10.1145/3777912.3839781

*Their method works from the ground.* They identified more than 900
Starlink aircraft by their router addresses, read Starlink’s own routing
labels from a Starlink terminal in Canada, and measured latency from 27
cloud servers over five months. *Our view complements theirs from inside
the cabin, using passengers’ own Speedtest results.*


All the best,

Frank

Frantisek (Frank) Borsik


*In loving memory of Dave Täht: *1965-2025

https://libreqos.io/2025/04/01/in-loving-memory-of-dave/


https://www.linkedin.com/in/frantisekborsik

Signal, Telegram, WhatsApp: +421919416714

iMessage, mobile: +420775230885

Skype: casioa5302ca

frantisek.borsik@gmail.com
_______________________________________________
Starlink mailing list -- starlink@lists.bufferbloat.net
To unsubscribe send an email to starlink-leave@lists.bufferbloat.net

[Starlink] Re: Ookla's Speedtest results now map the city & PoP where your traffic joins the IXPs as the aircraft moves

[Frantisek Borsik]

Thanks, Jianping! Dave is definitely happy up in the air, seeing all this
improvements happening over time, courtesy of hard work and ideas of many,
coming together.

There was another great question asked in the discussion on the original
post on LinkedIn, so copy+pasting it with the Luke's answer.

Does it use IP addresses dedicated to aircraft or does it use landing
> country allocated ranges as per their public IP Geofeed ? Last year I was
> discussing anomalies with Geoff Huston on the way they allocate country IPs
> to maritime communications clients. [Ben Roberts
> <https://www.linkedin.com/feed/update/urn:li:ugcPost:7519146674263498752/?dashCommentUrn=urn%3Ali%3Afsd_comment%3A%287519370925272883200%2Curn%3Ali%3AugcPost%3A7519146674263498752%29>
> ]


Luke's answer:

(...) My understanding is that both exist (depending on the airline). Most
Starlink airlines in our data (e.g., Qatar Airways, United, Emirates,
WestJet and others) use address blocks dedicated to aviation. Each block
has one fixed city in Starlink’s geofeed, usually but not always the
airline’s home (Doha, Chicago, Dubai, Calgary).

The aircraft’s traffic still reaches the internet wherever it is (for
example, one Qatar Airways block exited through at least 18 different PoPs,
each confirmed independently by the internet exchange the traffic entered
next).

An example like Air France works the other way though. Its addresses are
listed against individual PoPs (London, Frankfurt, Madrid, Milan) and
change as the aircraft moves, while the geofeed shows Paris for all of them.

This means the geofeed can say little about where an aircraft’s traffic
actually goes, and so we don’t use it or IP-based location for that. Each
result’s PoP here comes from Starlink’s own routers in the passenger’s
traceroute, and its position from the phone’s GPS.

The UVic team saw the same split but from the outside (i.e., some aircraft
keep one address across PoPs, others change it).



All the best,

Frank

Frantisek (Frank) Borsik


*In loving memory of Dave Täht: *1965-2025

https://libreqos.io/2025/04/01/in-loving-memory-of-dave/


https://www.linkedin.com/in/frantisekborsik

Signal, Telegram, WhatsApp: +421919416714 <+421%20919%20416%20714>

iMessage, mobile: +420775230885 <775%20230%20885>

Skype: casioa5302ca

frantisek.borsik@gmail.com


On Fri, Oct 23, 2026 at 7:12 PM Jianping Pan <pan@uvic.ca> wrote:

> Thanks Frank: this is a(nother) example of network users, engineers and
> researchers interaction and collaboration to make the internet a better
> place for everyone. it started as user complaints on starlink geoip/content
> mismatch, our initial investigation, ietf ipgeo workshop, starlink
> response, our follow-up work, inside-out measurement, wars in middle east,
> outside-in measurement, and an imc paper award ;-)
>
> a lot of people on the mailing list helped along the way. yes, those 900+
> aircraft are part of the dave daht memorial testbed too. thanks!
>
> is
> https://www.reddit.com/r/StarlinkEngineering/comments/1wtu2d0/ookla_vs_cloudflare_speedtest_on_starlinkequipped/
> fixed now?
> --
> J Pan, UVic CSc, ECS566, 250-472-5796 (NO VM), Pan@UVic.CA,
> Web.UVic.CA/~pan
>
> ________________________________________
> From: Frantisek Borsik via Starlink <starlink@lists.bufferbloat.net>
> Sent: Friday, October 23, 2026 1:23 AM
> To: Dave Taht via Starlink
> Subject: [Starlink] Ookla's Speedtest results now map the city & PoP where
> your traffic joins the IXPs as the aircraft moves
>
> Nice job, Ookla (or rather, Accenture now, lol)
>
> Kudos to Jianping Pan and Jinwei Zhao (University of Victoria).
>
> Original post shared by Luke Kehoe annoucing it on LinkedIn:
> https://www.linkedin.com/feed/update/urn:li:activity:7519293982208761856/
>
> *TL; DR;* Now we can trace Starlink packets from the ground (thanks to work
> done by Jianping Pan and Jinwei Zhao at University of Victoria - see their
> research paper below) AND also from inside the cabin, using passengers’ own
> Speedtest results, thanks to Ookla.
>
> If you don't want to go there, here is a copy+paste:
>
> On a Starlink-connected flight, the city and PoP where your traffic joins
> the internet changes as the aircraft moves, and passengers’ own Speedtest
> results now let us map that from inside the cabin across more than 20
> airlines around the world, building on research by Jinwei Zhao and Jianping
> Pan at the University of Victoria (who identified more than 900 Starlink
> aircraft from the ground).
>
> *Speedtest app results carry a traceroute, and on Starlink those that get a
> reply cross Starlink’s routers at the point of presence (PoP) where traffic
> meets the internet. We matched those routers to PoPs using Starlink’s own
> address records (archived by the UVic team), keeping only passengers with a
> fresh GPS fix at airliner speed (April to September 2026).*
>
> Over the North Atlantic, passengers connected through Montreal or New York
> until roughly halfway across, then London or Madrid (i.e., directionally
> consistent with the mid-ocean handovers UVic observed).
>
> Hawaii has Starlink ground stations but no PoP, so passengers within 1,500
> km of Honolulu reached the internet in Los Angeles, nearly 4,000 km away,
> at a median multi-server latency of 95 ms (against 43 ms within 750 km of
> their PoP).
>
> The most policy-relevant (and interesting) observation here concerns
> in-country egress. Starlink places home users in Oman on its Muscat PoP and
> in Indonesia on Jakarta, Surabaya or Batam, yet passengers over Oman and
> Indonesia connected through Doha and Singapore respectively in our data
> (small numbers, but UVic saw the same and hypothesise these PoPs exist for
> local egress rules). As more governments mandate in-country egress, how
> overflying aircraft are treated is an open question.
>
> Separately, but relevant, passengers measured about twice the median
> download speed of Starlink homes in the same areas and months in our data.
>
> The University of Victoria research was able to follow one aircraft for a
> whole flight by combining publicly reachable IPv6 addresses, MPLS routing
> labels and flight tracking data (e.g., one Qatar Airways flight from Doha
> to New York connected through seven cities in turn, at times over 2,000 km
> away, as visualised in the film), and the team found aircraft unreachable
> over India and Pakistan.
>
> *The research also showed how Starlink's new "anycast users" feature allows
> aircraft to retain the same public IP address as traffic moves between
> geographically distant PoPs, avoiding the TCP connection disruptions
> associated with previous handovers.*
>
> Research paper linked in the comments.
>
> The research by Jinwei Zhao and Jianping Pan (University of Victoria),
> *“Measuring
> Starlink Aviation Around the World”*, ACM IMC 2026, open access:
>
> doi.org/10.1145/3777912.3839781
>
> *Their method works from the ground.* They identified more than 900
> Starlink aircraft by their router addresses, read Starlink’s own routing
> labels from a Starlink terminal in Canada, and measured latency from 27
> cloud servers over five months. *Our view complements theirs from inside
> the cabin, using passengers’ own Speedtest results.*
>
>
> All the best,
>
> Frank
>
> Frantisek (Frank) Borsik
>
>
> *In loving memory of Dave Täht: *1965-2025
>
> https://libreqos.io/2025/04/01/in-loving-memory-of-dave/
>
>
> https://www.linkedin.com/in/frantisekborsik
>
> Signal, Telegram, WhatsApp: +421919416714 <+421%20919%20416%20714>
>
> iMessage, mobile: +420775230885 <775%20230%20885>
>
> Skype: casioa5302ca
>
> frantisek.borsik@gmail.com
> _______________________________________________
> Starlink mailing list -- starlink@lists.bufferbloat.net
> To unsubscribe send an email to starlink-leave@lists.bufferbloat.net
>

[Starlink] Re: Ookla's Speedtest results now map the city & PoP where your traffic joins the IXPs as the aircraft moves

[Jianping Pan]

luke is correct as we stated in our paper. "anycast user" seems to be a premier feature for starlink aviation (initially aircraft was anchored at departure pop---obviously bad in latency when aircraft landing at arrival airport, especially for long-haul flights; next aircraft handover pops along the way, latency reduced but tcp resets with new ip addresses; finally the anycast feature, which is likely more expensive, so some airlines use it, some not, and some just testing it, e.g., air france only has one aircraft with anycast, all others still change pop ip ;-)
--
J Pan, UVic CSc, ECS566, 250-472-5796 (NO VM), Pan@UVic.CA, Web.UVic.CA/~pan

________________________________________
From: Frantisek Borsik <frantisek.borsik@gmail.com>
Sent: Friday, October 23, 2026 10:55 AM
To: Jianping Pan; Dave Taht via Starlink
Subject: Re: [Starlink] Ookla's Speedtest results now map the city & PoP where your traffic joins the IXPs as the aircraft moves

Thanks, Jianping! Dave is definitely happy up in the air, seeing all this improvements happening over time, courtesy of hard work and ideas of many, coming together.

There was another great question asked in the discussion on the original post on LinkedIn, so copy+pasting it with the Luke's answer.

Does it use IP addresses dedicated to aircraft or does it use landing country allocated ranges as per their public IP Geofeed ? Last year I was discussing anomalies with Geoff Huston on the way they allocate country IPs to maritime communications clients. [Ben Roberts<https://www.linkedin.com/feed/update/urn:li:ugcPost:7519146674263498752/?dashCommentUrn=urn%3Ali%3Afsd_comment%3A%287519370925272883200%2Curn%3Ali%3AugcPost%3A7519146674263498752%29>]

Luke's answer:

(...) My understanding is that both exist (depending on the airline). Most Starlink airlines in our data (e.g., Qatar Airways, United, Emirates, WestJet and others) use address blocks dedicated to aviation. Each block has one fixed city in Starlink’s geofeed, usually but not always the airline’s home (Doha, Chicago, Dubai, Calgary).

The aircraft’s traffic still reaches the internet wherever it is (for example, one Qatar Airways block exited through at least 18 different PoPs, each confirmed independently by the internet exchange the traffic entered next).

An example like Air France works the other way though. Its addresses are listed against individual PoPs (London, Frankfurt, Madrid, Milan) and change as the aircraft moves, while the geofeed shows Paris for all of them.

This means the geofeed can say little about where an aircraft’s traffic actually goes, and so we don’t use it or IP-based location for that. Each result’s PoP here comes from Starlink’s own routers in the passenger’s traceroute, and its position from the phone’s GPS.

The UVic team saw the same split but from the outside (i.e., some aircraft keep one address across PoPs, others change it).



All the best,

Frank
Frantisek (Frank) Borsik

In loving memory of Dave Täht: 1965-2025
https://libreqos.io/2025/04/01/in-loving-memory-of-dave/<https://libreqos.io/2025/04/01/in-loving-memory-of-dave/>

https://www.linkedin.com/in/frantisekborsik<https://www.linkedin.com/in/frantisekborsik>
Signal, Telegram, WhatsApp: +421919416714<tel:+421%20919%20416%20714>
iMessage, mobile: +420775230885<tel:775%20230%20885>
Skype: casioa5302ca
frantisek.borsik@gmail.com<mailto:frantisek.borsik@gmail.com>


On Fri, Oct 23, 2026 at 7:12 PM Jianping Pan <pan@uvic.ca<mailto:pan@uvic.ca>> wrote:
Thanks Frank: this is a(nother) example of network users, engineers and researchers interaction and collaboration to make the internet a better place for everyone. it started as user complaints on starlink geoip/content mismatch, our initial investigation, ietf ipgeo workshop, starlink response, our follow-up work, inside-out measurement, wars in middle east, outside-in measurement, and an imc paper award ;-)

a lot of people on the mailing list helped along the way. yes, those 900+ aircraft are part of the dave daht memorial testbed too. thanks!

is https://www.reddit.com/r/StarlinkEngineering/comments/1wtu2d0/ookla_vs_cloudflare_speedtest_on_starlinkequipped/<https://www.reddit.com/r/StarlinkEngineering/comments/1wtu2d0/ookla_vs_cloudflare_speedtest_on_starlinkequipped/> fixed now?
--
J Pan, UVic CSc, ECS566, 250-472-5796 (NO VM), Pan@UVic.CA, Web.UVic.CA/~pan<http://web.uvic.ca/~pan>

________________________________________
From: Frantisek Borsik via Starlink <starlink@lists.bufferbloat.net<mailto:starlink@lists.bufferbloat.net>>
Sent: Friday, October 23, 2026 1:23 AM
To: Dave Taht via Starlink
Subject: [Starlink] Ookla's Speedtest results now map the city & PoP where your traffic joins the IXPs as the aircraft moves

Nice job, Ookla (or rather, Accenture now, lol)

Kudos to Jianping Pan and Jinwei Zhao (University of Victoria).

Original post shared by Luke Kehoe annoucing it on LinkedIn:
https://www.linkedin.com/feed/update/urn:li:activity:7519293982208761856/<https://www.linkedin.com/feed/update/urn:li:activity:7519293982208761856/>

*TL; DR;* Now we can trace Starlink packets from the ground (thanks to work
done by Jianping Pan and Jinwei Zhao at University of Victoria - see their
research paper below) AND also from inside the cabin, using passengers’ own
Speedtest results, thanks to Ookla.

If you don't want to go there, here is a copy+paste:

On a Starlink-connected flight, the city and PoP where your traffic joins
the internet changes as the aircraft moves, and passengers’ own Speedtest
results now let us map that from inside the cabin across more than 20
airlines around the world, building on research by Jinwei Zhao and Jianping
Pan at the University of Victoria (who identified more than 900 Starlink
aircraft from the ground).

*Speedtest app results carry a traceroute, and on Starlink those that get a
reply cross Starlink’s routers at the point of presence (PoP) where traffic
meets the internet. We matched those routers to PoPs using Starlink’s own
address records (archived by the UVic team), keeping only passengers with a
fresh GPS fix at airliner speed (April to September 2026).*

Over the North Atlantic, passengers connected through Montreal or New York
until roughly halfway across, then London or Madrid (i.e., directionally
consistent with the mid-ocean handovers UVic observed).

Hawaii has Starlink ground stations but no PoP, so passengers within 1,500
km of Honolulu reached the internet in Los Angeles, nearly 4,000 km away,
at a median multi-server latency of 95 ms (against 43 ms within 750 km of
their PoP).

The most policy-relevant (and interesting) observation here concerns
in-country egress. Starlink places home users in Oman on its Muscat PoP and
in Indonesia on Jakarta, Surabaya or Batam, yet passengers over Oman and
Indonesia connected through Doha and Singapore respectively in our data
(small numbers, but UVic saw the same and hypothesise these PoPs exist for
local egress rules). As more governments mandate in-country egress, how
overflying aircraft are treated is an open question.

Separately, but relevant, passengers measured about twice the median
download speed of Starlink homes in the same areas and months in our data.

The University of Victoria research was able to follow one aircraft for a
whole flight by combining publicly reachable IPv6 addresses, MPLS routing
labels and flight tracking data (e.g., one Qatar Airways flight from Doha
to New York connected through seven cities in turn, at times over 2,000 km
away, as visualised in the film), and the team found aircraft unreachable
over India and Pakistan.

*The research also showed how Starlink's new "anycast users" feature allows
aircraft to retain the same public IP address as traffic moves between
geographically distant PoPs, avoiding the TCP connection disruptions
associated with previous handovers.*

Research paper linked in the comments.

The research by Jinwei Zhao and Jianping Pan (University of Victoria),
*“Measuring
Starlink Aviation Around the World”*, ACM IMC 2026, open access:

doi.org/10.1145/3777912.3839781<http://doi.org/10.1145/3777912.3839781>

*Their method works from the ground.* They identified more than 900
Starlink aircraft by their router addresses, read Starlink’s own routing
labels from a Starlink terminal in Canada, and measured latency from 27
cloud servers over five months. *Our view complements theirs from inside
the cabin, using passengers’ own Speedtest results.*


All the best,

Frank

Frantisek (Frank) Borsik


*In loving memory of Dave Täht: *1965-2025

https://libreqos.io/2025/04/01/in-loving-memory-of-dave/<https://libreqos.io/2025/04/01/in-loving-memory-of-dave/>


https://www.linkedin.com/in/frantisekborsik<https://www.linkedin.com/in/frantisekborsik>

Signal, Telegram, WhatsApp: +421919416714<tel:+421%20919%20416%20714>

iMessage, mobile: +420775230885<tel:775%20230%20885>

Skype: casioa5302ca

frantisek.borsik@gmail.com<mailto:frantisek.borsik@gmail.com>
_______________________________________________
Starlink mailing list -- starlink@lists.bufferbloat.net<mailto:starlink@lists.bufferbloat.net>
To unsubscribe send an email to starlink-leave@lists.bufferbloat.net<mailto:starlink-leave@lists.bufferbloat.net>