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

[Spencer Sevilla <spencer.builds.networks@gmail.com>]

Yes, you’re correct - thanks for articulating the clarification.

> On Sep 25, 2025, at 11:53, David Lang <david@lang.hm> wrote:
> 
> Spencer Sevilla wrote:
> 
>> Also worth mentioning, I’m not 100% sure if it’s QUIC or not (its been a long time since I did this study) but pretty much all the OTT messenging/calling apps out there already handle IP address mobility just fine, and those are probably the longest-lived connections seen in most consumer contexts.
> 
> what are you meaning by IP mobility?
> 
> 1. a connection can shift from one IP to another
> 
> 2. an endpoint IP can move from one network to another
> 
> mobileIP was #2, I think you are talking about #1
> 
> David Lang
> 
>>> On Sep 25, 2025, at 11:31, Marc Blanchet via Starlink <starlink@lists.bufferbloat.net <mailto:starlink@lists.bufferbloat.net>> wrote:
>>> 
>>> 
>>> 
>>>> Le 25 sept. 2025 à 13:45, Michael Richardson via Starlink <starlink@lists.bufferbloat.net <mailto:starlink@lists.bufferbloat.net> <mailto:starlink@lists.bufferbloat.net>> a écrit :
>>>> 
>>>> {resending without signature, since new list can't cope with attachments yet}
>>>> 
>>>> Luis A. Cornejo via Starlink <starlink@lists.bufferbloat.net <mailto:starlink@lists.bufferbloat.net> <mailto:starlink@lists.bufferbloat.net>> wrote:
>>>> 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)
>>> 
>>> MobileIP required cooperative routers "everywhere". And did not really address the fact that a transport connection is based on the four-tuple. Transport mobility (aka QUIC 0RTT connection migration) is the right level where mobility should happen. And this is way more easy when the identifier of the connection is not the four-tuple but just a random id within the connection.
>>> 
>>>> 
>>>> 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.
>>> 
>>> But scone is a 1.5 RTT mechanism and it requires updated L3 forwarders in the path.
>>> 
>>> Remains to be seen if this will have enough traction for LEO constellations.
>>> 
>>> Marc.
>>> 
>>>> 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
>>> 
>>> _______________________________________________
>>> Starlink mailing list -- starlink@lists.bufferbloat.net <mailto: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> <mailto:starlink-leave@lists.bufferbloat.net>
>> _______________________________________________
>> 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>