[Starlink] Starlink and bufferbloat status?

[Dave Taht]

On Sun, Jul 18, 2021 at 12:17 PM David Lang <david at lang.hm> wrote:
>
> On Fri, 16 Jul 2021, Michael Richardson wrote:
>
> > David Lang <david at lang.hm> wrote:
> >    > As there are more staellites, the up down time will get closer to 4-5ms
> >    > rather then the ~7ms you list, and with laser relays in orbit, and terminal
> >    > to terminal routing in orbit, there is the potential for the theoretical
> >    > minimum to tend lower, giving some headroom for other overhead but still
> >    > being in the 20ms range.

I also used the 20ms figure in my podcast.
https://twit.tv/shows/floss-weekly/episodes/638?autostart=false

I like to think with FQ in the loop, they can do even better for
"ping" and gaming, but for a change I'd like to see elon actually
underpromise and overdeliver.

> >
> > I really want this to happen, but how will this get managed?
> > We will don't know shit, and I'm not convinced SpaceX knows either.
> >
> > I'm scared that these paths will centrally managed, and not based upon
> > longest prefix (IPv6) match.
>
> unless you are going to have stations changing their IPv6 address frequently,

I'd really, really, hope for a dedicated /56 per station, no changes,
EVER, unless the user requests it it falls under attack. Perhaps two
/56s for failover reasons. Really silly
to make ipv6 dynamic in this environment.

Sure wish some ipv4/12 was available. Dynamic ipv4 doesn't make much
sense anymore either.

> don't see how you would route based on their address. The system is extremely
> dynamic, and propgating routing tables would be a huge overhead. Remember,
> stations are not in fixed locations, they move (and if on an airliner or rocket,
> they move pretty quickly)

IMHO:

IF you were to go about designing a sane and fast planetary “mac”
layer that could carry ipv4 and ipv6 (and hopefully ICN), traffic, on
stuff in orbit...

( some relevant recent complaints over on this thread:
https://www.linkedin.com/feed/update/urn:li:activity:6817609260348911616/
)

… and you were for !@#! sure that you would never have more than 2^32
exit nodes, a bunch of things  get simpler. All you need to do on the
ground is pick the exit node, with a couple other fields and the
payload. How something gets there is the network’s problem. All the l3
stuff “up there” just vanishes. You end up with a very, very simple
and fast global routing table "up there" that is gps clock based, and
only needs to be updated in case of a sat failure or to route around
congestion (roughly the same thing)

You do the complicated ipv4 or ipv6 route matching on the ground
before translating it to L2 ... just to pick the *exit node*. Choosing
nexthops on the ground happen on a schedule, and “nexthop” behavior on
the sats in orbit or the solar system is also extremely predictable.
If you yourself are moving, that too is extremely predictable. Other
truly needed fields carried from l3 to the l2 layer should be kind of
obvious if you look at the flaws in the ethernet and mpls “mac”,
relative to what ipv6 tried to (over)do, what we've learned from
history, and think about what a globally sync’d clock can do for you,
as well as a hashed flowid.

I worked a bunch of this out in the period 1989-92 when I was working
on a hard SF book “centered” on the asteroid Toutatis[1] and IPng was
starting to bake (and I was still involved in ISO, I didn't really
become an ipv4 convert until I got fed up with ISO in 1991 or so). If
you spend enough time flying around the solar system from inside an
epicycle (try it! Download celestia or try https://www.asterank.com/
and take a few rides on a rock and note the timescales at which any
immediate routing change might need to be made) some things become
obvious...

Doesn't mean that I was right, but starlink's layer two design hasn't
been published so I figure I should publish what I think I already
knew before they tell me....

[1] Some info on "the toutatis way":
https://web.archive.org/web/20040415014525/http://www.taht.net/~mtaht/asteroid/toutatis.html

Sadly I never finished writing the book. I’d had too much fun
designing the network and plumbing, and not on the characters or
conflict, and Vernor Vinge’s *awesome* “Fire upon the deep” came out
in 93, centered on one of “my” core ideas (leveraging netnews), and
had a better plot. And characters. And other crap happened to me. Ah,
well. I am thinking if ever I get the time I will try to pull at least
a short story out of it, someday.

I keep meaning to update that spreadsheet of fast rotators. Been a long time.

>
> I expect that initially it's going to be centrally managed, but over time I
> would expect that it would become more decentralized.

I am looking forward to getting a few more nodes that are closer together to
monitor with the cosmic background bufferbloat detector. Certainly precise
sync is probably a bad idea...


>
> David Lang
> _______________________________________________
> Starlink mailing list
> Starlink at lists.bufferbloat.net
> https://lists.bufferbloat.net/listinfo/starlink



-- 
Latest Podcast:
https://www.linkedin.com/feed/update/urn:li:activity:6791014284936785920/

Dave Täht CTO, TekLibre, LLC