From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-pl1-x633.google.com (mail-pl1-x633.google.com [IPv6:2607:f8b0:4864:20::633]) (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 28CA03B29E for ; Thu, 20 Apr 2023 18:07:45 -0400 (EDT) Received: by mail-pl1-x633.google.com with SMTP id d9443c01a7336-1a6ebc66ca4so13151375ad.3 for ; Thu, 20 Apr 2023 15:07:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20221208; t=1682028464; x=1684620464; h=references:to:cc:in-reply-to:date:subject:mime-version:message-id :from:from:to:cc:subject:date:message-id:reply-to; bh=/rCFVIenizh0h/toENYtUyip/IgAZzLkdXGG4Qa9r5M=; b=P/MPSnoTVbvhtcHXpEM57mGTqxyKZ3c1oLFGqzPRoU9mleDPLoIat8SCN+FqBcWUw3 v8jqK29xXdKeh8mNP5e231jO0OoPRJ2wJJgZ1aHSPTC9gBujj1UOixU6TQz8hNXErzND A0j/SIz7NF3+9D00f0y44mMS8siC+2jHb0fWdMIZ2PZ+SXsE1Mk9HocS6n+wHr//F6Ju MJcD+uMazkwlTeVZi3Bw7oBTrEygHIhs9xzT+B1+1oJplkPQ/OVdWi6t/Z4cdGMGwDsL UFw+DY9JMDTDc1xl/aUM/+Ot8EqM1HzmUOFsMYAE3UxvPoJUzZ5Tavi0/9SIbAImA7Vq kh8A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1682028464; x=1684620464; h=references:to:cc:in-reply-to:date:subject:mime-version:message-id :from:x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=/rCFVIenizh0h/toENYtUyip/IgAZzLkdXGG4Qa9r5M=; b=Yxp3XiduFAV5pMSg+VmMPCCx0w36s4/jAHzAou1ELuOP+grzvOTjJB+zKgOPAb2G6u /Tp9OI0QoPmyZ73fIbwj4J+ezyyjTZRbgCDaiHT8bgHV8MsFnBrzhIEgQ9hFBWmYlqxy Mr65moF6xJ/Sj1SlJTm0Bbe184rRM/fRoO4ZlGSpKG4IQIq3clvwclWbQG11Ol2BIUwQ iE60DNm9R+kivKSa3UX//gMTHhJYeR6Dy3I7AMra2+5oW8SFlOk95fyNqIVPcGyc/u0B wssV5XOg5GKX/3ww+QdE3jNb/GcIKIVqUzUn5eH0qmc9hTFIW3iU/YLpuGdfBv2PI74O IB/A== X-Gm-Message-State: AAQBX9csvFXNwhyV+ywKcmRosIFnva3EUL/4Wm+AMls5sc0c02x3vN78 9W1lE17StTiRMg25W1oTVlk= X-Google-Smtp-Source: AKy350ZuZiNwALmhIL0jSRzB4c4a1JuPl2Kr9VjAmKcJWhL931qaZByxOpFDq1SmYAbChHpdEbTNKQ== X-Received: by 2002:a17:902:f28d:b0:1a1:b440:3773 with SMTP id k13-20020a170902f28d00b001a1b4403773mr3011437plc.27.1682028464005; Thu, 20 Apr 2023 15:07:44 -0700 (PDT) Received: from smtpclient.apple ([2601:603:4881:6e20:690d:e928:b282:6cd8]) by smtp.gmail.com with ESMTPSA id d13-20020a17090abf8d00b002474ea30ce2sm3424815pjs.16.2023.04.20.15.07.43 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Thu, 20 Apr 2023 15:07:43 -0700 (PDT) From: Spencer Sevilla Message-Id: <5472C863-B81B-42C9-B9A4-7BF032F075FD@gmail.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_08768A12-D5EB-4C24-B039-8E85AE0E7D15" Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3731.500.231\)) Date: Thu, 20 Apr 2023 15:07:32 -0700 In-Reply-To: Cc: =?utf-8?Q?David_Fern=C3=A1ndez?= , "starlink@lists.bufferbloat.net" To: Eugene Chang References: X-Mailer: Apple Mail (2.3731.500.231) Subject: Re: [Starlink] Starlink Digest, Vol 25, Issue 28 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, 20 Apr 2023 22:07:45 -0000 --Apple-Mail=_08768A12-D5EB-4C24-B039-8E85AE0E7D15 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 +1 to Gene, I have shared the exact same confusion on this thread. For satellites moving so fast (horizon to horizon in ~90sec), any = network functions above L2 (e.g. routing, caching, etc) feel like = they=E2=80=99d spend all their time churning. Keeping the satellites as = bent-pipe repeaters between a dishy and a ground station effectively = hides their orbital mobility from all other layers in the network and = allows for stability in other layers. Now, caching *at* the dishy, on the other hand=E2=80=A6 sounds like a = great idea! Caching at the ground station as well, though that doesn=E2=80= =99t get you any gains in terms of minimizing satellite network = bandwidth. Spencer > On Apr 20, 2023, at 14:34, Eugene Chang via Starlink = wrote: >=20 > Friends, > As I follow the discussion of putting computers on satellite, I can = understand the attraction if I apply the discussion with a satellite and = server above my location, suspended by a skyhook. The geometry is very = easy (some variations of a triangle). However, with an LEO satellite (or = MEO), most of the time the server is not overhead, it is hidden by the = horizon.=20 >=20 > Have I missed comments (or naively not understood comments) about how = the solutions work when the server is not overhead? I wanted to hear = about data locality and how the desired behavior varies according to the = position of the server. Does some of the proposed edge computing imply = (or assume) the data is needed on many satellites so that there is = always a server overhead with the needed data? (Then we have lots of = data synchronization challenges.) Clearly, this suggests there is a = scaling problem for edge computing solutions because for a single = server, most of the time the computer is not at the edge near me. >=20 > What am I missing? >=20 > Gene > ----------------------------------- > Eugene Chang > eugene.chang@alum.mit.edu > +1-781-799-0233 (in Honolulu) >=20 >=20 >=20 >=20 >=20 >> On Apr 20, 2023, at 2:24 AM, David Fern=C3=A1ndez via Starlink = > = wrote: >>=20 >> Well, O3b MPower (MEO satellites) is offering independent one hop >> dedicated access to the (Microsoft Azure) cloud as "killer >> application". If the cloud is on the satellite, half-hop. >>=20 >> Starlink GWs are near Google Cloud datacenters. >>=20 >> Blue Origin is on the mission to move Amazon Cloud to orbit, >> eventually, maybe, leaving the Earth as a garden to enjoy, without = any >> industry on the surface (in a century, maybe). Kuiper will offer one >> hop access to Amazon Cloud, then half-hop. >>=20 >> What seems a crazy idea today will be eventually implemented later, >> like Starlink (Teledesic failed, fingers crossed Starlink does not go >> bankrupt, although I would expect it be saved by Department of >> Defense, as Iridium was saved). >>=20 >> As we were discussing recently, maybe starting with anycast DNS >> servers on satellites is a first step to consider, before embarking >> any other type of cloud servers. >>=20 >> Regards, >>=20 >> David >>=20 >>> Date: Thu, 20 Apr 2023 04:33:00 +0000 >>> From: Ulrich Speidel > >>> To: "tom@evslin.com " >, 'Michael Richardson' >>> >, 'starlink' = >, >>> "e-impact@ietf.org " = > >>> Subject: Re: [Starlink] DataCenters in Space (was Re: fiber IXPs in >>> space) >>> Message-ID: >>> = > >>> =09 >>> Content-Type: text/plain; charset=3D"windows-1252" >>>=20 >>> Where do I even start? The lack of substantial bandwidth between = space and >>> ground? The extra latency between ground and space compared to = terrestrial >>> cloud, especially as terrestrial cloud edge can move much closer to >>> customers when space can't? The fact that every LEO satellite is = both a few >>> 100 km from every customer and out of the customer's range depending = on when >>> you look? That low temperatures in space don't mean superconductive = chips >>> that produce zero heat, and that that heat is difficult to get rid = of in >>> space? That generating power in space is orders of magnitude more = expensive >>> than on the ground? >>>=20 >>> Just because Starlink can provide a service somewhere between DSL = and low to >>> medium grade fibre to a few million around the globe it's not = "done". Even >>> with 10x the number of satellites and a couple of times the current = capacity >>> per satellite, Starlink isn't going to supply more than a couple of = 100 >>> million at best, and that's not even accounting for growth in demand = from >>> IOT... >>>=20 >>> -- >>>=20 >>> **************************************************************** >>> Dr. Ulrich Speidel >>>=20 >>> School of Computer Science >>>=20 >>> Room 303S.594 (City Campus) >>> Ph: (+64-9)-373-7599 ext. 85282 >>>=20 >>> 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 >=20 > _______________________________________________ > Starlink mailing list > Starlink@lists.bufferbloat.net > https://lists.bufferbloat.net/listinfo/starlink --Apple-Mail=_08768A12-D5EB-4C24-B039-8E85AE0E7D15 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 +1 to Gene, I = have shared the exact same confusion on this = thread.

For satellites moving so fast (horizon to = horizon in ~90sec), any network functions above L2 (e.g. routing, = caching, etc) feel like they=E2=80=99d spend all their time churning. = Keeping the satellites as bent-pipe repeaters between a dishy and a = ground station effectively hides their orbital mobility from all other = layers in the network and allows for stability in other = layers.

Now, caching *at* the dishy, on the other = hand=E2=80=A6 sounds like a great idea! Caching at the ground station as = well, though that doesn=E2=80=99t get you any gains in terms of = minimizing satellite network = bandwidth.

Spencer

On Apr 20, 2023, at 14:34, Eugene Chang via Starlink = <starlink@lists.bufferbloat.net> wrote:

Friends,
As I follow the discussion of putting = computers on satellite, I can understand the attraction if I apply the = discussion with a satellite and server above my location, suspended by a = skyhook. The geometry is very easy (some variations of a triangle). = However, with an LEO satellite (or MEO), most of the time the server is = not overhead, it is hidden by the = horizon. 

Have I missed comments (or = naively not understood comments) about how the solutions work when the = server is not overhead? I wanted to hear about data locality and how the = desired behavior varies according to the position of the server. Does = some of the proposed edge computing imply (or assume) the data is needed = on many satellites so that there is always a server overhead with the = needed data? (Then we have lots of data synchronization challenges.) = Clearly, this suggests there is a scaling problem for edge computing = solutions because for a single server, most of the time the computer is = not at the edge near me.

What am I = missing?

Gene
-----------------------------------
Eugene = Chang
eugene.chang@alum.mit.edu
+1-781-799-0233 (in Honolulu)





On Apr 20, 2023, at 2:24 AM, = David Fern=C3=A1ndez via Starlink <starlink@lists.bufferbloat.= net> wrote:

Well, O3b MPower (MEO = satellites) is offering independent one hop
dedicated access to the = (Microsoft Azure) cloud as "killer
application". If the cloud is on = the satellite, half-hop.

Starlink GWs are near Google Cloud = datacenters.

Blue Origin is on the mission to move Amazon Cloud = to orbit,
eventually, maybe, leaving the Earth as a garden to enjoy, = without any
industry on the surface (in a century, maybe). Kuiper = will offer one
hop access to Amazon Cloud, then half-hop.

What = seems a crazy idea today will be eventually implemented later,
like = Starlink (Teledesic failed, fingers crossed Starlink does not = go
bankrupt, although I would expect it be saved by Department = of
Defense, as Iridium was saved).

As we were discussing = recently, maybe starting with anycast DNS
servers on satellites is a = first step to consider, before embarking
any other type of cloud = servers.

Regards,

David

Date: Thu, 20 Apr 2023 04:33:00 +0000
From: Ulrich = Speidel <u.speidel@auckland.ac.nz><= br>To: "tom@evslin.com" <tom@evslin.com>, 'Michael = Richardson'
= <mcr@sandelman.ca>, = 'starlink' <starlink@lists.bufferbloat.= net>,
= "e-impact@ietf.org" = <e-impact@ietf.org>
Subject: = Re: [Starlink] DataCenters in Space (was Re:  fiber IXPs = in
= space)
Message-ID:
<SY4PR01MB697983BB5DEB1B2AA0B2690BCE639@SY4PR01MB6979.= ausprd01.prod.outlook.com>

Content-Type: text/plain; = charset=3D"windows-1252"

Where do I even start? The lack of = substantial bandwidth between space and
ground? The extra latency = between ground and space compared to terrestrial
cloud, especially as = terrestrial cloud edge can move much closer to
customers when space = can't? The fact that every LEO satellite is both a few
100 km from = every customer and out of the customer's range depending on when
you = look? That low temperatures in space don't mean superconductive = chips
that produce zero heat, and that that heat is difficult to get = rid of in
space? That generating power in space is orders of = magnitude more expensive
than on the ground?

Just because = Starlink can provide a service somewhere between DSL and low = to
medium grade fibre to a few million around the globe it's not = "done". Even
with 10x the number of satellites and a couple of times = the current capacity
per satellite, Starlink isn't going to supply = more than a couple of 100
million at best, and that's not even = accounting for growth in demand = from
IOT...

--

******************************************= **********************
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<<= a = href=3D"mailto:ulrich@cs.auckland.ac.nz">mailto:ulrich@cs.auckland.ac.nz>
http://www.cs.auckland.ac.n= z/~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/li= stinfo/starlink

= --Apple-Mail=_08768A12-D5EB-4C24-B039-8E85AE0E7D15--