From: David Lang <david@lang.hm>
To: Michael Richardson <mcr@sandelman.ca>
Cc: David Lang <david@lang.hm>, "David P. Reed" <dpreed@deepplum.com>,
Jonathan Morton <chromatix99@gmail.com>,
bloat <bloat@lists.bufferbloat.net>
Subject: Re: [Bloat] FW: [Dewayne-Net] Ajit Pai caves to SpaceX but is still skeptical of Musk's latency claims
Date: Sat, 13 Jun 2020 18:17:50 -0700 (PDT) [thread overview]
Message-ID: <nycvar.QRO.7.76.6.2006131815220.16262@qynat-yncgbc> (raw)
In-Reply-To: <20571.1592095016@localhost>
On Sat, 13 Jun 2020, Michael Richardson wrote:
> David Lang <david@lang.hm> wrote:
> >> David Lang <david@lang.hm> wrote:
> >> > my point is that the if the satellite links are not the bottleneck, no
> >> > queuing will happen there.
> >>
> >> It's a mesh of satellites.
> >>
> >> If you build it into a DODAG (RFC6550 would work well), then you will either
> >> a bottleneck at the top of tree (where the downlink to the DC is), or you
> >> will have significant under utilitization at the edges, which might encourage
> >> them to buffer.
> >>
> >> Now, the satellites are always moving, so which satellite is next to the DC
> >> will change, and this quite possibly could be exploited such that it's
> >> always a different buffer that you bloat, so the accumulated backlog that
> >> David P spoke about in his message might get to drain.
> >>
> >> But, the right way to use this mesh is, in my opinion, to have a lot of
> >> downlinks, and ideally, to do as much e2e connection as possible.
> >> Don't connect *to* the Internet, *become* an Internet.
> >> That is, routing in the satellite mesh, not just creation of circuits to DCs.
>
> > realistically, the vast majority of the people who have the mobile endpoints
> > are going to be talking to standard websites and services, and those are
> > going to be on the Internet, not on starlink nodes.
>
> Well, as along as we continue to build NATworks on the assumption that
> everyone is a consumer, not a citizen, that pattern will continue to happen.
>
> I think that when FACEBOOK suggested such a thing, explaining how they could
> accelerate everything through their servers, it was a major problem.
>
> Had this been the attitude in 1989, then the Internet would never have
> happened, and WWW would not have been a thing.
>
> The lockdown has shown that actual low-latency e2e communication matters.
> The gaming community has known this for awhile.
how has the lockdown shown this? video conferencing is seldom e2e
and starlink will do very well with e2e communications, but the potential
bottlenecks (and therefor potential buffering) aren't going to show up in e2e
communications, they will show up where lots of endpoints are pulling data from
servers not directly connected to starlink.
David Lang
next prev parent reply other threads:[~2020-06-14 1:17 UTC|newest]
Thread overview: 22+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-06-11 16:03 David P. Reed
2020-06-11 16:14 ` Jonathan Morton
2020-06-11 18:46 ` David P. Reed
2020-06-11 18:56 ` David Lang
2020-06-11 19:16 ` David P. Reed
2020-06-11 19:28 ` David Lang
2020-06-12 15:39 ` Michael Richardson
2020-06-13 5:43 ` David Lang
2020-06-13 18:41 ` David P. Reed
2020-06-14 0:03 ` David Lang
2020-06-14 0:36 ` Michael Richardson
2020-06-14 1:17 ` David Lang [this message]
2020-06-14 15:40 ` David P. Reed
2020-06-14 15:57 ` Michael Richardson
2020-06-14 21:04 ` David P. Reed
2020-06-14 23:13 ` Michael Richardson
2020-06-12 15:30 ` Michael Richardson
2020-06-12 19:50 ` David P. Reed
2020-06-13 21:15 ` Michael Richardson
2020-06-13 23:02 ` Jonathan Morton
2020-06-14 0:06 ` David Lang
2020-06-14 11:23 ` Roland Bless
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/bloat.lists.bufferbloat.net/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=nycvar.QRO.7.76.6.2006131815220.16262@qynat-yncgbc \
--to=david@lang.hm \
--cc=bloat@lists.bufferbloat.net \
--cc=chromatix99@gmail.com \
--cc=dpreed@deepplum.com \
--cc=mcr@sandelman.ca \
/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