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 213EF3B2A4 for ; Sun, 16 Apr 2023 23:21:58 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=auckland.ac.nz; s=mimecast20200506; t=1681701716; 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=deGRmHKEtvmsbven0aDoJivvZlYbP8pq9uOOGGgj+dc=; b=BzvtdrXTapQIaDU6gAP6Qb1U0nlnuN6PiONRcJfCgoGdcYBe3hOeu2rg4qpG9ppXv6dd0U TZ0na5QUqu1jGQBR5Scpd+S64OuUUGhRdanjyDGxYkezIHg1IHgusj1Lmw79k2khbELC0t 5Vfjf1vRJKTaprJUMy/tXa0ko64jhQk= Received: from AUS01-ME3-obe.outbound.protection.outlook.com (mail-me3aus01lp2241.outbound.protection.outlook.com [104.47.71.241]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id au-mta-54-qvQlWIAWMXOMjL-r9klnZw-1; Mon, 17 Apr 2023 13:21:55 +1000 X-MC-Unique: qvQlWIAWMXOMjL-r9klnZw-1 Received: from SY4PR01MB6979.ausprd01.prod.outlook.com (2603:10c6:10:142::13) by SYZPR01MB7587.ausprd01.prod.outlook.com (2603:10c6:10:16c::24) 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 03:21:53 +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 03:21:53 +0000 Message-ID: Date: Mon, 17 Apr 2023 15:21:52 +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> <5e2937ec-9d94-29ed-eac1-18d96db3a19e@auckland.ac.nz> <2sp7r191-q0o6-6543-0q78-p760477317o5@ynat.uz> From: Ulrich Speidel In-Reply-To: <2sp7r191-q0o6-6543-0q78-p760477317o5@ynat.uz> X-ClientProxiedBy: SY6PR01CA0107.ausprd01.prod.outlook.com (2603:10c6:10:111::22) To SY4PR01MB6979.ausprd01.prod.outlook.com (2603:10c6:10:142::13) MIME-Version: 1.0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: SY4PR01MB6979:EE_|SYZPR01MB7587:EE_ X-MS-Office365-Filtering-Correlation-Id: 9fead023-4149-4d0a-72a9-08db3ef2e448 X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0 X-Microsoft-Antispam-Message-Info: 18XKgDk+b/cnBfDMEg8MbKaHmcPRJ6Vxyn4sfUybuT0P8AwGW/PzAKjtrAPW2yDG8MBJpjHbJFjQUthGpVGb2cYLfSVwt+SuMKyOOkF0S9+DCg+ROx1SRXzKdyWzBxVOdMF3ahrJ3esvFRexs/eKkB6KskL0TMOc1lA4L9utIp+b4y4IF9/abRzjlqtlMSpHCU793ir2dRfElN/eR3+4z1ccO3y1zMAwJFESmJKl8pBAgqfC0Wue90YLsSrh8YH5Oop06zmwzx0XhnRwffhVgXmti/gNhhCXSKXS2DVjPpDPywKg0D0CQ8jvk9PhbQl2LNuGCxTQ96xDZ3pgLKXdFR9aL8h1MVK8fOQtZK2YcmjE4Uul3b20OXVGH2Py7x+acUrNO/aNrPVsWjkaPrfXUZJkRR1e4JA1lH1+mdewbq/28LKkUCVFknYE7RO0LfOGnoyADb1+5mbVuarAdNDd9xvS3F7l+ass+48M6qzPCB3rW/CmGM8ljycUgzJMmpNxB1r6OGoE3rIesDS4ak7aUEDmtZhkZ64B1a2g2UpQhEhKHZLy7Dj5jHbRvH8il85Is8p5daF5uFx0V59WNM2VcAryQsbcW82faAwWgPPjT97NetuY/uCh/wCYozks25hIBx5HjDLNR8qj7LnEZ6XEVQ== 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)(346002)(396003)(39860400002)(366004)(451199021)(6916009)(66476007)(66556008)(4326008)(66946007)(2906002)(66899021)(31686004)(2616005)(5660300002)(86362001)(8936002)(316002)(786003)(41300700001)(36756003)(478600001)(6486002)(186003)(53546011)(6506007)(6512007)(31696002)(966005)(83380400001)(8676002)(38100700002)(45980500001)(43740500002); DIR:OUT; SFP:1101 X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?utf-8?B?ZzVlcW4wK1AzeW9CNW44M3RPeC8zOElsUkdyc0FMWHp1NDBJSEprMmJrNWw2?= =?utf-8?B?VFYvYmg4RW4zOXFOOGhibGxXVXFjbjhGYWRBSm9XK0twU1RINWxPMFZUQThk?= =?utf-8?B?MVZhWUJVRW9tazdQdENxc2gvWnVqa0gwcHdFVHFSRDVybmV5dTBuQ1M3QXhr?= =?utf-8?B?RXZBUVRsZDN5N3R1TmIxdklxWFhnRVBhT3M0OTNoVGVZWStwbUc3OW1Wc1NJ?= =?utf-8?B?dVQvVnhNdUhTNnl1YUh6UzlzR1RkOE9BdU95dEtZa2luTm5ET2kzTXNjU21q?= =?utf-8?B?TzBXRFFINlppaWZsYngzTGJJTStDOG9FRmFBMmtsQnpVeFVFTjRCNzE0b0or?= =?utf-8?B?eWZLRlVzZmM1SWYzRE9UOHF2NFJaeHllN1BqaHBZUWNHVXBmbFlvOHpYN29j?= =?utf-8?B?Z1c2R2w5MTdJS0NNQU1NbWk1R3pGUTJSeDBrRHdaR0dtSmpVSHE0bitBSmp1?= =?utf-8?B?YlZxYjRpek01OHYrLzltWHZUMGZHL3hMWXpIR3lLVitQNlhwVDIza2NlT2Rz?= =?utf-8?B?NDBJK1RxNU8wWmo5cjJSWmN1dXQ1S0FaMXFGK2tza290a0R5U2lKNFVmY01F?= =?utf-8?B?Nk9wc1NXaVpGT0dyYzQzODFFK01ueUhWT0I5RlJkQzVjbm9oTTlCdHRWdnpT?= =?utf-8?B?dFlRck9FaUNJcFNDcmliOEhjY254SWJMak1wZVYyQWhwcGw3N2phK0Fjc0cy?= =?utf-8?B?RFdZazBLQU5tcXh2bGZZalZZQXZ6eE5yOHN6MmVmSXljUEJuVUJUK24yQXhN?= =?utf-8?B?MERoOVZJZnZtOC9HdE5zZVoxMmhSN0F4T0pqTXNQeXdTTTFnMDMvSUx2T0pY?= =?utf-8?B?emdiblo0Tm5PcEtmWjFoVzVQaTlOTnhYdXVscUxFRkoyOTlBaG1jUWxLZzAz?= =?utf-8?B?OGk5UnpQTjdDZ05BeVR6S011RHJhNGhzdHdsSUdIQWdaV2IrOGh1OXByY3Zs?= =?utf-8?B?cUpoZnEvbEdPeHhTalJnRkN2SUt3c1Z3cUVDSmxERjFaRUFYak45VUhOVDRw?= =?utf-8?B?RjlNZ2VMeDBlZ2d4dmxCZUhKV3Q2VHU2U3plM0d0bFFkOU9VazZsZEtkM1g4?= =?utf-8?B?ekt5eW12czdrMHJoR2pwU0lKL081MzZyNUFNeXJ0YjYxNWdJME4reUQ5VnVQ?= =?utf-8?B?NEFFTUM0cnBjT0hkazZHUGM0aG1BZEU3OFc2VGVXK3N0LzVmQkliTU5lbmNm?= =?utf-8?B?YWc4V3FPVUg0a0RnY1hjc0IwT2Mrc1BvTDVzZExBRXhFQXYvN053eFFZbUp3?= =?utf-8?B?N0g1MWduZDRIU3JmcURBSHJRUDlBYTJNVWZLUTZoYlhEVUhVd0drektNUExa?= =?utf-8?B?emdXekhVYnlKK3NlNTFxQStMdXlISStaNkdSdWN6czh5eUR5ODVIODFueGVp?= =?utf-8?B?ZTBwS1JWcy9icjR4RlpGV1VxT21zelhzM3RpWEU2OXhkRFRKOFdXV2lXSEZz?= =?utf-8?B?UHpLVHU5blFCM25MQTdNek9rbEVQTFEzOXM5dFpkcXA4NVNibXExR3V4cDRP?= =?utf-8?B?NDZDTk1EY0lnejl2bnZlTkFPT1hpcTRMeDJoOUxjSXgzYzhQQ2pEek5sbGcv?= =?utf-8?B?MUU3RnAwa3k1aGxuWGR2S1YwTllZZ3FORXJpc2JPdEw1azFySVlTRUNDRjRh?= =?utf-8?B?K0F1SEJjVWVYV21jekxrd2pNSXUxaWVmZTBrY3BwRlZnUVhiZ0dQb3hoWHEx?= =?utf-8?B?b052WW85cGFmQkpyMFdORnM3dHQ1cnpzeEVvWFN2T25LUHI5cnIzSTF0UnJ6?= =?utf-8?B?K1dac1BWQmwxMkVrMnNqUnp2QkVZdVJUZmYxVklMYW53ekhxRG5mM1U5Wm9n?= =?utf-8?B?UVBYandOdi9ibm9xOFZTNUxTeklRMjF4eDZQNDFwclJxN1JaV0hmcndCYm9W?= =?utf-8?B?SGxvOWQyNXhtUXhnMHN1MWM2VWh2NGZvOEZoc25hMEJGMnBnaDhlZEE2c0Vo?= =?utf-8?B?MjA1TDJMdVcrQ3I0bUUvbTVTdW95OUw5WEdOcGJHam9BMUtYNU96UkM0NTha?= =?utf-8?B?bjh0TVYrZlVMQUREcDNVMFo1NWU0OWIyRnZWZ3R2RkhxSE1oUFJKQlVHWUNV?= =?utf-8?B?VCtaNUw2TDd0OE5vNm1DYkl4TmdMQlFzMnVoTGVZTUMyTmcwektsYXRKVXMx?= =?utf-8?B?RklRekRzL3kxUXJEbWpjditkakxLbmVYbUNnZ2puUEQ2RjNaN0V4eFFlT1RD?= =?utf-8?B?WDlvUG1uWk1sbllLU005QllsV1JjUFBOS1d2U3ZVcXpFRXJIR2Q2bXhTdEls?= =?utf-8?B?bUgvUXNXSW1EYlgrMFUvSUxIMlR3PT0=?= X-OriginatorOrg: auckland.ac.nz X-MS-Exchange-CrossTenant-Network-Message-Id: 9fead023-4149-4d0a-72a9-08db3ef2e448 X-MS-Exchange-CrossTenant-AuthSource: SY4PR01MB6979.ausprd01.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 17 Apr 2023 03:21:53.7106 (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: 2pbecTQrVS0uD26UmLVlk3SFh/XzUi5vltxPOyNu8Ge4JHLk/r1p5mnz4Wp+ksTfWopE+8/2t52hmBb0iB61bJphZ95xbOhruZ9Mc7OnMO4= X-MS-Exchange-Transport-CrossTenantHeadersStamped: SYZPR01MB7587 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 03:21:59 -0000 On 17/04/2023 2:34 pm, David Lang wrote: > On Mon, 17 Apr 2023, Ulrich Speidel wrote: > >> 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=20 >>> is that you don't have to risk much to try it. Long lived DNS=20 >>> answers (and especially root servers and TLD servers) can trivially=20 >>> be mirrored to the satellites, and you can experiment with caching=20 >>> to see what sort of hit rate you get. Even if you don't cache a lot=20 >>> of the CDN type traffic, it should still be a win to have the longer=20 >>> term 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=20 >> TLD 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.,=20 >> your satellite-based DNS would have to point you at the TLD server=20 >> that is topologically closest to your Starlink gateway, or risk a=20 >> potentially much longer RTT for the lookup. So you'd need to maintain=20 >> a list of TLD instances on your satellite-based DNS and return the=20 >> one that corresponds to what your gateway-based DNS would get. Sure=20 >> possible but more complex than a bog standard DNS server in a fixed=20 >> network. > > really? I don't think the root and TLD servers do any geolocation, I=20 > think they have fixed answers and rely on anycast addresses to find=20 > the closest one. Adding those anycast addresses to the satellites=20 > would be transpoarent to all users (assuming the satellites are=20 > operating at the IP layer, the old bent-pipe approach did not, but=20 > once you have routing in space via the laser links...) So what you're suggesting would be a generic anycast-based set of DNS=20 records to be kept on all satellites? Hm. My terrestrial RTT to the closest 8.8.8.8 and 8.8.4.4 anycast DNS=20 servers is about 28 ms, indicating that they're over in Australia. No=20 big surprise here, but that RTT isn't all too different from what I'd=20 expect from a Starlink connection. That compares to < 1 ms to my local=20 resolver. Would an anycast-based generic DNS give us better RTT than a=20 gateway-based DNS with full ability to cache local information? Even with the laser links, it's worth repeating that most of Starlink's=20 operation is still bent pipe, and likely to continue to be so in future.=20 There is little evidence that the lasers are currently being used for=20 anything but remote location access. That said, bent pipe isn't the same as bent pipe. Analog telecom GEO=20 sats used to do physical layer bent pipe with the satellite incapable of=20 IP. If you have a satellite capable of IP, you can still call it a bent=20 pipe as long as it downlinks traffic that has come in on the uplink. You=20 could even run an IP-based tunnel between dishy and gateway that makes=20 it appear like a single link for the next network layer up the stack.=20 And do the same for lasers. There'd be a number of advantages in this. > >>>> Practically speaking, we know from various sources that each=20 >>>> Starlink satellite provides - ballpark - a couple of dozen Gb/s in=20 >>>> capacity, and that active users on a "busy" satellite see a couple=20 >>>> of dozen Mb/s of that. "Busy" means most active users, and so we=20 >>>> can conclude that the number of users per satellite who use any=20 >>>> site is at most around 1000. The subset of users navigating to new=20 >>>> sites among them is probably in the low 100's at best. If we're=20 >>>> excluding new sites that aren't dynamic, we're probably down to a=20 >>>> couple of dozen new static sites being queried per satellite pass.=20 >>>> How many of these queries will be duplicates? Not a lot. If we're=20 >>>> including sites that are dynamic, we're still not getting a huge=20 >>>> probability of cache 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... > > even users who are using the connection aren't going to be using=20 > dozens of MB of bandwidth. Yes - but that should reflect as a lower level of DNS usage in most=20 cases, shouldn't it? > >>>>> 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=20 >>>>> big deal. The dynamic data expires fast enough (and can be=20 >>>>> detected as being dynamic and expired faster in the satellite)=20 >>>>> that I'm not worried about serving data from one side of the world=20 >>>>> to the other. >>>> Yes, but the only advantage we'd get here is faster resolution for=20 >>>> a 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? > > possibly. it's worth discussing and DNS is an easy thing to start with=20 > compared to most others. > > David Lang > --=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/ ****************************************************************