[Starlink] Re: Starlink looking less niche as its retail presence expands

[J Pan <Pan@uvic.ca>]

Thanks Michael for attending my talk. my slides are at
http://tinyurl.com/leosatnet and we are looking for hosts around the
world to help us http://tinyurl.com/starlinkuser . cheers.  -j
--
J Pan, UVic CSc, ECS566, 250-472-5796 (NO VM), Pan@UVic.CA, Web.UVic.CA/~pan

On Thu, Sep 25, 2025 at 10:45 AM Michael Richardson via Starlink
<starlink@lists.bufferbloat.net> wrote:
>
> {resending without signature, since new list can't cope with attachments yet}
>
> Luis A. Cornejo via Starlink <starlink@lists.bufferbloat.net> wrote:
>     > Since Starlink controls all the wireless parts of their system. Does
>     > anybody here know what they could do to mitigate the limits of
>     > classical wireless comms, like Shannon-Hartley Capacity Theorem or the
>     > interference?
>
> I don't know much about this part.
> I am kinda hijacking this thread, but I think there is a connection.
> Dr.Pan gave a talk about Starlink measurements last week in Ottawa.
> (The time slot was way too short.  Very nice talk)
>
> I was thinking about the many places where bandwidth can go up and down, both
> for Starlink's various mis-attachment situations, but also for OneWeb's Polar
> orbit mechanism.  (I didn't know it was doing that).
> And just getting redirected to a different downlink/base-station, and then
> have to cross over Starlink's internal network to the same exit point.
> (Too bad MobileIP never took off)
>
> I think the only thing worse than bufferbloat is varying bandwidth rates.
> That's because the only way to use that bandwidth is to introduce bufferbloat :-)
> It was the cablemodem burst mechanism that clued Jim into bufferbloat.
>
> So my related question is, if they could mitigate, they likely can't do it
> continuously, so things will up/down.  The IETF now has a SCONE WG, with the
> aim of inserting signals into QUIC traffic about bandwidth available.
> Yes, meddling by middle boxes.  Ick.
>
> Could Starlink even do this given the lack of L3 processing along the
> entire link?  At least according to Dr. Pan's diagrams.
> (An L2 hop could well mess with packets too).
> Ideally, one or more of the satellites involved in the ISL would
> know what the current bandwidth to a given terminal is, and could inform the
> end system.
>
> The two questions:
> 1. are the limits/conditions stable enough for long enough that the available
>    bandwidth could be communicated back to the uplink?
>
> 2. assuming, yes, what would the best place to do the SCONE marking?
>
>     >> Let's recap: Spectrum's boxed in, and power is boxed in. That imposes
>     >> a hard limit on total capacity (look up the Shannon-Hartley Capacity
>     >> Theorem if you don't believe me). This capacity is all that Starlink
>     >> has to share among its users in a cell. No matter how many satellites
>     >> they launch or how big the rocket. Add more users in a cell, and the
>     >> capacity per user there has to go down. Law of nature.
>
> And users will need to know what they have on a minute-by-minute basis so
> that they avoid screwing themselves, let alone their neighbours.
> Packets going up the link, then being dropped, is just wasted.
>
> ps:
> I have been watching: https://www.youtube.com/playlist?list=PL-_93BVApb58SXL-BCv4rVHL-8GuC2WGb
> where they have powered up 50+ year old Apollo Transponders.
>
> --
> ]               Never tell me the odds!                 | ipv6 mesh networks [
> ]   Michael Richardson, Sandelman Software Works        |    IoT architect   [
> ]     mcr@sandelman.ca  http://www.sandelman.ca/        |   ruby on rails    [
> _______________________________________________
> Starlink mailing list -- starlink@lists.bufferbloat.net
> To unsubscribe send an email to starlink-leave@lists.bufferbloat.net