[Cerowrt-devel] starlink as a mesh network

[Cerowrt-devel] starlink as a mesh network

[Dave Taht]

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

Re: [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@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@lists.bufferbloat.net
> https://lists.bufferbloat.net/listinfo/cerowrt-devel
> 

Re: [Cerowrt-devel] starlink as a mesh network

[Michael Richardson]

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


David P. Reed <dpreed@deepplum.com> wrote:
    > Fun, but it is all just a dynamic geometry game.

True.

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

And I still don't think we know much about how they are going to build paths.
Unless they do L3 switching, or support creating **many** paths on demand,
it's not going to be useable for P2P directly between terminals, as Musk has
claimed.

AFAIK, all we still have from him is, "Simpler than IPv6"

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


[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 487 bytes --]