From mboxrd@z Thu Jan 1 00:00:00 1970 Authentication-Results: mail.toke.dk; spf=pass smtp.mailfrom=; dkim=pass header.d=auckland.ac.nz; arc=pass; dmarc=pass (Used From Domain Record) header.from=auckland.ac.nz policy.dmarc=reject Received: from SY8PR01CU002.outbound.protection.outlook.com (mail-australiaeastazlp170100001.outbound.protection.outlook.com [IPv6:2a01:111:f403:c40d::1]) by mail.toke.dk (Postfix) with ESMTPS id CA0BB6F10E5 for ; Thu, 25 Sep 2025 22:09:02 +0200 (CEST) ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=dcsWEhg7sPHMSaZ2/d6L8m+RFHVoA2RDJLWJ6kO0WtPW22kCJs2fugvrOFvMcOxlJieOY1WYP6Km8qMTrsNHll9bpCtzNATQm7GOscuh8Q+TenX6gUcCPdlOX/YYEqw7YEhFNMrIF29Q1agfLTyL0hkDLqQbJob8ZvnHhomMYVT2qM9Ihrv+UGy5KBcVKYbYqLyX3N81DQ2OuCMlN1odfBz7ZLL1IoTdusb5xvcAHG3HprvZPenlPp89hvzFqCZkvjNgrTs3XOoPxN73vW8W83CSUYjOyS646XO6/TpurnBf8Mp1NwmS/YdLoar2kOi19W/12TWu1C3J6iQ2gLHexA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=jlylVtWKRdgcIa2PiNgOSkSBJHnEt8XRQrd4L+CDtHE=; b=Fm2VznfxjW2zpfbIfNABU9sFmd3i8wfQH4b/WppA4TrxNzAvbbcSaAaexYsQjCN52YbyNoYSXq3Y8VBXm5SJbqYgM43QsekVAvaHkGVnPCqI3d0pw1VnNTELMXXx64wvLIEfp+oGlCyLZrFgFEd7q3DRUor8JdqJGfdL3rTVpJb62UPg1mxcp/G66JoFJqIXQM7PYToJORAWczVDkh54SmuEIZYKD1xrncVum0PUhtkgGFLJgPxXkTiZcVp6nJrB/gJnHPAcYWjC8ZK+9HoT3fpuajPOygZIkYh251X2HFleOlv9xffgRz9L43mDgg4ETkFgdB9Ab9Fpj/sfQWTJHQ== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=auckland.ac.nz; dmarc=pass action=none header.from=auckland.ac.nz; dkim=pass header.d=auckland.ac.nz; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=auckland.ac.nz; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=jlylVtWKRdgcIa2PiNgOSkSBJHnEt8XRQrd4L+CDtHE=; b=Vp0kKBAh6Ixdn+SBrtSRHyPoUR0DZGY5G+IcWlPg0M0lWmfzS/exwEVZv5vnrRKMyKoN+D1CUBOEBm+zTOtNXsUAwCnU8n9ZBB8bIMOHSW8m1/2MP2lWZo8n79rv2Lx73/3CoilmA4SatquYuNy7EgtbvmpjFYtBlHxadCe3Vic= Received: from SY8P300MB0544.AUSP300.PROD.OUTLOOK.COM (2603:10c6:10:297::19) by SY7P300MB1513.AUSP300.PROD.OUTLOOK.COM (2603:10c6:10:2c6::22) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.9137.20; Thu, 25 Sep 2025 20:08:55 +0000 Received: from SY8P300MB0544.AUSP300.PROD.OUTLOOK.COM ([fe80::2100:96f2:f11b:4fc2]) by SY8P300MB0544.AUSP300.PROD.OUTLOOK.COM ([fe80::2100:96f2:f11b:4fc2%5]) with mapi id 15.20.9160.011; Thu, 25 Sep 2025 20:08:55 +0000 Message-ID: <91ccf1a3-5c78-4a57-8c16-e312c231b6a0@auckland.ac.nz> Date: Fri, 26 Sep 2025 08:08:54 +1200 User-Agent: Mozilla Thunderbird To: starlink@lists.bufferbloat.net References: <175876550514.1555.8294777204829819629@gauss> <30473.1758822310@obiwan.sandelman.ca> Content-Language: en-US From: Ulrich Speidel In-Reply-To: <30473.1758822310@obiwan.sandelman.ca> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-ClientProxiedBy: AK0P299CA0031.NZLP299.PROD.OUTLOOK.COM (2603:10c6:108:16::11) To SY8P300MB0544.AUSP300.PROD.OUTLOOK.COM (2603:10c6:10:297::19) MIME-Version: 1.0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: SY8P300MB0544:EE_|SY7P300MB1513:EE_ X-MS-Office365-Filtering-Correlation-Id: 5a6037d2-ad3b-43a8-fba7-08ddfc6f5b03 X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0;ARA:13230040|376014|366016|1800799024; X-Microsoft-Antispam-Message-Info: =?utf-8?B?aW5OSkh0TUNxSUJLUVlkbjlqUzZaT3cxeGNCczRKZ0tMNGwrWnVNZFlwWFNl?= =?utf-8?B?YW1oQnBFY1NYVmY3ZWdlay9sWlZrOGgvV3VFWHlVVGRFbDB0eTFta05vK09G?= =?utf-8?B?MmlPWkt4UUtmNSszSlF5SVY0U0NDa1VBUEx6NHcybHRJTGJXaC8zK0tOY2Z6?= =?utf-8?B?aXhTdzJ3c1pqTSsyd1JzR0tWUVgzWUEwNW9iS1BHZ3BrQXFuRjBUbGJVbURO?= =?utf-8?B?a3QzR215WW9zRVJZR01ndm9QdWtBMHZtZ05zMzZualFFeHdFM0NhU3RIanBn?= =?utf-8?B?VWZFckNkZEZlUHllVE13OWZoQXhwSUVFNnZnbTBVVmR3K0FpVTFQVEdmdXZ2?= =?utf-8?B?ZFFSUDkzeFlOYWhJTlRaS3djSXpRQjhsajl3eWNtSXJGekh4ZXJQV2xiaS9i?= =?utf-8?B?eTRVMC9wRDFRYURRZWtBb29QUWdJcTJrT0xyMlZ0SGRkUXBUemd0dFdvMWl2?= =?utf-8?B?V09pRVcwZEFtWE5hRDAySWE4R3J1WjBSWVZKcUJ0bkh3U29PbHowNHdLUzJv?= =?utf-8?B?UkVhdW1DL1RSOUZmTU9wMXFpSGZzM1lEVC9abzMwV2NhQVdMbzNXYm9UWHJJ?= =?utf-8?B?aU9wYU9mT1ZmMERPaUZSNS9ZZG9TOERQNXNabE9ReTdXOXdEbXJIa0U3SStj?= =?utf-8?B?QnB0YzBZNXF0UEpoSTlwMEtsN3dLcG9EMzlBN21IVVJhWmQrdGxzM1pqbWM3?= =?utf-8?B?RHd2alVXb0ozWVZNTTlQS3V6ODBBZEZMQUxqQktubkVvNVhNZFYxYm9CTk9N?= =?utf-8?B?bE5vdUY4ckNEZURCeXRrNFhLbzcySmpaaHY5cG8yaTRhdWFCS1VCRlVLMldl?= =?utf-8?B?a3NpYkJnUWQrdFhNSnJMZmowcXlnOVRBTnczOEVwd2JVVG0zZDhpc253ZE8r?= =?utf-8?B?Uy9MeUthZEFFWWl5aVJ2TjNITnZJTlZBRnJFdG9xWnVMT3BwdE9QODFyNFp6?= =?utf-8?B?VmlxY1hCbXpSeG44cjRXY2dyTWhsaENTNEZkYnlBaFVjV3JmbmY0VHp2Sk55?= =?utf-8?B?aTMrd1BmVzdzRmZLcThaSm53RDVVNmhJMjhZczdCckIyOWVFWDdxOStwbzFu?= =?utf-8?B?MEd4aFJod3JmQWZXcE9lVTlXaWhNcmJsaWFKTy9ZUWJKcWYrTUVTZ2I2MUY4?= =?utf-8?B?MDkvelZsMGJaT1hoQTJsZnBsS1AwZFgwYTNpdmRHQzNHT2pPK0FLN3pzZFBJ?= =?utf-8?B?cGlRSTExNTVyMGxkLzhndUZrN3NjdHV0ay9zSXh1MVl0dWxOaWp0SzdhdDN2?= =?utf-8?B?bklDbHI4RXh2SGZjS1paVHFwRWpZbDlWWXFxOTdCa0JPODErU25XSXRCTDZh?= =?utf-8?B?R0VLWVU4S29qMkE3ZFRZZlFtMzJRQ3gxZlBUNG5lRWFTT3VMZlRyV05SUDBO?= =?utf-8?B?V2szOW1Kc3Z1b3JTTzFPZk9IUkRzS2hlMHRJTlo5dE14VWx6V2lkMmdzYTg1?= =?utf-8?B?K2tGaXo2SlNJdnQ1eWdpTmxubnB4YmV2cFdKWE5MZm13czhJbU9qQlFtK0Jo?= =?utf-8?B?SGsySkdMNENDRUkxMUF6dkltRmtUS29jTndPQU1jdmVDM3BTQVo2N0ZkUVZU?= =?utf-8?B?UjNyUHdlcHI3NG1nZHZBKzcyd091VnZieW5IbXUyVXZ1bXR1SkdnaVNMemJo?= =?utf-8?B?NkJnS0pKWHNybDkyMHlwYm5senphTklCV21HRHpkc1FBQjEwNUxSVmFpUm5X?= =?utf-8?B?V2N4WFJLR3RyZG9Qeks3V3ViNGNqZEZuQ0V1VktJUXY5YWU2K0s1cytnc1Fq?= =?utf-8?B?clpjekNNem1kNDgrb3dWdmxHSDM1Mkpka0dZSUY3Z21JczJZV0wxNXdZMFlo?= =?utf-8?B?VVhOemJuK3JyRC9MMlFqNVNoa3dKUThRWGUyaXBtSVgvVlV0MjBvYVVYL1Zt?= =?utf-8?B?SzJCb3E1VTkwekRGTUprbmZkQ3NFTkNRdW9Zb0NoWXlDelE9PQ==?= X-Forefront-Antispam-Report: CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:SY8P300MB0544.AUSP300.PROD.OUTLOOK.COM;PTR:;CAT:NONE;SFS:(13230040)(376014)(366016)(1800799024);DIR:OUT;SFP:1102; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?utf-8?B?OGNBY1lkMWxTTE9kdDVPeVozRW1QT3NuRTR6K2ZhQ1NWWThFalRjTkw4RkxD?= =?utf-8?B?SzZSMVg0UkJMb0RtcWIvaFpnVnM4UWJHTEJwamNNcndKbnRyLzRMN21QUmxv?= =?utf-8?B?UzJ0OHBRZDVzWVpPekQzejlyRUI1UWZTYzJVZjU2SEpjQnU2ZmlxNUZnYkNK?= =?utf-8?B?eldnQzZlK0x6cEptbkJ1ZWVKTUcxdGtBK0UrcnkyWXFPZFRScXpKUlUra3Vl?= =?utf-8?B?V2RqM2tFUVViQjk1OW0zK09SUGFIbktHWmxjK0N4YWNpb3Q5a0lVWWUwOVlw?= =?utf-8?B?eVpxdG9qZUNBRlJnVTdwM29RdkFPK1VYeDBKTklXQzdVdm1WQlE4TkZOUVlp?= =?utf-8?B?d1dITk5zd2pOVTg3d2FmRmRqeEdvUjBKRERPQjR0ZVdHdE1uRnVkTEoxaUk4?= =?utf-8?B?TjJKK2ZxQnVTeWI5UTF0N2tjSHhheCtycjF5UzV1RXBkQkw2WUJUVmFmWjVR?= =?utf-8?B?R2lqcWJiUVpxZE40eUcxSkcxZ2EzRTAxODZtVzFsbmkvcjQzSVdhc20yQVp5?= =?utf-8?B?cXpRVzUxSVZqUFgzaFdOTWJGbStuM2dpVmNRUlZYd1FNNlI2d3M3aDU0WnpL?= =?utf-8?B?QXdGc2gvYTcvRkhyZFZuSFRDc3NHZFVNbmtHNzJ5cGk1YUc3Ykx3Yzk2WUNG?= =?utf-8?B?Tkd6SUs4ZW9pOFNFSlNmWGhlejJqcUwyWEF1VjA1QWdGSFpDRUZyQi9GbWtk?= =?utf-8?B?NUNUbk0rSDBmS1ZWekw4QndtbjlKQWxlVkVnOWRXUmExbkZlU242ZEg1bk40?= =?utf-8?B?TDNEdHYrTEhSZTBYcG1PM1hjMEVtQ2JtL3JBaUpEVUVweHZOcGl6U2tyMjBn?= =?utf-8?B?STBURDRJYmE1cE1nc0Vzb3czWm1rRC9mdDFuOUpkdWx3UlhGZXhrYzhSYWYx?= =?utf-8?B?bXhaOFMyZHFFRW5Xd2xkOUlUNlpBd0VKU0FrUWtsWmNpbzFySnFPWS9yMG01?= =?utf-8?B?bFk3SEtlTDc2Y2tnVm11dWFlcFVOajN0SW4wRnF3NjRtajQ3NllPUFhwdk8r?= =?utf-8?B?Wm5uTWJFcUtYT0F0em5zMlRUSjdlbkdvaFV6WUphQWhTVDJDM2xmQzN2cURZ?= =?utf-8?B?cGdaV3JxUWZKZmJsUlZsOW1CSzloU3BidGhQeHFzMnpycU15N3E5K0FpOHM4?= =?utf-8?B?YWoxRE5vaVNiZnFXSkNyTDBNTmNzSU9ma1JkYnJFRGxzeHlGUnZtN0VlM1JB?= =?utf-8?B?VENzRU5pbXVwSVJvVGExZGJESkwzNHBBMS91dXdzNkhuOGJGRlBzM2RxRzF0?= =?utf-8?B?dVdKdmZoeGN0d2RBT0VxSEg4WEJGQ1Zid3MzSGlWN3dsUDZQbk90VjFGNk04?= =?utf-8?B?VStzUlZkTWN5bUJ4MmJvQU5QcVRkc2hSM0dlU1d4V1N3SG9Gd2dTUzgwVHZT?= =?utf-8?B?c0tkOTYvSUlMMGR2N3k0U2tXVUkva09OSlJNNHF5dFgzUWcxMFJqMDZ6MTAr?= =?utf-8?B?NC8vNDFYRTdVVG42R1U3NDQ2WXQ5dktwYWNKQUVhZ1I4bTl2aVprRk9uUUcx?= =?utf-8?B?eWcrTzR4REZubWdsUlIrby9sL1hGR2czWlk1TzErVTh0MWtTRjBzWFB1R0Ir?= =?utf-8?B?eTJ5WklpcXR2cER6cC9YYk50a3B6RER6VUZoSFhnTUY1bnNPTmp6eXRnRFpX?= =?utf-8?B?UHh2QnVKM2JWczZwTGcwcUVZTTc0S2czeXZ4TWthT2ZkSmUyR2x2dExxREJI?= =?utf-8?B?U0ZFNW5PendIdVYyR1BhNU8yT2IrTnZ2c1I3eklmeWNZZEh0RDRuUnJ6d2ow?= =?utf-8?B?L3FIVklKYWVHZEh2ZUdabis1RHI0SWx0cU1DdWRueVpaQkN5SEJ4MWNVdzh4?= =?utf-8?B?TWdhMnk0cXFKT1NUQU1XUnI5VFk4M3NNN0VXamF0bmZHVmQxVCsvVVJINk5r?= =?utf-8?B?eWE3ZWdTYU5pNXF5QUJqc2VPV3ZxZEJBaU8rRWVMbjB0bEJINXhyblg1MmM5?= =?utf-8?B?L1FPUFFmblFvYWN3d2d2M3RRT1JWRWpERGR4cTRERCtJVjR2czZTVkpiaXJH?= =?utf-8?B?WWpNOEk4N2R0ejFFcUxvaHVFMCtEUVZFb0ZSRGhSOUg2TlVITGI0T3NCcUFK?= =?utf-8?B?cmlLODFweHlqU3VJYlJuRmZkaW5PL0ZsNFNqdXBVVDdiQ0xHcnMvOFNjZnhM?= =?utf-8?B?SUQwbWo0UjcrVjZHQ3BvQ3BuZDA0NmtPVVRQV1dmYVliVUJYUVg3VDR5cWxl?= =?utf-8?B?L2c9PQ==?= X-OriginatorOrg: auckland.ac.nz X-MS-Exchange-CrossTenant-Network-Message-Id: 5a6037d2-ad3b-43a8-fba7-08ddfc6f5b03 X-MS-Exchange-CrossTenant-AuthSource: SY8P300MB0544.AUSP300.PROD.OUTLOOK.COM X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 25 Sep 2025 20:08:55.6660 (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: LgdKU1Hw3zx9VD4WMpl8FTHjhCcUozn+VBaW5nfGmDLOfEn715iwAeYT03us+vAOnG2JiIRimbUbhgZB2FdklLiqNtAp0fP58jlUZl356iU= X-MS-Exchange-Transport-CrossTenantHeadersStamped: SY7P300MB1513 Message-ID-Hash: DW7CKX5HZ2D7C6BF2HSISATRSYSX36XU X-Message-ID-Hash: DW7CKX5HZ2D7C6BF2HSISATRSYSX36XU X-MailFrom: u.speidel@auckland.ac.nz X-Mailman-Rule-Misses: dmarc-mitigation; no-senders; approved; loop; banned-address; emergency; member-moderation; nonmember-moderation; administrivia; implicit-dest; max-recipients; max-size; news-moderation; no-subject; digests; suspicious-header X-Mailman-Version: 3.3.10 Precedence: list Subject: [Starlink] Re: Starlink looking less niche as its retail presence expands List-Id: "Starlink has bufferbloat. Bad." Archived-At: List-Archive: List-Help: List-Owner: List-Post: List-Subscribe: List-Unsubscribe: On 26/09/2025 5:45 am, Michael Richardson via Starlink wrote: > I think the only thing worse than bufferbloat is varying bandwidth rates. > That's because the only way to use that bandwidth is to introduce bufferbloat :-) > It was the cablemodem burst mechanism that clued Jim into bufferbloat. > > So my related question is, if they could mitigate, they likely can't do it > continuously, so things will up/down. The IETF now has a SCONE WG, with the > aim of inserting signals into QUIC traffic about bandwidth available. > Yes, meddling by middle boxes. Ick. > > Could Starlink even do this given the lack of L3 processing along the > entire link? At least according to Dr. Pan's diagrams. > (An L2 hop could well mess with packets too). > Ideally, one or more of the satellites involved in the ISL would > know what the current bandwidth to a given terminal is, and could inform the > end system. I'd expect almost any modern communication system these days to operate with a more complex protocol stack than just the good old textbook OSI ... so your "L2" may actually be sitting on top of a layer running UDP over IP, for example. In that sense, L2 and L3 as labels mean very little these days, and issues at one layer can actually come about as a result of this complexity, having been introduced further down the stack. > > The two questions: > 1. are the limits/conditions stable enough for long enough that the available > bandwidth could be communicated back to the uplink? Um yes, but I wouldn't work on the assumption of shared bandwidth (in the sense of "sharing the same Ethernet cable" here). The uplink/downlink bandwidth an end user on Starlink gets is almost certainly determined by the assignment of a time slot or slots on a certain frequency (beam) subband(s). You could add other parameters to this (e.g., spreading code, polarisation, ...). This is an assignment made by Starlink's scheduler, and the only thing that's certain here is that for a given satellite, the maximum total number of frequency subbands and time slots is fixed. These have to be shared between all users of the satellite. Quite how many slots someone gets therefore depends on the number of other users and whatever they get, plus whatever Starlink might want / need to reserve for regulatory and other reasons. Of course, every 15 seconds, things change: Existing users get handed over to new satellites, new users join the present one, and slots get redistributed. Switching to user perspective, getting handed over to a new satellite at the 15 second point means potentially getting a completely different share of bandwidth. Even staying with the same satellite does. Whatever the cwnd value of participating TCP sockets is at that point, it's not adapted to what you're dealing with here. > > 2. assuming, yes, what would the best place to do the SCONE marking? > > >> Let's recap: Spectrum's boxed in, and power is boxed in. That imposes > >> a hard limit on total capacity (look up the Shannon-Hartley Capacity > >> Theorem if you don't believe me). This capacity is all that Starlink > >> has to share among its users in a cell. No matter how many satellites > >> they launch or how big the rocket. Add more users in a cell, and the > >> capacity per user there has to go down. Law of nature. > > And users will need to know what they have on a minute-by-minute basis so > that they avoid screwing themselves, let alone their neighbours. > Packets going up the link, then being dropped, is just wasted. Now there's also the data that's in transit from the Internet to the user. That'll have to hit a queue somewhere, from where it then gets uplinked to the satellite that serves the user it's destined for. Given that TCP senders out there have the RFC-given right to transmit data whenever they think fit, the Internet has zero control over when a TCP segment hits that queue, however. Now imagine that it hits that queue just before the user in question gets handed over to a different satellite ... and it doesn't make it out of the queue before the user gets passed on. Then where does that data go? I think it was Geoff Huston who told me that he'd observed packet loss at the handover times and that's probably what he was looking at here. -- **************************************************************** 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/ ****************************************************************