From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from tuna.sandelman.ca (tuna.sandelman.ca [209.87.249.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by lists.bufferbloat.net (Postfix) with ESMTPS id 3A7163CB39 for ; Fri, 12 Jun 2020 11:39:38 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by tuna.sandelman.ca (Postfix) with ESMTP id 8EB64389AA; Fri, 12 Jun 2020 11:37:06 -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 B3Uptvo3sKUC; Fri, 12 Jun 2020 11:37:05 -0400 (EDT) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id C898A389A7; Fri, 12 Jun 2020 11:37:05 -0400 (EDT) Received: from localhost (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id 9EE8C5FB; Fri, 12 Jun 2020 11:39:36 -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> 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: Fri, 12 Jun 2020 15:39:38 -0000 --=-=-= Content-Type: text/plain 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. Anything less, and it's just a faster Iridium. > I expect the queuing to happen at the internet-satellite gateways, which is > much more conventional software and if they do something sane at the gateways > it will address the problem for pretty much everyone. They don't have to > implement anything special on the satellites. > and if he is promising good latency, but there isn't good latency, it isn't > going to be swept under the rug the way incumbant ISPs were able to. I would expect to use SDN to create virtual satellites which appear to be "stationary", and then do routing on top of that. -- ] 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+93Q3WUFAl7jobgACgkQgItw+93Q 3WVjRAf/TF/QF9YVwc3+MQ4k8iPC1YTBYPYBPvDzPZamkbGMI49RVZNNJgI7ACdN YmcZG4KozdZsT7h/9MHPUdYf0AtQX48UJgE36tJunHCU73QAktY7MNV+IrWRPlNP w2yCrG0SstIfqXy31j7Lc2z+vsn4HEkr4ev7yA9AhpDxgOzajRh+OfeI3usVVFF1 Ew1Tt7OHNcgTwqQ5EnBW8Zb1mf8OliI8sRkN2IxGpjNwh6VYjYoDJRZvUog9VQyt wEFRymr1DC7qq042yZ+q1CjIx1HCGWJpabdoM4Ndqlf1FXSs1wk0TcVSrdSLBAqm Fp/NSWffPf+akDOCg4HxwgYfTnV27Q== =uEPX -----END PGP SIGNATURE----- --=-=-=--