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 A02943B29E for ; Thu, 1 Sep 2022 18:00:36 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by tuna.sandelman.ca (Postfix) with ESMTP id 3D7F218373; Thu, 1 Sep 2022 18:21:08 -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 SLXE4i7O8eZW; Thu, 1 Sep 2022 18:21:04 -0400 (EDT) Received: from sandelman.ca (obiwan.sandelman.ca [209.87.249.21]) by tuna.sandelman.ca (Postfix) with ESMTP id 7745E18367; Thu, 1 Sep 2022 18:21:04 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=sandelman.ca; s=mail; t=1662070864; bh=Rb6uLZKf/2OH891tOYmIr9EiGraH7BVqdPsGfoeEOcM=; h=From:To:Subject:In-Reply-To:References:Date:From; b=wDz5Xc4MAJxXI8xLTNnmCRsfA8sufG2aAcLznFhGzUmCtLBKY97qMoQxXdJMIvBV7 BiyC2JY3xIqgBGIY4MNwURhVFH8IA8UlDwR9c6C3lTT+RorhiaN1f2ZKnAI5ahYj4B EIaBXhheqTzAkKkBsZ1WZuxzn8D932vAhsQxdVPNpVOahzcPb7vJajLd0PWSTWNdM0 EvnA+KAdKsV6+u3R1K6L+Oj4Bo7GZ+1Z99t8qgJZLVouqJywQYRZbx3UAkRPbaoDBQ 9cBdq8LvV1uu3TcIP08wf98i8kZwNHnHhTNln8hEMMGLl1NUjSft9RBUkKs/u9FnCx Y1J/wlISAbf5A== Received: from localhost (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id 3355D551; Thu, 1 Sep 2022 18:00:32 -0400 (EDT) From: Michael Richardson To: Mike Puchol , starlink@lists.bufferbloat.net In-Reply-To: <8231ade1-cac9-4a82-bdb0-66ff87217a63@Spark> References: <8231ade1-cac9-4a82-bdb0-66ff87217a63@Spark> X-Mailer: MH-E 8.6+git; nmh 1.7+dev; GNU Emacs 27.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: [Starlink] Why ISLs are difficult... 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: Thu, 01 Sep 2022 22:00:36 -0000 --=-=-= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Mike Puchol via Starlink wrote: > In terms of ground station coverage, once the entire ISL =E2=80=9Cmes= h=E2=80=9D is > complete, you could find a satellite with gateway coverage somewhere, > all the time. The path will change every few minutes, as the satellite > linking to the gateway changes, but it=E2=80=99s in the order of minu= tes, not > seconds. And, it's clockwork as you've said, so it's not like our traditional routing protocols where failures are due to problems or errors. To my mind, I'd want to have a fourth laser so that one could always be making before breaking, but if it's fast enough then one can probably buffer the packets while the lasers move. That's an evolution to my mind. That creates spikes in latency though, and it would be wise to keep the maximum apparent bandwidth to some 95% (or something) of max in order to always have enough bandwidth to catch up. (By Theory of Constraints) > Turning this into a global network in the shell: Even harder. > Agreed! If you equate this to an OSPF network with 4400 nodes, which > are reconfiguring themselves every few minutes, the task is not > trivial. OSPF is just not what I'd use :-) RPL (RFC6550) is probably better, but you'd still need a few tweaks since t= he parent selection is going to be predictable. > automatically adjust. Any calculation as to what links are establishe= d, > are active, etc. can be done on the ground and sent to the satellites > for execution, much in the same way that RF resource scheduling is do= ne > centrally in 15 second blocks. SDN is great, but a self-healing control plane loop is better (as Rogers le= arnt on July 7 in Canada). =2D- Michael Richardson . o O ( IPv6 I=C3=B8T consulti= ng ) Sandelman Software Works Inc, Ottawa and Worldwide --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQFKBAEBCgA0FiEEbsyLEzg/qUTA43uogItw+93Q3WUFAmMRK38WHG1jcitpZXRm QHNhbmRlbG1hbi5jYQAKCRCAi3D73dDdZU1MB/9tRZKACuCY3i/IkmbxPB7o8tDY BPL91IN0EM6H8+W4ZzGirQTAAQ8QOwNov7SwdvMnDY2UkNEveKUkb8dTPLaBN7kK RkC/F4MI2/v1A4m/nAySnLpPsh3v+aXOxZmY9k9VjbYy7HRNGr071ObsZsy2oodH 1VkjusQFIKdHpyzFBA0GO1c95GfmrwGEFPLYK7ldiQmFQqQ0vBkkLtpf2v5JpfVB SajNszI7RT5O0PgJFmcZ2BBjJxuG41CM1SQVf8tLdP3TOzRm808h/z9ZfAW4Lz42 5Rn21RclGPU801cwVz17U8a3+qCipoDmlz3bLvNCCUc+nXXT22OWTy+PUfAr =2Rma -----END PGP SIGNATURE----- --=-=-=--