[Cerowrt-devel] starlink as a mesh network

[David P. Reed]

Fun, but it is all just a dynamic geometry game. 

It's worth remembering that Congestion Control will be a huge problem here. It's far from obvious that current TCP congestion control (which assumes all packets in a virtual circuit traverse the same path in a very deep way indeed) will do the job. Thus there is a serious risk of congestion collapse if windows larger than one packet are allowed to operate.

So the Dijkstra algorithm reachability is not at all predictive of how this network will respond once it has a moderate load percentage on any path (over 10% of average link capacity).

Glad it's being funded by billionaires who may have a long timeframe in mind.

Iridium took a much different approach, focused on 14 kb/sec constrant-rate virtual circuits (compressed voice).

My guess is that, just as in the Internet, nobody understands bufferbloat, or deeply understands the TCP congestion control approach's limitations. And I bet they will throw in "differential service" as if it were a solved problem, and maybe network layer multicast, too. Why not create a huge mess based on assuming you can just figure it out after the satellites are up?

Are there any queueing theory and control theory folks among the leadership here? There are few in the IETF, and few in the cellular community, too, who can explore a completely new topology...

On Sunday, January 12, 2020 7:59am, "Dave Taht" <dave.taht at gmail.com> said:

> Mark  ignores retries and loss. I'm really far from confident this can
> be avoided, however perhaps with multiple terminals retransmitting...
> 
> http://nrg.cs.ucl.ac.uk/mjh/starlink/hotnets19.pdf
> 
> And it's still a bear to cross an ocean.
> 
> --
> Make Music, Not War
> 
> Dave Täht
> CTO, TekLibre, LLC
> http://www.teklibre.com
> Tel: 1-831-435-0729
> _______________________________________________
> Cerowrt-devel mailing list
> Cerowrt-devel at lists.bufferbloat.net
> https://lists.bufferbloat.net/listinfo/cerowrt-devel
>