From: "David P. Reed" <dpreed@deepplum.com>
To: "Dave Taht" <dave.taht@gmail.com>
Cc: "cerowrt-devel" <cerowrt-devel@lists.bufferbloat.net>
Subject: Re: [Cerowrt-devel] starlink as a mesh network
Date: Mon, 13 Jan 2020 12:56:39 -0500 (EST) [thread overview]
Message-ID: <1578938199.64982240@apps.rackspace.com> (raw)
In-Reply-To: <CAA93jw4PRyw_cBBMemPuU_NEEn+D_LztYtZqqrRasPS3Q5wioA@mail.gmail.com>
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
>
next prev parent reply other threads:[~2020-01-13 17:56 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-01-12 12:59 Dave Taht
2020-01-13 17:56 ` David P. Reed [this message]
2020-01-14 2:30 ` Michael Richardson
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: https://lists.bufferbloat.net/postorius/lists/cerowrt-devel.lists.bufferbloat.net/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1578938199.64982240@apps.rackspace.com \
--to=dpreed@deepplum.com \
--cc=cerowrt-devel@lists.bufferbloat.net \
--cc=dave.taht@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox