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 ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by lists.bufferbloat.net (Postfix) with ESMTPS id 9B4B03B29E for ; Fri, 16 Jul 2021 16:51:06 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by tuna.sandelman.ca (Postfix) with ESMTP id 9E3C938A6A; Fri, 16 Jul 2021 16:54:10 -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 wMT7rw9QFiXz; Fri, 16 Jul 2021 16:54:07 -0400 (EDT) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id 0B92338A72; Fri, 16 Jul 2021 16:54:07 -0400 (EDT) Received: from localhost (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id DA75F407; Fri, 16 Jul 2021 16:51:00 -0400 (EDT) From: Michael Richardson To: David Lang , Nathan Owens , "starlink@lists.bufferbloat.net" , "David P. Reed" In-Reply-To: References: <1625856001.74681750@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 Content-Transfer-Encoding: quoted-printable Date: Fri, 16 Jul 2021 16:51:00 -0400 Message-ID: <15095.1626468660@localhost> Subject: Re: [Starlink] Starlink and bufferbloat status? X-BeenThere: starlink@lists.bufferbloat.net X-Mailman-Version: 2.1.20 Precedence: list List-Id: "Starlink has bufferbloat. Bad." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Jul 2021 20:51:06 -0000 David Lang wrote: > As there are more staellites, the up down time will get closer to 4-= 5ms > rather then the ~7ms you list, and with laser relays in orbit, and t= erminal > to terminal routing in orbit, there is the potential for the theoret= ical > minimum to tend lower, giving some headroom for other overhead but s= till > being in the 20ms range. I really want this to happen, but how will this get managed? We will don't know shit, and I'm not convinced SpaceX knows either. I'm scared that these paths will centrally managed, and not based upon longest prefix (IPv6) match. -- ] Never tell me the odds! | ipv6 mesh networ= ks [ ] Michael Richardson, Sandelman Software Works | IoT architect= [ ] mcr@sandelman.ca http://www.sandelman.ca/ | ruby on rails = [