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 27F6E3B29D for ; Sun, 16 Apr 2023 03:04:07 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=auckland.ac.nz; s=mimecast20200506; t=1681628645; 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=6Juidj9AwMP35PoEkR/egyOhWyBDxgjue43AMuSdcWM=; b=nVikmSM94j4DvtKazle0g70g1Cb+4Gxbk/lMK8R1A42gCElLH6KVHUV8q/oXsJ78HV+P28 YY5vL2XDCMTw0soE2pf4sa3LRODmUSHtWfqCsQEXOTN8wbHj/9v+7SSf2vbLBN/sw/X2Ra VbADPuAtfpXHfiMCpqxmJahzdDtiQdU= Received: from AUS01-SY4-obe.outbound.protection.outlook.com (mail-sy4aus01lp2177.outbound.protection.outlook.com [104.47.71.177]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id au-mta-40-A-H3YvogN5yY3WexSEsNzQ-1; Sun, 16 Apr 2023 17:04:02 +1000 X-MC-Unique: A-H3YvogN5yY3WexSEsNzQ-1 Received: from SY4PR01MB6979.ausprd01.prod.outlook.com (2603:10c6:10:142::13) by SYBPR01MB5758.ausprd01.prod.outlook.com (2603:10c6:10:e7::13) 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 07:04:01 +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.030; Sun, 16 Apr 2023 07:04:01 +0000 Message-ID: <7ed253a9-15d2-d0fd-af59-c5996687ab5b@auckland.ac.nz> Date: Sun, 16 Apr 2023 19:03:56 +1200 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:102.0) Gecko/20100101 Thunderbird/102.10.0 To: starlink@lists.bufferbloat.net References: <202304152356.33FNuD8m049509@gndrsh.dnsmgr.net> From: Ulrich Speidel In-Reply-To: <202304152356.33FNuD8m049509@gndrsh.dnsmgr.net> X-ClientProxiedBy: SY3PR01CA0140.ausprd01.prod.outlook.com (2603:10c6:0:1b::25) To SY4PR01MB6979.ausprd01.prod.outlook.com (2603:10c6:10:142::13) MIME-Version: 1.0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: SY4PR01MB6979:EE_|SYBPR01MB5758:EE_ X-MS-Office365-Filtering-Correlation-Id: 4aea2db5-6336-4432-70a8-08db3e48c199 X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0 X-Microsoft-Antispam-Message-Info: RvUuoVJz4UNUEEzLoBH0iW0Fx0G6TlUhoUMQHPuzDqqAilb5W8ASEHJVPhFIRUXMuKTbMHNoADaPjMwFX2Hnr3PEEPDvHhm4BLRE7tjfBqSZb1fl/NHJmSIc8UaxXi0kgyD+i9g/oix3EOq5UKdugzOXVAsKOmayE6AMgC/Rsgee6d+aV4bhi5cphEcKZki2adA/8qvlWhzqBWLodsG+Svvp3WLqWXCBKEhquRPharqDRmavUEKkUo1tjA1NkNtPI6uLUYID7Lyqmu0RSoRvkjJUcfj33+MYQM5qJoD5H3fEQHozCgfNFniMwu+R9+9vrD8YTo9ZkFpB9bZpOJ2DtzUh0XkrCfXQPVYszJNniR1UUk8oG4bpasNBScLl0kiJmElusTVnlW0tCfQw75iv4AiqyTjG13M4AgJ/SIUmKd/SfTW0d4gUmRIIvVlo0rbolbaalt6dj8ovWFXuNtdfbdAQZd4k4aGo6dTBxDDJTkZx4J/TcqOh/biWeCPVz6ZFuTlNvCJUnu+pEwh3sTAWParVcboZtPgn+23d4qiA5Ns+kaSBvEfjlMbQWsuUVW9lV8dmGd4vzwoRtN4qkgnyGruip0AvKQpyhGbXuNDfo1gy+Q/fOTIhI/C1lPfEgZ2Pljnkrwl2QMUaIg+RyuwTQk/a2Cc2j9dl2ujNo6paSBiuXusl9Pl4mR4Xmk/RDmTE 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)(366004)(136003)(396003)(346002)(376002)(39860400002)(451199021)(166002)(2616005)(66574015)(53546011)(6506007)(2906002)(6512007)(186003)(38100700002)(8936002)(83380400001)(86362001)(66946007)(66556008)(66476007)(6666004)(33964004)(478600001)(6486002)(966005)(36756003)(31686004)(5660300002)(316002)(786003)(6916009)(8676002)(41300700001)(31696002)(45980500001)(43740500002); DIR:OUT; SFP:1101 X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?utf-8?B?UDZFTDRwdmsrQ1FQcmx4djFqS3hkVVBCV1ozK1h4aXhoL041elJ4bXJaZlBI?= =?utf-8?B?YWFBZmYxOEVKbnl1YzZ0dzVVVytGK2J2V2pRcWh1SzRyaUxCTVVEdStVWVR2?= =?utf-8?B?cTN3OXo4QXBJZDlkUEswNzBYaDdjQkJDRGl3VGRiN3VsVFFwbjhFUnhIaVlh?= =?utf-8?B?ZktjUk9DL0gwYVRIL1YzSkpLcVE3RGFHVDdOT3dDbFBHdGVMYk5iUUFDanAy?= =?utf-8?B?cGs1bFFHbmR4ZWZXcCtGaGRtaVpKZVQvNVJqOVF2RDBWdHkyK3N4YmsvcEV3?= =?utf-8?B?ZWU1QzYyRElrd3JyR004ODJ6S1E5QmMrTG0vSmtUMHpneW9CR3NrZ1RtS1ZU?= =?utf-8?B?aDRRWFIvdDFvYWJrbFdrNFZkVURVeWJkSkx1dkJRN1hoNFZUREEwR0ZTbHpL?= =?utf-8?B?dzFSM25qZ0thYW5YOHptcE9SblBFeXE1NzdTU0VwQWs3QU9IN0llTU42VnZF?= =?utf-8?B?bTl6UnhXU2Njd3hPWXRTeXBGU0xlT2hJQ1VJTmFoUWNqbUFHNjhjbTJSM09o?= =?utf-8?B?UmdYbUpvbVBzWEd0NXpoNWVXNndqZTJKSFNsOVJXUXRMRDVnUEpwTzhtcEsv?= =?utf-8?B?VzFGWGFzSjh3eVhha1d6MFlZcXhpaUpENStUN2Iwb1pJSkdMc1VzSmtIUDRp?= =?utf-8?B?b2RxbnVVVWpKUUNSZi9wQmJ2azJ5TnN3MkxhaXhIbDZZY0M4ZFJRK0dvRFJJ?= =?utf-8?B?dzRmNmQ2amswS0NIL1V5OHBvRXNWaEY3dHFqUm9NQWsvay9Nb3BNaHRreDFl?= =?utf-8?B?YTljYnJVcVF3M0k3WkpZQ3VjTGlmT0x5UnF6ajNNQVg3UEU4MzBhc2p2cDl6?= =?utf-8?B?a0svMjdYV0hrbXE3TTRCRGRYcUp0MVgxVlpaTEx6RFFsczFEYnNra1BnbHRI?= =?utf-8?B?MVFULzE0Z2hQZVh2WHFjWExxcGdQcG5TM2V1eUEyWDhadVlxNlpraGJLUC8y?= =?utf-8?B?OXJVenlqM0dXUkRYci9LcHQ5T0MvZE9UenVnUTFmNnRFQkdUOWduQitabVFu?= =?utf-8?B?NGZ6cUFEeHAxNUNXdGdLQk9NdUpmRUdFMWUxb1JXQVZhQVUwOGdCNXp6cFJ1?= =?utf-8?B?SG0waWRSVndqMVpQc20xWjg0N0YxQ0htZThaaDJmUVgrZzE0Q0M5NlJHWEt0?= =?utf-8?B?L3diRmdMM0ZCMWRRNkQwVEhRNlN3S1dTSkdYN1drMmlEcVE4L2J3NC9BZ1dI?= =?utf-8?B?bVo1Znd6eHZkam9YYkNoZXdaejFxb3BXa2NGanBEcTZNU1NsV2Y2YWhkcUZa?= =?utf-8?B?RUYzOTNteE51NGJqb3FYWDNSdnNpRzlaNllmdlV5dEt3NEEwek9WOUFkWnlh?= =?utf-8?B?Qi91cC9Eby9uWjJYRVN1WGxpVWVpMU43VnJSZURoOVdIem03WlVlTkVjdGh3?= =?utf-8?B?cU9VYWZRN1BuQmFvS3BFRzhzbTdwUE5ELzBWYkM0eXdiT1Y5blh5KzgzVktk?= =?utf-8?B?WXRsK0RrUFhSRkNlaHRMOHRlZENTSXp3SUM5THRRekh2b3JSRU14eXdqN3lJ?= =?utf-8?B?WVRJRkhMWDBkbW1GL1VHZWpxMEx1RXdPRXZNbXlqZGNJLzZOOEhtOUN0dmhE?= =?utf-8?B?VXRmNEFlbmVYV0NERjRxbVRFQjJmZXJWTlJDRVFLL0c3V3V1WitpK0tlall1?= =?utf-8?B?Q0tNTGdOZFZWUGU4czBDbzAwVDQxN1g1R3h3RzFTL2tKbkw5K1U4L3lpYWtB?= =?utf-8?B?NUJlTU9DMlR0WmUvU29zdHNhd3dJK0JVMXNCSzJMVi9hWVdZTDFJcFhOWHFO?= =?utf-8?B?bFI2NXYvc1hSMHJtU1plOCtiUGN3a2lCbElCZ2pyRlF0aGw5ZjZDZWxiZzhZ?= =?utf-8?B?VzIyajM1aVhXQ3hUZXRxT3BLZXh6OTBqZ1M1bklxRHNlMCsxdW9EUTVjTm1K?= =?utf-8?B?Nk5oWHdXekpXY3VsVkxDelRLK2draG1UMjY4c2FrU1JobXNQLzJFcUJXMHov?= =?utf-8?B?Y2RVbHJiWEpCVkRiaFhkTzgrb29FbjZoRk9qclRSNk1DekRqYnZ0clRZb2pR?= =?utf-8?B?Znc1dng4N014ZnZka2k1dHltYmtjMmx2VUpiZHhZZlVYMkVrN1Y4Mm44MC93?= =?utf-8?B?b1JpS0wzK2lNeTJqcTcvYXhsZCtnb2VESm80OGJETDlHZ1pYeVFOZ0xKc3hC?= =?utf-8?B?NVZDWkVDdkFKNFFnWGhaT2RUamJSaElhS1NNd2UrelBoTnU4a21Rb3hvcGtK?= =?utf-8?B?cGJmSXBiUDhCTVNMajlXNTJvZTRsS1ZzdUoyNXl5dWYwQXdiN09EWlVqdTBk?= =?utf-8?B?V1l1TUJRb0ZGV1J6eHpHS1FuWmpBPT0=?= X-OriginatorOrg: auckland.ac.nz X-MS-Exchange-CrossTenant-Network-Message-Id: 4aea2db5-6336-4432-70a8-08db3e48c199 X-MS-Exchange-CrossTenant-AuthSource: SY4PR01MB6979.ausprd01.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 16 Apr 2023 07:04:01.0505 (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: 4JgjLhcT5emuUVRXtJkih1PDCJwv6R4EXAgJAVWmPHTIe1sgLbF2RscMUXNcb6WFbHTEQDm4D9wF29QaoEFTgottVgCjkLtxSuSY5H3QgD0= X-MS-Exchange-Transport-CrossTenantHeadersStamped: SYBPR01MB5758 X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: auckland.ac.nz Content-Type: multipart/alternative; boundary="------------42s0JVsKfTNbPFJdWFwqkxjL" 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 07:04:08 -0000 --------------42s0JVsKfTNbPFJdWFwqkxjL Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: quoted-printable 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 traffic)=20 work by redirecting HTTP(S) requests for content to a CDN server that's=20 in closer topological (and, by inference, physical) proximity to your=20 web browser. That keeps repeated requests for the same content off=20 expensive and scarce long-distance bandwidth while allowing for fast TCP=20 cwnd growth due to the low RTT in the branch- and (thus collectively)=20 bandwidth-rich local ISP networks. But that doesn't work for Starlink:=20 There's no way to prevent everyone watching the same cat video via=20 Starlink in your area from having to take up scarce space segment=20 bandwidth each time the video is viewed. And we're talking serious data=20 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 a=20 lot of storage capacity on each satellite in space, with a much reduced=20 probability of a cache hit, since the fact that the satellites move=20 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, and=20 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 th= e > > > >> original distributed database... > > > > > > > > As others have pointed out a "root server" may not be very=20 > advantages, > > > > but what I think would be far better is to put up a couple of=20 > anycast > > > > recursive caching resolvers, aka 8.8.8.8/8.8.4.4=20 > =20 > and almost anyone > > > > can do that, including starlink itself. > > > > > > I believe that the root servers are all (or almost all) anycast=20 > 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=20 > =20 > would > be far more useful than just a stock "root server." > > > -- > > AMA March 31:=20 > https://www.broadband.io/c/broadband-grant-events/dave-taht=20 > > > 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 > --=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/ **************************************************************** --------------42s0JVsKfTNbPFJdWFwqkxjL Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

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:
=20 > 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" m= ay 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 anyon= e
> > > 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/b= roadband-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/
****************************************************************
--------------42s0JVsKfTNbPFJdWFwqkxjL--