<html><head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
</head>
<body>
<p>So we got a Yaosheng adapter here but I didn't get to play with
it until last week. We hooked up a SuperMicro with a DHCP-ing
Ethernet interface to it. <br>
</p>
<p>First impressions: <br>
</p>
<ul>
<li>DHCP server and IPv4 gateway is 100.64.0.1, which sits on the
infrastructure side of the Starlink network. <br>
</li>
<li>The IPv4 address is assigned from 100.64.0.0/10.</li>
<li>DNS assigned by 100.64.0.1 are 1.1.1.1 and 8.8.8.8 - but woe
betide you, their reachability wasn't all that great when we
tried, so a lot of name lookups failed.</li>
</ul>
<p>More to come when I have a moment.</p>
<div class="moz-cite-prefix">On 25/05/2023 10:39 am, Ulrich Speidel
wrote:<br>
</div>
<blockquote type="cite" cite="mid:c528e8c7-847b-d92b-6c63-eb2a970e7f0e@auckland.ac.nz">
<p><br>
</p>
<div class="moz-cite-prefix">On 25/05/2023 1:59 am, David Lang
wrote:<br>
</div>
<blockquote type="cite" cite="mid:po3q5s4q-196n-7q6p-qs0o-6qp29sn3o002@ynat.uz"> <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>
>> >> >><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<br>
>> >> > doesn't meet electrical safety standards.<br>
> OK, we have one on order, along with PoE injector and power
supply. Don't <br>
> hold your breath, though, I'll be out of the country when
it arrives and <br>
> it'll be late July before I get to play with it.<br>
<br>
I've got a couple on order, but they won't arrive for 1-3 more
weeks :-(<br>
</blockquote>
I envy you!<br>
<blockquote type="cite" cite="mid:po3q5s4q-196n-7q6p-qs0o-6qp29sn3o002@ynat.uz"> I'll
also note that in the last launch of the v2 mini satellites,
they mentioned <br>
that those now supported E band backhaul to handle 4x the
bandwidth of the <br>
earlier satellites<br>
</blockquote>
Still not enough to connect the missing 2.5 or so billion, but a
step in the right direction for sure.<br>
<blockquote type="cite" cite="mid:po3q5s4q-196n-7q6p-qs0o-6qp29sn3o002@ynat.uz"> <br>
> It's certainly noticeable here that they seem to have sets
of three grouped <br>
> together in a relatively compact geographical area (you
could visit all NZ <br>
> North Island ground stations in a day by car from Auckland,
Auckland traffic <br>
> notwithstanding, and at a stretch could do the same down
south from Hinds to <br>
> Awarua if you manage to ignore the scenery, but getting
from the southernmost <br>
> North Island ground station to the northernmost South
Island one is basically <br>
> a two day drive plus ferry trip).<br>
<br>
I lived in Wanganui for a few years, including one RV trip down
the South <br>
Island. I know what you mean about needing to ignore the scenery
:-)<br>
</blockquote>
Interesting - that must have been before the local īwi pointed out
once again that the town had misspelled its name since 1854, and
for once were heard - so it's now officially "Whanganui", for
crown agencies, anyway.<br>
<blockquote type="cite" cite="mid:po3q5s4q-196n-7q6p-qs0o-6qp29sn3o002@ynat.uz"> Ok, I
thought I had heard they switched every 15 min, so it's every 5
min <br>
instead?<br>
</blockquote>
Dishy collects this information as a cumulative dataset, which the
tools query via grpc. The frames in the movie corresponds to
snapshots of the dataset taken at 5 second intervals. This
indicates switches roughly every ten to seventy seconds, with most
dwell times being around 15-30 seconds.<br>
<blockquote type="cite" cite="mid:po3q5s4q-196n-7q6p-qs0o-6qp29sn3o002@ynat.uz"> <br>
> Conclusion: latency change from tracking one satellite is
smaller than the <br>
> latency difference as you jump between satellites. You
could be looking at <br>
> several 100 km of path difference here. In an instant. Even
that, at 300,000 <br>
> km/s of propagation speed, is only in the order of maybe 1
ms or so - peanuts <br>
> compared to the RTTs in the dozens of ms that we're seeing.
But if you get <br>
> thrown from one queue onto another as you get handed over -
what does that do <br>
> to the remote TCP stack that's serving you?<br>
<br>
yes, the point I thought that I was trying to make was that the
latency change <br>
from satellite movement was not very significant<br>
</blockquote>
So it's got to come from somewhere else.<br>
<blockquote type="cite" cite="mid:po3q5s4q-196n-7q6p-qs0o-6qp29sn3o002@ynat.uz"> <br>
>> >> If it stays the same, I would suspect that you
are actually hitting a <br>
>> >> different ground station and there is a VPN
backhaul to your egress point <br>
>> >> to the regular Internet (which doesn't support
mobile IP addresses) for <br>
>> >> that cycle. If it tapers off, then I could buy
bufferbloat that gets <br>
>> >> resolved as TCP backs off.<br>
>> ><br>
>> > Yes, quite sorting out which part of your latency
is what is the million<br>
>> > dollar question here...<br>
>> ><br>
>> > We saw significant RTT changes here during the
recent cyclone over periods <br>
>> > of several hours, and these came in steps (see
below), with the initial <br>
>> > change being a downward one. Averages are over 60
pings (the time scale <br>
>> > isn't 100% true as we used "one ping, one second"
timing) here.<br>
>> ><br>
>> ><br>
>> > We're still not sure whether to attribute this to
load change or ground <br>
>> > station changes. There were a lot of power
outages, especially in <br>
>> > Auckland's lifestyle block belt, which teems with
Starlink users, but all <br>
>> > three North Island ground stations were also in
areas affected by power <br>
>> > outages (although the power companies concerned
don't provide the level of <br>
>> > detail to establish whether they were affected).
It's also not clear what, <br>
>> > if any, backup power arrangements they have). At
~25 ms, the step changes <br>
>> > in RTT are too large be the result of a switch in
ground stations, though, <br>
>> > the path differences just aren't that large. You'd
also expect a ground <br>
>> > station outage to result in longer RTTs, not
shorter ones, if you need to <br>
>> > re-route via another ground station. One
explanation might be users getting <br>
>> > cut off if they relied on one particular ground
station for bent pipe ops - <br>
>> > but that would not explain this order of magnitude
effect as I'd expect <br>
>> > that number to be small. So maybe power outages at
the user end after all. <br>
>> > But that would then tell us that these are
load-dependent queuing delays. <br>
>> > Moreover, since those load changes wouldn't have
involved the router at our <br>
>> > site, we can conclude that these are queue sojourn
times in the Starlink <br>
>> > network.<br>
<br>
remember that SpaceX controlls the ground stations as well, so
if they are doing <br>
any mobile IP trickery to redirect traffic from one ground
station to another, <br>
they can anticipate the shift or move the queue for the user or
other trickery <br>
like this (probably aren't yet, they seem to be in the early
days here, focusing <br>
on keeping things working and improving on the space side more
than anything <br>
else)<br>
</blockquote>
I strongly suspect that they are experimenting with this here and
with that there.<br>
<blockquote type="cite" cite="mid:po3q5s4q-196n-7q6p-qs0o-6qp29sn3o002@ynat.uz"> <br>
<br>
>> AQM allocates the available bandwidth between different
connections (usually <br>
>> different users)<br>
> But it does this under the assumption that the vector for
changes in bandwidth <br>
> availability is the incoming traffic, which AQM gives
(indirect) feedback to, <br>
> right?<br>
<br>
no, this is what I'm getting at below<br>
<br>
>> When it does this indirectly for inbound traffic by
delaying acks, the <br>
>> results depend on the senders handling of these
indirect signals that were <br>
>> never intended for this purpose.<br>
<br>
This is what you are thinking of, where it's providing indirect
feedback to an <br>
unknowable inbound queue on a remote system<br>
<br>
>> But when it does this directly on the sending side, it
doesn't matter what <br>
>> the senders want, their data WILL be managed to the
priority/bandwidth that <br>
>> the AQM sets, and eventually their feedback is dropped
packets, which <br>
>> everyone who is legitimate responds to.<br>
<br>
when the AQM in on the sending side of the bottleneck, it now
has direct control <br>
over the queue, and potentially has information over the
available bandwidth as <br>
it changes. But even if it doesn't know what the available
bandwidth is, it <br>
still can dispatch the data in it's queues 'fairly' (whatever
that means to the <br>
particulat AQM algorithm), changes in the data rate just change
how fast the <br>
queue drains.<br>
</blockquote>
<p>Yes - but if you delay ACKs, the only entity this has any
effect on is the original (remote) TCP sender, which is who you
are trying to persuade to take it easy so you're not going to be
forced to (tail or otherwise) drop packets.</p>
<p>Dropping helps clear your queue (the one in front of the
bottleneck).<br>
</p>
<blockquote type="cite" cite="mid:po3q5s4q-196n-7q6p-qs0o-6qp29sn3o002@ynat.uz"> <br>
> Understood. You build a control loop, where the latency is
the delay in the <br>
> control signal.<br>
><br>
> Classically, you have a physical bottleneck that the AQM
manages, where the <br>
> physical bandwidth doesn't change.<br>
><br>
> The available bandwidth changes, (mostly) as a result of
TCP connections (or <br>
> similarly behaved UDP applications) joining in slow start,
or disappearing.<br>
><br>
> Basically, your queues grow and shrink one packet at a
time.<br>
><br>
> Your control signal allows you (if they're well behaved)
throttle / <br>
> accelerate senders.<br>
><br>
> What you don't get are quantum jumps in queue occupancy,
jump changes in <br>
> underlying physical bandwidth, or a whole set of new
senders that are <br>
> completely oblivious to any of your previous control
signals. But you get all <br>
> that with satellite handovers like these.<br>
<br>
for a single TCP session,it has slow-start, but if you suddently
start dozens or <br>
hundreds of TCP sessions, (bittorrent, other file transfer
protocols, or just a <br>
website with hundreds of sub-elements), I think it's a bigger
step than you are <br>
thinking.<br>
</blockquote>
Doesn't each TCP session maintain and manage its own cwnd?<br>
<blockquote type="cite" cite="mid:po3q5s4q-196n-7q6p-qs0o-6qp29sn3o002@ynat.uz"> <br>
And again, I think the same issue exists on cell sites as users
move from one <br>
cell to another.<br>
</blockquote>
Yes. But that happens gradually in comparison to Starlink, and the
only TCP stack that potentially gets affected badly as a user
moves from one cell site to the next is that of the user. But what
you have here is the equivalent of the cell tower moving out of
range of a whole group of users in one go. Different ballpark?<br>
<blockquote type="cite" cite="mid:po3q5s4q-196n-7q6p-qs0o-6qp29sn3o002@ynat.uz"> <br>
> So what if the response you elicit in this way is to a
queue scenario that no <br>
> longer applies?<br>
<br>
you run the risk of under-utilizing the link for a short time
(which may mean <br>
that you decide to run the queues a little bigger than with
fixed links, so that <br>
when a chunk of data disappears from your queue, you still will
keep utilization <br>
up, sacraficing some latency to improve overall throughput)<br>
</blockquote>
So we're back to the "more buffer" scenario here, too.<br>
<blockquote type="cite" cite="mid:po3q5s4q-196n-7q6p-qs0o-6qp29sn3o002@ynat.uz"> <br>
David Lang </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 moz-txt-link-freetext" href="mailto:u.speidel@auckland.ac.nz" moz-do-not-send="true">u.speidel@auckland.ac.nz</a>
<a class="moz-txt-link-freetext" href="http://www.cs.auckland.ac.nz/~ulrich/" moz-do-not-send="true">http://www.cs.auckland.ac.nz/~ulrich/</a>
****************************************************************
</pre>
</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>