From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-ed1-x52b.google.com (mail-ed1-x52b.google.com [IPv6:2a00:1450:4864:20::52b]) (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 2261B3B2A4 for ; Thu, 28 Oct 2021 22:38:54 -0400 (EDT) Received: by mail-ed1-x52b.google.com with SMTP id h7so33669807ede.8 for ; Thu, 28 Oct 2021 19:38:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=shinkuro-com.20210112.gappssmtp.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=XRCcVoY6Cgb2tExsriCkFbpFrtQixsJfWdaNL7raqtY=; b=HCzTtxyCNKANrWaCVWcghz7YYvmF62Dp0JDY7Vr36tB0PAqGD35MXv52TCGZwRtfbL XTfxm+gTkGCYnDXvUkSATwlsZ8pmUnmvUAVcTwCgDRqHu+pvT73TTcrWLB4pLlsG2sV3 O8cqIMXcPjOolGZBHY8O+2jO+31ZD4/f9OiGOla/lFSd4DsAU7gvpFbhYmCRQoPP5soI YQvGcgR74wa8wWI8oLgLbwVpZS0uW3ztWNnm112CCGnb/axwzFTBZzbIJER44UdK4QCD SiM9mSyfWGDbMtDvgL7/Qi3RdFla61m88Q/AV0GQn2v2zz6H8ujJY6dM8q0wCFibQG2o j2JA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=XRCcVoY6Cgb2tExsriCkFbpFrtQixsJfWdaNL7raqtY=; b=nEciKRwYbRdjSFSQpcUre6z/sua917vOJqdaTFm9FD6L1JK+NLONDyWKeW8WI3EL6X v4j+mMRRkY1CaYA9F4cw859vpgetc/MdfbcEDXgjD9Xv+dYDTTcvZd2ipQCPbFjePmU5 /XSwKVOBZhjtb9IHYJTaFxcYxKdzHqAzGjNbb4xnWzP5G9GJAcPOsDj/Ax7Xs8rdjzoC lInFf6hLMgK9UUmoUsp8Csz1/rzXtFoCjbsv+PYH6L2b5WeEuKuwebbnXorb18vtgivU M7qsNx5lhmOdHcdtP7WboJQBk3M0hMEr5/mX53ytrCxBupLLZl7RpFVNdX9nyjmYj2c3 sozw== X-Gm-Message-State: AOAM530IYOFv1c7d/9LnmgGs31N8yMP7AWrzD9AWAeZUHhTR9/t5r6rS N72igk99Go44cXlcqlWnE6S2MP1nSvpVFublHrQEYOSqJeo= X-Google-Smtp-Source: ABdhPJxUFtgvmJZof12a7ok4hj816uzyNxPmuSE4OKaFzITvJuP8NDeXPLBFWxr272ycaPJb5aCS26aw73H44Hd4ye8= X-Received: by 2002:a05:6402:4315:: with SMTP id m21mr11173464edc.277.1635475133045; Thu, 28 Oct 2021 19:38:53 -0700 (PDT) MIME-Version: 1.0 References: <28034.1635270711@localhost> <8007.1635359366@localhost> In-Reply-To: From: Steve Crocker Date: Thu, 28 Oct 2021 22:38:41 -0400 Message-ID: To: Dave Taht Cc: Mike Puchol , starlink@lists.bufferbloat.net Content-Type: multipart/alternative; boundary="000000000000582ec405cf74ba9d" Subject: Re: [Starlink] thinking about the laser links again 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, 29 Oct 2021 02:38:54 -0000 --000000000000582ec405cf74ba9d Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Why wouldn't they make it completely IPv6??? Steve On Thu, Oct 28, 2021 at 9:12 PM Dave Taht wrote: > I spent some time today looking over the job listings for clues ( > https://www.spacex.com/careers/index.html?search=3Dlinux ) BGP/ISIS > keeps cropping up. It really also looks like they are inventing their > own SDN along the way. And: their public BGP table has gained a bunch > of ipv4/21s lately with a few users reporting a routable IP for a few > days or weeks. I do hope they find a ipv4/12 somewhere or better, as I > think they've discovered CGNs are not particularly fun, and their > projected growth for the next year or two would be within that, (and > one fantasy I harbor is they peer with a bunch of outback BGP AS > holders with a "pro" service) > > I've been trying for a few years to get some industry interested in > leveraging 240/4 (at least within their CGN for dishy to dishy comms), > there's a preso on it at the upcoming ietf intarea: > https://datatracker.ietf.org/doc/draft-schoen-intarea-unicast-240/ > > I know that's kind of a blue sky thing, but all the code has been > working for years in both bsd and linux, as well as in multiple big > iron routers, amazon, and in openwrt (where we tested it first). Just > someone with balls and $s needs to step up to become a space RIR and > try to make those addrs more routable than we already have.... > > Anyway, good discussion on this thread!!! but all of you failed to > answer my humdinger question - *when* will they be able to route a > packet from new york to tokyo over the laser links? That kind of event > would be a world network latency record - right up there in > significance with the first inter-imp comms oct 29 1969: > > > https://en.wikipedia.org/wiki/ARPANET#/media/File:First-arpanet-imp-log.j= pg > > On Thu, Oct 28, 2021 at 3:53 AM Mike Puchol wrote: > > > > I cannot add more than the real experts on the networking / topology > side, but on the lasers themselves, a question was raised about multiple > links. The only way to do it economically is to use a single optical trai= n > per link (includes laser TX and photon detector, mirrors, power control, > attenuators, etc.). > > > > I raised the idea of an FSOC =E2=80=9Cflashlight=E2=80=9D to what could= be counted as > people in the top 10 worldwide list of experts in the field. Here, a beam > would be made wide enough to have multiple =E2=80=9Cclients=E2=80=9D, as = for radio sector > antennas. The idea was quickly discarded for a number of reasons, the > principal being that you are spreading the photons so much that not enoug= h > would reach the other side, at least at any meaningful distance. > > > > Photon detectors that could work are in the scientific instrument > category, thus really expensive. > > > > From photos, we know that each satellite has at least two lasers, so we > can assume at least in-plane communications. > > > > Best, > > > > Mike > > On Oct 28, 2021, 11:01 +0300, Ulrich Speidel = , > wrote: > > > > On 28/10/2021 7:29 am, Michael Richardson wrote: > > > > I guess the real question is: have you written the Hollywood Security > > Theatre > > script based upon this issues, and can I play the geek that explains > > this? :-) > > > > Sure! > > > > > > - Tell satellites where to send packets (in something along the > > > > lines of a > > > > long header, as in AX.25 for example). Then a sending ground station > > > > would > > > > need a complete almanach of the constellation and an idea as to > > > > where the > > > > receiving ground station is, and which satellite it would use for the > > downlink. Pros: The sending ground station can do all the number > > > > crunching on > > > > ground rather than space power. Cons: Header size costs bandwidth. > > > > > > From what I understood, Starlink shipped some kind of comodity SDN > capable > > chip. So MPLS, or SRv6 ought to be easy, costing only a few bytes > > interpreted in hardware, and a path computation element on the ground > > should > > be able to deal with the calculation. > > > > It's a challenging situation perhaps because the network effectively ge= ts > > rewired every few minutes, but ground based computation should be able = to > > deal with the problem. > > > > > > That presumes that the ground station has complete topology information > > for the constellation, though. That includes knowing about defective > > satellites and lasers etc., birds deviating from assigned orbit. > > > > But in principle, I can see how that could work, yes. > > > > > > - Get the satellites to work out where stuff needs to be sent. If > > > > they were > > > > to use something like Bellman-Ford here, that would require an enormous > > amount of update traffic. Dijkstra would require complete topology > > information, which should in principle be computable from an > > > > almanach on the > > > > satellites. > > > > > > I think, but I might be wrong, that there is a pattern which repeats > > over and > > over again. Just need to update the mapping of which satellite is in > which > > position in the precomputed mesh. No need to send the entire mesh. > > > > > > Of course. Bellman-Ford & Co. all assume a network without such > > regularities. But you need to make use of those patterns in order to > > make things possible - whether you do source or hop-to-hop routing. And > > while the configuration of the network is indeed predictable at least > > for the near future, it's not simply repeating over and over again. The > > current constellation (if viewed in isolation) more or less runs in 95 > > minute cycles. Earth rotates under the constellation, so the teleports > > only return to the same position with respect to the constellation when > > multiples of the length of a sidereal day coincide with multiples of 95 > > minutes. Plus you may find that the Starlink constellation isn't > > perfectly regular either in its pattern. > > > > > > > > -- > > **************************************************************** > > Dr. Ulrich Speidel > > > > School of Computer Science > > > > Room 303S.594 (City Campus) > > Ph: (+64-9)-373-7599 ext. 85282 > > > > The University of Auckland > > ulrich@cs.auckland.ac.nz > > http://www.cs.auckland.ac.nz/~ulrich/ > > **************************************************************** > > > > > > > > _______________________________________________ > > Starlink mailing list > > Starlink@lists.bufferbloat.net > > https://lists.bufferbloat.net/listinfo/starlink > > > > _______________________________________________ > > Starlink mailing list > > Starlink@lists.bufferbloat.net > > https://lists.bufferbloat.net/listinfo/starlink > > > > -- > Fixing Starlink's Latencies: https://www.youtube.com/watch?v=3Dc9gLo6Xrwg= w > > Dave T=C3=A4ht CEO, TekLibre, LLC > _______________________________________________ > Starlink mailing list > Starlink@lists.bufferbloat.net > https://lists.bufferbloat.net/listinfo/starlink > --000000000000582ec405cf74ba9d Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Why=C2=A0wouldn't they make it = completely IPv6???

Steve

On Thu, Oct 28, 2021 at 9:12 PM Dave Taht <dave.taht@gmail.com> wrote:
I spent some time today lookin= g over the job listings for clues (
https://www.spacex.com/careers/index.html?se= arch=3Dlinux ) BGP/ISIS
keeps cropping up. It really also looks like they are inventing their
own SDN along the way. And: their public BGP table has gained a bunch
of ipv4/21s lately with a few users reporting a routable IP for a few
days or weeks. I do hope they find a ipv4/12 somewhere or better, as I
think they've discovered CGNs are not particularly fun, and their
projected growth for the next year or two would be within that, (and
one fantasy I harbor is they peer with a bunch of outback BGP AS
holders with a "pro" service)

I've been trying for a few years to get some industry interested in
leveraging 240/4 (at least within their CGN for dishy to dishy comms),
there's a preso on it at the upcoming ietf intarea:
https://datatracker.ietf.org/doc/d= raft-schoen-intarea-unicast-240/

I know that's kind of a blue sky thing, but all the code has been
working for years in both bsd and linux, as well as in multiple big
iron routers, amazon, and in openwrt (where we tested it first). Just
someone with balls and $s needs to step up to become a space RIR and
try to make those addrs more routable than we already have....

Anyway, good discussion on this thread!!! but all of you failed to
answer my humdinger question - *when* will they be able to route a
packet from new york to tokyo over the laser links? That kind of event
would be a world network latency record - right up there in
significance with the first inter-imp comms oct 29 1969:

=C2=A0https://en.wikipedi= a.org/wiki/ARPANET#/media/File:First-arpanet-imp-log.jpg

On Thu, Oct 28, 2021 at 3:53 AM Mike Puchol <mike@starlink.sx> wrote:
>
> I cannot add more than the real experts on the networking / topology s= ide, but on the lasers themselves, a question was raised about multiple lin= ks. The only way to do it economically is to use a single optical train per= link (includes laser TX and photon detector, mirrors, power control, atten= uators, etc.).
>
> I raised the idea of an FSOC =E2=80=9Cflashlight=E2=80=9D to what coul= d be counted as people in the top 10 worldwide list of experts in the field= . Here, a beam would be made wide enough to have multiple =E2=80=9Cclients= =E2=80=9D, as for radio sector antennas. The idea was quickly discarded for= a number of reasons, the principal being that you are spreading the photon= s so much that not enough would reach the other side, at least at any meani= ngful distance.
>
> Photon detectors that could work are in the scientific instrument cate= gory, thus really expensive.
>
> From photos, we know that each satellite has at least two lasers, so w= e can assume at least in-plane communications.
>
> Best,
>
> Mike
> On Oct 28, 2021, 11:01 +0300, Ulrich Speidel <ulrich@cs.auckland.ac.nz>, = wrote:
>
> On 28/10/2021 7:29 am, Michael Richardson wrote:
>
> I guess the real question is: have you written the Hollywood Security<= br> > Theatre
> script based upon this issues, and can I play the geek that explains > this? :-)
>
> Sure!
>
>
> - Tell satellites where to send packets (in something along the
>
> lines of a
>
> long header, as in AX.25 for example). Then a sending ground station >
> would
>
> need a complete almanach of the constellation and an idea as to
>
> where the
>
> receiving ground station is, and which satellite it would use for the<= br> > downlink. Pros: The sending ground station can do all the number
>
> crunching on
>
> ground rather than space power. Cons:=C2=A0 Header size costs bandwidt= h.
>
>
> From what I understood, Starlink shipped some kind of comodity SDN cap= able
> chip. So MPLS, or SRv6 ought to be easy, costing only a few bytes
> interpreted in hardware, and a path computation element on the ground<= br> > should
> be able to deal with the calculation.
>
> It's a challenging situation perhaps because the network effective= ly gets
> rewired every few minutes, but ground based computation should be able= to
> deal with the problem.
>
>
> That presumes that the ground station has complete topology informatio= n
> for the constellation, though. That includes knowing about defective > satellites and lasers etc., birds deviating from assigned orbit.
>
> But in principle, I can see how that could work, yes.
>
>
> - Get the satellites to work out where stuff needs to be sent. If
>
> they were
>
> to use something like Bellman-Ford here, that would require an enormou= s
> amount of update traffic. Dijkstra would require complete topology
> information, which should in principle be computable from an
>
> almanach on the
>
> satellites.
>
>
> I think, but I might be wrong, that there is a pattern which repeats > over and
> over again. Just need to update the mapping of which satellite is in w= hich
> position in the precomputed mesh. No need to send the entire mesh.
>
>
> Of course. Bellman-Ford & Co. all assume a network without such > regularities. But you need to make use of those patterns in order to > make things possible - whether you do source or hop-to-hop routing. An= d
> while the configuration of the network is indeed predictable at least<= br> > for the near future, it's not simply repeating over and over again= . The
> current constellation (if viewed in isolation) more or less runs in 95=
> minute cycles. Earth rotates under the constellation, so the teleports=
> only return to the same position with respect to the constellation whe= n
> multiples of the length of a sidereal day coincide with multiples of 9= 5
> minutes. Plus you may find that the Starlink constellation isn't > perfectly regular either in its pattern.
>
>
>
> --
> ****************************************************************
> Dr. Ulrich Speidel
>
> School of Computer Science
>
> Room 303S.594 (City Campus)
> Ph: (+64-9)-373-7599 ext. 85282
>
> The University of Auckland
> ulrich@c= s.auckland.ac.nz
> http://www.cs.auckland.ac.nz/~ulrich/
> ****************************************************************
>
>
>
> _______________________________________________
> Starlink mailing list
> St= arlink@lists.bufferbloat.net
> https://lists.bufferbloat.net/listinfo/starlink<= /a>
>
> _______________________________________________
> Starlink mailing list
> St= arlink@lists.bufferbloat.net
> https://lists.bufferbloat.net/listinfo/starlink<= /a>



--
Fixing Starlink's Latencies: https://www.youtube.co= m/watch?v=3Dc9gLo6Xrwgw

Dave T=C3=A4ht CEO, TekLibre, LLC
_______________________________________________
Starlink mailing list
Starlin= k@lists.bufferbloat.net
https://lists.bufferbloat.net/listinfo/starlink
--000000000000582ec405cf74ba9d--