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 D226B3B29E for ; Wed, 24 May 2023 17:50:37 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=auckland.ac.nz; s=mimecast20200506; t=1684965034; 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: in-reply-to:in-reply-to:references:references; bh=Fgpc74fNk4dSfP7JgXaQZg3juPlTBg8ItzbblrpSm3w=; b=grzYlsM2DLhexp3OIyK7S8OA43n3XZIWwHR+L1T+eQqCsGN2Sg0GqzOqszmG0VI/KO1szx vIjzlLW3tBuuRnTzgfXyxVck8Avt8z8M8TCmTPjIEfhjrbaL3Hzd8yHKCot+zIbE4AucgA OV5Ed7hzQWl8o3dnwCdjzVHDAeBPQ/g= Received: from AUS01-SY4-obe.outbound.protection.outlook.com (mail-sy4aus01lp2169.outbound.protection.outlook.com [104.47.71.169]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id au-mta-71--0aEzaFNOTSKWf0QEhd2uQ-1; Thu, 25 May 2023 07:50:32 +1000 X-MC-Unique: -0aEzaFNOTSKWf0QEhd2uQ-1 Received: from SY4PR01MB6979.ausprd01.prod.outlook.com (2603:10c6:10:142::13) by SY6PR01MB7592.ausprd01.prod.outlook.com (2603:10c6:10:173::20) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.6433.16; Wed, 24 May 2023 21:50:30 +0000 Received: from SY4PR01MB6979.ausprd01.prod.outlook.com ([fe80::68d5:4e6b:745e:197e]) by SY4PR01MB6979.ausprd01.prod.outlook.com ([fe80::68d5:4e6b:745e:197e%7]) with mapi id 15.20.6433.016; Wed, 24 May 2023 21:50:30 +0000 Message-ID: Date: Thu, 25 May 2023 09:50:28 +1200 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:102.0) Gecko/20100101 Thunderbird/102.11.0 To: Mark Handley Cc: "starlink@lists.bufferbloat.net" References: <0no84q43-s4n6-45n8-50or-12o3rq104n99@ynat.uz> <48b00469-0dbb-54c4-bedb-3aecbf714a1a@auckland.ac.nz> <728orr66-1432-751p-263q-sqopr12s20sq@ynat.uz> <077e6ad1-d7cc-2d57-39f8-e9646bea32a5@auckland.ac.nz> <09552rq0-0n24-0pqo-4085-n918r0n71138@ynat.uz> <9q29o7n2-69rs-3os1-s93q-0795262qs3o1@ynat.uz> <1c9df33b-e964-f531-7326-1a11b159e6a7@auckland.ac.nz> <624969fc-29ee-4fcf-963a-34afa95b6bc2@app.fastmail.com> From: Ulrich Speidel In-Reply-To: <624969fc-29ee-4fcf-963a-34afa95b6bc2@app.fastmail.com> X-ClientProxiedBy: SY5P282CA0044.AUSP282.PROD.OUTLOOK.COM (2603:10c6:10:206::15) To SY4PR01MB6979.ausprd01.prod.outlook.com (2603:10c6:10:142::13) MIME-Version: 1.0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: SY4PR01MB6979:EE_|SY6PR01MB7592:EE_ X-MS-Office365-Filtering-Correlation-Id: 1b0d7745-2d43-4de7-82b2-08db5ca0e48e X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0 X-Microsoft-Antispam-Message-Info: oYWE953Q/m4jsNacVAEU5kITkjy1fba34E1989x/dJtOAxUMeDC5aAP96VIeYLmc12llZ6YsDOXB1YYCOqFro5tt2ytAf55gPydLXlBiJs/OYDoZ+YknLOOi2p0DJ7aQcDfm2Mf4HTuCDe+zMTlYhND/tymFg1D6zfDsHzabmQ22bJhOFVBR87OAmAisc3xcMgANxOx/qBE9YnYVCadUE+VIGsXJJmL9sLJQi5EozNAqrBJ+gQgQ6YOWpdMNoVqGVzFZJwvos75dxD6EHHxFl5UT//SH54h5eyXnLNg2t8FYUxYlY2Dz8+1VQ14r1eOXKgiOgoKU9TaOV2psFdv0kXVwrQGYYRmj4XA/mUqG1F6HNL1uiGRyRNGwtYCBDSwVz6BqIpodfX+x/5jGJVL0ZgbICZGcG3xLE0SbsD9VI5hmoodwCm0ccf8w9f1w0G1onLuvyl5vylheoncT3cwifKpcrrChbavrD8SeUyAOr9bqbGaTwJau5mKi2d3oi5O8xQlakXV3lDNWV6NtUhGdMgUl2muqi0JldiGAkJIZxBmWtTEHYsAk68Ce2OiUO606tafHrmKtxDqYXMwQSstkZZXLLHASysVODJ3fBAF6u2UBLJ0m99nRZd8z/MVB5l30Q9Bmyi8ONqKrzXVwNe+zX/9lALoxpgqeuwac+DgOyWVyWpJ4nZf2SqZLz0mYcuMp 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)(136003)(376002)(366004)(346002)(396003)(451199021)(2616005)(83380400001)(30864003)(2906002)(186003)(166002)(36756003)(31696002)(86362001)(38100700002)(966005)(786003)(316002)(6486002)(33964004)(8936002)(41300700001)(8676002)(5660300002)(31686004)(478600001)(66946007)(66476007)(66556008)(6916009)(4326008)(6512007)(53546011)(6506007)(43740500002)(45980500001); DIR:OUT; SFP:1101 X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?utf-8?B?L0ZKWWJ2OCtCZ3dZeWQ5WnhsMm41UnZ3RWVUeXVMTnYrR0xTa0g1T2hmVFJu?= =?utf-8?B?K0NtQ0VnbFlKeHJHMkpBZ1hPVWV5Q0VBZVZPRm5vcFZubGpkUDRJRis0dnpT?= =?utf-8?B?d2RZZXFvNDdZTjFvakVKbmxuSVVkc2t0Q3pCVE5nWUJhNmdkZitzSURLb2tL?= =?utf-8?B?bGQ5MmxrQzNEOXdmbXVRdHZWRE1uMEJpTVdZUTVqeVRxQWhpdENyL2w0em0v?= =?utf-8?B?dlB1dkFLRW51VzV1dDdLMFl6T1N2ekhwYk84Ykt5a1BFdFdyZVZPNlI5V01H?= =?utf-8?B?QjJDdit6MUVBRGp3c0xDS0FPa2h0cnovV2d3VlZPaWpaVW1oRFM3dDdCVHdm?= =?utf-8?B?TzZNMkFOODd3TVRpSTlKWTNQdk80NWkvcFI2eXdySWtSbDkzYUtSY1diZDFa?= =?utf-8?B?YVpDcnZxdHNsNkpzenIwNFVrYlMrT05JZGRJMm8wenRXSXUwV0NlWjVNa1Qw?= =?utf-8?B?MFI5N2QxZFJQaGhwNG4zTFEzZ0xkeUlKY3BCaDFRbExERVhEL2xwd1VIS1pr?= =?utf-8?B?MkF1b0srK1hua2NRdVhTaFNRVDBiS0R1QTB6dXlNME5hM2tISzlpL3I4RnEx?= =?utf-8?B?THZhV1B3S3pQdGN3TjZMaDVlRkU4elF6NVhCUVhDd0RQUFE0NlFlNkZMV2Zq?= =?utf-8?B?ZDdUMmp4dWIvQ0tuRnBPZ0cxVGtySjVwY2EyUThGWWpPUlpJSDlkb1RuTjVC?= =?utf-8?B?eWFSUGh5bmRjSEp2KzZZTGFyZnMrU3lsVFVpOWt1TjY5RTIxT2FGTWQ3aXVy?= =?utf-8?B?RTYyWDh2elhRa0p2OW1rd2k2Qkw5WjRXUTdQVjFuSmYwb3NwNWJCS2Y2YXp0?= =?utf-8?B?dGl2RWZXN3ZjNytxRUdWVHBoTXBqcjRvbFZybGZvdXlEVWhndHN1TmNNd29n?= =?utf-8?B?Tnk0Mk9OT2I2ZWtFaWNONVZkUXFwNThGV0trZHJ4VmhUVTdPQ1hhR1NuQmFn?= =?utf-8?B?T0F0cmNSSDVHWURxdFU1MHlkeDJtWkZqTnJEeGVUQjRoZXVzc1MwQVdlTDhC?= =?utf-8?B?dXJBdTMySmw5QS9PWGZHU09aUzN6Y3U3VzZZTTNQZHEydjgwRHBISGtyakU2?= =?utf-8?B?Sk1JUysySitKMUtsRGxNeTJxZElTeVlCVzlXMUpHTTM4MVNnTHdUVkV1bCs0?= =?utf-8?B?akoydDNZTjVjb09CV1ptWHN5VzhEb2tlOE9kczByUzZ2QVAwelFnS1ZTQTQ2?= =?utf-8?B?R3lGZFZpT3ZCemczazJqckVOaFJqd1N4aEZQSXdUNUpzQlgyekdBZ1pid0pr?= =?utf-8?B?R3Z1MkliVzFpR3FubzY3SzBqdUJlYUVrT3BWQWlWRHdaODZnT29qb2IyMU9q?= =?utf-8?B?VW5xa1pFMTVUQTJhVEx4clV5SkxvS2lnU2tnMTIvYnlhSjNMd0pGM3ZQMGpI?= =?utf-8?B?WkNLWENhRFk1VGdlQ2ZDTVN1QWtqUnlwc0FvdTNrVWUwQkRFN2l0REtxZnVZ?= =?utf-8?B?bUlXcElPQUVoKzM2bW4veWtZR3QyYVROMWs2TWMxRzIzWVkzV1NQQm9UbU1N?= =?utf-8?B?bHRBYTJmdUJjRjlvVVl6YnN5K1FYcVd6MXlGR1hlNDE0cEhwQjRpZ1Byelh5?= =?utf-8?B?cVJQTHBUTjNGaGxMbUhFeG5kQ1FUUFF6czRzTTc4WE1sVVNXMGVkOUlraWgv?= =?utf-8?B?MzdmRXVlOFQzb0VxaHFyWDVKRFpLdUNBTlBzZEdLYzlPS0ZZek9OV0ZCaFJI?= =?utf-8?B?R2tiK3g0YzZTMGZneTB6Y01Rb2txQWNYakdYeGVtZFZROFcxZVpnRHpvdEZI?= =?utf-8?B?QktwUis2dHFpWHZheTFDcWpPLzIvMlNESlVyZFRNZVd5SXdsRHV5enFWa0NU?= =?utf-8?B?cDhuODcrTDZMVU1jZ3EzRmZValkrYVRWS1FQVHpuVGl3WXFYODJUc0NaNUM0?= =?utf-8?B?aG9NWnlqY1JqdGRTMjJIV2Nwem1NMjVEN0grZkhFZVdoVlc1cGV3dU5uditC?= =?utf-8?B?aStXbnkycHBvS1U1T3VvbUlNQVk2ZllZWTkyQVV5dTkvcXF6RjhaY1E4M2lM?= =?utf-8?B?eWdPNWpVcjcyaW9xVHgxTHZ2QkczSEtkYnUxZFB0VnRUdWJNYThETXdDdmZP?= =?utf-8?B?QW92TFdEVFdwVVV4Ui9pZWxsT3JZZ2FtcTlDbU8yZTdGL2dYUm1RZzluMlpk?= =?utf-8?B?K2FBY2hKcTZWVm04MHh0ZGFPVUpQTmJ3endJdGc5TlVCMDNqV0RWcXpzVXZO?= =?utf-8?B?WFJ4b2ZCNTZYSnpOdEVyOUdDUmR2eDVKZjdTelBIa1VOdG1LQkdvY1Vuci82?= =?utf-8?B?dDRPTGFIV05sT21hVlNoMFRDRVNBPT0=?= X-OriginatorOrg: auckland.ac.nz X-MS-Exchange-CrossTenant-Network-Message-Id: 1b0d7745-2d43-4de7-82b2-08db5ca0e48e X-MS-Exchange-CrossTenant-AuthSource: SY4PR01MB6979.ausprd01.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 24 May 2023 21:50:30.3904 (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: gmv//2ZH+XeNOv/yTVzpK5qwH1TgK3NGvu0C0OGYXz8vKEcHrNlUWCgioJhbqyTFeQKyS9g07POZeVw930qkVHLEmpDoP7V+p7qjofp7sEY= X-MS-Exchange-Transport-CrossTenantHeadersStamped: SY6PR01MB7592 X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: auckland.ac.nz Content-Type: multipart/alternative; boundary="------------HjvKAWOtaPVSoSyHZM06tapg" Content-Language: en-US Subject: Re: [Starlink] Starlink hidden buffers 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: Wed, 24 May 2023 21:50:38 -0000 --------------HjvKAWOtaPVSoSyHZM06tapg Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: quoted-printable On 25/05/2023 3:18 am, Mark Handley wrote: > > > On Wed, 24 May 2023, at 1:55 PM, Ulrich Speidel via Starlink wrote: >> >> Dishy tracks most satellites for significantly less than 15 minutes,=20 >> and for a relatively small part of their orbit. Let me explain: >> >> >> >> This is an obstruction map obtained with starlink-grpc-tools=20 >> (https://github.com/sparky8512/starlink-grpc-tools=20 >> ).=20 >> The way to read this is in polar coordinates: The centre of the image=20 >> is the dishy boresight (direction of surface normal), distance from=20 >> the centre is elevation measured as an angle from the surface normal,=20 >> and direction from the centre is essentially the azimuth - top is=20 >> north, left is west, bottom is south, and right is east. The white=20 >> tracks are the satellites dishy uses, and a graph like this gets=20 >> built up over time, one track at a time. Notice how short the tracks=20 >> are - they don't follow the satellite for long - typically under a=20 >> minute. The red bits are satellites getting obscured by the edge of=20 >> our roof. >> >> I've also attached a time lapse movie of how one of these graphs=20 >> builds up - if I correctly remember (the script is on another=20 >> machine), one frame in the video corresponds to 5 seconds. >> >> Conclusion: latency change from tracking one satellite is smaller=20 >> than the latency difference as you jump between satellites. You could=20 >> be looking at several 100 km of path difference here. In an instant.=20 >> Even that, at 300,000 km/s of propagation speed, is only in the order=20 >> of maybe 1 ms or so - peanuts compared to the RTTs in the dozens of=20 >> ms that we're seeing. But if you get thrown from one queue onto=20 >> another as you get handed over - what does that do to the remote TCP=20 >> stack that's serving you? >> > > Interesting video.=C2=A0 From eyeballing it, it seems that when it change= s=20 > satellite, it's most often changing between satellites that are a=20 > similar distance from boresight.=C2=A0 When it does this, the difference = in=20 > propogation delay from dishy to satellite will be minimal.=C2=A0 It's=20 > possible it's even switching when the latency matches - I can't really=20 > tell from the video. Qualified "maybe" here ... most of Starlink still runs on bent pipe=20 topology, and we don't know how or why a particular satellite is chosen,=20 of for that matter where that choice is made. The video was produced in=20 Auckland, within relatively close proximity (23.15 km) to Starlink's=20 Clevedon ground station. So there would have been quite a few satellites=20 to choose from that were in sight of both ends. Also, on our deck (where=20 the measurement was taken), there are obstructions in pretty much all=20 directions on the lower horizon. That's not necessarily the situation=20 you'd get on the ridgeline of a farmhouse roof 300 km away from a=20 gateway. So that "similar distance from boresight" might be a location=20 artefact. > > Of course you can't tell from just one end of the connection whether=20 > starlink is switching satellite just when overall ground-to-ground=20 > path latency of the current path drops below the path latency of the=20 > next path.=C2=A0 For that we'd need to see what happened at the=20 > groundstation too.=C2=A0 But if you were trying to optimize things to=20 > minimize reordering, you might try something like this.=C2=A0 As you poin= t=20 > out, you've still got variable uplink queue sizes to handle as you=20 > switch, but there's no fundamental reason why path switches *always*=20 > need to result in latency discontinuities. Yes, although with slot assignments (which they can't really avoid I=20 guess), satellite capacity would be the primary criterion I suppose. The=20 effect of reordering is mostly that it drives up the amount of buffer=20 memory needed for reassembly at the receiving end, which is not much of=20 an issue nowadays with sufficient receiver socket memory. In this sort=20 of scenario, delays from reordering to the application reading from the=20 socket are no worse than delays from not switching until a bit later. > > > If you did decide to switch when the underlying path latency matches,=20 > and thinking more about those uplink queues: when you switch a path=20 > from a smaller uplink queue (at a groundstation) to a larger one,=20 > there's no reordering, so TCP should be happy(ish).=C2=A0 When switching= =20 > from a larger uplink queue to a smaller one, you can cause reordering,=20 > but it's easy enough to hide by adding an earliest release time to any=20 > new packets (based on the last time a packet from that flow was (or=20 > will be) last sent on the old path), and not release the packets from=20 > the new queue to send to the satellite before that time.=C2=A0 I've no id= ea=20 > if anyone cares enough to implement such a scheme though. Case in point: This discussion started because we were wondering why=20 Starlink had so much buffer in the system. That adding of earliest=20 release time means that you are buffering, so it'd be exactly the thing=20 that started this mailing list! > > Not saying any of this is what Starlink does - just idle speculation=20 > as to how you might minimize reordering if it was enough of a=20 > problem.=C2=A0 And of course I'm ignoring any queues in satellites... We know that we're seeing RTTs into the hundreds of ms in scenarios=20 where we have physical path latencies of at most a couple of dozen ms.=20 So, yes, speculation, but ... Also, I don't get the impression that path latency minimisation is top=20 priority for Starlink. My impression is that as long as RTT is what you=20 might see on a terrestrial connection to the other side of the globe,=20 it's good enough for Starlink. Cheers, 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/ **************************************************************** --------------HjvKAWOtaPVSoSyHZM06tapg Content-Type: multipart/related; boundary="------------qVT6FaBSU3GKsqBDKa5RCBbU" --------------qVT6FaBSU3GKsqBDKa5RCBbU Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On 25/05/2023 3:18 am, Mark Handley wrote:
=20


On Wed, 24 May 2023, at 1:55 PM, Ulrich Speidel via Starlink wrote:

Dishy tracks most satellites for significantly less than 15 minutes, and for a relatively small part of their orbit. Let me explain:



This is an obstruction map obtained with starlink-grpc-tools (https://github.com/sparky8512/starlink-grpc-tools). The way to read this is in polar coordinates: The centre of the image is the dishy boresight (direction of surface normal), distance from the centre is elevation measured as an angle from the surface normal, and direction from the centre is essentially the azimuth - top is north, left is west, bottom is south, and right is east. The white tracks are the satellites dishy uses, and a graph like this gets built up over time, one track at a time. Notice how short the tracks are - they don't follow the satellite for long - typically under a minute. The red bits are satellites getting obscured by the edge of our roof.

I've also attached a time lapse movie of how one of these graphs builds up - if I correctly remember (the script is on another machine), one frame in the video corresponds to 5 seconds.

Conclusion: latency change from tracking one satellite is smaller than the latency difference as you jump between satellites. You could be looking at several 100 km of path difference here. In an instant. Even that, at 300,000 km/s of propagation speed, is only in the order of maybe 1 ms or so - peanuts compared to the RTTs in the dozens of ms that we're seeing. But if you get thrown from one queue onto another as you get handed over - what does that do to the remote TCP stack that's serving you? 


Interesting video.  From eyeballing it, it seems that when = it changes satellite, it's most often changing between satellites that are a similar distance from boresight.  When it does this= , the difference in propogation delay from dishy to satellite will be minimal.  It's possible it's even switching when the latenc= y matches - I can't really tell from the video. 
Qualified "maybe" here ... most of Starlink still runs on ben= t pipe topology, and we don't know how or why a particular satellite is chosen, of for that matter where that choice is made. The video was produced in Auckland, within relatively close proximity (23.15 km) to Starlink's Clevedon ground station. So there would have been quite a few satellites to choose from that were in sight of both ends. Also, on our deck (where the measurement was taken), there are obstructions in pretty much all directions on the lower horizon. That's not necessarily the situation you'd get on the ridgeline of a farmhouse roof 300 km away from a gateway. So that "similar distan= ce from boresight" might be a location artefact.

Of course you can't tell from just one end of the connection whether starlink is switching satellite just when overall ground-to-ground path latency of the current path drops below the path latency of the next path.  For that we'd need to see what happened at the groundstation too.  But if you were tryin= g to optimize things to minimize reordering, you might try something like this.  As you point out, you've still got variable uplink queue sizes to handle as you switch, but there's no fundamental reason why path switches *always* need to result in latency discontinuities.
Yes, although with slot assignments (which they can't really avoid I guess), satellite capacity would be the primary criterion I suppose. The effect of reordering is mostly that it drives up the amount of buffer memory needed for reassembly at the receiving end, which is not much of an issue nowadays with sufficient receiver socket memory. In this sort of scenario, delays from reordering to the application reading from the socket are no worse than delays from not switching until a bit later.
 

If you did decide to switch when the underlying path latency matches, and thinking more about those uplink queues: when you switch a path from a smaller uplink queue (at a groundstation) to a larger one, there's no reordering, so TCP should be happy(ish).  When switching from a larger uplink queue to a smaller one, you can cause reordering, but it's easy enough to hide by adding an earliest release time to any new packets (based on the last time a packet from that flow was (or will be) last sent on the old path), and not release the packets from the new queue to send to the satellite before that time.  I've no idea if anyone cares enough to implement such a scheme though.
Case in point: This discussion started because we were wondering why Starlink had so much buffer in the system. That adding of earliest release time means that you are buffering, so it'd be exactly the thing that started this mailing list!

Not saying any of this is what Starlink does - just idle speculation as to how you might minimize reordering if it was enough of a problem.  And of course I'm ignoring any queues in satellites...

We know that we're seeing RTTs into the hundreds of ms in scenarios where we have physical path latencies of at most a couple of dozen ms. So, yes, speculation, but ...

Also, I don't get the impression that path latency minimisation is top priority for Starlink. My impression is that as long as RTT is what you might see on a terrestrial connection to the other side of the globe, it's good enough for Starlink.

Cheers,

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/
****************************************************************
--------------qVT6FaBSU3GKsqBDKa5RCBbU Content-Type: image/png; name="obstructions_pos2_762.png" Content-Disposition: inline; filename="obstructions_pos2_762.png" Content-Id: Content-Transfer-Encoding: base64 iVBORw0KGgoAAAANSUhEUgAAAHsAAAB7CAIAAADbpWgoAAAE0ElEQVR4nO2Z7VXcMBREVQdtUAdt UAdt0EbqSBvU4UAOxxjNvNGzpd2Vd+f+smV9jK6eTQilGGOMMcYYY4wxxhhjjDHGGGOMMcYYY4wx xhhjjDHGGGOMMcacluU/t05xTqg7LXR9aukNhNxte1J3+a3e9r/RNitlaF/PVtiB0W6PhbZctYvP Rc8r8hBnQF//7W1UrXlleHjW/VOteACi8DOOolOkBzliT3NT6Vsbty2VryJfi2iJ7S1Kv3/d0Z4z Cmh57lqXxqCT3NUxRO81rXoxqmfFAp+pUWtNh6hxpBrVs6J+RF+ye5AefT209AvpXjtggOTYE4Bl i9KrWyz2XcvR/kvwTcP+Z5VOSxXf3MyG8wpET3G0OORkxkWpRtUXVX1zbOZpFGwdtXe56aA7ocVe Pe3R2nS0bN65TGmL85gO3FKm3jNlJU4leWBVaWcizW48KvDCvh6FlV5+CdoezbAAGAnnn113af0v El7j/pPSxer6PGi8ZtqpEQapX7Hnw6vjDOKAaeD88U9BtZNtY4m9Y8+e1WmLlq4jHc5zcZoScZ/D CwqXw3gFTiITfgowjaiR5m4vlwrjaehGpoBmojVCS+lYNXVaSEqnIW/MahDbo2Por6BOBaKWTyAd A1XbwG7UO86pV+wMjJGaZ3B4xfFo6bRPtQc6Vqx1PGrw6752PbV0fUt1F1nvtNuQtIW9edg4nfRI VrWHbeMkugszHt0ODDAALZ3usDk2WmJU1NKqZc7fv/0ZxrBAOa+34gwGlk9meKS7SPu/cr6/L29v PTmHQZVVubGx03IzgO6QqQaS/+VlVOZe6JboI7qZfvtaOs0QRRJlsTw9zfEt/w8WCD6Keg6p96T0 SHdh1UCk9wcdCAbV+8T2UQHE06TuaJ5lKum0OlS9DK3x7ZzJeAeMl6mMlz3So+tRGaJGNBupD+ef SnoVN5KOpTTKOMqikSLddAhZZUjWY+gdavt0+OEYIgxm6zR+YzAZ3UZJHMDhAPSYd+luDp8ImozK LcEbcGBvOOFh3ZgKV5kOvb0iD6AagjNXF3QJ4V13jobQRecCPWb2qSfJ3FJxuwIsrBSilqkR+xTq o/boKU5LG4VuYfxMRPvU+y9Qy9HMooWeh9AtwswOcbFpPwadH59Wj0q8bvUIk59S+hJ8IveKFoq3 k1erl+BTo3uS85jnTxBNqj1E28t4p64zq+M1jbcExfF18edPl4Vrwktmj2g6Kr80ZsiEJI23/YU+ CWra3pDGQDq9zSyd6Sxi/DQ+Py9PT2OkXI6qaqptYHukuJqnGpjMgP1x8mja5fV1or+x5aEGt48K 1GOm/7aRLpe5jUZ9tby9fRo/uukbgQWL9qMLMaT8FkRn0/PQqNuL5ePjTD8zV5rGqWIxfNteYtd6 6WTgSwi5EhnpBZRVw0uirpsLCZt34nolaSHac8b1trNYsbCj/dXj83vy/n5ZHddB+K1EL/BxqNqb h4QT4inSYN8tLy+f/ygcsuvbQ/1S79WQaKpqkupRNOdjgRaS0pvimrX/oERmm7J2eRdDHu4waDnn vRyQFXnfn/3MVNJ14Q8p0ocrbcqXgI+Pn+ug8P1xuCBU+uo96n/ViHdJVM72e1UW4NaJHgwbN8YY Y4wxxhhjjDHGGGOMifkHPxsBnUEAZ/EAAAAASUVORK5CYII= --------------qVT6FaBSU3GKsqBDKa5RCBbU-- --------------HjvKAWOtaPVSoSyHZM06tapg--