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 8E8743B2A4 for ; Mon, 26 Feb 2024 17:19:46 -0500 (EST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=auckland.ac.nz; s=mimecast20200506; t=1708985983; 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=oOCgpjUttyf6aETNu1N+ZuLlORnziD1a1UTvVAjEG7A=; b=daMdwpHa5q4fAt2+EYMWw4zEnDibZ4Da2uIsHjI6EM04xbXx3qWMDWmKp6P4o/yaX+VV51 y8d3a7TxVdMVNMxud1CuXSGujNsMJ2lsGwcVGshppaIiXYa9htzavCBZW+m6IqKq1oPHyk tpUGir9DOkR9SEJykDLTyGbyuP6KZkc= Received: from AUS01-ME3-obe.outbound.protection.outlook.com (mail-me3aus01lp2232.outbound.protection.outlook.com [104.47.71.232]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id au-mta-52-GN90FIYcPDqPJNIW_jZH0Q-1; Tue, 27 Feb 2024 09:19:41 +1100 X-MC-Unique: GN90FIYcPDqPJNIW_jZH0Q-1 Received: from SY4PR01MB6979.ausprd01.prod.outlook.com (2603:10c6:10:142::13) by ME3PR01MB5926.ausprd01.prod.outlook.com (2603:10c6:220:e4::9) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.7316.36; Mon, 26 Feb 2024 22:19:39 +0000 Received: from SY4PR01MB6979.ausprd01.prod.outlook.com ([fe80::2faf:5dbf:9124:8a6f]) by SY4PR01MB6979.ausprd01.prod.outlook.com ([fe80::2faf:5dbf:9124:8a6f%5]) with mapi id 15.20.7316.035; Mon, 26 Feb 2024 22:19:39 +0000 Message-ID: Date: Tue, 27 Feb 2024 11:19:38 +1300 User-Agent: Mozilla Thunderbird To: starlink@lists.bufferbloat.net References: From: Ulrich Speidel In-Reply-To: X-ClientProxiedBy: SY5P300CA0069.AUSP300.PROD.OUTLOOK.COM (2603:10c6:10:247::7) To SY4PR01MB6979.ausprd01.prod.outlook.com (2603:10c6:10:142::13) MIME-Version: 1.0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: SY4PR01MB6979:EE_|ME3PR01MB5926:EE_ X-MS-Office365-Filtering-Correlation-Id: 4c4f8a5c-c11b-46e5-b62a-08dc3719061c X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0 X-Microsoft-Antispam-Message-Info: 7EawVWK8CcXrun+kjqaHLN9E6DBUZpbrKNAlIlTnOVssqewtfmr807aK+uWRfuybg7H/NbOpRfdqT9xmcb60mbHGAVfYKRPtFgtlGgh92Kt7lx45F/MBKL+fErWKIFcM3ou1me4yQSgKQPOZNLtl7fmiTKtT76EnxrYYtLbO15/e/XDsgL3h1z7RtM62lVOUXCy41km6kiyizt0kfdORmV1d0EuV5GF8AV2gvq+TWtnXr7LPXPUzv0AxXv7LloR/S2X2n0irvJjvil+N+WLDEzUhscaguXTmXA9hNAgKr0Kjlm2NxEXKTWxHXp/t6qBttQwxRxC++xVR+v8hQ8rT5XM6539ioH1Qq6t/Ujx89ZT3+zdoIrrMYpA2T7+6hI3OKHt1VoM+6unHWGRrCVGH9EFIMe8cX8Q29KHwFshRTkRbSp3WLF5m1+2TPemnD4FkJc58e2XbkE1qZWNI2tGrYSgoMhEnDBCJ+/HG6trEM+VBWg6l7vuOYQ8ALVm6W6tUkZIlcR7wOdtbT1/s8M3GFuGS//1BiQEL2bfzxM34JAe86IObmpK79qWIPoNV8qLk0mSM6Sf8Q0eTzqlutFe5lWb4AOjrjlkUNFHyFw4ymFWt9RMq5Bcs+yVFH8JNYShL 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:(13230031); DIR:OUT; SFP:1102 X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?utf-8?B?cXpVK1lJSVM1ZHpmSWVGNjYrYXJSbTQyVlBraVBNVHU5cXhOQ1F1V24zTW5n?= =?utf-8?B?VGx6Um5lZmRvSFFURG5taE1YV2FySTBVOU96R0ZSSzl1ZnBIb3NDK1lGV1dO?= =?utf-8?B?N1gzT3ZnUjh3cC92bForVnQ2OFVsMGRScTNLd293V283UHpjMnNYVWdKN0Vr?= =?utf-8?B?M1ZkVzM1am5KQmpyazhQdUZRS0FRMDZQc3RYWUtSWDJSWUxRcTVYbFI2SjRS?= =?utf-8?B?UXFZdUpqcW9RMHBhSjFSeGFYVDJOTkpJcnRBT2pWN1ZHYmJQUndIOHNkSTEv?= =?utf-8?B?bjMrN2N1WlJqQTJhM2NpY3pFaEJnSGdXY3QyVWlucGJ0bm0zTWQweUd1YUxU?= =?utf-8?B?VnJuOUtsWW5EUVRNT0hHN3orNDBaR2wvQlVZWWVnaWlBSjE0cGt2aFd2bkZN?= =?utf-8?B?cHlKQ2xDcjdMWTZhajAxNndiNU5wM0RPN0hXOUp0b0hYb3VvcXBVWWpWRTdz?= =?utf-8?B?SW00d1orL0h0bUZQTWNVbExxeTdZK2lwMHpFRzI5Z1cyNC94VVh5WTR2M2Vw?= =?utf-8?B?eTRraVl0RmtteUpKcUp0U2plb2Q4NmZ6VzI5NTdHbnBaaXBPTDVmenpIWE9j?= =?utf-8?B?UnAydGlxNUdFYkhtUTlNSU45WE5GWlhDZGlwUCtNSVo4MXF2RURCTHlUaFZ5?= =?utf-8?B?WDg0TmRZSUhUb3ppUUcvRkhrQ0pFKytjcnlockdBbnhGdmt0K1JoOUpGTUtT?= =?utf-8?B?SzVCU0VxMmtwNmFvaGE4bzFuK0lNU1kwZndoOXZpeDViWFMrSFdQYmh0S0Rw?= =?utf-8?B?akpIZTRFR1kvcERaWUhUYlJGeWY2RExpcFdwNlgrREtsWnU5b1JYSFdScG9B?= =?utf-8?B?OTIzSlVoVE5mSDUzeU1VMVdqVTJxRU5LRGlBa1FYQ1hJbnNBMUFTS2ZnR1hM?= =?utf-8?B?cGI3TDk2WGUyazhZSVhZZEsvbEkrQXY4djE4SVpXV0dONGoxRytTeHZCRkZZ?= =?utf-8?B?OEJCZCtGaW5hRm5ZWlQxQWR5MytYZjhzS1hid29CZDhPdTdxMUpSdkp4V25E?= =?utf-8?B?dkRKSGRRQkFFSUNsWmFyOXNpenNTN0NKQ3YyUDU3QnVTR0d5ZHp5Y1J2SGlN?= =?utf-8?B?Qk5jSTdIRmlEakFWSzd5MUNpUTRjNDR2Qkh5aktFUHJmNXB4N21xMzB4WWY5?= =?utf-8?B?bFJIN2t0SWk5NE9NeEZsWHJQWVVtYnlWMkkrK1ZVSjRWQjlVZzd0Z3pkajNn?= =?utf-8?B?cWxQWlgwc2xOcytRcDNkVWdWVC9QeGdkMThVeGdKd3hBN3FPSVJXK29EVUcw?= =?utf-8?B?M0s3SXpySUpsUmJUWVNoTGNubFp5N3pITzF4NU5nbEV0ZGdsZnQzdmhxQ3B3?= =?utf-8?B?c2UyVUFXTEFsZTJ1RHFjY3RnTGd1a1RPSThqQ0E5T2FlT2RoQVh6a05aTWFQ?= =?utf-8?B?cXpFNzIvZWtnZ3I3UlBaM2wxak1qOVBxeGZ4VmczcDhYT2hFc1plbUdReWtv?= =?utf-8?B?aU9QU0NRWGoxQ3dtblkrU0xlRndWSklMVExyS3Jwa3lFS2dad0dneHJZYmU3?= =?utf-8?B?dXBzZXQwZHRRUFFULzYrZ0RaNlB5ZUNKQ1drQUlyMzBNRnB1SDdvMkVXZm44?= =?utf-8?B?UGZMSTBoVEhmQ1F0YWFqaTFxalJhTFVsbTEydFNoWFIvbHZMVzdmM2R1YUo2?= =?utf-8?B?RjI4K2dxeWM1eHdweisyTWpDMUJ3ZFBxWmZDSnFZNndZeG41bGh5aGNzeGxQ?= =?utf-8?B?S09WdDRMMHNxVm00V0RCOGxnVkpCOU9hTTlDMXl2Z3VSODVxdWhleUMrWkdR?= =?utf-8?B?SHVoYzNjejVqRWJmVHdaL28vRFNVc2Roc2h5WWRPZ2lPc2k3RWhSOWpramxt?= =?utf-8?B?MW4zbjhiRmFwUUFpQ0lEMVU0am0rOE1BWnRvOVVwdEoxUlF4T2dXRW9WN3Ux?= =?utf-8?B?ZHRZU0JlOVNrdGlpRXFEdldobThOdnNVSGdtYXZmU3V1eGdyZUpiTk5HbW9K?= =?utf-8?B?MlRSMCs5cVEwY2lTY1cxUEdBSld4MHBjbUhPdDZGNEZHTnZzdk9aUW1XeVRS?= =?utf-8?B?VmhkSlJoWW40Y3pnMUk3ZkpZVFo3ZlE0VzQ1aXRBcUZwNTR4VEVJQURsRGRv?= =?utf-8?B?VmRuR0FwVDhIbHlaM1VCS2FlcUk0TVJkVmhWaUJRdjBTRk4wVGI1NWg3dEhx?= =?utf-8?B?T2dLcHRRMVphY3k3bFFUWGdST0R5SE9EclZxVzJSYVBMMFVjRnBNbXBXK29V?= =?utf-8?B?TkE9PQ==?= X-OriginatorOrg: auckland.ac.nz X-MS-Exchange-CrossTenant-Network-Message-Id: 4c4f8a5c-c11b-46e5-b62a-08dc3719061c X-MS-Exchange-CrossTenant-AuthSource: SY4PR01MB6979.ausprd01.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 26 Feb 2024 22:19:39.8149 (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: f757lZ7IR8n0nyhR9aq87suz32sPjhVYrLhUrEm8+70VIeg7dwjAvOvcNYdroNpKUs+1LtpqtgmnTdzNI1Ed+l7HdIq0/YoU7bkEG37udtc= X-MS-Exchange-Transport-CrossTenantHeadersStamped: ME3PR01MB5926 X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: auckland.ac.nz Content-Type: multipart/alternative; boundary="------------0eDzw0XqujMaEULgLtLFx47W" Content-Language: en-US Subject: Re: [Starlink] Comprehensive Measurement Study on Starlink Performance Published 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, 26 Feb 2024 22:19:47 -0000 --------------0eDzw0XqujMaEULgLtLFx47W Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: quoted-printable Thanks for that! Another few interesting pieces to the jigsaw puzzle. I've been a bit reluctant to enter the performance measurement game=20 around Starlink myself, chiefly because it's a moving target in more=20 than one sense, so essentially you end up producing (nevertheless=20 useful) snapshots. There's the rapid growth in satellite numbers and=20 hence the associated change in Dishy behaviour and improved performance=20 in conditions where Dishy has obstructions to deal with. There's the=20 advent of the ISLs. There's also the fact that we don't know which=20 underlying changes are made by SpaceX in terms of network configuration. 5G is also a moving target in its own right. Handovers: I think it's important to consider that while your Dishy=20 might not get handed over, others operating via the same satellite might=20 move away and yet others again might join the satellite you're on. So=20 it's not just the potential of you moving away to a satellite that looks=20 different in terms of load, it's also a matter of your satellite's=20 capacity changing during someone else getting handed over to it with=20 cwnd wide open and being allocated fewer slots than before. But, again,=20 as mentioned above, good on SpaceX if they're using some form of AQM to=20 try and manage this. My most serious concern about Starlink as a system remains the fact that=20 it puts a pipe between the end user and the first network hop (the=20 satellite) that is in principle very difficult to scale: There's only so=20 much extra spectrum one can use, spatial diversity (beamforming) has=20 limited potential, and unlike in cellular networks, you can't really=20 shrink the cell size to accommodate more end users through frequency=20 re-use as your cell size is determined to a good part by orbital=20 altitude. That all but rules out the scaling effects that CDNs have=20 brought to the rest of the Internet, which keep orders of magnitude=20 worth of traffic off long distance cables. There simply isn't an obvious=20 place in LEO topology to put a cache that'll produce a decent number of=20 hits while being able to serve this content to end users through a large=20 collective bandwidth. The interesting question for me is how much we can scale Starlink and=20 its up-and-coming cousins from the few million users Starlink has now.=20 To 100 million? To 200 million? Half a billion even? On 27/02/2024 7:12 am, Nitinder Mohan via Starlink wrote: > Hi folks, > > Our comprehensive multifaceted measurement study looking at Starlink=20 > global and last-mile performance is now available online:=20 > https://arxiv.org/abs/2310.09242=20 > .=20 > > > TL;DR: See the summary in this nice teaser video we made:=20 > https://youtu.be/WtE3MoK8J80=20 > =20 > > > We looked at several third-party measurement sources (M-Lab, RIPE=20 > Atlas) and performed our own measurements over multiple Starlink=20 > dishes to uncover the following: > > 1. How different is Starlink network performance globally? How do=20 > ground station and PoP availability impact performance? > 2. How much latency is consumed by the satellite part of the link? > 3. Is Starlink connection affected by bufferbloat? > 4. Are satellite handovers the root-cause of Starlink 15-sec=20 > reconfigurations? > 5. How good is Starlink compared to terrestrial cellular networks for=20 > real-time applications, specifically Cloud Gaming and Zoom. > > The study has been accepted and will appear in ACM The Web Conference=20 > 2024=20 > (WWW),=20 > which is a flagship venue that has historically housed several=20 > pioneering works central to Internet success. > > Feel free to let me know if you have any questions related to the work. > > P.S. We also thanked this mailing list in our paper for providing us=20 > several key insights and inquisitive=C2=A0discussions :) > > Thanks and Regards > > Nitinder Mohan > Technical University Munich (TUM) > https://www.nitindermohan.com/=20 > > > _______________________________________________ > 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/ **************************************************************** --------------0eDzw0XqujMaEULgLtLFx47W Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

Thanks for that! Another few interesting pieces to the jigsaw puzzle.

I've been a bit reluctant to enter the performance measurement game around Starlink myself, chiefly because it's a moving target in more than one sense, so essentially you end up producing (nevertheless useful) snapshots. There's the rapid growth in satellite numbers and hence the associated change in Dishy behaviour and improved performance in conditions where Dishy has obstructions to deal with. There's the advent of the ISLs. There's also the fact that we don't know which underlying changes are made by SpaceX in terms of network configuration.

5G is also a moving target in its own right.

Handovers: I think it's important to consider that while your Dishy might not get handed over, others operating via the same satellite might move away and yet others again might join the satellite you're on. So it's not just the potential of you moving away to a satellite that looks different in terms of load, it's also a matter of your satellite's capacity changing during someone else getting handed over to it with cwnd wide open and being allocated fewer slots than before. But, again, as mentioned above, good on SpaceX if they're using some form of AQM to try and manage this.

My most serious concern about Starlink as a system remains the fact that it puts a pipe between the end user and the first network hop (the satellite) that is in principle very difficult to scale: There's only so much extra spectrum one can use, spatial diversity (beamforming) has limited potential, and unlike in cellular networks, you can't really shrink the cell size to accommodate more end users through frequency re-use as your cell size is determined to a good part by orbital altitude. That all but rules out the scaling effects that CDNs have brought to the rest of the Internet, which keep orders of magnitude worth of traffic off long distance cables. There simply isn't an obvious place in LEO topology to put a cache that'll produce a decent number of hits while being able to serve this content to end users through a large collective bandwidth.

The interesting question for me is how much we can scale Starlink and its up-and-coming cousins from the few million users Starlink has now. To 100 million? To 200 million? Half a billion even?

On 27/02/2024 7:12 am, Nitinder Mohan via Starlink wrote:
=20
Hi folks,

Our comprehensive multifaceted measurement study looking at Starlink global and last-mile performance is now available online: https://a= rxiv.org/abs/2310.09242. 

TL;D= R: See the summary in this nice teaser video we made: https://youtu.be/WtE= 3MoK8J80 

We looked at several third-party measurement sources (M-Lab, RIPE Atlas) and performed our own measurements over multiple Starlink dishes to uncover the following:

1. How different is Starlink network performance globally? How do ground station and PoP availability impact performance?
2. How much latency is consumed by the satellite part of the link?
3. Is Starlink connection affected by bufferbloat?
4. Are satellite handovers the root-cause of Starlink 15-sec reconfigurations?
5. How good is Starlink compared to terrestrial cellular networks for real-time applications, specifically Cloud Gaming and Zoom.

The study has been accepted and will appear in ACM The Web Conference 202= 4 (WWW), which is a flagship venue that has historically housed several pioneering works central to Internet success.

Feel free to let me know if you have any questions related to the work. 

P.S. We also thanked this mailing list in our paper for providing us several key insights and inquisitive discussions :)

Thanks and Regards

Nitinder Mohan
Technical University Munich (TUM)

______________________________=
_________________
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/
****************************************************************
--------------0eDzw0XqujMaEULgLtLFx47W--