From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wr1-x429.google.com (mail-wr1-x429.google.com [IPv6:2a00:1450:4864:20::429]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by lists.bufferbloat.net (Postfix) with ESMTPS id 015DD3B29E for ; Thu, 1 Sep 2022 18:12:27 -0400 (EDT) Received: by mail-wr1-x429.google.com with SMTP id b16so85419wru.7 for ; Thu, 01 Sep 2022 15:12:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date; bh=iFj1gnD6iS1+KHYMbM8+RPomAU9F4WYPomu2CueUPRQ=; b=qGXGy/2RHcepg6wNfzIlwIyodoRyXKtAFEjrhrohCnE1BcZ7Yf+n7mhYjjj/4UNXTp LrHiSOWUKhS/+VfT6ivlHZJW20vGzu2v2thbzmFjuq0zHwqdr99cSQpuCMw9VI8W1z6v OrL41HkssvDvyVTGHSEbGnGzpJwRCkae1VdsoZx08j97W6STkNwQsfuDds74bNbhsBFP epOPaLk0QwUC0lOD/dPMgW6a8sNka/j5DSxX1H8ynBJ0EPHACNBZq0cJDQIMf0/lrIc6 Pr2GFLH/4ghAc6PBnAU36ewQhwF7CFiZXwjONXvV95JdGFtcvnrOOeeQMUxqyH1Y9BZx YCvQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc :subject:date; bh=iFj1gnD6iS1+KHYMbM8+RPomAU9F4WYPomu2CueUPRQ=; b=CPQTs1C1+6ocq9tMDMaupAfIPCUnsWoYMdF7rbjUWtgPhujOYMn24TC2lO4++py7GX g5zNfsGfiM2T6WiGkdwpOHl7tWHYKnItvGDW+w3Vss4dXOt12TA6yE1lZh3rf3mbR2ZF j6pRhqe/WVxCgWkaUe2zgW2iL2HLIhEGgL0etK/ohLrxR9470cf3mXm8lpFOwqFHr/dG 7of/nybK/z4fEhJp7sY2GCxyxT2koit1LLSOYKOwwpFU5u5cq2GSxEuXaPIpzrNGOZnO uzsdQ0TwvI5Q7blViMTYpCAmuhuQgcrsns1Qg26N3RyZ53/z5lIIv8NN2WegaNLKHEOR 0MHA== X-Gm-Message-State: ACgBeo20kSn9aPH1+zO6u/QPU+fb5vbcEfPCzKEvCj4CH3OYeeXIL0f+ aTNQumU/TAHbixucntpokYEEfVVN8Tu7Lq7eESE= X-Google-Smtp-Source: AA6agR6A+EVgy51PzRTMmje706bJLNLQZvrEvyYotZ8Jm+4umYya8607tP5Rd+C3CW+imXEOmEQNzGRfOzlYBbTFyZE= X-Received: by 2002:a05:6000:1549:b0:225:652e:45d4 with SMTP id 9-20020a056000154900b00225652e45d4mr16233704wry.15.1662070346726; Thu, 01 Sep 2022 15:12:26 -0700 (PDT) MIME-Version: 1.0 References: <8231ade1-cac9-4a82-bdb0-66ff87217a63@Spark> <27620.1662069632@localhost> In-Reply-To: <27620.1662069632@localhost> From: Dave Taht Date: Thu, 1 Sep 2022 15:12:14 -0700 Message-ID: To: Michael Richardson Cc: Mike Puchol , Dave Taht via Starlink Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable 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:12:28 -0000 On Thu, Sep 1, 2022 at 3:00 PM Michael Richardson via Starlink wrote: > > > Mike Puchol via Starlink wrote: > > In terms of ground station coverage, once the entire ISL =E2=80=9Cm= esh=E2=80=9D is > > complete, you could find a satellite with gateway coverage somewher= e, > > all the time. The path will change every few minutes, as the satell= ite > > linking to the gateway changes, but it=E2=80=99s in the order of mi= nutes, not > > seconds. > > And, it's clockwork as you've said, so it's not like our traditional rout= ing > 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 buf= fer > the packets while the lasers move. That's an evolution to my mind. One of the big flaws in early wifi extending to today was only 3 useful channels. https://mathworld.wolfram.com/Four-ColorTheorem.html I used to fiddle with graph theory a lot, one of my favorites for describing "optimum" resilient connectivity was the blanusa snark: https://en.wikipedia.org/wiki/Blanu%C5%A1a_snarks Which became the logo of the cerowrt project, and a subset of which, of the babel routing protocol. > 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, whic= h > > 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= the > parent selection is going to be predictable. Tee-hee. I would use something derived from a DV protocol in general, and as I said, would use a l2 more amiable to movement, which is something that ipv6 gloriously failed at. L3 identifiers would stay fixed, the points underneath change.... The effects of what seems to be a starlink link state protocol (every 15s) are rather noticible at the scale they are currently at, and far more dynamic convergence is possible with DV. Any centralized approach fails at distance. I have not been paying attention, to what extent are any rtt sensitive metrics being used in production? https://datatracker.ietf.org/doc/html/draft-ietf-babel-rtt-extension-00 > > automatically adjust. Any calculation as to what links are establis= hed, > > are active, etc. can be done on the ground and sent to the satellit= es > > for execution, much in the same way that RF resource scheduling is = done > > centrally in 15 second blocks. > > SDN is great, but a self-healing control plane loop is better (as Rogers = learnt on July 7 in Canada). > > > -- > Michael Richardson . o O ( IPv6 I=C3=B8T consul= ting ) > Sandelman Software Works Inc, Ottawa and Worldwide > > > > > _______________________________________________ > Starlink mailing list > Starlink@lists.bufferbloat.net > https://lists.bufferbloat.net/listinfo/starlink --=20 FQ World Domination pending: https://blog.cerowrt.org/post/state_of_fq_code= l/ Dave T=C3=A4ht CEO, TekLibre, LLC