Starlink has bufferbloat. Bad.
 help / color / mirror / Atom feed
From: David Lang <david@lang.hm>
To: "Livingood, Jason" <Jason_Livingood@comcast.com>
Cc: Frantisek Borsik <frantisek.borsik@gmail.com>,
	Dave Taht via Starlink <starlink@lists.bufferbloat.net>
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:22:26 -0700 (PDT)	[thread overview]
Message-ID: <o81q4sns-99p4-4qnr-7p76-41q235954449@ynat.uz> (raw)
In-Reply-To: <MW4PR11MB71045524AA90D9ACF5DF9982C7E6A@MW4PR11MB7104.namprd11.prod.outlook.com>

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

  reply	other threads:[~2025-10-01 21:22 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 [this message]
2025-10-01 21:51     ` Spencer Sevilla
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=o81q4sns-99p4-4qnr-7p76-41q235954449@ynat.uz \
    --to=david@lang.hm \
    --cc=Jason_Livingood@comcast.com \
    --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