Re: [Starlink] Starlink and bufferbloat status?

[David Lang <david@lang.hm>]

[-- Attachment #1: Type: text/plain, Size: 3573 bytes --]

On Sun, 18 Jul 2021, Dave Taht wrote:

>>> 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.

if you are going to route based on IPv6 prefixes, then the prefixes need to have 
a close relationship to location (which is what routing needs to care about). If 
you have fixed addresses and mobile stations, you can't route based on address 
prefixes.

>> 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)

remember, every terminal is potentially an exit node, and they are already 
licensed for 1m nodes in the US alone, so I would not bet on never exceeding 
2^32 nodes

> 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.
>

IMHO, the sending station should not know or care what exit nodes exist, so how 
would they go about picking one? Or if it should care, how would it pick which 
one is best? Best is a combination of 'shortest path to destination' and 'avoid 
overly busy nodes'. How would you get that topology info to every station?

One of the wonderful things about the Internet is that no device needs to 
understand the entire network. They just need information about which next hop 
to use to get to different destiantions. When the route changes, you don't have 
to update every device on the network, just routers up to the point where you 
can aggregate routes (and again, you hit the static addressing vs dynamic 
stations problem)

David Lang