From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from tuna.sandelman.ca (tuna.sandelman.ca [IPv6:2607:f0b0:f:3:216:3eff:fe7c:d1f3]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by lists.bufferbloat.net (Postfix) with ESMTPS id 5B0A33B2A4 for ; Sat, 13 Jun 2020 20:36:59 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by tuna.sandelman.ca (Postfix) with ESMTP id E132E389E9; Sat, 13 Jun 2020 20:34:25 -0400 (EDT) Received: from tuna.sandelman.ca ([127.0.0.1]) by localhost (localhost [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 0GYb5WVD5A-C; Sat, 13 Jun 2020 20:34:24 -0400 (EDT) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id C19AC389E7; Sat, 13 Jun 2020 20:34:24 -0400 (EDT) Received: from localhost (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id C5B71A9; Sat, 13 Jun 2020 20:36:56 -0400 (EDT) From: Michael Richardson To: David Lang , "David P. Reed" , Jonathan Morton , bloat In-Reply-To: References: <1591891396.41838464@apps.rackspace.com> <1591901205.85717618@apps.rackspace.com> <1591902977.45963161@apps.rackspace.com> <12673.1591976376@localhost> X-Mailer: MH-E 8.6+git; nmh 1.7+dev; GNU Emacs 26.1 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Subject: Re: [Bloat] FW: [Dewayne-Net] Ajit Pai caves to SpaceX but is still skeptical of Musk's latency claims X-BeenThere: bloat@lists.bufferbloat.net X-Mailman-Version: 2.1.20 Precedence: list List-Id: General list for discussing Bufferbloat List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 14 Jun 2020 00:36:59 -0000 --=-=-= Content-Type: text/plain David Lang wrote: >> David Lang 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. -- ] 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 [ --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCgAdFiEEbsyLEzg/qUTA43uogItw+93Q3WUFAl7lcSgACgkQgItw+93Q 3WWggggAlJu48BCLL2vonq1T/REz0iBA4hoRYrIJE3h21NzgDtnuqXKo50OXQLZu BFdCZWq0llbSW4teTqQ9H+gbOBGGy41MmyQpLlQiedun5QOmJ89Yb0JxOedUPxyx //ohHroWykG4waagoeYKXBYYTG5o0M8jxdLYUV8tmyKoyw+7VBzcXTJMjuM4Au67 9hqIREBq0SNEn0ydliSP9KTW29K3KAotfG5v+BYR7Q1LSY8cn6rcROvs8vRxW2KH RBaSmOnNXEMvb8Ly6rdkAqCYjJzEsajEuRWNfqk3vJDOF9vY5H4ND7Y5dzDd+eK3 Fj/fi0au11EFxY6YosoELCfHlJvvHA== =HDgk -----END PGP SIGNATURE----- --=-=-=--