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 B48D03B2A4 for ; Mon, 27 Mar 2023 23:58:51 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=auckland.ac.nz; s=mimecast20200506; t=1679975929; 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=AxPlvw2KVLzn+uTOY1Eu/diY+JUUyHLFJT8q6rhOxw8=; b=ZeWzX66IPXFl24jPuesj7qqIET7kffNDUISsCXrDZrFXlZEOMf9KT9db2exsKgSKTc5P1d 1UW821LabzZ1jNVmdeRaremQtx5GwmR+VFJiESBTo3KZjnc2B0UtZEhlt9xyIB9r81PQyr ncTVNUwqGOxfCsXcFYfYTsWXbO1vWco= Received: from AUS01-SY4-obe.outbound.protection.outlook.com (mail-sy4aus01lp2176.outbound.protection.outlook.com [104.47.71.176]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id au-mta-40-voznDCPaMdiiD1bFeMTsog-1; Tue, 28 Mar 2023 14:58:46 +1100 X-MC-Unique: voznDCPaMdiiD1bFeMTsog-1 Received: from SY4PR01MB6979.ausprd01.prod.outlook.com (2603:10c6:10:142::13) by ME3PR01MB6739.ausprd01.prod.outlook.com (2603:10c6:220:124::8) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.6178.41; Tue, 28 Mar 2023 03:58:44 +0000 Received: from SY4PR01MB6979.ausprd01.prod.outlook.com ([fe80::7606:e0d1:21c8:6e83]) by SY4PR01MB6979.ausprd01.prod.outlook.com ([fe80::7606:e0d1:21c8:6e83%4]) with mapi id 15.20.6222.033; Tue, 28 Mar 2023 03:58:44 +0000 Message-ID: <9d6facf6-faf4-efd4-d4e4-a709c74b5b39@auckland.ac.nz> Date: Tue, 28 Mar 2023 16:58:41 +1300 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:102.0) Gecko/20100101 Thunderbird/102.9.0 To: starlink@lists.bufferbloat.net References: <768s6nq6-q9q8-741s-75o6-72qp279482rr@ynat.uz> From: Ulrich Speidel In-Reply-To: <768s6nq6-q9q8-741s-75o6-72qp279482rr@ynat.uz> X-ClientProxiedBy: SYBPR01CA0178.ausprd01.prod.outlook.com (2603:10c6:10:52::22) To SY4PR01MB6979.ausprd01.prod.outlook.com (2603:10c6:10:142::13) MIME-Version: 1.0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: SY4PR01MB6979:EE_|ME3PR01MB6739:EE_ X-MS-Office365-Filtering-Correlation-Id: c64ff223-1f6b-48e1-eb5a-08db2f40b8f5 X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0 X-Microsoft-Antispam-Message-Info: Rbed7qx+GLvANCzASFWmJqet4BM7+i+an/pQW4ZL4q3f0o2NPCjE1FQCtF3+Vol1I6fYpt13dyA75aejMuXxvzLO2d2C1KZEJtsgOAdGP62Kyv7cQpUzMlnbOIoLpfotzdBmox02/llxtk5vOy64Q7W0MzSLVB+HlWRMjnqco1UIaMhuBIQMXbkxe/rSOIEDgkbJ3T95T9ScVDaPP2gynZeYVrvLbIWwbbN2icNMc1ft1wsln+vKLUWv8UCLHphpy1dhCqZ7rprfOoQSmdNG1Q1ZvdkUvmF2Mm7WugFvtzFbKHU667fDWtmk5xTYzo2JvkKwihYeNMTVer2i3MSjE3hXjkeonI/8Daqhckl7QF6VqV5jwgceB1Fxrtdu//iKNo7gRfyDwsL/BRe3TabyUofgiIuvuORwinjrxStiod4lGWXSxr0TbzUl4O4HKl4M1uk3eOBdrpMAYNQvK8ahS+TV9JP4vMHbB9lfVBlHl6bZeeBHo2LRNHjL2jY8cUalmdICZgkFX+gFSpgpPoTrX9BkJCUj4DfNHq1gj2wBF8vpqBwF37HqW/5yD4A+CYlJOlpqkrRN2h/g4VDqNlfBNSZrfIGPi9rFaygOFBm62UG85Xm2Y4ZqksheKp7MzZdErkCrqkVRNSlU2bpbHaoJp3GKBfxqm0HRVYFe9Yli3v0cts5spvOWB5Wut2arzn0t 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)(376002)(396003)(136003)(39860400002)(346002)(366004)(451199021)(30864003)(66574015)(5660300002)(2616005)(2906002)(8936002)(166002)(36756003)(86362001)(31696002)(83380400001)(38100700002)(6506007)(6512007)(478600001)(33964004)(53546011)(186003)(316002)(786003)(6666004)(966005)(31686004)(41300700001)(6486002)(66556008)(6916009)(66476007)(8676002)(66946007)(43740500002)(45980500001); DIR:OUT; SFP:1101 X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?utf-8?B?Q3hKOEhCWGNvaW9KRlR2MlZ4d0t0UGRRbE90RVFQTEZIdEdiZnNxRmc4NHRX?= =?utf-8?B?UDFPaCszdmlOSFEwNXl3bW9wZDFrOEhIaUtXbUkydW9jcTFValRETVMwNlhF?= =?utf-8?B?RFZ1eTNsZVdxNlNrSVlhOXAzR0VoTllQNjJNRjlreGd3UGVId1dXY2lWNWx4?= =?utf-8?B?UlRiSUxRUnhBS1FKWWRLTkl1MkNNMmRxM0I0MmE2ZlFudUUxalVsYXBOOWFN?= =?utf-8?B?blU2N2RYTHlpY0JaY3hOamd3T1JBcXQwRnhyalBHQXhkQ1pWS3pPdnhMeXBF?= =?utf-8?B?M3VpMmdTWFhwZDBablBIRmRUdVB0eVB3N2I0NzJkWU5STEhTcmtTTjhyTVZs?= =?utf-8?B?bVdEaHdSZURkSWlVZnZ6RkhjUlJ4bStva3FSTHUvLzNPRHRNTmlFemtYMDZz?= =?utf-8?B?YWJsbUxwUGtGSVEvS3E4T0MzQjJzY1ZYaGhkOXBYb09PdUVIeklhWEZxeUpO?= =?utf-8?B?TE1jNTcvd0lTckhUSk5zck96eDdCN2FsazZ0dUU1RlB3Zm1GK1JDLy9UOGtE?= =?utf-8?B?Tzd2clIybHdBYSttZWFLRVh5TjV4VXNUOVBQb2hqaXVDSG4zbGlrM1ZpM1Ru?= =?utf-8?B?N2s0MEs2M3dYWkpxNXp6b01YeE0vc1E3Vm52NTV0dEozQVZIRG9KODVmdUxF?= =?utf-8?B?dHJYaFZIQTF1R2czOGVWbnkxSWNVVGgybVdDN3ZIcytKNk54RlRRcUtNZlZz?= =?utf-8?B?ZU1iQVlkYnhST0ZwejVyd3B6b0l4TFJnNWlPdUpKTmdhU0QwRnV4QjR0Rk9p?= =?utf-8?B?bE85Z21QNFNXRjdaQzBNbkdNY2s3NExFN2orOEQvMWdRd3hzODBQZmFKYXZO?= =?utf-8?B?WWdMMnU3YS9rWGFsQ2JiTkcybGtzVjFhOXlteFFqMnVCY3l2UElwQjVJREgr?= =?utf-8?B?ZzZCQUo4cjcveUdacFlacEFUZFJxc3VJRmpVRDZWMDFhenBkQWx6Sys4d3VJ?= =?utf-8?B?MXJONk1YcVY5WDg5eHgvMlVWR2FIeUd0ZHMrelgxMWRYb1k4QlJPRURnQktS?= =?utf-8?B?SytyKzdYL1JWNVRIY1d1bThKUjlHaER4VEtUN3lkTVU3R2VmVlJZUjlYRUVL?= =?utf-8?B?cTQweVg5VC9jam90UUIyRGRzL1VaMmlEejdoc3NBaGt4K29DSzhER0FJVW8z?= =?utf-8?B?SXAwTnVyY1BmVFlKVHQ0eVVyMEd2bDNSSkRGRVlNOWYxMFNLSitKODlDTHg3?= =?utf-8?B?bjFjR0VTZkJ3d0NaTDZvbCtBVi91aDMraEJMc1B3VWRKelkwVkdKa1Nvb1ZP?= =?utf-8?B?OE5ESHo0VnNEMlNsWTF2M0NRNnlKMS9vNWRWRm96NXZEWE1rNEdXcnE5T295?= =?utf-8?B?VW4yemg4S1dzNU9JbGdGUmg1RnJFSGhBOFp0aXNrS2ZEMURjb1RVQjk3WWZH?= =?utf-8?B?dlE4dnJMaEJFQ2xsOHh2c29WUXl1eDc4Mm5OaDNjQ3JBUTVCRFVBcXYxazVK?= =?utf-8?B?MXBlUDI5SkFyVk5hbmVyUjhQVkcrb01mcmpwNVVtMXVSYVpxNlQyV0RWWHJI?= =?utf-8?B?TlRxeEdKb2FmcjVYaFlXZEpqUEt3K3RXTzF5NW80aVdUYVVQUjNCUXQ4NnNR?= =?utf-8?B?WXV1VjdnOFVLdUtvdmIwa0V4M2ZHVXNGSTFtUWU1V0NJNEVNTllKNlZLWXlx?= =?utf-8?B?STIyNEd3eFNaN2lZNjlycVJ4Y0J6OFhBUTdBZlpiNjBWZXlWZmxnd3JYKzFG?= =?utf-8?B?dlVkRzVkRW9id0dsd09vaWhlMnlyMmwzc0xvMDdPMGJ6aWxTZE5VaWNRMmxp?= =?utf-8?B?dXVlZDNmd0QvS3NJWVZxZE5oMDJmTjBKZytPbnlRYWV3dkZPUUE4ajYwVk1w?= =?utf-8?B?RjkzMnpRbW5vaUNybnl4VFBNT2owNEpZNDVmVUhMdDZpNy9hTGZ3N01McDFl?= =?utf-8?B?M0dJejI4Tm9LOGpnSDVod09uZGhucmVXVENaRm5sZjNubWw1cjhLUzYvVGJD?= =?utf-8?B?anF0UFp6UzVpa080aWdLcWJ5d3NUenczRkZFTnBCLytJK3hDRmx5TzBscnhs?= =?utf-8?B?SkRoNVRqN25vZVhNcGR6dVBQc0xSOXRhSVd0aHFPdE1zOWc2ZWhoNHZnSWtj?= =?utf-8?B?dXNJN21hTlNiVzE0cWNodVZmVmVqcDJVRGtvUUJVcVdFTkkzT3llbEpPTjNP?= =?utf-8?B?NS9FcS9UdjBrUjNCUFdabW9HY2lZWUQ3ZW9XZW5pSnFkSnpNUUJiSzdybWZG?= =?utf-8?B?QjBvVUd1TjJUbHgwdkFXVzNHVjNuVjJRWTFaNUZMTFMyWDZobFMrSlJnLzRO?= =?utf-8?B?SDczY2VOOWxySmZKdzE0Mk8wYlFRPT0=?= X-OriginatorOrg: auckland.ac.nz X-MS-Exchange-CrossTenant-Network-Message-Id: c64ff223-1f6b-48e1-eb5a-08db2f40b8f5 X-MS-Exchange-CrossTenant-AuthSource: SY4PR01MB6979.ausprd01.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 28 Mar 2023 03:58:43.9870 (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: CsQrOHhg8iccaaaBqxHgM+R6cfnJKrcWvAjOU19k/PVepuj3vhtGizpXCgIg1898WH33djV4bniPXrBLS8GSWMyxoss8YZMz1JWs57zwIDE= X-MS-Exchange-Transport-CrossTenantHeadersStamped: ME3PR01MB6739 X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: auckland.ac.nz Content-Type: multipart/alternative; boundary="------------sJxZvO66qxkql7Slk31Ttzu2" Content-Language: en-US Subject: Re: [Starlink] Starlink ISL data 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: Tue, 28 Mar 2023 03:58:52 -0000 --------------sJxZvO66qxkql7Slk31Ttzu2 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: quoted-printable Still not seeing any IPv6 from a roaming unit in New Zealand, although I=20 notice Starlink advertising global maritime coverage now, which requires=20 the laser links to work at least a little bit. Dave, I'm currently collecting more flent data for you - did so the=20 other week but then realised that the directory the data was going to=20 was cloud synced, so wouldn't have made for a fair measurement given=20 that it would have synced via Starlink, too. As for the jumps in performance, that's easily explained: As dishy=20 switches to a different satellite, it sees a different queue, but the=20 satellite that this queue belongs to also sees a different set of users=20 with different cardinality, doing different things. So if you're=20 switching to a satellite that sits over an area with low Starlink user=20 density, you're likely to see a shorter queue (less latency) than if=20 you're thrown in with the crowd. If it's the BBR where a significant=20 jump happened, then that could just be coincidence. On 28/03/2023 7:54 am, David Lang via Starlink wrote: > I'm seeing some IPv6 on starlink (and had to troubleshoot another=20 > person on > starlink that had a corporate access problem that was resovled by=20 > disabling > IPv6) > > David Lang > > On Mon, 27 Mar 2023, David Fern=C3=A1ndez via Starlink wrote: > > > Date: Mon, 27 Mar 2023 12:44:26 +0200 > > From: David Fern=C3=A1ndez via Starlink > > Reply-To: David Fern=C3=A1ndez > > To: starlink@lists.bufferbloat.net > > Subject: Re: [Starlink] Starlink ISL data > > > > I thought Starlink was not supporting IPv6, because of this: > > > > https://twitter.com/elonmusk/status/967712110661615616=20 > > > > >> Date: Sun, 26 Mar 2023 19:32:31 -0700 > >> From: Dave Taht > >> To: Dave Taht via Starlink > >> Subject: Re: [Starlink] Starlink ISL data > >> Message-ID: > >> > >> Content-Type: text/plain; charset=3D"utf-8" > >> > >> Nate gave me the opportunity to test a bit of ipv6 access on one of > >> his dishys today. I am going to give p2p a shot, also, and he > >> conveniently has bbr2 installed. It is of course difficult to discern > >> the difference between transport behaviors and their underlying > >> connectivity - for example the BBR2 result attached has a baseline > >> (idle!) latency jump of over 40ms which is hard to explain. > >> > >> Despite these plots saying downloads, they were essentially uploads > >> from his box over the internet. > >> > >> The summary of the data I have so far on this direction is: > >> > >> Cubic, looks like cubic, usually, but not always. BBR rarely looks=20 > like BBR. > >> > >> On Fri, Mar 24, 2023 at 2:46=E2=80=AFPM Dave Taht wrote: > >>> > >>> Vint just asked me a difficult question over here about the > >>> performance of the ISL links for my upcoming AMA next week > >>> > >>> https://twitter.com/mtaht/status/1639361656106156032=20 > > >>> > >>> And to date, we really don't know. We do know it is up!? but... > >>> > >>> has anyone managed to measure p2p ipv6 performance starlink to > >>> starlink over an ISL link as yet? Do we know anyone at the poles? In > >>> general I always look for flent and irtt data, but I'd settle for a, > >>> oh, call it 5-10 minute long packet capture of single iperf flow, > >>> running over tcp cubic (bbr would be great too).... one test in each > >>> direction. > >>> > >>> (in fact that would be great from any starlink terminal to any of my > >>> servers around the world) > >>> > >>> I have some data from a couple of you (thx ulrich in particular!), bu= t > >>> I have not sat down to take it apart as I have been far, far too busy > >>> with libreqos and a bunch of nice, small, competent ISPs deploying > >>> that, to worry about fixing a billionaire's network all that much.... > >>> but I've set aside next week to answer AMAs about everything from all > >>> and sundry, so if you got data, please share? > >>> > >>> -- > >>> Come Heckle Mar 6-9 at: https://www.understandinglatency.com/=20 > > >>> Dave T=C3=A4ht CEO, TekLibre, LLC > >> > >> > >> > >> -- > >> https://www.youtube.com/watch?v=3DtAVwmUG21OY&t=3D6483s=20 > > >> Dave T=C3=A4ht CEO, TekLibre, LLC > >> -------------- next part -------------- > >> A non-text attachment was scrubbed... > >> Name: tcp_ndown_-_starlink-ipv6-cubic.png > >> Type: image/png > >> Size: 145300 bytes > >> Desc: not available > >> URL: > >>=20 > > > >> -------------- next part -------------- > >> A non-text attachment was scrubbed... > >> Name: tcp_ndown_-_starlink-ipv6-bbr2.png > >> Type: image/png > >> Size: 64805 bytes > >> Desc: not available > >> URL: > >>=20 > > > > _______________________________________________ > > Starlink mailing list > > Starlink@lists.bufferbloat.net > > https://lists.bufferbloat.net/listinfo/starlink=20 > =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/ **************************************************************** --------------sJxZvO66qxkql7Slk31Ttzu2 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

Still not seeing any IPv6 from a roaming unit in New Zealand, although I notice Starlink advertising global maritime coverage now, which requires the laser links to work at least a little bit.

Dave, I'm currently collecting more flent data for you - did so the other week but then realised that the directory the data was going to was cloud synced, so wouldn't have made for a fair measurement given that it would have synced via Starlink, too.

As for the jumps in performance, that's easily explained: As dishy switches to a different satellite, it sees a different queue, but the satellite that this queue belongs to also sees a different set of users with different cardinality, doing different things. So if you're switching to a satellite that sits over an area with low Starlink user density, you're likely to see a shorter queue (less latency) than if you're thrown in with the crowd. If it's the BBR where a significant jump happened, then that could just be coincidence.

On 28/03/2023 7:54 am, David Lang via Starlink wrote:
=20 I'm seeing some IPv6 on starlink (and had to troubleshoot another person on
starlink that had a corporate access problem that was resovled by disabling
IPv6)

David Lang

On Mon, 27 Mar 2023, David Fern=C3=A1ndez via Starlink wrote:

> Date: Mon, 27 Mar 2023 12:44:26 +0200
> From: David Fern=C3=A1ndez via Starlink <starlink@lists.bufferbloat.net>
> Reply-To: David Fern=C3=A1ndez <davidfdzp@gmail.com>
> To: starlink@lists.bufferbloat.net
> Subject: Re: [Starlink] Starlink ISL data
>
> I thought Starlink was not supporting IPv6, because of this:
>
> https://twitter.com/elonmusk/status/96771211066= 1615616
>
>> Date: Sun, 26 Mar 2023 19:32:31 -0700
>> From: Dave Taht <dave.taht@gmail.com>
>> To: Dave Taht via Starlink <starlink@lists.bufferbloat.net>
>> Subject: Re: [Starlink] Starlink ISL data
>> Message-ID:
>> <CAA93jw4kcfXiwMw0zKAuQV3BjpW= p6ZvQ2TQFbtEy9CFRN5aY2w@mail.gmail.com>
>> Content-Type: text/plain; charset=3D"utf-8"
>>
>> Nate gave me the opportunity to test a bit of ipv6 access on one of
>> his dishys today. I am going to give p2p a shot, also, and he
>> conveniently has bbr2 installed. It is of course difficult to discern
>> the difference between transport behaviors and their underlying
>> connectivity - for example the BBR2 result attached has a baseline
>> (idle!) latency jump of over 40ms which is hard to explain.
>>
>> Despite these plots saying downloads, they were essentially uploads
>> from his box over the internet.
>>
>> The summary of the data I have so far on this direction is:
>>
>> Cubic, looks like cubic, usually, but not always. BBR rarely looks like BBR.
>>
>> On Fri, Mar 24, 2023 at 2:46=E2=80=AFPM Dave Taht <dave.taht@gmail.com> wrote:
>>>
>>> Vint just asked me a difficult question over here about the
>>> performance of the ISL links for my upcoming AMA next week
>>>
>>> https://twitter.com/mtaht/status/16393616= 56106156032
>>>
>>> And to date, we really don't know. We do know it is up!? but...
>>>
>>> has anyone managed to measure p2p ipv6 performance starlink to
>>> starlink over an ISL link as yet? Do we know anyone at the poles? In
>>> general I always look for flent and irtt data, but I'd settle for a,
>>> oh, call it 5-10 minute long packet capture of single iperf flow,
>>> running over tcp cubic (bbr would be great too).... one test in each
>>> direction.
>>>
>>> (in fact that would be great from any starlink terminal to any of my
>>> servers around the world)
>>>
>>> I have some data from a couple of you (thx ulrich in particular!), but
>>> I have not sat down to take it apart as I have been far, far too busy
>>> with libreqos and a bunch of nice, small, competent ISPs deploying
>>> that, to worry about fixing a billionaire's network all that much....
>>> but I've set aside next week to answer AMAs about everything from all
>>> and sundry, so if you got data, please share?
>>>
>>> --
>>> Come Heckle Mar 6-9 at: https://www.understandinglatency.= com/
>>> Dave T=C3=A4ht CEO, TekLibre, LLC
>>
>>
>>
>> --
>> https://www.youtube.com/watch?v=3DtAVw= mUG21OY&t=3D6483s
>> Dave T=C3=A4ht CEO, TekLibre, LLC
>> -------------- next part --------------
>> A non-text attachment was scrubbed...
>> Name: tcp_ndown_-_starlink-ipv6-cubic.png
>> Type: image/png
>> Size: 145300 bytes
>> Desc: not available
>> URL:
>> <= https://lists.bufferbloat.net/pipermail/starlink/attachments/20230326/32c7f= ed1/attachment.png>
>> -------------- next part --------------
>> A non-text attachment was scrubbed...
>> Name: tcp_ndown_-_starlink-ipv6-bbr2.png
>> Type: image/png
>> Size: 64805 bytes
>> Desc: not available
>> URL:
>> <https://lists.bufferbloat.net/pipermail/starlink/attachments/20230326/= 32c7fed1/attachment-0001.png>
> _______________________________________________
> Starlink mailing list
> Starlink@lists.bufferbloat.net
> https://lists.bufferbloat.net/listinfo/starlink 
______________________________=
_________________
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/
****************************************************************
--------------sJxZvO66qxkql7Slk31Ttzu2--