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 B71E03B2A4 for ; Sun, 16 Apr 2023 17:23:02 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=auckland.ac.nz; s=mimecast20200506; t=1681680180; 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=pbVYMxW6O2Vl8Gr1JEX3PemIubMzojUg2GebGoYOt2c=; b=qtDpt6Y0DkClasRvRVntl3/eDR+LbjRyZkhBRcFjMsNZcw3tcrQPYB1wUUx5JOWzcfLbAw pkGEExi2iZy484w3yDl/4tpkznoLgtYvKwgMVIm2Ddh5v/xiYVzWMp9nYqRrdr50mnHjsh 0wRbnaYXledoR256Dnot+NRwiF0QHsA= 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-74-vD1ZDtdsPNSebEVnY2JbOw-1; Mon, 17 Apr 2023 07:22:58 +1000 X-MC-Unique: vD1ZDtdsPNSebEVnY2JbOw-1 Received: from SY4PR01MB6979.ausprd01.prod.outlook.com (2603:10c6:10:142::13) by SYBPR01MB6906.ausprd01.prod.outlook.com (2603:10c6:10:149::7) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.6298.45; Sun, 16 Apr 2023 21:22:56 +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 21:22:56 +0000 Message-ID: Date: Mon, 17 Apr 2023 09:22:51 +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: From: Ulrich Speidel In-Reply-To: X-ClientProxiedBy: SYBPR01CA0192.ausprd01.prod.outlook.com (2603:10c6:10:52::36) To SY4PR01MB6979.ausprd01.prod.outlook.com (2603:10c6:10:142::13) MIME-Version: 1.0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: SY4PR01MB6979:EE_|SYBPR01MB6906:EE_ X-MS-Office365-Filtering-Correlation-Id: 5ac2a122-5e48-4264-a839-08db3ec0bef7 X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0 X-Microsoft-Antispam-Message-Info: jw+KMvAZ74eyxtvQGpASWOHxKNSf5Rx1NlIbtD+nw2rbLixxSBfANfsbBRmJx5zLjW0/90K5YuVB+lbSphNNI/LPRekQn3bhDcU3i0zjhP77Xlue8/O3c9kfTN3ZyucCh1Lcu6KgV4Fkl1CxZZCoz2BZgX+JQeH9ufrCfxHZDt8BaQ290+nf+XLQxTxphutY08lYbfXbcuVcjQGx8rknJMpx1Ymv6Vp+QUPEFiJ4eU8gDh57t7h9DLe4XbMWrRsYm20yOUI8NZyaFEH64042dT53JGhvaqxTv+UCcJykdqAklIueS/RDU9/Ig4fkMGeaeauYtsU7RDTzCWUfWp3HVp/csvuiBtV7xEBicV2367ZR8h8i31V9V5pzUs5aa+0GNUsfYosHhDxmVLmJls+x5pcmbPft9kgpKf0dumTn+ihoVUGV1OR8KhhDM/hbO30CYGybKvceqfC2b/fmU+LeG+r42XgTRelXaet2tdcy021raQP1ZWN8sKwR9LcTAedyTMQxqpASp25fT7j77ARcH6wP7ec54uM8NSpm2LeX6g+GIQpjmtaJ8YDcrU1jwSO/lAn3aN5UZjGPcdAz5aMVdwZkKRgaPiSgqEmqho9xS9ct3QJY6g73SLxmRjc2vKQ3j2kACmtDBGQlmSUfvL9eCX2z1rhPRWjGGUWhEltYn7M2zj8pUoCggFijp6LtCJxw 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)(39860400002)(366004)(136003)(346002)(376002)(396003)(451199021)(5660300002)(2616005)(86362001)(31696002)(66574015)(83380400001)(966005)(53546011)(186003)(6506007)(6512007)(166002)(38100700002)(8676002)(8936002)(478600001)(6666004)(6486002)(33964004)(41300700001)(316002)(786003)(36756003)(6916009)(66476007)(66556008)(66946007)(31686004)(2906002)(45980500001)(43740500002); DIR:OUT; SFP:1101 X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?utf-8?B?QVJTWGNicnZDc2lFdkF2ZWNkOGIwWlFSc0VHWTh2em03ekZCZlNRcFBmNVU0?= =?utf-8?B?K2hzY1p1OWI2Q1RjVWF6ZEYyMkR4NmlTNCtwbFJQS0h6VkZYOEM1OXhEYkhX?= =?utf-8?B?djJob29KNTBWS1BBRlBQQmRjZ2VTeHp4cjRpTXV2bXpQeEJLQ0hLNVBuTkt0?= =?utf-8?B?cXhkeERWd25RRlo5cW8yREdWeFBjMjhkeHU2a0YxOFErMTJyWlVTYzhYMHR6?= =?utf-8?B?bTVBb3RaaFVuVmhzREhhcHo0YkNMMklmNkp5aXZkam1ObEhZUlpEc29nRWM4?= =?utf-8?B?Vk5remJMb0UrME9SdHpiMUpqb0hmcHJmUXhBV0tqRTBOYTlvUGpRclFYaDln?= =?utf-8?B?Ny9FUWg4aUt1cmhiWmVXa1BtbmMxek8zSVJjbC9GY2JpWG5ibGFwM0xyYU1k?= =?utf-8?B?elEwcnhJa25TektTc2hvWE10Qy9mNW82UFdobmZsRTZHV0s0ZCt3eXNaU25X?= =?utf-8?B?TTFiTWxlcjRBZmJ1QytwVnNCU0RyczNjWkFyUGltVnZUTS9zcGgyd3RKUmYw?= =?utf-8?B?aVRPUGFmSHM3aE9Pdlp6aitCVk5DR1JLV1YyZXhjVVpnRGpzZlJVc0ZUMkpG?= =?utf-8?B?SVhNczljOE1ZWjdSUDBZRmVYT01jKy9zRXo0VnBNMjUwTlpKUUdqZ3hOUTF6?= =?utf-8?B?dXhJOXRYSklFUVNoYW16WEc0MVBaOFErUHhOQkxKWnlRRC9DcEM2SDlKTEQv?= =?utf-8?B?N21CYldpdWJFUDhuamt4MzE0UGk2bUhuOVNNMk1uT3dMc3c1S3dTdy9mWFFS?= =?utf-8?B?SFRlMmIrcjNuVDN2M3NLT0E2bnJBUndwR2NjMCtKK0JHY25RL1RSUEl5RFZP?= =?utf-8?B?WE8xOTZSWnV3MU5qNUJ2UE1YcVdVczVzL0Jja2cvR0duakVwUEl3ekp6eWJK?= =?utf-8?B?WlYvVldvcGxGSS8wL2c0ZFNwNElFYUh2R2dKeXBGaWN5elVONDRCU1Jhdzk1?= =?utf-8?B?RUg1L1dGK0U2aUc3NWpEUko0ekJzUGNLYmtNN3FHaTlYR1VVOExNZzJvczNw?= =?utf-8?B?cFhJME1Fc0pLd1FMK1RmTHNmcGJzNVNzV3g4ZHJKUjdWK2JRczF4VVcrWGJK?= =?utf-8?B?a3BRcnVJUHZleVlpTy9HSDZ5WlBNOGw0WE9kQVMzQ2htQWhRQ0ZtVVpEWEVi?= =?utf-8?B?ZE02VXhhN0dLZnMzRnFhcDJ1Tzh4dkRxcENhZ2cyaWQ5cEhmNFJvS21DV2J4?= =?utf-8?B?eXNBUjZxejVQaEpUQ3BodU1wVm5HcDVNeHgwTlROVnhtTnRaZ0RlN1I0ejhY?= =?utf-8?B?ZGs2dnNiaUZvWXl6YjQ2SE9QQkxqYzk2bm1wZGtVQUxQcll4VlJFU2JiOFVw?= =?utf-8?B?dmordWorMVFxeUh0UmEvQXhnT1BDd3E4UzFJVEJQWStZU1JEbUM4eHR4T1JL?= =?utf-8?B?U3dXS2JURStMeDJFOG44QjU5ME42SmQvTDY5N1lPS29ISkFqRVc3c3ZZTmZX?= =?utf-8?B?N0s5N3VZRGF6bjdCcDd4YmVNald6eHF6S2JsUFdJN3ZZNEFKcUNxazVjSnZj?= =?utf-8?B?bzUwRWlPK3JsWTZpYnAreG1BajRBcjdsSjAwM0Iyd1VIaGg3T2hod0R5Zyt3?= =?utf-8?B?S1lwcFNzdTdNMmQxWW9PN1NBY0lzNlcvb2k0eFlscWlabmltOTZmck1YR2N0?= =?utf-8?B?MUdBOTJUdDVwRkdKUnhsdVNZWVAzME1hMkc5Ym5USTFrSGJrbDdZTzVVczhS?= =?utf-8?B?MUpkSXZtUmFLRlphbDJCRDRxbnpnNWZLVHAxTm1zWE5ONXFSanJxVGlpUmFK?= =?utf-8?B?U2c5akE0TDVLbmVwODJQRktERGZaVzYrYzFCYWVtd096M0xTMW4vbWxkWm9q?= =?utf-8?B?RDNSdGUzR1hwanE5cjNLeHFmbUJ2dkNzWVFQMzRDVVhOSWx5d2xpa0tZNWQr?= =?utf-8?B?bCtzcDZmdHBtUyttL1dSTVhTaFRjbzV6WndNbCtKdU92aVVHT3JCK2FZWERU?= =?utf-8?B?a1FlYjJzLzBRNEgwbGMzV0hoZFB2dDZYWGk0eG8zWEF6M1plai85MVFFV0pH?= =?utf-8?B?Q2hjdXJScFNwK1NRbzBuNTkyeHVWYWZCTi9oZ2t0cUF2bE5Dbml1eSthamww?= =?utf-8?B?SXNHSEUzUksxWVJsbTNXbTVORTJOWjM5eFdQeHdzWUY5UC8yMHVnOWFlQmE5?= =?utf-8?B?QVd6WnNaeFZrV2JUSk12ME9RMy9XWTdLdjFkRmlsZzQ5dm9EYTc0YVAycElU?= =?utf-8?B?M3NpSkt5K0RmN24rUDM1U01lZ2kwWnRVMEIzL0tCN1NxTWpxN1NQWHpSRG9U?= =?utf-8?B?aEY5WElES01rS00zZjZLSkVTZml3PT0=?= X-OriginatorOrg: auckland.ac.nz X-MS-Exchange-CrossTenant-Network-Message-Id: 5ac2a122-5e48-4264-a839-08db3ec0bef7 X-MS-Exchange-CrossTenant-AuthSource: SY4PR01MB6979.ausprd01.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 16 Apr 2023 21:22:56.3108 (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: Ode4cGfvmTXE2BNN3qia1tkfCbc1+Fj70WouiFmDCFV8Q0DYy7CHTgKuh6pjXDVA1gT7dzpjGb3WD+jGvAz/w1VEKooSTqrTWxBfFOnnkcY= X-MS-Exchange-Transport-CrossTenantHeadersStamped: SYBPR01MB6906 X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: auckland.ac.nz Content-Type: multipart/alternative; boundary="------------10f5UG6wsDBjWby4RzYM6NZu" 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 21:23:03 -0000 --------------10f5UG6wsDBjWby4RzYM6NZu Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: quoted-printable On 17/04/2023 5:54 am, David Fern=C3=A1ndez via Starlink wrote: > In case you put a DNS server in the satellite, so that it replies > instead of a DNS server on ground, the RTT is reduced by half. > > The idea would be that the satellite inspects IP packets and when it > detects a DNS query, instead of forwarding the packet to ground > station, it just answers back to the sender of the query. Understood - it's just that the gain you have from this is quite small.=20 DNS queries only happen the first time a host needs to resolve a name,=20 and then again after cache expiry much later, so they account for only a=20 tiny fraction of the traffic, and also for only a small amount of the=20 total delay in page loads. RTT isn't really the big issue in Starlink -=20 yes it's larger than it perhaps needs to be, and bufferbloat seems to be=20 present, but compared to GEO, it's now in the range seen for terrestrial=20 Internet. > > Nowadays, satellites (starlink included) are still transparent and are > signal repeaters, not routers processing IP packets, so doing this is > not immediate at all, but it could bring some benefits. Yes, but the benefits are quite small. > > CDNs or even datacenters (Cloud) in GEO or LEO is even more complex. Indeed. In so many ways. Mind though that CDNs are generally tied in with DNS nowadays, and=20 there's another snag: Take two users, Alice in the UK and Bob in New=20 Zealand - pretty much antipodean, using Starlink in bent-pipe=20 configuration, i.e., their traffic goes through, say, the London gateway=20 in the UK and the Clevedon gateway in NZ. Now imagine both trying to=20 resolve the same CDN hostname some time apart, but via the same=20 satellite DNS as the satellite has moved from the UK to NZ in the=20 interim. Say Alice resolves first and gets the IP address of a CDN=20 server in the UK. If the satellite DNS now caches this, and Bob queries=20 the same hostname, he gets directed to a server in the UK literally a=20 world away instead of the Auckland one closest to him. So unless each=20 satellite carries a geolocated copy of the world's DNS entries with it=20 and makes a decision based on user location, you have a problem. > > Regards, > > David > _______________________________________________ > 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/ **************************************************************** --------------10f5UG6wsDBjWby4RzYM6NZu Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On 17/04/2023 5:54 am, David Fern=C3=A1n= dez via Starlink wrote:
=20 In case you put a DNS server in the satellite, so that it replies
instead of a DNS server on ground, the RTT is reduced by half.

The idea would be that the satellite inspects IP packets and when it
detects a DNS query, instead of forwarding the packet to ground
station, it just answers back to the sender of the query.
Understood - it's just that the gain you have from this is quite small. DNS queries only happen the first time a host needs to resolve a name, and then again after cache expiry much later, so they account for only a tiny fraction of the traffic, and also for only a small amount of the total delay in page loads. RTT isn't really the big issue in Starlink - yes it's larger than it perhaps needs to be, and bufferbloat seems to be present, but compared to GEO, it's now in the range seen for terrestrial Internet.

Nowadays, satellites (starlink included) are still transparent and are
signal repeaters, not routers processing IP packets, so doing this is
not immediate at all, but it could bring some benefits.

Yes, but the benefits are quite small.


CDNs or even datacenters (Cloud) in GEO or LEO is even more complex.

Indeed. In so many ways.

Mind though that CDNs are generally tied in with DNS nowadays, and there's another snag: Take two users, Alice in the UK and Bob in New Zealand - pretty much antipodean, using Starlink in bent-pipe configuration, i.e., their traffic goes through, say, the London gateway in the UK and the Clevedon gateway in NZ. Now imagine both trying to resolve the same CDN hostname some time apart, but via the same satellite DNS as the satellite has moved from the UK to NZ in the interim. Say Alice resolves first and gets the IP address of a CDN server in the UK. If the satellite DNS now caches this, and Bob queries the same hostname, he gets directed to a server in the UK literally a world away instead of the Auckland one closest to him. So unless each satellite carries a geolocated copy of the world's DNS entries with it and makes a decision based on user location, you have a problem.


Regards,

David
_______________________________________________
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/
****************************************************************
--------------10f5UG6wsDBjWby4RzYM6NZu--