From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from au-smtp-delivery-117.mimecast.com (au-smtp-delivery-117.mimecast.com [103.96.23.117]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by lists.bufferbloat.net (Postfix) with ESMTPS id A02A93B2A4 for ; Sun, 16 Apr 2023 09:48:41 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=auckland.ac.nz; s=mimecast20200506; t=1681652918; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=Nbnlv/iw4UO03wvIpP+qhLU5xLQ8b0BWXEYxED5GIoU=; b=AwwBOh1HXcZA6ib+hwh7qinB5+s3lcAIh/HycG1oS81ectJKlO61fWO1CcZEiYDG8Qvcus Uvdj9UpcRVvV/Nab3Cd9H/UQsN0YlpybPfkEK9FDjoHBX1LDh6xdYWTZalo8/PAsU6ArUE c9BHq5MSCGBbjNlVqAlERxraMP4UhBU= Received: from AUS01-ME3-obe.outbound.protection.outlook.com (mail-me3aus01lp2236.outbound.protection.outlook.com [104.47.71.236]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id au-mta-84-LFsYOzYfO-SpfODUuLT4lA-1; Sun, 16 Apr 2023 23:48:34 +1000 X-MC-Unique: LFsYOzYfO-SpfODUuLT4lA-1 Received: from SY4PR01MB6979.ausprd01.prod.outlook.com (2603:10c6:10:142::13) by MEYPR01MB7377.ausprd01.prod.outlook.com (2603:10c6:220:15e::12) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.6298.30; Sun, 16 Apr 2023 13:48:32 +0000 Received: from SY4PR01MB6979.ausprd01.prod.outlook.com ([fe80::8ab6:3d14:f4e:6fa2]) by SY4PR01MB6979.ausprd01.prod.outlook.com ([fe80::8ab6:3d14:f4e:6fa2%7]) with mapi id 15.20.6298.045; Sun, 16 Apr 2023 13:48:32 +0000 Message-ID: Date: Mon, 17 Apr 2023 01:48:26 +1200 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:102.0) Gecko/20100101 Thunderbird/102.10.0 To: tom@evslin.com, starlink@lists.bufferbloat.net References: <202304152356.33FNuD8m049509@gndrsh.dnsmgr.net> <7ed253a9-15d2-d0fd-af59-c5996687ab5b@auckland.ac.nz> <1c03701d97063$85436500$8fca2f00$@evslin.com> From: Ulrich Speidel In-Reply-To: <1c03701d97063$85436500$8fca2f00$@evslin.com> X-ClientProxiedBy: SY6PR01CA0060.ausprd01.prod.outlook.com (2603:10c6:10:ea::11) To SY4PR01MB6979.ausprd01.prod.outlook.com (2603:10c6:10:142::13) MIME-Version: 1.0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: SY4PR01MB6979:EE_|MEYPR01MB7377:EE_ X-MS-Office365-Filtering-Correlation-Id: f431a80b-733d-4dc6-b23f-08db3e814434 X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0 X-Microsoft-Antispam-Message-Info: pLEZ1TO0xhd4zTUf+0qZcEdgjH8cIVaYBhtLH/HoRC6vP+stgmRl0bJnhLkMQhedgnSeD1EFk4F4OnSAPJgvPzdUNNVndpUYCsHMTi5RNy/eYBjNfP9VBgvgOJr0gAqx71xxHrIhl6RRv/Lq05jGrfBKRljVy9z8Ro1uGVo3J3jcFwSPJyi8KOpGgZY9Ap0CZbXEZwdiHBIfATHu87tUkjERfn36bVS8CK9J+HIqKAajZLdW+yP1W/jWT/GPjIFKRwkfghjT1qC3LAu4p5+jY5++pQy4YaOCHIvn349szIO/riv7PCNHrelOn8pXChCdbWZey9mYcFPB3TJu7YbVtY28OipABiNKPEnjZbWP2Jcx8SmN3cCH9qGWBSHDDMdT0kaSdbM6j9rBkdRwRMVSkbaIg8ANnNVdyGCz7YqKew67BfsG74m0LRblwe2Jp/PXLig9BPIFipOyDmIzrrrK0fTlj1u4GFIjwRzZa05vYmhr+yj0nqWTrRJrmsOElFY6PslU1wAuSeaJbDsrwL366rLI/Q5qIbwxW0woSPGXgqKd/jjTQqsRypG8IS6ujF4h+XsaCQ8+JcRhWwp0MgKLPG4PRAKfxWeG05NgSlg+CoIb/qdJTUpSPx9kNz4rzliH3K8ZnDNDBiVatJbSeZKCfIMzjHA5umvqMbJ9iNAeOxEiju69SfXK5BZDijWaAr5a X-Forefront-Antispam-Report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:SY4PR01MB6979.ausprd01.prod.outlook.com; PTR:; CAT:NONE; SFS:(13230028)(4636009)(376002)(136003)(396003)(39860400002)(346002)(366004)(451199021)(41300700001)(38100700002)(36756003)(5660300002)(30864003)(786003)(31696002)(166002)(2906002)(31686004)(8676002)(86362001)(8936002)(66556008)(66946007)(66476007)(966005)(2616005)(66574015)(6506007)(83380400001)(6512007)(478600001)(186003)(53546011)(6666004)(6486002)(33964004)(316002)(43740500002)(45980500001); DIR:OUT; SFP:1101 X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?utf-8?B?bmp3eEJOWHJ3bkc5SmZkb3c1dDBiTUcxWmNqN1VHTm1wQmZ2dmhTME1Ocnda?= =?utf-8?B?dnB5cnF4NHcvUzRjYWE2WW1XSDQybTRVd2lhOUUzYmIraDNRNTdvVGRncERz?= =?utf-8?B?bGREdWdmV0pRc2pHelVHWDRWMFpzSk8zckpSQXNaQm1yOENmb2ZubGlVNzNh?= =?utf-8?B?cWMvSi9KeGdsQkFzNUcxanlMV2NCcDRXaVdNQU1xU01iZmpEcEU4c2xDZGdx?= =?utf-8?B?ZlNKRXMwYzlScHI4N2lyaFVPWTRTQ3NaUVkxbGpkVFA0ZCs3NTlUbURYOXdv?= =?utf-8?B?V3ZrbDdtL2tpbXdUVGpIazNZYlFZVjRMZmpxa3N4U1FDczI0RkFWckd5NHVG?= =?utf-8?B?ejVWdm1hQ2dPU1JkMHNFb1lZNExiYW5WQzVPL2JERkNHL2EzMVVGRUZxWHhD?= =?utf-8?B?V0ZxU0VOQ011Y09zc3NDOTdJbzB5RkFKM2RXOWUxU1N1SDJDZEZ1WTUrL2sy?= =?utf-8?B?dERIWDhvQTk2dmVhc0ZoZDhRaU1BZGZvUzBUTFR1S2ZxVkZjZmo2S2dESVIz?= =?utf-8?B?NE5aNDhHYkpNVEJCQ0NRTnl0R1JhWkl6RjZHenYyYk5JTldDN2hxc1pjYml4?= =?utf-8?B?bi9XZGJibUdSWmJiZDREbWRZemJrekFpa05IeE1lTzFuU3FQWVpQQTZrcmRs?= =?utf-8?B?NDZ3RTJrWmp2VDRleVYwTEZuWkhuUDh6NHpGalBNRHV0aXU0aHhWcDY4K1BN?= =?utf-8?B?Tk9Qb2pZQzhVU2pEa2NvOTQ5QlVsalBlYWlPYW5RaElyb3Iwek03N0pKdGJq?= =?utf-8?B?MjRYbGJyODVLdW12SkZUN201eVZkVTR1VmZoTVc5VkhJYkZITlU3RmhqcFdR?= =?utf-8?B?cnJJdFI3NUJXZzFubXJIMnlaTHN3bHFTU2Q4eWVidXNHanhkdXpxSmlqSExG?= =?utf-8?B?Q3JMSHBjMjZ3OGR2L2xXTW5UUXVLZ1dER1h3YnlDVkJKc1l5d1pkYmpKLzlk?= =?utf-8?B?SmJHdTg5L1hRaVpiOHR4Sit4UjdyaXVZK3FYMTU2SEdKeWNkY25hOTFpNndw?= =?utf-8?B?eTBwQWdmaFF1QmlnSk15aXdmVkpDVXNFL29oLzFpS2FpMys4UEtzdXZabFVz?= =?utf-8?B?Um9CelozUFkwMG1KbGFqT0xlT1NoUTF5bWdmOUVXemgwLzRiKy93MkVxZ1ZL?= =?utf-8?B?QnZFSDVYUUxuckQrRHFUWEtLeHlzMHBOaDcxTkZzWERpSXFJd3U4dEdTaEdS?= =?utf-8?B?N1pEckZnWWRtZWpQQkR4NEhwOExsVFpsYzJlejFvcThFSHkrQ2xseDZ4c2JJ?= =?utf-8?B?NVJpMFNYQ2lCaUZxaTdHOGpFc1JjYm9tblN0T0JxKy8vZU5oR21aMGVMTjZn?= =?utf-8?B?dS90NURMemxTNkhQb2c1V284TC80c3RuUHQyYkN2QXk0eGJoK1hvRlRRSU9F?= =?utf-8?B?bzYxV0ZtcTV3OGg2b0lsM3dyRVdYUTFCLzN5NkY4cnBWSWIyN0o4dHBqbzZZ?= =?utf-8?B?d09YQWhBWHIyZ1JGb0gwZkJCVXBlQlpEUE1HcUNDcDZQR1JmbzdhVWdqdUJJ?= =?utf-8?B?bHlLUVl6QU9aWnlxTzYva0lvMnNFMEI4NTc5RnFNYUZHVFpsd0cxd3VJME5N?= =?utf-8?B?RExBVWVEeVZGOTFVL1JINHFFejNTRjJXeGRFN1czYkFENnhOSGdIcjFadVJZ?= =?utf-8?B?RWZnU2UvbkpHMnd2V01jWVFnVjhVOXRSd240QWpUcVhES0VxT3NUNGRIczNv?= =?utf-8?B?RW10eXpXWmQvRkxQYjZhYkRvMlJYOS84SERBTXpYUCswanlOZGUvK3RPMHht?= =?utf-8?B?MzVzSlg0MjJQWnNyWEtnV2J0TE5mbXl2dHRzQVJEMEk0aVRGWHBHeG5xS0pl?= =?utf-8?B?TFdnZVd3bU9GWU82Qmp1SStaNWZIMUMvWnh5RDhmOUgwdjI2eTR6RDArSTM2?= =?utf-8?B?K1J2a2h0cE5EWWI5RlFWNWNTTlp1a0NaVWUxaXlnUlpZdEtGNEVQR0tJOVFK?= =?utf-8?B?d25PWkNNbHl2Wlo1ZXNJbzByMFYrN1Vnd1dEV0FjcTlsM21NSGlCclVMeGhG?= =?utf-8?B?bkU0L21mcmFrS0tDVjJyWHNjYmNMbVFIM29vdnNIYTJxZjMrdHJMS1BnZ0tD?= =?utf-8?B?NHlicGVmbzFBRGlDZDdDRHI2Vk5VWHVQWE93T1hyM2ZmcDB1Q3hucGtEUmdR?= =?utf-8?B?ZXVuVHpucHg0MTJLelRqOTlzbGNvZ1hJVUhQSmc5eEE3UjNHQjFZc3E3NlQ2?= =?utf-8?B?U1R3ZlhJZEd1WU9abmxBbURTK3FEMmdiMzA1YXV4blAyMXk0SEFCQ2RHZ0xa?= =?utf-8?B?d0FmaCtSazRFREdhR0pwZnZ4c3dRPT0=?= X-OriginatorOrg: auckland.ac.nz X-MS-Exchange-CrossTenant-Network-Message-Id: f431a80b-733d-4dc6-b23f-08db3e814434 X-MS-Exchange-CrossTenant-AuthSource: SY4PR01MB6979.ausprd01.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 16 Apr 2023 13:48:32.0705 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-CrossTenant-Id: d1b36e95-0d50-42e9-958f-b63fa906beaa X-MS-Exchange-CrossTenant-MailboxType: HOSTED X-MS-Exchange-CrossTenant-UserPrincipalName: hOrLc42f8kTH95noYK1NpTAq5rJO259PP5l0e8mkiSXqERjrwnxuga+h7/08IMwUmMaj+o1resQgopWYAjrY26o0weceC4F++PFpX2vok+A= X-MS-Exchange-Transport-CrossTenantHeadersStamped: MEYPR01MB7377 X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: auckland.ac.nz Content-Type: multipart/alternative; boundary="------------P39z50QlvK7Md6QgPED8XW2F" Content-Language: en-US Subject: Re: [Starlink] fiber IXPs in space 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, 16 Apr 2023 13:48:42 -0000 --------------P39z50QlvK7Md6QgPED8XW2F Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: quoted-printable It doesn't really solve the fundamental problem, though: Every single=20 copy of your cat video takes up RF bandwidth from the satellite to the=20 ground. Sure, you can save on uplink bandwidth to the satellite by putting a CDN=20 server into space, but that's only a factor of two, when terrestrial=20 CDNs already get way more than that on long distance fibre. Let's do a back-of-the-envelope: Base scenario: Population in Sampletown: 100,000. Cat video: 100 MB.=20 Percentage of users wanting to watch cat video of Sampletown's kindy's=20 resident cat making off with a lego piece: 0.1% =3D 100. 40,000 Starlink=20 satellites (looking ahead here). Number of people interested in the=20 video outside Sampletown: basically zero. Variant 0: No CDN server in Sampletown, backhaul to Sampletown via=20 fibre, local users on fibre. * Video sent to CDN server once: 100 MB =3D 80 Gb load on fibre. * Total spectrum use: zero Variant 1: CDN server in Sampletown, backhaul to Sampletown via fibre,=20 local users on fibre. * Video sent to CDN server once: 100 MB =3D 800 Mb load on fibre. * Total spectrum use: zero Variant 2: Everyone in Sampletown uses Starlink, no CDN in space. * Video uplinked 100 times: 80 Gb load on Starlink uplink bandwidth. * Video downlinked 100 times: 80 Gb load on Starlink downlink bandwidth. * Total spectrum use: 160 Gb Variant 3: Everyone in Sampletown uses Starlink, some sort of CDN in=20 space on the Starlink satellites themselves. * Video uplinked only to satellites that don't have a copy. After the first view of the video, the probability of the second viewer using the same satellite that handled the first view is 1 in 40,000. l.e., almost none of the 100 views will strike a satellite that already has a copy. That will only happen for videos with tens of thousands of views. So you get : 80 Gb load on Starlink uplink bandwidth. * Video downlinked 100 times: 80 Gb load on Starlink downlink bandwidth. * Total spectrum use: 160 Gb Variant 4: Everyone in Sampletown uses Starlink, some CDN in space=20 residing on GEO sats, so there's one GEO sat where all cat videos for=20 Sampletown end up. * Video uplinked to a Starlink sat on first request from CDN on GEO sat: 800 Mb. Further uplink to GEO via laser - 800 Mb load on laser. * Video downlinked 100 times: 80 Gb load on Starlink downlink bandwidth, plus 80 Gb load on laser from GEO sat CDN to Starlink satellite below. * Total spectrum use: 80.8 Gb, plus a bit of light pollution. That's your factor of 2 improvement. Variant 5: CDN server in Sampletown, backhaul to Sampletown via=20 Starlink, local users on fibre. * Video sent to CDN server once: 100 MB =3D 800 Mb load on Starlink uplink and downlink to CDN. * Total spectrum use: 1.6 Gb. That's a factor of 50-100 over the previous three scenarios. * But: That's not direct to site. It requires you as an end user not to be on Starlink. It's the downlink to your dishy that spoils the party. On 17/04/2023 1:01 am, tom@evslin.com wrote: > > The cdns, at least for streaming, could be higher since response time=20 > from them is not critical and the LEOs could serve as relays to earth.=20 > Depends whether it=E2=80=99s cheaper to do ISL between the LEOs and the h= igher=20 > satellites than linking down to earth for the stream. > > *From:* Starlink *On Behalf=20 > Of *Ulrich Speidel via Starlink > *Sent:* Sunday, April 16, 2023 3:04 AM > *To:* starlink@lists.bufferbloat.net > *Subject:* Re: [Starlink] fiber IXPs in space > > Given that clients cache DNS responses (including iterative responses=20 > from root servers), having DNS in space would be a nice-to-have, but=20 > it's not the most pressing issue IMHO. > > A far bigger problem is that a direct-to-site model like Starlink's=20 > essentially rules out placing CDN servers in close proximity to web=20 > clients. For those unfamiliar with them: CDNs (content delivery=20 > networks, which now carry a huge percentage of Internet content=20 > traffic) work by redirecting HTTP(S) requests for content to a CDN=20 > server that's in closer topological (and, by inference, physical)=20 > proximity to your web browser. That keeps repeated requests for the=20 > same content off expensive and scarce long-distance bandwidth while=20 > allowing for fast TCP cwnd growth due to the low RTT in the branch-=20 > and (thus collectively) bandwidth-rich local ISP networks. But that=20 > doesn't work for Starlink: There's no way to prevent everyone watching=20 > the same cat video via Starlink in your area from having to take up=20 > scarce space segment bandwidth each time the video is viewed. And=20 > we're talking serious data volumes here, unlike for DNS. > > You could, in principle, put CDN servers onto the satellites, but that=20 > would require the many earthly CDN providers to (a) persuade Elon that=20 > this is a good idea, (b) buy the service off SpaceX as it's unlikely=20 > they'll be given rack space on the Starlink fleet, and (c) you'd need=20 > a lot of storage capacity on each satellite in space, with a much=20 > reduced probability of a cache hit, since the fact that the satellites=20 > move across pretty much the whole globe over time, your next cat video=20 > download for your mates in town might need to come from a different=20 > satellite, and the satellite you currently talk to needs to cache not=20 > just stuff you and your neighbours like, but also stuff everyone else=20 > around the globe likes. So make that Chilean soap operas over Ukraine,=20 > Danish comedy for Australia, Aussie Rules Footy for the US Midwest,=20 > and so on... Or maybe quietly can the concept altogether. > > On 16/04/2023 11:56 am, Rodney W. Grimes via Starlink wrote: > > > On Fri, Apr 14, 2023 at 12:36?PM David Lang > wrote: > > > > > > On Fri, 14 Apr 2023, Rodney W. Grimes via Starlink wrote: > > > > > > >> I keep wondering when or if Nasa will find a way to move > their DNS > > > >> root server "up there" . DNS data is not all that much... > it is the > > > >> original distributed database... > > > > > > > > As others have pointed out a "root server" may not be very > advantages, > > > > but what I think would be far better is to put up a couple > of anycast > > > > recursive caching resolvers, aka 8.8.8.8/8.8.4.4 > > and almost anyone > > > > can do that, including starlink itself. > > > > > > I believe that the root servers are all (or almost all) > anycast nowdays. > > > > Anycast is perfect for an orbital DNS. > > BUTT, root servers are NOT recursive or caching, they serve a very > small limitited set of data that changes at low frequency (I am > not sure of the current rate of updates, but it use to be only > once daily.) > > Anyone can bring up there own replicate of a root server locally, > I do, and have for 2 decades, its a rather trivial thing to setup > and maintain. But unlike a root, I also turn on recursision and > caching. > > Again IMHO, a caching recursive any cast server ala 8.8.8.8 > > would > be far more useful than just a stock "root server." > > > -- > > AMA March 31: > https://www.broadband.io/c/broadband-grant-events/dave-taht > > > Dave T?ht CEO, TekLibre, LLC > -- > Rod Grimes rgrimes@freebsd.org > _______________________________________________ > Starlink mailing list > Starlink@lists.bufferbloat.net > https://lists.bufferbloat.net/listinfo/starlink > > > --=20 > **************************************************************** > Dr. Ulrich Speidel > School of Computer Science > Room 303S.594 (City Campus) > The University of Auckland > u.speidel@auckland.ac.nz =20 > http://www.cs.auckland.ac.nz/~ulrich/ > **************************************************************** --=20 **************************************************************** Dr. Ulrich Speidel School of Computer Science Room 303S.594 (City Campus) The University of Auckland u.speidel@auckland.ac.nz =20 http://www.cs.auckland.ac.nz/~ulrich/ **************************************************************** --------------P39z50QlvK7Md6QgPED8XW2F Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

It doesn't really solve the fundamental problem, though: Every single copy of your cat video takes up RF bandwidth from the satellite to the ground.

Sure, you can save on uplink bandwidth to the satellite by putting a CDN server into space, but that's only a factor of two, when terrestrial CDNs already get way more than that on long distance fibre.

Let's do a back-of-the-envelope:

Base scenario: Population in Sampletown: 100,000. Cat video: 100 MB. Percentage of users wanting to watch cat video of Sampletown's kindy's resident cat making off with a lego piece: 0.1% =3D 100. 40,000 Starlink satellites (looking ahead here). Number of people interested in the video outside Sampletown: basically zero.

Variant 0: No CDN server in Sampletown, backhaul to Sampletown via fibre, local users on fibre.

  • Video sent to CDN server once: 100 MB =3D 80 Gb load on fibre.
  • Total spectrum use: zero

Variant 1: CDN server in Sampletown, backhaul to Sampletown via fibre, local users on fibre.

  • Video sent to CDN server once: 100 MB =3D 800 Mb load on fibre.
  • Total spectrum use: zero

Variant 2: Everyone in Sampletown uses Starlink, no CDN in space.

  • Video uplinked 100 times: 80 Gb load on Starlink uplink bandwidth.
  • Video downlinked 100 times: 80 Gb load on Starlink downlink bandwidth.
  • Total spectrum use: 160 Gb

Variant 3: Everyone in Sampletown uses Starlink, some sort of CDN in space on the Starlink satellites themselves.

  • Video uplinked only to satellites that don't have a copy. After the first view of the video, the probability of the second viewer using the same satellite that handled the first view is 1 in 40,000. l.e., almost none of the 100 views will strike a satellite that already has a copy. That will only happen for videos with tens of thousands of views. So you get : 80 Gb load on Starlink uplink bandwidth.
  • Video downlinked 100 times: 80 Gb load on Starlink downlink bandwidth.
  • Total spectrum use: 160 Gb

Variant 4: Everyone in Sampletown uses Starlink, some CDN in space residing on GEO sats, so there's one GEO sat where all cat videos for Sampletown end up.

  • Video uplinked to a Starlink sat on first request from CDN on GEO sat: 800 Mb. Further uplink to GEO via laser - 800 Mb load on laser.
  • Video downlinked 100 times: 80 Gb load on Starlink downlink bandwidth, plus 80 Gb load on laser from GEO sat CDN to Starlink satellite below.
  • Total spectrum use: 80.8 Gb, plus a bit of light pollution. That's your factor of 2 improvement.

Variant 5: CDN server in Sampletown, backhaul to Sampletown via Starlink, local users on fibre.

  • Video sent to CDN server once: 100 MB =3D 800 Mb load on Starlink uplink and downlink to CDN.
  • Total spectrum use: 1.6 Gb. That's a factor of 50-100 over the previous three scenarios.
  • But: That's not direct to site. It requires you as an end user not to be on Starlink.

It's the downlink to your dishy that spoils the party.

On 17/04/2023 1:01 am, tom@evslin.com wrote:
=20

The cdns, at least for streaming, could be higher since response time from them is not critical and the LEOs could serve as relays to earth. Depends whether it=E2=80=99s cheaper to do ISL between the LEOs and the higher satellites than linking down to earth for the stream.

 

From: Starlink <starlink-bounces@lists.bufferbloat.net>= On Behalf Of Ulrich Speidel via Starlink
Sent: Sunday, April 16, 2023 3:04 AM
To: starlink@lists.bufferbloat.net
Subject: Re: [Starlink] fiber IXPs in space=

 

Given that clients cache DNS responses (including iterative responses from root servers), having DNS in space would be a nice-to-have, but it's not the most pressing issue IMHO.

A far bigger problem is that a direct-to-site model like Starlink's essentially rules out placing CDN servers in close proximity to web clients. For those unfamiliar with them: CDNs (content delivery networks, which now carry a huge percentage of Internet content traffic) work by redirecting HTTP(S) requests for content to a CDN server that's in closer topological (and, by inference, physical) proximity to your web browser. That keeps repeated requests for the same content off expensive and scarce long-distance bandwidth while allowing for fast TCP cwnd growth due to the low RTT in the branch- and (thus collectively) bandwidth-rich local ISP networks. But that doesn't work for Starlink: There's no way to prevent everyone watching the same cat video via Starlink in your area from having to take up scarce space segment bandwidth each time the video is viewed. And we're talking serious data volumes here, unlike for DNS.

You could, in principle, put CDN servers onto the satellites, but that would require the many earthly CDN providers to (a) persuade Elon that this is a good idea, (b) buy the service off SpaceX as it's unlikely they'll be given rack space on the Starlink fleet, and (c) you'd need a lot of storage capacity on each satellite in space, with a much reduced probability of a cache hit, since the fact that the satellites move across pretty much the whole globe over time, your next cat video download for your mates in town might need to come from a different satellite, and the satellite you currently talk to needs to cache not just stuff you and your neighbours like, but also stuff everyone else around the globe likes. So make that Chilean soap operas over Ukraine, Danish comedy for Australia, Aussie Rules Footy for the US Midwest, and so on... Or maybe quietly can the concept altogether.   

On 16/04/2023 11:56 am, Rodney W. Grimes via Starlink wrote:

> On Fri, Apr 14, 2023 at 12:36?PM David Lang <david@lang.hm> wrote:
> >
> > On Fri, 14 Apr 2023, Rodney W. Grimes via Starlink wrote:
> >
> > >> I keep wondering when or if Nasa will find a way to move their DNS
> > >> root server "up there" . DNS data = is not all that much... it is the
> > >> original distributed database...
> > >
> > > As others have pointed out a "root server&q= uot; may not be very advantages,
> > > but what I think would be far better is to put up a couple of anycast
> > > recursive caching resolvers, aka 8.8.8.8/8.8.4.4 and almost anyone
> > > can do that, including starlink itself.
> >
> > I believe that the root servers are all (or almost all) anycast nowdays.
>
> Anycast is perfect for an orbital DNS.

BUTT, root servers are NOT recursive or caching, they serve a very
small limitited set of data that changes at low frequency (I am
not sure of the current rate of updates, but it use to be only
once daily.)

Anyone can bring up there own replicate of a root server locally,
I do, and have for 2 decades, its a rather trivial thing to setup
and maintain. But unlike a root, I also turn on recursision and
caching.

Again IMHO, a caching recursive any cast server ala 8.8.8.8 would
be far more useful than just a stock "root server."
> --
> AMA March 31: https://www.broadband.= io/c/broadband-grant-events/dave-taht
> Dave T?ht CEO, TekLibre, LLC
--
Rod Grimes rgrimes@freebsd.org
_______________________________________________
Starlink mailing list
Starlink@lists.bufferbloat.net<= /a>
https://lists.bufferbloat.net/listinfo/starlink

-- 
**************************************************************=
**
Dr. Ulrich Speidel
 
School of Computer Science
 
Room 303S.594 (City Campus)
 
The University of Auckland
u.speidel@auckland.ac.nz 
http://www.cs.auckland.ac.nz/~ulrich/
**************************************************************=
**
 
 
 
--=20
****************************************************************
Dr. Ulrich Speidel

School of Computer Science

Room 303S.594 (City Campus)

The University of Auckland
u.speidel@auckland.ac.nz=20
http://www.cs.auckland.ac.nz/~ulrich/
****************************************************************
--------------P39z50QlvK7Md6QgPED8XW2F--