[Starlink] SCONE, bandwidth indeterminacy and network to host signals (was Re: Re: Starlink Digest, Vol 53, Issue 14)

[Michael Richardson <mcr@sandelman.ca>]

The point of SCONE is allow end ("terminals") to better select (video)
bandwidths that are going to be more sustainable.  It's definitely driven by
3GPP (LTE) operators so far.   I give it a 40% chance of getting usefully
deployed before the need is overtaken by other events.
The promise is that 3GPP operators won't have to do expensive DPI anymore.

It's true the the 3GPP people have a long-standing habit of doing often
useless DPI, including ack pacing, ack-proxying, https://en.wikipedia.org/wiki/TCP_pacing

While I'm definitely in the smart-end-point, dumb-network camp,
I also see that the lack of useful end-host<->network relationship/API has
resulted in our inability to offer new kinds of services.
(Ironically: "5G" operators need this more than anyone else.  The ill-fated
IETF APN BOF/WG was after that.  Kinda. But not everyone knew that)

I've often wanted a "less than best effort" service (as much as that's a
terrible term), which would allow me to purchase unused bandwidth at low-peak
times in order to do bulk data movement.  I'd often be happy to do this in a
store-and-forward fashion.    (Yes, I used to live on UUCP!)

That's what we should be creating for space use; my understanding is that
Bundle Protocol tries to be that, but that many think it is un-deploybale.
(I haven't an opinion myself)

I see no reason why any streaming service has to be live in the same way that
a video conference needs to be.  Even people watching a "live" football game
would probably be happy with a feed that was 3-5 minutes behind, if it meant
they never stalled.

--
]               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    [