From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-io1-xd29.google.com (mail-io1-xd29.google.com [IPv6:2607:f8b0:4864:20::d29]) (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 7FB1D3CB37 for ; Sun, 18 Jul 2021 18:29:59 -0400 (EDT) Received: by mail-io1-xd29.google.com with SMTP id p186so17756473iod.13 for ; Sun, 18 Jul 2021 15:29:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=0AQRYYoV7PFWYYvDYmcNtpsKIxMT1FaplnTWIN52TgE=; b=m6DydlVLW/pW2o2L7JJ9+vJX1T4lujam3+bSMjFcZg16r37Rd8tJh1vxkk+xfraP3Q 2ykeTpBL1CGulKVQuaGkvCtjNN2zwYwSyKRmkX2VBqTM96u7fkoOFx1KFSOiA33S4DJV nm2Yo6Cj68OSe/roolfgMc0rfmxUYpHWQSehfq6q+Q48YLrhKza7kCxiaUX10LrHD1Qn GwUBbjYlrCQGR5WnQhnE/6mcP7q4AlMfZuGTAMET8yBPy2CLQzhRHQFxJwd+AR5ZtUbd /PQxZyq67jX1S7G84itBcWGhwUYfKZdjbd/Z0SoCBoAQ0fauoxK47qhRTgx5+QBtKl2t 7rNQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=0AQRYYoV7PFWYYvDYmcNtpsKIxMT1FaplnTWIN52TgE=; b=BZROeNBJYWRuBROnSa/Diu5KkRcWJqSqkAVcaDDrF8Tk/4LtrNlfXNUH6lsSZ9ZBIF HB4jaeNPXsawN6tydPIMoqwXq3ln2TTkafjykHZ/z2no3/rjtNj4r4mszazDtcP6HkcY 9+WXvB8P+ax8kqigF17Xi5GeopFcwYHgKCUGhUashSdRIiuxkTCJSPn1RhYoot8W5vdH Lanwq+TdEbzBR67SrAYfa0FiOTZrvSQKbcFMIMC1GCsbZ7YlqZlOelaA0Y6lcXhr/aJn jOFu8uoZ/5CGzfN3dsinQRRldlr1SQJFEslDHZfZs62CEhC753znn/+LPI7aQwTjN+C7 /AkQ== X-Gm-Message-State: AOAM5312w1b7OBUWFvu21Kr2jIA8MXgRivb0i8EJZvvr8hGiKuG1vUpV 50MryzTgxZWqHEGMFUZKOfIwXEo75rRPu/Sqhrs= X-Google-Smtp-Source: ABdhPJyvBxRHkXeM6edcHfaC39E8+FTkV6QaPAMGu3rvqeryPN53N77S2QMKgMAOxsabY7Jwoit7aYYuTjhhZStHB5g= X-Received: by 2002:a6b:1406:: with SMTP id 6mr16543592iou.25.1626647398608; Sun, 18 Jul 2021 15:29:58 -0700 (PDT) MIME-Version: 1.0 References: <1625856001.74681750@apps.rackspace.com> <15095.1626468660@localhost> In-Reply-To: From: Dave Taht Date: Sun, 18 Jul 2021 15:29:46 -0700 Message-ID: To: David Lang Cc: Michael Richardson , "starlink@lists.bufferbloat.net" , "David P. Reed" Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable 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: Sun, 18 Jul 2021 22:29:59 -0000 On Sun, Jul 18, 2021 at 12:17 PM David Lang wrote: > > On Fri, 16 Jul 2021, Michael Richardson wrote: > > > 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= terminal > > > to terminal routing in orbit, there is the potential for the theor= etical > > > minimum to tend lower, giving some headroom for other overhead but= still > > > being in the 20ms range. I also used the 20ms figure in my podcast. https://twit.tv/shows/floss-weekly/episodes/638?autostart=3Dfalse I like to think with FQ in the loop, they can do even better for "ping" and gaming, but for a change I'd like to see elon actually underpromise and overdeliver. > > > > 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. > > unless you are going to have stations changing their IPv6 address frequen= tly, I'd really, really, hope for a dedicated /56 per station, no changes, EVER, unless the user requests it it falls under attack. Perhaps two /56s for failover reasons. Really silly to make ipv6 dynamic in this environment. Sure wish some ipv4/12 was available. Dynamic ipv4 doesn't make much sense anymore either. > don't see how you would route based on their address. The system is extre= mely > dynamic, and propgating routing tables would be a huge overhead. Remember= , > stations are not in fixed locations, they move (and if on an airliner or = rocket, > they move pretty quickly) IMHO: IF you were to go about designing a sane and fast planetary =E2=80=9Cmac=E2= =80=9D layer that could carry ipv4 and ipv6 (and hopefully ICN), traffic, on stuff in orbit... ( some relevant recent complaints over on this thread: https://www.linkedin.com/feed/update/urn:li:activity:6817609260348911616/ ) =E2=80=A6 and you were for !@#! sure that you would never have more than 2^= 32 exit nodes, a bunch of things get simpler. All you need to do on the ground is pick the exit node, with a couple other fields and the payload. How something gets there is the network=E2=80=99s problem. All the= l3 stuff =E2=80=9Cup there=E2=80=9D just vanishes. You end up with a very, ver= y simple and fast global routing table "up there" that is gps clock based, and only needs to be updated in case of a sat failure or to route around congestion (roughly the same thing) You do the complicated ipv4 or ipv6 route matching on the ground before translating it to L2 ... just to pick the *exit node*. Choosing nexthops on the ground happen on a schedule, and =E2=80=9Cnexthop=E2=80=9D = behavior on the sats in orbit or the solar system is also extremely predictable. If you yourself are moving, that too is extremely predictable. Other truly needed fields carried from l3 to the l2 layer should be kind of obvious if you look at the flaws in the ethernet and mpls =E2=80=9Cmac=E2= =80=9D, relative to what ipv6 tried to (over)do, what we've learned from history, and think about what a globally sync=E2=80=99d clock can do for yo= u, as well as a hashed flowid. I worked a bunch of this out in the period 1989-92 when I was working on a hard SF book =E2=80=9Ccentered=E2=80=9D on the asteroid Toutatis[1] an= d IPng was starting to bake (and I was still involved in ISO, I didn't really become an ipv4 convert until I got fed up with ISO in 1991 or so). If you spend enough time flying around the solar system from inside an epicycle (try it! Download celestia or try https://www.asterank.com/ and take a few rides on a rock and note the timescales at which any immediate routing change might need to be made) some things become obvious... Doesn't mean that I was right, but starlink's layer two design hasn't been published so I figure I should publish what I think I already knew before they tell me.... [1] Some info on "the toutatis way": https://web.archive.org/web/20040415014525/http://www.taht.net/~mtaht/aster= oid/toutatis.html Sadly I never finished writing the book. I=E2=80=99d had too much fun designing the network and plumbing, and not on the characters or conflict, and Vernor Vinge=E2=80=99s *awesome* =E2=80=9CFire upon the deep= =E2=80=9D came out in 93, centered on one of =E2=80=9Cmy=E2=80=9D core ideas (leveraging netne= ws), and had a better plot. And characters. And other crap happened to me. Ah, well. I am thinking if ever I get the time I will try to pull at least a short story out of it, someday. I keep meaning to update that spreadsheet of fast rotators. Been a long tim= e. > > I expect that initially it's going to be centrally managed, but over time= I > would expect that it would become more decentralized. I am looking forward to getting a few more nodes that are closer together t= o monitor with the cosmic background bufferbloat detector. Certainly precise sync is probably a bad idea... > > David Lang > _______________________________________________ > Starlink mailing list > Starlink@lists.bufferbloat.net > https://lists.bufferbloat.net/listinfo/starlink --=20 Latest Podcast: https://www.linkedin.com/feed/update/urn:li:activity:6791014284936785920/ Dave T=C3=A4ht CTO, TekLibre, LLC