Starlink has bufferbloat. Bad.
 help / color / mirror / Atom feed
From: Spencer Sevilla <spencer.builds.networks@gmail.com>
To: David Lang <david@lang.hm>,
	Dave Taht via Starlink <starlink@lists.bufferbloat.net>
Cc: "Livingood, Jason" <Jason_Livingood@comcast.com>,
	Frantisek Borsik <frantisek.borsik@gmail.com>
Subject: [Starlink] Re: Lost in Space: The Limits of Geolocation in a Satellite-Connected World (new article from Geoff Huston)
Date: Wed, 1 Oct 2025 14:51:32 -0700	[thread overview]
Message-ID: <853161C6-6C99-47BF-B0BB-AA8D9BAD512F@gmail.com> (raw)
In-Reply-To: <o81q4sns-99p4-4qnr-7p76-41q235954449@ynat.uz>

Yeah I agree with David here. I am medium confident this approach (query for GPS) is part of the E911 system rollout as well, which strikes me as a far better approach than “for each number, enter a corresponding address in some database.”

I could certainly see some use for IP-based geolocation going forward, less as a concrete primary source and more as a cross-check on other location-based tools for e.g. security purposes.

Spencer

> On Oct 1, 2025, at 14:22, David Lang via Starlink <starlink@lists.bufferbloat.net> wrote:
> 
> Livingood, Jason wrote:
> 
>> Related reminder that the IAB is holding a workshop on IP Geolocation – with statements of interested due at the end of this week. For more info:
>> https://www.iab.org/announcements/call-for-papers-iab-workshop-on-ip-address-geolocation-ip-geo/
>> 
>> Call for Papers: IAB Workshop on IP Address Geolocation (ip-geo)
>> 17 Jul 2025, 6:42 p.m.
>> This workshop aims to understand the current use cases for publishing, discovering, and consuming IP address geolocation data.
>> Workshop Description
>> This workshop aims to understand the current use cases for publishing, discovering, and consuming IP address geolocation data ('IP-geo' hereafter). It will also explore areas for improvement, both in ways to update or replace IP geolocation mechanisms, and to consider mechanisms that satisfy the use cases without relying on IP addresses.
>> The IAB seeks short position papers on the topics listed below. This list is non-exhaustive and should be interpreted broadly.
>> 
>> *   Today's Use Cases: How is IP-geo data used today? In particular, what are the root challenges, technical needs, or business needs that IP-geo data is being leveraged to address?
>> *   Gaps and Problems: What are gaps or problems with the current approaches being used by industry? Are there preferences for particular file types? How effective are current approaches? What are the impacts on user privacy?
>> *   Future Opportunities: If we re-designed technical solutions to address the motivating use cases, what would those solutions look like? Are there alternative approaches that can avoid the gaps and problems we have today? Is there value in conveying other information in addition to or instead of geography, such as type of last mile network connection?
> 
> If I were attending and had the power to do so, I would add a discussion on how much geolocation is needed and what other approaches are
> 
> for example:
> 
> If you are using a mobile device (with an app or browser), you have access to the location from the device (either GPS or lower accuracy)
> 
> If you are using Starlink, it has a GPS in it, make it's location available on it's local network and have a way for computers/devices/browsers to query the local network for a location.
> 
> At that point, just about all that remains is traditional fixed location services (wired or wireless), and they can leverage a similar approach to what I outline for starlink, a service on their local router that provides location information for things on the network.
> 
> Now, if you are not just trying to provide geo-based services, but instead analyze IP data in logs to get geo info, this won't help, but (recognizing the security limitations of asking the user to provide their location), I think it would be both more useful for consumers, and better overall to explicitly pass location information rather than try to reverse engineer it from the IP addresses.
> 
> David Lang
> _______________________________________________
> 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>

  reply	other threads:[~2025-10-01 21:51 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-10-01  5:34 [Starlink] " Frantisek Borsik
2025-10-01  5:56 ` [Starlink] " J Pan
2025-10-01 16:46   ` Michael Richardson
2025-10-01 17:40     ` J Pan
2025-10-01 21:08       ` Michael Richardson
2025-10-01 22:50         ` J Pan
2025-10-01 13:18 ` Livingood, Jason
2025-10-01 21:22   ` David Lang
2025-10-01 21:51     ` Spencer Sevilla [this message]
2025-10-01 22:48       ` J Pan
2025-10-01 23:05       ` David Lang
2025-10-02  4:34         ` J Pan
     [not found] ` <22339.1759337017@obiwan.sandelman.ca>
2025-10-01 16:47   ` Michael Richardson
2025-10-01 21:13 ` David Lang

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://lists.bufferbloat.net/postorius/lists/starlink.lists.bufferbloat.net/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=853161C6-6C99-47BF-B0BB-AA8D9BAD512F@gmail.com \
    --to=spencer.builds.networks@gmail.com \
    --cc=Jason_Livingood@comcast.com \
    --cc=david@lang.hm \
    --cc=frantisek.borsik@gmail.com \
    --cc=starlink@lists.bufferbloat.net \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox