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 84F723B2A4 for ; Sun, 14 May 2023 04:43:16 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=auckland.ac.nz; s=mimecast20200506; t=1684053793; 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=BK4ZdTmMg9uaWw9YDaiGDSPrZp7pLCESYuUzf0YTTE8=; b=R0BrhdafFKjTBgVthZoTJel7///u/8quc+GDHJOgjckWgJV9FKcaHzV+LamdIljLjNw4ST AOhSkQe3tVI8aA6MIqTnY1DTmEqtSkHlTfkmn1OcXRM8QhQIoAJ+86OT3m217cg7pnv0h3 2exXVdm3nPVYztAGaXhSf9p70B7C8vo= Received: from AUS01-SY4-obe.outbound.protection.outlook.com (mail-sy4aus01lp2170.outbound.protection.outlook.com [104.47.71.170]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id au-mta-42-xUTu2tCgPzKufBcle4_Hag-1; Sun, 14 May 2023 18:43:10 +1000 X-MC-Unique: xUTu2tCgPzKufBcle4_Hag-1 Received: from SY4PR01MB6979.ausprd01.prod.outlook.com (2603:10c6:10:142::13) by SY8PR01MB9093.ausprd01.prod.outlook.com (2603:10c6:10:226::19) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.6387.29; Sun, 14 May 2023 08:43:09 +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.6387.029; Sun, 14 May 2023 08:43:09 +0000 Message-ID: <077e6ad1-d7cc-2d57-39f8-e9646bea32a5@auckland.ac.nz> Date: Sun, 14 May 2023 20:43:05 +1200 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:102.0) Gecko/20100101 Thunderbird/102.11.0 To: David Lang 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> From: Ulrich Speidel In-Reply-To: <728orr66-1432-751p-263q-sqopr12s20sq@ynat.uz> X-ClientProxiedBy: SYAPR01CA0001.ausprd01.prod.outlook.com (2603:10c6:1::13) To SY4PR01MB6979.ausprd01.prod.outlook.com (2603:10c6:10:142::13) MIME-Version: 1.0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: SY4PR01MB6979:EE_|SY8PR01MB9093:EE_ X-MS-Office365-Filtering-Correlation-Id: 1031c3b3-c6e6-4f69-a465-08db54573e55 X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0 X-Microsoft-Antispam-Message-Info: teUpyZRq6S5EdcXBqEUL8ww2dHln7h8+YdVXpJ2Rsz6CtAh/lt6XCzDA3FX3VffaVw13ZozzSoZUYopmceI9F3hR4SEOIheBKbPsSHFWG/IKfUPzTBfkMwq05m+AVicucp5H+g4qf6hQwQfYxpy/18QPJ1aYK5YipF0o38yJgcIlSg3Ch7uq4QvWwAPqMl8cFuUTbtnSCJYZrfcjjCI4+004qCHhsuGjmWDuv0/I/NK87b4VxmrBSkz4RlKfGBjdnlfbIZerHKojnVwJ84AWbSGuGsir8EtTUflZxXNvBTeACcPt8wxOKvAKskPXlwEGX1oizIgzSvODKElBHC4egbFK/WQNyT4pz2iqUOOvH0+yc5zkZMrmhDbiiAMcuuX8EmU1jMURyVwfAO5gXyBTo20mJFuVHYs1Q1q704NOJq2xcsUZPOFCetqaf+ZRZbs3ODa3JnpCM77KxyyD9wCK5yZ0zcrzizPIBbIZdcLjYW6aRXhuklzH6wYj9uVLGU/vjSuVTGnXAPUV3S72GmFbv+61CNpH5L/G6UNFWzujVmN+TnnShvK9uEPEkK1QmAxheOsE3WOTw4NPBggL3Gqp/5K0u8sonYMhxQlPQdf/Py7rBiGXBRDFYcH59etfhJFdy+Es8cNyDzCHMvtqZ3xN/6+g4JYmfAj1yT5N9vAXueZwNHBmw2Pc3iwW+jNUoEtW 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)(396003)(346002)(39860400002)(136003)(366004)(376002)(451199021)(31686004)(33964004)(36756003)(38100700002)(4326008)(6916009)(2906002)(5660300002)(8676002)(8936002)(31696002)(786003)(83380400001)(316002)(86362001)(66946007)(66476007)(66556008)(166002)(41300700001)(966005)(66574015)(186003)(6512007)(6506007)(53546011)(6486002)(478600001)(6666004)(2616005)(43740500002)(45980500001); DIR:OUT; SFP:1101 X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?utf-8?B?QzFsMytnbnRzbnQxUkt6dkozWkgzdW14SWt3cU5WeTJsVFRRV05pbFppeHVW?= =?utf-8?B?T1gyR08wa1RpVlFhWVVHNkszZ3IxOUVPYjM1ckplenNuWUIrbXI4bDE3SlJI?= =?utf-8?B?TExTY0kxWGZXWDdBWG5rbEE2bWorKzhKVll1QTdEMDBYYzJwT2haZDBXcm41?= =?utf-8?B?L1VoeXM2ZStPbWgzMTVOeWNnZGMyWGpuSC84UnNkZ3hna0QyUVZYOGpzRFNL?= =?utf-8?B?S0p6RE5INUFaT1kzcFZRVDVnNUNrS2l4Zmtld1ZBTis4UjR4clhybGV1UTdT?= =?utf-8?B?ZFUrRDMyN0xuMVdEUVNBaUxJdFVmV1JKcjkzcFZjQ1Z1MEVpanF4R2ZWN3VY?= =?utf-8?B?ek5ZRHorV2k1YUhFOVN1WUpISmM1VnUxR3ZMUWxGTlhlWVVvK0pvd3YrSzZU?= =?utf-8?B?eXIzdkcrZmRuMlcyQnlaazVMcHRGMStGZnVhUWF1MGZTVktVeTZMMlh4WU55?= =?utf-8?B?T0pvK3o4RC9Ka2tnQVJRbFZHOGRyQ2tjNVA2WW9jOERPRFhlZTNud0ZiODNu?= =?utf-8?B?NmpWTTgvL0U3Z2w0Q2MrWm5SSDh6VDg3dkZYR3lVT0dtZU1CWFpSeGZDTEU0?= =?utf-8?B?OXkrb2dqb2Z3a3dGWVIvang5TloydXdlS2t3MWFaYVhmRkFGV0t6VmxDUnUw?= =?utf-8?B?ZDFLQXQyUWhVaisrd0NlQUxHR2J3bVFTTHpDRS91VTFWVFlsV1JwR3RGRmdz?= =?utf-8?B?aUUrYWFYeVcvYXNSUGtlMWE3MFJCcTRYNzk3UURpZXRoSjhBNmZ2SFk3Vkhp?= =?utf-8?B?TXZZSkJsNUQyc3JIclRwYmVJWWRQTHJERjJscVFDVlJPNVM5UnFWK1RHRmU4?= =?utf-8?B?dE84cUlOSFp4V0d5WnRJdkV5aXVpTDBHam9GRWYyK05WTnI0djVNdVkwNDg1?= =?utf-8?B?bGkwc3lkLy9VVlRHSWdJN2VSTDFmQ2Nha1N4VVVEKzdua1VXMWw3M3FsK0JD?= =?utf-8?B?dkhvVTlScXk4L1lWVHBJMlF5UUhhYm1zeVRzYXU0NFlCVE1tRUdZSXVVUzFZ?= =?utf-8?B?SU9NWndXMHppV1dOOGt3ZU81a2lCWHJZRHJlbXhGU1BleHdpa1diQ3hoSzNI?= =?utf-8?B?OHUvYnpPakwxZk14V1BybTRxRlB6WXRPZnhvM1k3Yys0MnVMc21GUkcvcmVZ?= =?utf-8?B?dTFZVzUxSHVHYVVadTJaV0R0c0JXTXhoeXdoVERVUkN0Ui8xUUk2TkN6VERn?= =?utf-8?B?QzNEeUJqcFJ2NVFIUDdyTXM4SitXQmNYZWN6ZTJtLzlOcHN4SkdCdzA2NjJW?= =?utf-8?B?bVVsUmsvZWx6TFV4ei96TGJKOTFrTWlkRVA0UE0zOCtJcFBXUFd1Umt1dVV3?= =?utf-8?B?OGQzWnc0S2VNTjB4OGNOVFFMNmZEbTFYOGVoNFhnMjdFNUtLTjYvMXg2Yi9K?= =?utf-8?B?enFqOW9hS09xUzkyK0tUTnVMY0J6NXhYZjFJTDZzWVBqRk5qRXNDZitrb1p1?= =?utf-8?B?N25hZUNXSkJUdTlJRHZiYjVMSy9QMDNGa1NEWGtwVGF6UnJCT0dtcGQ4VWl1?= =?utf-8?B?WCt4SWRmY2lsODN1T0NkUmx3aU1qNEEwa25YSTh0UmFyMnJjUFNhMjBPbjRm?= =?utf-8?B?TE1nbS9oYUNiT1VHOG5PWXpnZGpMOUxqNGV2UCs0VmxiSFZTZFlRSUZnN0sw?= =?utf-8?B?dUw5QnF4R2JBRnlCeFVQekF6aExDMk40UVRRQkFGL0VCSmNVMndGQmpuSFhK?= =?utf-8?B?VURWQmQyeXFJSEVrNkdrVnNMMnBteXBOMVdibzR5SWdXZFdtN3ZYZVNjY25x?= =?utf-8?B?SFZwMzdKR1RDc2lsdHpOQ2ZRTjdZZGgvVTRkc0luRkcyMCtVZXo0SWRBK1Fo?= =?utf-8?B?U1FsVldXc25UL2s0dW9CYWJ4S2pmLzZoWVpib2NzeHFQZlNqV3M1d2Q5eTlv?= =?utf-8?B?OHdQa3U2OTd3dnd1U3BCWUJZYjBHMDB1aVptazF2WFJlVjlEVHZiVncrN0dY?= =?utf-8?B?cldhbEtsb1hMRVJkdlBySVBlcmI1QmZMY3M4ZDliSG5SNi8yQ3ZOb3hYKzI1?= =?utf-8?B?T0ppV0VWS1djYVhIL3AxWEx0a3lURVFLWTVhZWhQd3pYLzhOTHdGVC8vVUNJ?= =?utf-8?B?UWRBalZxbldxRXFFejlVbDlhQWpaMW9QaUJMMG41bTJPYUxBYUkyUzRXSUdD?= =?utf-8?B?OU5vUmVwdkxKWFVseUkvNFhVVGh6OTgwb2x4L0xIb24vQjRHTEZ2NXJ1Mktk?= =?utf-8?B?U2MwMFp5dFU5U1VYbkVaWTUxbi92ZXBEN2pqaG1VNWhxaUpBKzdUbmNFbldW?= =?utf-8?B?SHVScnRUMUZqaVF1VHRNYTFLNE1BPT0=?= X-OriginatorOrg: auckland.ac.nz X-MS-Exchange-CrossTenant-Network-Message-Id: 1031c3b3-c6e6-4f69-a465-08db54573e55 X-MS-Exchange-CrossTenant-AuthSource: SY4PR01MB6979.ausprd01.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 14 May 2023 08:43:08.8788 (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: 4rnIiL7zDDlVibxDazKHaW51b0gtm+WAxRWaRoWaOolbTweq6sVYnehrEMPafpAhSzrQCwCYXhojtMgzJ4M4jSoAcygUFqUJAZBWtXa4fIo= X-MS-Exchange-Transport-CrossTenantHeadersStamped: SY8PR01MB9093 X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: auckland.ac.nz Content-Type: multipart/alternative; boundary="------------npOjopAZIJTWLJIsGqdwOzlr" 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: Sun, 14 May 2023 08:43:17 -0000 --------------npOjopAZIJTWLJIsGqdwOzlr Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: quoted-printable On 14/05/2023 6:55 pm, David Lang wrote: > > I just discovered that someone is manufacturing an adapter so you no=20 > longer have > to cut the cable > > https://www.amazon.com/YAOSHENG-Rectangular-Adapter-Connect-Injector/dp/B= 0BYJTHX4P=20 > > I'll see whether I can get hold of one of these. Cutting a cable on a=20 university IT asset as an academic is not allowed here, except if it=20 doesn't meet electrical safety standards. Alternatively, has anyone tried the standard Starlink Ethernet adapter=20 with a PoE injector instead of the WiFi box? The adapter above seems to=20 be like the Starlink one (which also inserts into the cable between=20 Dishy and router). > > Put another way: If you have a protocol (TCP) that is designed to=20 > reasonably > > expect that its current cwnd is OK to use for now is put into a=20 > situation > > where there are relatively frequent, huge and lasting step changes in > > available BDP within subsecond periods, are your underlying=20 > assumptions still > > valid? > > I think that with interference from other APs, WIFI suffers at least=20 > as much > unpredictable changes to the available bandwidth. Really? I'm thinking stuff like the sudden addition of packets from=20 potentially dozens of TCP flows with large cwnd's? > > > I suspect they're handing over whole cells, not individual users, at=20 > a time. > > I would guess the same (remember, in spite of them having launched >4000 > satellites, this is still the early days, with the network changing as=20 > more are > launching) > > We've seen that it seems that there is only one satellite serving any=20 > cell at > one time.=20 But the reverse is almost certainly not true: Each satellite must serve=20 multiple cells. > But remember that the system does know how much usage there is in the > cell before they do the handoff. It's unknown if they do anything with=20 > that, or > if they are just relaying based on geography. We also don't know what the > bandwidth to the ground stations is compared to the dishy. Well, we do know for NZ, sort of, based on the licences Starlink has here. > > And remember that for every cell that a satellite takes over, it's=20 > also giving > away one cell at the same time. Yes, except that some cells may have no users in them and some of them=20 have a lot (think of a satellite flying into range of California from=20 the Pacific, dropping over-the-water cells and acquiring land-based ones). > > I'm not saying that the problem is trivial, but just that it's not unique What makes me suspicious here that it's not the usual bufferbloat=20 problem is this: With conventional bufferbloat and FIFOs, you'd expect=20 standing queues, right? With Starlink, we see the queues emptying=20 relatively occasionally with RTTs in the low 20 ms, and in some cases=20 under 20 ms even. With large ping packets (1500 bytes). > > David Lang --=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/ **************************************************************** --------------npOjopAZIJTWLJIsGqdwOzlr Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On 14/05/2023 6:55 pm, David Lang wrote:
=20
I just discovered that someone is manufacturing an adapter so you no longer have
to cut the cable

https://www.amazon.com/Y= AOSHENG-Rectangular-Adapter-Connect-Injector/dp/B0BYJTHX4P

I'll see whether I can get hold of one of these. Cutting a cable on a university IT asset as an academic is not allowed here, except if it doesn't meet electrical safety standards.

Alternatively, has anyone tried the standard Starlink Ethernet adapter with a PoE injector instead of the WiFi box? The adapter above seems to be like the Starlink one (which also inserts into the cable between Dishy and router).

> Put another way: If you have a protocol (TCP) that is designed to reasonably
> expect that its current cwnd is OK to use for now is put into a situation
> where there are relatively frequent, huge and lasting step changes in
> available BDP within subsecond periods, are your underlying assumptions still
> valid?

I think that with interference from other APs, WIFI suffers at least as much
unpredictable changes to the available bandwidth.
Really? I'm thinking stuff like the sudden addition of packets from potentially dozens of TCP flows with large cwnd's? 

> I suspect they're handing over whole cells, not individual users, at a time.

I would guess the same (remember, in spite of them having launched >4000
satellites, this is still the early days, with the network changing as more are
launching)

We've seen that it seems that there is only one satellite serving any cell at
one time.
But the reverse is almost certainly not true: Each satellite must serve multiple cells.
But remember that the system does know how much usage there is in the
cell before they do the handoff. It's unknown if they do anything with that, or
if they are just relaying based on geography. We also don't know what the
bandwidth to the ground stations is compared to the dishy.
Well, we do know for NZ, sort of, based on the licences Starlink has here.

And remember that for every cell that a satellite takes over, it's also giving
away one cell at the same time.
Yes, except that some cells may have no users in them and some of them have a lot (think of a satellite flying into range of California from the Pacific, dropping over-the-water cells and acquiring land-based ones).

I'm not saying that the problem is trivial, but just that it's not unique
What makes me suspicious here that it's not the usual bufferbloat problem is this: With conventional bufferbloat and FIFOs, you'd expect standing queues, right? With Starlink, we see the queues emptying relatively occasionally with RTTs in the low 20 ms, and in some cases under 20 ms even. With large ping packets (1500 bytes).

David Lang
--=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/
****************************************************************
--------------npOjopAZIJTWLJIsGqdwOzlr--