<html><head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
</head>
<body>
<div class="moz-cite-prefix">On 14/05/2023 9:00 pm, David Lang
wrote:<br>
</div>
<blockquote type="cite" cite="mid:09552rq0-0n24-0pqo-4085-n918r0n71138@ynat.uz">
On Sun, 14 May 2023, Ulrich Speidel wrote:<br>
<br>
>> I just discovered that someone is manufacturing an
adapter so you no longer <br>
>> have<br>
>> to cut the cable<br>
>> <br>
>> <a href="https://www.amazon.com/YAOSHENG-Rectangular-Adapter-Connect-Injector/dp/B0BYJTHX4P" moz-do-not-send="true">https://www.amazon.com/YAOSHENG-Rectangular-Adapter-Connect-Injector/dp/B0BYJTHX4P</a>
<br>
>> <<a href="https://www.amazon.com/YAOSHENG-Rectangular-Adapter-Connect-Injector/dp/B0BYJTHX4P" moz-do-not-send="true">https://www.amazon.com/YAOSHENG-Rectangular-Adapter-Connect-Injector/dp/B0BYJTHX4P</a>><br>
>> <br>
> I'll see whether I can get hold of one of these. Cutting a
cable on a <br>
> university IT asset as an academic is not allowed here,
except if it doesn't <br>
> meet electrical safety standards.<br>
><br>
> Alternatively, has anyone tried the standard Starlink
Ethernet adapter with a <br>
> PoE injector instead of the WiFi box? The adapter above seems
to be like the <br>
> Starlink one (which also inserts into the cable between Dishy
and router).<br>
<br>
that connects you a 2nd ethernet port on the router, not on the
dishy<br>
<br>
I just ordered one of those adapters, it will take a few weeks to
arrive.<br>
</blockquote>
How do we know that the Amazon version doesn't do the same?<br>
<blockquote type="cite" cite="mid:09552rq0-0n24-0pqo-4085-n918r0n71138@ynat.uz">
<br>
>> > Put another way: If you have a protocol (TCP) that
is designed to <br>
>> > reasonably<br>
>> > expect that its current cwnd is OK to use for now is
put into a situation<br>
>> > where there are relatively frequent, huge and
lasting step changes in<br>
>> > available BDP within subsecond periods, are your
underlying assumptions <br>
>> > still<br>
>> > valid?<br>
>> <br>
>> I think that with interference from other APs, WIFI
suffers at least as much <br>
>> unpredictable changes to the available bandwidth.<br>
<br>
> Really? I'm thinking stuff like the sudden addition of
packets from <br>
> potentially dozens of TCP flows with large cwnd's?<br>
<br>
vs losing 90% of your available bandwidth to interference?? I
think it's going <br>
to be a similar problem<br>
</blockquote>
Hm. Not convinced, but I take your point...<br>
<blockquote type="cite" cite="mid:09552rq0-0n24-0pqo-4085-n918r0n71138@ynat.uz">
<br>
>> <br>
>> > I suspect they're handing over whole cells, not
individual users, at a <br>
>> time.<br>
>> <br>
>> I would guess the same (remember, in spite of them having
launched >4000<br>
>> satellites, this is still the early days, with the
network changing as more <br>
>> launching)<br>
>> <br>
>> We've seen that it seems that there is only one satellite
serving any cell <br>
>> one time.<br>
<br>
> But the reverse is almost certainly not true: Each satellite
must serve <br>
> multiple cells.<br>
<br>
true, but while the satellite over a given area will change, the
usage in that <br>
area isn't changing that much<br>
</blockquote>
Exactly. But your underlying queue sits on the satellite, not in the
area.<br>
<blockquote type="cite" cite="mid:09552rq0-0n24-0pqo-4085-n918r0n71138@ynat.uz">
<br>
>> But remember that the system does know how much usage
there is in the<br>
>> cell before they do the handoff. It's unknown if they do
anything with <br>
>> that, or<br>
>> if they are just relaying based on geography. We also
don't know what the<br>
>> bandwidth to the ground stations is compared to the
dishy.<br>
<br>
> Well, we do know for NZ, sort of, based on the licences
Starlink has here.<br>
<br>
what is the ground station bandwith?<br>
</blockquote>
<p><a class="moz-txt-link-freetext" href="https://rrf.rsm.govt.nz/ui/search/licence">https://rrf.rsm.govt.nz/ui/search/licence</a> - seach for "Starlink"</p>
<p>...all NZ licences in all their glory. Looking at Starlink SES
(satellite earth station) TX (which is the interesting direction I
guess):</p>
<p>- Awarua, Puwera, Hinds, Clevedon, Cromwell, Te Hana:
29750.000000 TX (BW = 500 MHz)<br>
- Awarua, Puwera, Hinds, Clevedon, Cromwell, Te Hana: 28850.000000
TX (BW = 500 MHz)<br>
- Awarua, Puwera, Hinds, Clevedon, Cromwell, Te Hana: 28350.000000
TX (BW = 500 MHz)<br>
- Awarua, Puwera, Hinds, Clevedon, Cromwell, Te Hana: 28250.000000
TX (BW = 500 MHz)<br>
- Awarua, Puwera, Hinds, Clevedon, Cromwell, Te Hana: 27750.000000
TX (BW = 500 MHz)</p>
<p>So 2.5 GHz up, licensed from 6 ground stations. Now I'm not
convinced that they would use all of those from all locations
simultaneously because of the risk of off-beam interference.
They'll all be transmitting south, ballpark. If there was full
re-use at all ground stations, we'd be looking at 15 GHz. If they
are able to re-use on all antennas at each ground station, then
we're looking at 9 golf balls each in Puwera, Te Hana, Clevedon,
Hinds and Cromwell, and an unknown number at Awarua. Assuming 9
there, we'd be looking at 135 GHz all up max.</p>
<p>Awarua and Cromwell are 175 km apart, Hinds another 220 km from
Cromwell, then it's a hop of about 830 km to Clevedon, and from
there another 100 km to Te Hana, which is another 53 km from
Puwera, so keeping them all out of each other's hair all the time
might be a bit difficult. <br>
<br>
Lots of other interesting info in the licenses, such as EIRP, in
case you're wanting to do link budgets.<br>
</p>
<p> </p>
<blockquote type="cite" cite="mid:09552rq0-0n24-0pqo-4085-n918r0n71138@ynat.uz">
<br>
>> And remember that for every cell that a satellite takes
over, it's also <br>
>> giving away one cell at the same time.<br>
<br>
> Yes, except that some cells may have no users in them and
some of them have a <br>
> lot (think of a satellite flying into range of California
from the Pacific, <br>
> dropping over-the-water cells and acquiring land-based ones).<br>
<br>
>> I'm not saying that the problem is trivial, but just that
it's not unique<br>
<br>
> What makes me suspicious here that it's not the usual
bufferbloat problem is <br>
> this: With conventional bufferbloat and FIFOs, you'd expect
standing queues, <br>
> right? With Starlink, we see the queues emptying relatively
occasionally with <br>
> RTTs in the low 20 ms, and in some cases under 20 ms even.
With large ping <br>
> packets (1500 bytes).<br>
<br>
it's not directly a bufferbloat problem, bufferbloat is a side
effect (At most)<br>
<br>
we know that the avaialble starlink bandwidth is chopped into
timeslots (sorry, <br>
don't remember how many), and I could see the possibility of there
being the <br>
same number of timeslots down to the ground station as up from the
dishies, and <br>
if the bottleneck is at the uplink from the ground station, then
things would <br>
queue there.<br>
<br>
As latency changes, figuring out if it's extra distance that must
be traveled, <br>
or buffering is hard. does the latency stay roughly the same until
the next <br>
satellite change? or does it taper off?<br>
</blockquote>
Good question. You would expect step changes in physical latency
between satellites, but also gradual change related to satellite
movement. Plus of course any rubble thrown into any queue by
something suddenly turning up on that path. Don't forget that it's
not just cells now, we're also talking up- and downlink for the
laser ISLs, at least in some places.<br>
<blockquote type="cite" cite="mid:09552rq0-0n24-0pqo-4085-n918r0n71138@ynat.uz">
<br>
If it stays the same, I would suspect that you are actually
hitting a different <br>
ground station and there is a VPN backhaul to your egress point to
the regular <br>
Internet (which doesn't support mobile IP addresses) for that
cycle. If it <br>
tapers off, then I could buy bufferbloat that gets resolved as TCP
backs off.<br>
</blockquote>
<p>Yes, quite sorting out which part of your latency is what is the
million dollar question here... <br>
</p>
<p>We saw significant RTT changes here during the recent cyclone
over periods of several hours, and these came in steps (see
below), with the initial change being a downward one. Averages are
over 60 pings (the time scale isn't 100% true as we used "one
ping, one second" timing) here.<br>
</p>
<p><img src="cid:part1.Uh80HFaC.Eb2mWOUW@auckland.ac.nz" moz-do-not-send="false"> <br>
</p>
<p>We're still not sure whether to attribute this to load change or
ground station changes. There were a lot of power outages,
especially in Auckland's lifestyle block belt, which teems with
Starlink users, but all three North Island ground stations were
also in areas affected by power outages (although the power
companies concerned don't provide the level of detail to establish
whether they were affected). It's also not clear what, if any,
backup power arrangements they have). At ~25 ms, the step changes
in RTT are too large be the result of a switch in ground stations,
though, the path differences just aren't that large. You'd also
expect a ground station outage to result in longer RTTs, not
shorter ones, if you need to re-route via another ground station.
One explanation might be users getting cut off if they relied on
one particular ground station for bent pipe ops - but that would
not explain this order of magnitude effect as I'd expect that
number to be small. So maybe power outages at the user end after
all. But that would then tell us that these are load-dependent
queuing delays. Moreover, since those load changes wouldn't have
involved the router at our site, we can conclude that these are
queue sojourn times in the Starlink network.</p>
<blockquote type="cite" cite="mid:09552rq0-0n24-0pqo-4085-n918r0n71138@ynat.uz">
<br>
my main point in replying several messages ago was to point out
other scenarios <br>
where the load changes rapidly and/or the available bandwidth
changes rapidly. <br>
And you are correct that it is generally not handled well by
common equipment.<br>
<br>
I think that active queue management on the sending side of the
bottleneck will <br>
handle it fairly well. It doesn't have to do calculations based on
what the <br>
bandwidth is, it just needs to know what it has pending to go out.<br>
</blockquote>
Understood - but your customer for AQM is the sending TCP client,
and there are two questions here: (a) Does your AQM handle rapid
load changes and (b) how do your TCP clients actually respond to
your AQM's handling?<br>
<blockquote type="cite" cite="mid:09552rq0-0n24-0pqo-4085-n918r0n71138@ynat.uz">
<br>
David Lang<br>
</blockquote>
<pre class="moz-signature" cols="72">--
****************************************************************
Dr. Ulrich Speidel
School of Computer Science
Room 303S.594 (City Campus)
The University of Auckland
<a class="moz-txt-link-abbreviated" href="mailto:u.speidel@auckland.ac.nz">u.speidel@auckland.ac.nz</a>
<a class="moz-txt-link-freetext" href="http://www.cs.auckland.ac.nz/~ulrich/">http://www.cs.auckland.ac.nz/~ulrich/</a>
****************************************************************
</pre>
</body>
</html>