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.21.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 978D23B2A4 for ; Sun, 16 Apr 2023 22:08:51 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=auckland.ac.nz; s=mimecast20200506; t=1681697329; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=RzogS47vWYNvKfbGe0SoVfMuXyojUEdLFnQjYMVBBDA=; b=fSnlLvAZH2WNwhwvVgPau5kipYVEMxG3C1S1CyUF/pFtqLHROcFijg5HUIO7Zn4j4rsPnh YoSp9Bhw4pAxDRVR5zvpj8MhJEN3cb+5h6R5K8pfdYzDqTeatydk0YszVZbUfpStUiKIAO BAgrRmp8RmCP2Sy/p8qMz5vBw/s+W3s= Received: from AUS01-ME3-obe.outbound.protection.outlook.com (mail-me3aus01lp2234.outbound.protection.outlook.com [104.47.71.234]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id au-mta-57-G-KzDw1sMTOhTJ74r_hcvQ-1; Mon, 17 Apr 2023 12:08:48 +1000 X-MC-Unique: G-KzDw1sMTOhTJ74r_hcvQ-1 Received: from SY4PR01MB6979.ausprd01.prod.outlook.com (2603:10c6:10:142::13) by SYBPR01MB6763.ausprd01.prod.outlook.com (2603:10c6:10:12e::11) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.6298.45; Mon, 17 Apr 2023 02:08:45 +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; Mon, 17 Apr 2023 02:08:45 +0000 Message-ID: <5e2937ec-9d94-29ed-eac1-18d96db3a19e@auckland.ac.nz> Date: Mon, 17 Apr 2023 14:08:44 +1200 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:102.0) Gecko/20100101 Thunderbird/102.10.0 To: David Lang Cc: starlink@lists.bufferbloat.net References: <83qps6or-4574-n64r-6r95-71sp695q58p4@ynat.uz> <79dbfe96-b5d5-3475-8da9-a32c2f4d53b7@auckland.ac.nz> From: Ulrich Speidel In-Reply-To: X-ClientProxiedBy: SY5P282CA0057.AUSP282.PROD.OUTLOOK.COM (2603:10c6:10:20a::9) To SY4PR01MB6979.ausprd01.prod.outlook.com (2603:10c6:10:142::13) MIME-Version: 1.0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: SY4PR01MB6979:EE_|SYBPR01MB6763:EE_ X-MS-Office365-Filtering-Correlation-Id: b077e761-b5d1-4119-addf-08db3ee8acd4 X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0 X-Microsoft-Antispam-Message-Info: ojv52xVkdpaWjIIv+RaTPI7INGIAsHvFXAvGJiPSnDeWiG5nEAIqbwJ+RwUlMmYROw/PrMuvSpWEo133r0I7WKcGgOof16dxLH07PYdpmVqcW/mqIKbPMcBOexTY9GvUnDxUuIvYYqT+oWOgc0u94utjCvinkUFjIVgwTfLpw9kVKjdruHszW2vdCeHfzQst3VENh97XF+1v7NFTC6VO09r7uzFxHl9uKpaCZ3ZkyrNr591PdGCzgNnskO46yRu91FIjio1ebFjTM3LYJb/hqaCL8Ahu4WwsT7ddMrdaJ1zrrfimb8I9MAKu2ZqrmoDx32gCsKEvu6WcSP9s8mssk9G2YpzhZnwW11SXc6QS5ZJLqzzSrpBlSnu1m+CuLJI7CM/Y5bSzqTxU/q0isO9bRjEieGOYtYPAdfze2gfOhQXSINVW+nYDYzweuYWowYOmNfqJjOlYWCI9VXDRSfYvooK7dMDbYriDTGSskKLfI0gnhc2IhXPbU3ALH9xcthr8mfjVvmVP/TxyWbYI0HAgnwejpeV+Z5W36iicRAcqgr3toLNkIvbn5NZ+WrM1aSuzO7Jds57ys9d01U/mQpaPbQQZz7MYfXqNmeX/fWIv37qZRZ2mlCnIcqgrItAb/2gwdj9DCkloZBzROIOWhG6oLA== 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)(136003)(366004)(346002)(376002)(396003)(39860400002)(451199021)(66899021)(38100700002)(8676002)(8936002)(5660300002)(2906002)(36756003)(86362001)(31696002)(478600001)(6486002)(31686004)(186003)(2616005)(966005)(6512007)(6506007)(53546011)(66476007)(66946007)(786003)(316002)(41300700001)(83380400001)(6916009)(4326008)(66556008)(43740500002)(45980500001); DIR:OUT; SFP:1101 X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?utf-8?B?L25nU3p4WlQ3NzFzb1pNTVFrUmtMVnZTZXNDT3Z4RWNwWktkMTBmWFhabXpF?= =?utf-8?B?MEpGTklQc2tWKzJLSVRTU0NPdXlvRk9lb2NNazNRWThqWUlBMlI3UnhiMEl1?= =?utf-8?B?WGYwbUI2N09neklwUGFCby9naTJjL3hLUnczZ1RPdWpSQXpTeW45VXBELzh4?= =?utf-8?B?R2tVYjVOUVp5TU92ekx4dW81TC84Mk5HUTZ4YXlqcHFWb0NWT3JFeGUvdE9u?= =?utf-8?B?RzFKRVZtRklEVmtpYTlFS2dRTk4yakxSMXZ3dDByQXk1akhYL1B3cytyY0Nh?= =?utf-8?B?Rm9EeVF4MHBHb0hoTW9WMGpSUHFoQk9SeXR4NDU2QVE2WlFkZzlWUHlncVVu?= =?utf-8?B?Rk5OZ24wTFgzYk5jbWdrSlo2YUJ6aTFnNGYzT3J0empDQXhYeERSQW9EL2lW?= =?utf-8?B?eW0rNS92azEyRzd3KzlYQlZIaGlzYnJTWGYzc1I1bm9qWUhtTEtSUDZ1RzdM?= =?utf-8?B?djhOaGZTaTZxT0Vod3hhUnJsYW50bXdlWUpNR1lNQWlhYTcrS0pVMnd6aFFW?= =?utf-8?B?WDQyUmtDR3RXamVjVzNQU3hZdmFUMUZldmhNWWNtQzFFeHRyUmJBRHZHL1Ix?= =?utf-8?B?TjdtMFdkM2RocHV1Y2VOTWNubmpBcGt6RXhka2J4T00velJCcEN6b1BObWNy?= =?utf-8?B?VjN2UzNEL1EzT25wcTBOdXllTXhiMWxxclM4RDVpbGNsNXJwaUN3UUN4U3Vi?= =?utf-8?B?dlQ1ZHlYU0pWWGVHenh1anFmWjBFcmZzM2gyRllXOEQyTXBjaUV6ak9DU0F4?= =?utf-8?B?K2xRTGpob05PcndreE94RUQ0MTNaTUFXMkRqTFk2WXR1eEZHeko5YzNLbmI0?= =?utf-8?B?aFF3dmV0KzlRRjA0by9vMk9MZFV1TkhlTW5xUWRrUUlxeGZ1ZGM3V3BoSTdh?= =?utf-8?B?MklmOGFvOW1EaWJ6TXVXMVdsbXN2bHhvYTZwSFl3ZG51RkJGZGU0RnpBR3lp?= =?utf-8?B?TzB2M1NjQk9VUU93YWFZN0VzNXlLTTd3T0NEbDRlVDQ5eGFBOVFISjRic3I2?= =?utf-8?B?YmNUY2thdG1hY3BnRGdHU3VRTmF4eXZxQkQ5elNmN0x0aGxIZGVBUW5zejdU?= =?utf-8?B?NW5iZitOZkNsbWZQZm5uK1M2K2hUb01yWGloQ0h2M1R3eGh5Y3YrZnFqRC9S?= =?utf-8?B?RS9xRTM0S1JnRm9vZ2hTRlI5ODdYQmEzc0IwMG9Jbnd5RnVwVnphZHArd0JZ?= =?utf-8?B?bHlkYjhiSjBTcWhRSFVIQmN1WjArQXRSWWF0d25yVkdtbE9memhHc2FHaEp2?= =?utf-8?B?U2lBWWt1VjdXWXZvZFZNaHg4d25saEpKelhLeXF4SVdQMDkvRzFFbHM1R1dk?= =?utf-8?B?S2R2SlV6NFlUQ3RsbHc2RFJEYnQxRG1waERvMkNZMjJhVlZZNEVZU1lOTms5?= =?utf-8?B?WjJ6YUNBdUU0T3pKaExuMW5LUDNiUDRLOG42RTFVb0plSm9HemNVOWpvVGtl?= =?utf-8?B?aGxLYk5haGdtOHpHUUdSR1Z4ZEJHMHlLQk01c3p4c3BWbWpWNVlTd21OV3FX?= =?utf-8?B?Qit2dFl1cEFoUGd3ZE1sQktkeUp0TnZENm5oTFFQMzNoQkhoTVRXZGtXbVZT?= =?utf-8?B?N0gxZHg5VmswMEU4aFdpTGE0WmZ4RjV6RnRsMUVkNTVWVWs0QkVpa3hKRDEy?= =?utf-8?B?NU1YcEpwZVc0SWxPeGxQMm5yYlJFSzVlTlFTcHRWdjJESHM0MFBvVExIUGFo?= =?utf-8?B?OURoQTcyODNtVHRZTzJoVzFHNnRuVThlcmtrYWdKbWZWVEUrTklSVmY2SU4z?= =?utf-8?B?cWxXdG9KbDh2UUtmaVFmK0dZRS9qSWJWTkt3L2pLZWlyZThIOERpSkZKQWR4?= =?utf-8?B?dkhmZFFUZGgvbTBONkdNSDBnazFhZjRFNGphTURRcjIzZEVsWGQrbE9SdFZ2?= =?utf-8?B?emNTcGJkWXRCT0R1a2xxaWhPTlRsUzFjdEVkS09ucW5HM0RvcjNOU21iQVZx?= =?utf-8?B?bDdETkVBSitaYWY1MXF0MjhKZFJmRnV0QkJYanoya3l0aHJpREdDa25uSlds?= =?utf-8?B?UWFmVElMNjZ6L3U1b0dzV3VSbkJCSnNCWlhYaU9qeWQ2V1ViUHZOVHY3R05U?= =?utf-8?B?YUZpYnRqTHlmYmcwUytTcGZwYWRjVEIzc09wTzJYUUUwZk13VmdMdGZQS1Qx?= =?utf-8?B?bmtOUjd5UURpa3ZOdTJJUnVXTTVOWEdIbU1HRzVHNm8yZFZpdXlFM3BERkJw?= =?utf-8?B?OVFMSzVQYTE3ZmQzYU1nRkVmR2pqeitHK0xYQWJWbWk0dEMvdjhHaFRHRWFZ?= =?utf-8?B?N1NiNWxlQSs1YVFUVncyOGxIWE1nPT0=?= X-OriginatorOrg: auckland.ac.nz X-MS-Exchange-CrossTenant-Network-Message-Id: b077e761-b5d1-4119-addf-08db3ee8acd4 X-MS-Exchange-CrossTenant-AuthSource: SY4PR01MB6979.ausprd01.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 17 Apr 2023 02:08:45.8031 (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: l8vwFXpUVwZkwuyRUJ8hIaJ1tbmQlh5S59KL8gA5IfqqmjEYCl8qmTu+Pf0ui9Luexma8njZxxcBZVTxcNxYGQjvOMWppvsOcnnd8jK5sBk= X-MS-Exchange-Transport-CrossTenantHeadersStamped: SYBPR01MB6763 X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: auckland.ac.nz Content-Language: en-US Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: quoted-printable 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: Mon, 17 Apr 2023 02:08:52 -0000 On 17/04/2023 1:04 pm, David Lang wrote: > I think it is going to be fairly common, but the beauty of the idea is=20 > that you don't have to risk much to try it. Long lived DNS answers=20 > (and especially root servers and TLD servers) can trivially be=20 > mirrored to the satellites, and you can experiment with caching to see=20 > what sort of hit rate you get. Even if you don't cache a lot of the=20 > CDN type traffic, it should still be a win to have the longer term=20 > stuff there. Yes - but root servers and TLD servers also get cached a long time at=20 the clients. If each of your clients needs a root server and a few TLD=20 lookups a day, it's not a huge gain in terms of performance. It is however a significant step up in terms of complexity. E.g., your=20 satellite-based DNS would have to point you at the TLD server that is=20 topologically closest to your Starlink gateway, or risk a potentially=20 much longer RTT for the lookup. So you'd need to maintain a list of TLD=20 instances on your satellite-based DNS and return the one that=20 corresponds to what your gateway-based DNS would get. Sure possible but=20 more complex than a bog standard DNS server in a fixed network. > >> Practically speaking, we know from various sources that each Starlink=20 >> satellite provides - ballpark - a couple of dozen Gb/s in capacity,=20 >> and that active users on a "busy" satellite see a couple of dozen=20 >> Mb/s of that. "Busy" means most active users, and so we can conclude=20 >> that the number of users per satellite who use any site is at most=20 >> around 1000. The subset of users navigating to new sites among them=20 >> is probably in the low 100's at best. If we're excluding new sites=20 >> that aren't dynamic, we're probably down to a couple of dozen new=20 >> static sites being queried per satellite pass. How many of these=20 >> queries will be duplicates? Not a lot. If we're including sites that=20 >> are dynamic, we're still not getting a huge probability of cache=20 >> entry re-use. > > I think that each user is typically going to use a lot less than the=20 > 'couple dozen MB' that is the limits that we see, so the number of=20 > users in a cell would be much higher. Yes, but these users aren't "active" in the sense that they will be=20 firing off DNS queries during the pass... > >>> DNS data is not that large, getting enough storage into the=20 >>> satellites to serve 90% of the non-dynamic data should not be a big=20 >>> deal. The dynamic data expires fast enough (and can be detected as=20 >>> being dynamic and expired faster in the satellite) that I'm not=20 >>> worried about serving data from one side of the world to the other. >> Yes, but the only advantage we'd get here is faster resolution for a=20 >> very small subset of DNS queries. > > and while that's not as big a win as faster resolution of a larger=20 > set, it's still a win. Yes, but are we chasing diminishing margins here when there are much=20 bigger fish to fry? > > There are various things that could be done if there is enough=20 > interest in starlink users to improve the CDN traffic, and it's not=20 > clear that misdirecting starlink users in some (or even many) cases=20 > would be that horrible. Geolocation is very imprecise at best and=20 > routinely misidentifies locations. See my comments on geolocation in my response to David Reed's post - I=20 shouldn't have used that term. --=20 **************************************************************** 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/ ****************************************************************