[Starlink] Starlink Digest, Vol 42, Issue 2
Werner Coomans (Nokia)
werner.coomans at nokia-bell-labs.com
Mon Sep 2 06:00:14 EDT 2024
Hi all,
Saw some questions on L4S: it definitely is a solution to bufferbloat. L4S requires an update to both the application (congestion control) as well as the network side of things (separate queuing, immediate ECN-marking AQM, rate-protection for non-L4S traffic), to improve how application and network cooperate leveraging ECN marking instead of packet drops or delay measurements as a congestion signal.
Here's a 30 min tutorial on the topic (recording and slides of a talk I gave at RIPE88):
https://ripe88.ripe.net/archives/video/1297/
Kr,
Werner.
-----Original Message-----
From: Starlink <starlink-bounces at lists.bufferbloat.net> On Behalf Of starlink-request at lists.bufferbloat.net
Sent: Monday, September 2, 2024 11:37 AM
To: starlink at lists.bufferbloat.net
Subject: Starlink Digest, Vol 42, Issue 2
[You don't often get email from starlink-request at lists.bufferbloat.net. Learn why this is important at https://aka.ms/LearnAboutSenderIdentification ]
CAUTION: This is an external email. Please be very careful when clicking links or opening attachments. See the URL nok.it/ext for additional information.
Send Starlink mailing list submissions to
starlink at lists.bufferbloat.net
To subscribe or unsubscribe via the World Wide Web, visit
https://lists.bufferbloat.net/listinfo/starlink
or, via email, send a message with subject or body 'help' to
starlink-request at lists.bufferbloat.net
You can reach the person managing the list at
starlink-owner at lists.bufferbloat.net
When replying, please edit your Subject line so it is more specific than "Re: Contents of Starlink digest..."
Today's Topics:
1. Re: An update on Tonga (Michael Richardson)
2. Re: [Make-wifi-fast] bloat on wifi8 and 802.11 wg (David Lang)
3. Re: [Make-wifi-fast] bloat on wifi8 and 802.11 wg (David Lang)
4. Re: An update on Tonga (Ulrich Speidel)
----------------------------------------------------------------------
Message: 1
Date: Sun, 01 Sep 2024 22:26:40 -0400
From: Michael Richardson <mcr at sandelman.ca>
To: Ulrich Speidel <u.speidel at auckland.ac.nz>,
"starlink at lists.bufferbloat.net" <starlink at lists.bufferbloat.net>
Subject: Re: [Starlink] An update on Tonga
Message-ID: <22997.1725244000 at obiwan.sandelman.ca>
Content-Type: text/plain; charset="utf-8"
Ulrich Speidel via Starlink <starlink at lists.bufferbloat.net> wrote:
> There were quite a few folk on this list a couple of years back who were
> interested in what was happening to Internet in Tonga after the big volcanic
> eruption there. I'm not sure where I left off.
Thank you for the update.
> Spare cable was ordered from France and was installed middle of 2023,
> restoring the TDCE to service.
How long was the outage caused by lack of spare cable?
Is there an effort to keep more spare cable closer?
> location. The operators were well aware of the risk, however re-routing the
> cable would have required it to be lengthened, with the need to insert
> repeaters, upgrade terminal equipment, and conduct a new marine survey, which
> would have meant further delays.
Is this on the long-term plan?
> On 26 August 2024, 11:29 am, a M6.9 quake struck in the area at a depth of
> about 106 km. Our Science building in Auckland has a "citizen science"
> seismograph with a big display in its foyer, and my student and I noticed the
That's pretty neat.
> Meanwhile, Starlink has been licensed to operate commercially in Tonga. For
> many Pacific Island countries, this is a double-edged sword: On the one hand,
> this provides short-term relief, on the other hand, it deprives local ISPs of
> customers and therefore impacts on aspirations to achieve cable connectivity
> which could provide more bandwidth in the medium term.
Yeah. I see those edges.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 511 bytes
Desc: not available
URL: <https://lists.bufferbloat.net/pipermail/starlink/attachments/20240901/c3c9ae3c/attachment-0001.sig>
------------------------------
Message: 2
Date: Sun, 1 Sep 2024 19:59:43 -0700 (PDT)
From: David Lang <david at lang.hm>
To: Bob McMahon <bob.mcmahon at broadcom.com>
Cc: Dave Taht <dave.taht at gmail.com>, David Fernández
<davidfdzp at gmail.com>, Make-Wifi-fast
<make-wifi-fast at lists.bufferbloat.net>, Dave Taht via Starlink
<starlink at lists.bufferbloat.net>, bloat
<bloat at lists.bufferbloat.net>, Dorothy Stanley
<dstanley1389 at gmail.com>
Subject: Re: [Starlink] [Make-wifi-fast] bloat on wifi8 and 802.11 wg
Message-ID: <0p31n75o-9o83-o9q6-1315-2os9p65450s5 at ynat.uz>
Content-Type: text/plain; charset="utf-8"; Format="flowed"
It really doesn't help that everyone in the industry is pushing for higher bandwidth for a single host. That's a nice benchmark number, but not really relevant int he real world.
Even mu-mimo is of limited use as most routers only handle a handful of clients.
But the biggest problem is just the push to use wider channels and gain efficiency in long-running bulk transfers by bundling lots of IP packets into a single transmission. This works well when you don't have congestion and have a small number of clients. But when you have lots of clients, spanning many generations of wifi technology, you need to go to narrower channels, but more separate routers to maximize the fairness of available airtime.
David Lang
On Sun, 1 Sep 2024, Bob McMahon via Starlink wrote:
> Date: Sun, 1 Sep 2024 18:15:11 -0700
> From: Bob McMahon via Starlink <starlink at lists.bufferbloat.net>
> Reply-To: Bob McMahon <bob.mcmahon at broadcom.com>
> To: Dave Taht <dave.taht at gmail.com>
> Cc: David Fernández <davidfdzp at gmail.com>,
> Make-Wifi-fast <make-wifi-fast at lists.bufferbloat.net>,
> Dave Taht via Starlink <starlink at lists.bufferbloat.net>,
> bloat <bloat at lists.bufferbloat.net>,
> Dorothy Stanley <dstanley1389 at gmail.com>
> Subject: Re: [Starlink] [Make-wifi-fast] bloat on wifi8 and 802.11 wg
>
> There is a lot of confusion on the 802.11 latency technology options.
> I think waiting for Wi-Fi 8 to solve this is a non starter. Solutions
> have to work for 20B devices already in the field.
>
> The silo'ing hasn't helped here. Those that cross the silos are needed
> by my judgment. It means deep dives into 802.11 which now is a 25 year
> old set of standards. Those with 25 years of 802.11 standards
> expertise are as rare as hen's teeth and are worth their weight in gold.
>
> Bob
>
> On Wed, May 8, 2024 at 8:35 AM Dave Taht via Make-wifi-fast <
> make-wifi-fast at lists.bufferbloat.net> wrote:
>
>> I wish I had gone to the 802.11wg more regularly than I did. I only
>> gave one bloat related presentation in 2014, shipped the
>> make-wifi-fast code in 2016(?), and never went back. IETF ate all my
>> money and time. I just assumed they were all in the slipstream of
>> linux and openwrt. :/
>>
>> I did have a great meetup a few weeks back with the former 802.11
>> chair (dorothy stanley, hi!!!) who is trying to recruit people to
>> participate in the wifi8 standard and perhaps some finishing touches
>> on wifi7. She gave a great update on the status of things at the
>> recent wifinow conference, but as there is a cost to that, perhaps
>> she can share her slides with us?
>>
>>
>> https://wif/
>> inowglobal.com%2Fproduct%2Fwi-fi-world-congress-usa-2024-sarasota-flo
>> rida-presentations-pdf%2F%3Fmc_cid%3Dbeb1b4a2ed%26mc_eid%3D327a64ba92
>> &data=05%7C02%7Cwerner.coomans%40nokia-bell-labs.com%7C5f886ef7e55342
>> 02af9308dccb32c099%7C5d4717519675428d917b70f44f9630b0%7C0%7C0%7C63860
>> 8666077141155%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2l
>> uMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7C%7C%7C&sdata=cNV%2Bvj0KCOOB
>> s20wD0RCplWnSH%2B2LdcQy8uySRvRNvw%3D&reserved=0
>>
>> On Wed, May 8, 2024 at 8:28 AM Livingood, Jason via Bloat
>> <bloat at lists.bufferbloat.net> wrote:
>>>
>>> Dropping Starlink as Bloat is the right list. The IEEE 802.11 domain
>>> is
>> certainly different than IP, so typical IP CCs don’t apply. In our
>> L4S/NQB trials, we put LL-marked packets into the AC_VI WMM queue in
>> the Wi-Fi network. IMO there is more work in 802.11 to focus on
>> latency – so much focus right now is on throughput over everything else.
>>>
>>>
>>>
>>> From: Starlink <starlink-bounces at lists.bufferbloat.net> on behalf of
>> Rich Brown via Starlink <starlink at lists.bufferbloat.net>
>>> Reply-To: Rich Brown <richb.hanover at gmail.com>
>>> Date: Wednesday, May 8, 2024 at 07:33
>>> To: David Fernández <davidfdzp at gmail.com>
>>> Cc: starlink <starlink at lists.bufferbloat.net>, bloat <
>> bloat at lists.bufferbloat.net>
>>> Subject: Re: [Starlink] [Bloat] L4S
>>>
>>>
>>>
>>> Let's split this thread and use this message to continue the
>>> discussion
>> of L4S. Thanks
>>>
>>>
>>>
>>> On May 8, 2024, at 5:31 AM, David Fernández via Starlink <
>> starlink at lists.bufferbloat.net> wrote:
>>>
>>>
>>>
>>> I see that L4S is not really solving everything (I read about issues
>> with Wi-Fi), although it seems to be a step in the right direction,
>> to be improved, let's hope.
>>>
>>>
>>>
>>> At least, Nokia is implementing it in its network gear (for mobile
>> operators), so the bufferbloat problem is somehow acknowledged by
>> industry, at least initially or partially.
>>>
>>>
>>>
>>> I have seen two consecutive RFCs to 9330:
>>>
>>> https://ww/
>>> w.rfc-editor.org%2Finfo%2Frfc9331&data=05%7C02%7Cwerner.coomans%40no
>>> kia-bell-labs.com%7C5f886ef7e5534202af9308dccb32c099%7C5d47175196754
>>> 28d917b70f44f9630b0%7C0%7C0%7C638608666077145657%7CUnknown%7CTWFpbGZ
>>> sb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0
>>> %3D%7C0%7C%7C%7C&sdata=HZqQeBMyA8fKx9KmCuxayAzPCqD%2BROajb7PwKU2v%2F
>>> JM%3D&reserved=0
>>>
>>> https://ww/
>>> w.rfc-editor.org%2Finfo%2Frfc9332&data=05%7C02%7Cwerner.coomans%40no
>>> kia-bell-labs.com%7C5f886ef7e5534202af9308dccb32c099%7C5d47175196754
>>> 28d917b70f44f9630b0%7C0%7C0%7C638608666077149877%7CUnknown%7CTWFpbGZ
>>> sb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0
>>> %3D%7C0%7C%7C%7C&sdata=Lz%2BCWmdMghtNI2ep81LnuZtIACOrCY8I%2Fg1PLT0bu
>>> %2Bc%3D&reserved=0
>>>
>>>
>>>
>>> I suspect that optimal results require the bufferbloat to be
>>> addressed
>> not only at network layer (IP), but also with some pipelining or
>> cross-layering at link level (Ethernet, Wi-Fi or any other link
>> technology, such as 5G, SATCOM, VHF...)
>>>
>>>
>>>
>>> Regards,
>>>
>>>
>>>
>>> David F.
>>>
>>>
>>>
>>> Date: Tue, 7 May 2024 08:46:03 -0400
>>>
>>> From: Dave Collier-Brown <dave.collier-Brown at indexexchange.com>
>>> To: starlink at lists.bufferbloat.net
>>> Subject: Re: [Starlink] The "reasons" that bufferbloat isn't a
>>> problem
>>> Message-ID: <3d6bdccf-e3d1-4f62-a029-25bfd1f458f5 at indexexchange.com>
>>> Content-Type: text/plain; charset="utf-8"; Format="flowed"
>>>
>>> It has an RFC at
>>> https://da/
>>> tatracker.ietf.org%2Fdoc%2Frfc9330%2F&data=05%7C02%7Cwerner.coomans%
>>> 40nokia-bell-labs.com%7C5f886ef7e5534202af9308dccb32c099%7C5d4717519
>>> 675428d917b70f44f9630b0%7C0%7C0%7C638608666077154001%7CUnknown%7CTWF
>>> pbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI
>>> 6Mn0%3D%7C0%7C%7C%7C&sdata=8d1EGzo8t733O7DIdderGqRcGqozRd9Pk8VZzjE9i
>>> 3o%3D&reserved=0
>>>
>>> I read it as a way to rapidly find the available bandwidth without
>>> the
>> TCP "sawtooth". The paper cites fc_codel and research based on it.
>>>
>>> I suspect My Smarter Colleagues know more (;-))
>>>
>>> --dave
>>>
>>>
>>>
>>> On 2024-05-07 08:13, David Fernández via Starlink wrote:
>>> Is L4S a solution to bufferbloat? I have read that gamers are happy
>>> with
>> it.
>>>
>>> Sorry, I read it here, in Spanish:
>>>
>> https://www/
>> .adslzone.net%2Fnoticias%2Foperadores%2Fretardo-videojuegos-nokia-vod
>> afone&data=05%7C02%7Cwerner.coomans%40nokia-bell-labs.com%7C5f886ef7e
>> 5534202af9308dccb32c099%7C5d4717519675428d917b70f44f9630b0%7C0%7C0%7C
>> 638608666077158133%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIj
>> oiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7C%7C%7C&sdata=plf%2BfvE
>> a24IYvafwoMw1TOvwmure4nxHFHeADKGapes%3D&reserved=0
>>>
>>> Regards,
>>>
>>> David F.
>>>
>>> _______________________________________________
>>> Starlink mailing list
>>> Starlink at lists.bufferbloat.net
>>> https://li/
>>> sts.bufferbloat.net%2Flistinfo%2Fstarlink&data=05%7C02%7Cwerner.coom
>>> ans%40nokia-bell-labs.com%7C5f886ef7e5534202af9308dccb32c099%7C5d471
>>> 7519675428d917b70f44f9630b0%7C0%7C0%7C638608666077162310%7CUnknown%7
>>> CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJ
>>> XVCI6Mn0%3D%7C0%7C%7C%7C&sdata=FWa5c5Lg6VUkkOFwS23HIWZbM1HinVSVKTupx
>>> c6ayRM%3D&reserved=0
>>>
>>>
>>>
>>> _______________________________________________
>>> Bloat mailing list
>>> Bloat at lists.bufferbloat.net
>>> https://li/
>>> sts.bufferbloat.net%2Flistinfo%2Fbloat&data=05%7C02%7Cwerner.coomans
>>> %40nokia-bell-labs.com%7C5f886ef7e5534202af9308dccb32c099%7C5d471751
>>> 9675428d917b70f44f9630b0%7C0%7C0%7C638608666077166588%7CUnknown%7CTW
>>> FpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVC
>>> I6Mn0%3D%7C0%7C%7C%7C&sdata=PNyMtAJIa3rKTg%2F1OdNcVt9RkkJ91jVqE4rSWB
>>> tsTYQ%3D&reserved=0
>>
>>
>>
>> --
>> https://www/
>> .youtube.com%2Fwatch%3Fv%3DBVFWSyMp3xg%26t%3D1098s&data=05%7C02%7Cwer
>> ner.coomans%40nokia-bell-labs.com%7C5f886ef7e5534202af9308dccb32c099%
>> 7C5d4717519675428d917b70f44f9630b0%7C0%7C0%7C638608666077171448%7CUnk
>> nown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haW
>> wiLCJXVCI6Mn0%3D%7C0%7C%7C%7C&sdata=QEG0RSbucDsZoTmdPjKxfITMjOzbjX%2B
>> 8o5D3RN4ZOwA%3D&reserved=0 Waves Podcast Dave Täht CSO, LibreQos
>> _______________________________________________
>> Make-wifi-fast mailing list
>> Make-wifi-fast at lists.bufferbloat.net
>> https://lis/
>> ts.bufferbloat.net%2Flistinfo%2Fmake-wifi-fast&data=05%7C02%7Cwerner.
>> coomans%40nokia-bell-labs.com%7C5f886ef7e5534202af9308dccb32c099%7C5d
>> 4717519675428d917b70f44f9630b0%7C0%7C0%7C638608666077177514%7CUnknown
>> %7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLC
>> JXVCI6Mn0%3D%7C0%7C%7C%7C&sdata=G%2Biw7GxdJb%2BxDREXyjqE9iqulB15keBWc
>> YZuGezT3C0%3D&reserved=0
>
>
-------------- next part --------------
_______________________________________________
Starlink mailing list
Starlink at lists.bufferbloat.net
https://lists.bufferbloat.net/listinfo/starlink
------------------------------
Message: 3
Date: Sun, 1 Sep 2024 22:05:03 -0700 (PDT)
From: David Lang <david at lang.hm>
To: Hal Murray <halmurray+mwf at sonic.net>
Cc: Make-Wifi-fast <make-wifi-fast at lists.bufferbloat.net>, Starlink
<starlink at lists.bufferbloat.net>, bloat <bloat at lists.bufferbloat.net>
Subject: Re: [Starlink] [Make-wifi-fast] bloat on wifi8 and 802.11 wg
Message-ID: <13so850r-s23q-r0sp-0nqp-ss9q2q522542 at ynat.uz>
Content-Type: text/plain; charset=US-ASCII; format=flowed
On Sun, 1 Sep 2024, Hal Murray via Make-wifi-fast wrote:
> David Lang said:
>> It really doesn't help that everyone in the industry is pushing for
>> higher bandwidth for a single host. That's a nice benchmark number,
>> but not really relevant int he real world.
>
>> Even mu-mimo is of limited use as most routers only handle a handful
>> of clients.
>
>> But the biggest problem is just the push to use wider channels and
>> gain efficiency in long-running bulk transfers by bundling lots of IP
>> packets into a single transmission. This works well when you don't
>> have congestion and have a small number of clients. But when you
>> have lots of clients, spanning many generations of wifi technology,
>> you need to go to narrower channels, but more separate routers to
>> maximize the fairness of available airtime.
>
> What does that say about the minimal collection of gear required in a
> test lab?
>
> If you had a lab with plenty of gear, what tests would you run?
I'll start off by saying that my experience is from practical in-the-field uses, deploying wifi to support thousands of users in a conference setting. It's possible that some people are doing the tests I describe below in their labs, but from the way routers and wifi standards are advertised and the guides to deploy them are written, it doesn't seem like they are.
My belief is that most of the tests are done in relatively clean RF environments where only the devices on the test network exist, and they can always hear everyone on the network. In such environments, everything about existing wifi standards and the push for higher bandwidth channels makes a lot of sense (there are still some latency problems)
But the world outside the lab is far more complex
you need to simulate a dispursed, congested RF environment. This includes hidden transmitters (stations A-B-C where B can hear A and C but A and C cannot hear each other), dealing with weak signals (already covered), interactions of independent networks on the same channels (a-b and c-d that cannot talk to each other), legacy equipment on the network (as slow as 802.11g at least, if not 802.11b to simulate old IoT devices), and a mix of bulk-transfers (download/uploads), buffered streaming (constant traffic, but buffered so not super-sentitive to latency), unbuffered streaming (low bandwidth, but sensitive to latency), and short, latency sensitive traffic (things that block other traffic until they are answered, like DNS, http cache checks, http main pages that they pull lots of other URLs, etc)
test large number of people in a given area (start with an all wireless office, then move on to classroom density), test not just one room, but multiple rooms that partially hear each other (the amount of attenuation or reflection between the rooms needs to vary). The ultimate density test would be a stadium-type setting where you have rows of chairs, but not tables and everyone is trying to livestream (or view a livestream) at once.
Test not just the ultra-wide bandwidth with a single AP in the rooms, but narrower channels with multiple APs distributed around the rooms. Test APs positioned high, and set to high power to have large coverage areas against APs positioned low (signals get absorbed by people, so channels can be reused at shorter distances) and set to low power (microcell approach). Test APs overhead with directional antennas so they cover a small footprint.
Test with different types of walls around/between the rooms, metal studs and sheetrock of a modern office have very little affect on signals, stone/brick walls of old buildings (and concrete walls in some areas of new buildings) absorb the signal, the metal grid in movable air walls blocks and reflects signals
Remember that these are operating in 'unlicensed' spectrum, and so you can have other devices operating here as well causing periodic interference (which could show up as short segments of corruption or just an increased noise floor).
Current wifi standards interpret any failed signals as a weak signal, so they drop down to a slower modulation or increasing power in the hope of getting the signal through. If the problem is actually interference from other devices (especially other APs that it can't decipher), the result is that all stations end up yelling slowly to try and get through and the result is very high levels of noise and no messages getting through. Somehow, the systems should detect that the noise floor is high and/or that there is other stuff happening on the network that they can hear, but not necessarily decipher and switch away from the 'weak signal' mode of operation (which is appropriate in sparse environments), and instead work to talk faster and at lower power to try and reduce the overall interference while still getting their signal through.
(it does no good for one station to be transmitting at 3w while the station it's talking to is transmitting at 50mw). As far as I know, there is currently no way for stations to signal what power they are using (and the effective power would be modified by the antenna system, both transmitted and received), so this may be that something like 'I'm transmitting at 50% of my max and I hear you at 30% with noise at 10%' <-> 'I'm transmitting at 100% of my max and I hear you at 80% woth noise at 30%' could cause the first station to cut down on it's power until the two are hearing each other at similar levels (pure speculation here, suggestion for research ideas)
> How many different tests would it take to give reasonable coverage?
That's hard for me to say, and not every device needs to go through every test.
But when working on a new standard, it needs to go through a lot of these tests, the most important ones IMHO are how they work with a high density of users accessing multiple routers which are distributed so there is overlapping coverage and include a mix of network traffic.
David Lang
------------------------------
Message: 4
Date: Mon, 2 Sep 2024 21:36:28 +1200
From: Ulrich Speidel <u.speidel at auckland.ac.nz>
To: Dave Taht <dave.taht at gmail.com>
Cc: "starlink at lists.bufferbloat.net" <starlink at lists.bufferbloat.net>
Subject: Re: [Starlink] An update on Tonga
Message-ID: <84765c06-eebc-4a31-8d60-ca5834a8373c at auckland.ac.nz>
Content-Type: text/plain; charset="utf-8"; Format="flowed"
On 2/09/2024 10:17 am, Dave Taht wrote:
> Thank you for the update!
>
> It sounds like the rightest option is to deploy more than one cable on
> more than one path, and my question is who pays for that?
Indeed, good question. That came up at the Pacific Internet Governance Forum today, too.
Basically, Tonga has been planning for some time for a spur off the Hawaiki cable to land in Vava'u (the northern population centre island), but that's still some time off.
The problem around Tonga is really unfriendly seafloor whichever way you look. Approaches from the West need to come through the chain of volcanoes, one of which is Hunga Tonga Hunga Ha'apai, the volcano that exploded the other year. It has a few siblings further north that are of similar calibre. To the East and North to Samoa you have the Tonga trench, meaning you'd need to lay down a steep slope - landslide territory known for semi-regular M8 quakes. Approaching from the South from NZ means going along the Kermadec ridge, where there are multiple active volcanoes above and below water.
My current hope is that they'll find a way of getting the cable up from that trench onto the Ha'apai plateau. It mightn't be that safe from anchors there, but that might be a matter of policing and having mandatory AIS in the area.
> Starlink cannot possibly provide enough bandwidth long term.
Indeed. But their Ka-band community gateways are a feasible gap-filler until a proper cable can be laid. I gather that this is what's been offered to the cable company in Kiribati that's waiting for its cable.
>
> Also have you been measuring the bloat and the ISLs any in tonga?
Starlink's only just been licensed in Tonga (to protect the local ISPs that co-fund the cable projects) so we haven't looked at ISLs or bloat there yet. Bloat via cable connections - not something we've looked into from our end but probably worth doing. I might chew Terry Sweetser's ear about having you give a talk on this before soon at a Pacific IGF or appropriate APNIC meeting session, and hook you up with a few of the folk out there. Definitely something to build into the community training here. I've been able to connect with a lot of old chums and new acquaintances here, from Tonga and Samoa to Vanuatu to Tuvalu to Cook Islands. There's even a few Tokelauans and Marshall Islanders here, not to forget the i-Kiribati having turned up in force.
>
>
> On Sat, Aug 31, 2024 at 12:35 AM Ulrich Speidel via Starlink
> <starlink at lists.bufferbloat.net> wrote:
>
> Howdy all,
>
> There were quite a few folk on this list a couple of years back
> who were
> interested in what was happening to Internet in Tonga after the big
> volcanic eruption there. I'm not sure where I left off.
>
> To re-cap, Tonga lost about 90 km of its international connection to
> Fiji at the time (a few dozen km of that could be recovered), and an
> amount of cable of similar magnitude on the Tonga Domestic Cable
> Extension (TDCE) that ran a fibre pair each to both Vava'u and
> Ha'apai
> from the main island Tongatapu. The TDCE is one of the longer
> unrepeatered stretches of submarine cable in the world and runs in a
> submarine trench just downhill from the Hunga Tonga Hunga Ha'apai
> volcano and its siblings in the chain. Simulations at the timed
> showed
> that this trench likely received a large amount of the material
> that was
> ejected from the volcano, likely several cubic kilometres, and
> acted as
> a kind of gutter that guided the material away from the volcano in
> turbidity flows stretching over hundreds of km. At the time, the
> cable
> ship sent to repair was unable to repair the TDCE for lack of spare
> cable - nothing was recoverable from the seafloor, and there was not
> enough spare cable in the South Pacific to bridge the gap.
>
> Spare cable was ordered from France and was installed middle of 2023,
> restoring the TDCE to service.
>
> Then, on 29 June 2024, an earthquake near the volcanoes caused yet
> more
> debris to descend on the cable, obliterating 13.7 km of it and
> cutting
> service to both Vava'u and Ha'apai again. Cable ship MV Lodbrog was
> brought in from Singapore with 60 km of spares but got delayed in
> Fiji
> due to mechanical issues. The cable was repaired on 16 August
> 2024, in
> the same location. The operators were well aware of the risk, however
> re-routing the cable would have required it to be lengthened, with
> the
> need to insert repeaters, upgrade terminal equipment, and conduct
> a new
> marine survey, which would have meant further delays.
>
> On 26 August 2024, 11:29 am, a M6.9 quake struck in the area at a
> depth
> of about 106 km. Our Science building in Auckland has a "citizen
> science" seismograph with a big display in its foyer, and my
> student and
> I noticed the very prominent event as we returned from lunch.
> Little did
> we know that this wasn't as close to home as we'd thought, but would
> touch us in other ways that week. You've guessed it: The cable has
> been
> cut again, the cable ship's been recalled, and nobody quite knows
> what
> they'll find this time.
>
>
> https://mata/
> ngitonga.to%2F2024%2F08%2F27%2Fdomestic-submarine-cable-out-again-afte
> r-haapai-earthquake-yesterday&data=05%7C02%7Cwerner.coomans%40nokia-be
> ll-labs.com%7C5f886ef7e5534202af9308dccb32c099%7C5d4717519675428d917b7
> 0f44f9630b0%7C0%7C0%7C638608666077189201%7CUnknown%7CTWFpbGZsb3d8eyJWI
> joiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7C%7
> C%7C&sdata=6bWkrDFV00%2FWFIdgGed2RgMqszgI7GiipFaSujjJOWo%3D&reserved=0
>
> The latest plan I know of was to repair in the same location again,
> using armored spares - but they know that this may not prevent
> further
> damage. Geological advice is that any decent quake in the area will
> cause further submarine landslides in the coming years until the area
> has settled.
>
> Meanwhile, Starlink has been licensed to operate commercially in
> Tonga.
> For many Pacific Island countries, this is a double-edged sword:
> On the
> one hand, this provides short-term relief, on the other hand, it
> deprives local ISPs of customers and therefore impacts on
> aspirations to
> achieve cable connectivity which could provide more bandwidth in the
> medium term.
>
> Some island nations have not yet licensed Starlink, but allow
> Starlink
> units on regional roaming plans to operate there. In some cases,
> there
> are now hundreds of such units operating in individual cells. This
> appears to be causing Starlink some headaches in terms of capacity -
> we've seen them being creative when it comes to user density
> management
> before. What happens if Starlink are going to be licensed there but
> can't offer fixed service on the ground because of the large
> number of
> roaming subscribers already there? I understand that some of these
> "roaming" users have been contacted by Starlink with a request to
> either
> take these units back to their home location country where they are
> registered (which isn't likely to happen given the cost involved) or
> register them in the country they're currently in (not possible in
> some
> cases for lack of local fixed service offered).
>
> Ulrich
>
>
> --
> ****************************************************************
> Dr. Ulrich Speidel
>
> School of Computer Science
>
> Room 303S.594 (City Campus)
>
> The University of Auckland
> u.speidel at auckland.ac.nz
> http://www.cs.auckland.ac.nz/~ulrich/
> ****************************************************************
>
>
>
> _______________________________________________
> Starlink mailing list
> Starlink at lists.bufferbloat.net
>
> https://list/
> s.bufferbloat.net%2Flistinfo%2Fstarlink&data=05%7C02%7Cwerner.coomans%
> 40nokia-bell-labs.com%7C5f886ef7e5534202af9308dccb32c099%7C5d471751967
> 5428d917b70f44f9630b0%7C0%7C0%7C638608666077198027%7CUnknown%7CTWFpbGZ
> sb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3
> D%7C0%7C%7C%7C&sdata=Mlx2FdEMDpO6xEte88TAuD4xRG%2FCERsn0Tylc3aKXvM%3D&
> reserved=0
>
>
>
> --
> Artists/Musician Campout Aug 9-11
> https://www/.
> eventbrite.com%2Fe%2Fhealing-arts-event-tickets-928910826287&data=05%7
> C02%7Cwerner.coomans%40nokia-bell-labs.com%7C5f886ef7e5534202af9308dcc
> b32c099%7C5d4717519675428d917b70f44f9630b0%7C0%7C0%7C63860866607720224
> 0%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6
> Ik1haWwiLCJXVCI6Mn0%3D%7C0%7C%7C%7C&sdata=4PUiLDE14Lo2T6mGEfXfcyTLBVcR
> EYg9mvfbVIdpgzU%3D&reserved=0
> Dave Täht CSO, LibreQos
--
****************************************************************
Dr. Ulrich Speidel
School of Computer Science
Room 303S.594 (City Campus)
The University of Auckland
u.speidel at auckland.ac.nz
http://www.cs.auckland.ac.nz/~ulrich/
****************************************************************
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.bufferbloat.net/pipermail/starlink/attachments/20240902/d2306578/attachment.html>
------------------------------
Subject: Digest Footer
_______________________________________________
Starlink mailing list
Starlink at lists.bufferbloat.net
https://lists.bufferbloat.net/listinfo/starlink
------------------------------
End of Starlink Digest, Vol 42, Issue 2
***************************************
More information about the Starlink
mailing list