Hi Sebastian,
Yes and no. But yes, not completely, and I'm not sure whether anyone has
ever looked at this, in fact. People who build mobile networks tend to
regard their job as complete the moment they can get an IP packet from a
mobile device to the Internet and vice versa, and mobile users tend to
be a bit more tolerant if things slow down for a moment or three.
There are a few differences, though. One is that cells are (or at least
can be) fibre connected, and that is something you would do along a
high-speed train line. So there is less of a bottleneck than having to
use RF for downlinking. I'd also imaging total user numbers to be lower
and the bandwidth demand per user to be less (hands up who takes their
50" TV onto trains to watch Netflix in HD?). The other is that most
places have 3+ networks serving the train line, which brings down user
numbers, or you have in-train cells, which communicate with off-train
POPs that have no extra users.
But yes, good question IMHO!
Cheers,
Ulrich
On 13/05/2023 11:20 pm, Sebastian Moeller wrote:
Hi Ulrich,
This situation is not completely different from say a train full of
LTE/5G users moving through a set of cells with already established
'static' users, no?
On 13 May 2023 12:10:17 CEST, Ulrich Speidel via Starlink
<[email protected]> wrote:
Here's a bit of a question to you all. See what you make of it.
I've been thinking a bit about the latencies we see in the
Starlink network. This is why this list exist (right, Dave?). So
what do we know? 1) We know that RTTs can be in the 100's of ms
even in what appear to be bent-pipe scenarios where the physical
one-way path should be well under 3000 km, with physical RTT under
20 ms. 2) We know from plenty of traceroutes that these RTTs
accrue in the Starlink network, not between the Starlink handover
point (POP) to the Internet. 3) We know that they aren't an
artifact of the Starlink WiFi router (our traceroutes were done
through their Ethernet adaptor, which bypasses the router), so
they must be delays on the satellites or the teleports. 4) We know
that processing delay isn't a huge factor because we also see RTTs
well under 30 ms. 5) That leaves queuing delays. This issue has
been known for a while now. Starlink have been innovating their
heart out around pretty much everything here - and yet, this
bufferbloat issue hasn't changed, despite Dave proposing what
appears to be an easy fix compared to a lot of other things they
have done. So what are we possibly missing here? Going back to
first principles: The purpose of a buffer on a network device is
to act as a shock absorber against sudden traffic bursts. If I
want to size that buffer correctly, I need to know at the very
least (paraphrasing queueing theory here) something about my
packet arrival process. If I look at conventional routers, then
that arrival process involves traffic generated by a user
population that changes relatively slowly: WiFi users come and go.
One at a time. Computers in a company get turned on and off and
rebooted, but there are no instantaneous jumps in load - you don't
suddenly have a hundred users in the middle of watching Netflix
turning up that weren't there a second ago. Most of what we know
about Internet traffic behaviour is based on this sort of network,
and this is what we've designed our queuing systems around, right?
Observation: Starlink potentially breaks that paradigm. Why?
Imagine a satellite X handling N users that are located closely
together in a fibre-less rural town watching a range of movies.
Assume that N is relatively large. Say these users are currently
handled through ground station teleport A some distance away to
the west (bent pipe with switching or basic routing on the
satellite). X is in view of both A and the N users, but with X
being a LEO satellite, that bliss doesn't last. Say X is moving to
the (south- or north-)east and out of A's range. Before connection
is lost, the N users migrate simultaneously to a new satellite Y
that has moved into view of both A and themselves. Y is doing so
from the west and is also catering to whatever users it can see
there, and let's suppose has been using A for a while already. The
point is that the user load on X and Y from users other than our N
friends could be quite different. E.g., one of them could be over
the ocean with few users, the other over countryside with a lot of
customers. The TCP stacks of our N friends are (hopefully)
somewhat adapted to the congestion situation on X with their cwnds
open to reasonable sizes, but they are now thrown onto a
completely different congestion scenario on Y. Similarly, say that
Y had less than N users before the handover. For existing users on
Y, there is now a huge surge of competing traffic that wasn't
there a second ago - surging far faster than we would expect this
to happen in a conventional network because there is no slow start
involved. This seems to explain the huge jumps you see on Starlink
in TCP goodput over time. But could this be throwing a few
spanners into the works in terms of queuing? Does it invalidate
what we know about queues and queue management? Would surges like
these justify larger buffers?
--
Sent from my Android device with K-9 Mail. Please excuse my brevity.
--
****************************************************************
Dr. Ulrich Speidel
School of Computer Science
Room 303S.594 (City Campus)
The University of Auckland
[email protected]
http://www.cs.auckland.ac.nz/~ulrich/
****************************************************************
_______________________________________________
Starlink mailing list
[email protected]
https://lists.bufferbloat.net/listinfo/starlink
