[Starlink] Starlink hidden buffers

[David Lang]

On Thu, 25 May 2023, Ulrich Speidel wrote:

>> I lived in Wanganui for a few years, including one RV trip down the South
>> Island. I know what you mean about needing to ignore the scenery :-)
> 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.

My spelling has always been a bit haphazard, but this was back in the '70s

>> remember that SpaceX controlls the ground stations as well, so if they are 
>> doing any mobile IP trickery to redirect traffic from one ground station to 
>> another, they can anticipate the shift or move the queue for the user or 
>> other trickery like this (probably aren't yet, they seem to be in the early 
>> days here, focusing on keeping things working and improving on the space side 
>> more than anything else)
> I strongly suspect that they are experimenting with this here and with that 
> there.
>> 
>> 
>> >> AQM allocates the available bandwidth between different connections 
>> >> (usually different users)
>> > But it does this under the assumption that the vector for changes in 
>> > bandwidth availability is the incoming traffic, which AQM gives (indirect) 
>> > feedback to, right?
>> 
>> no, this is what I'm getting at below
>> 
>> >> When it does this indirectly for inbound traffic by delaying acks, the 
>> >> results depend on the senders handling of these indirect signals that were 
>> >> never intended for this purpose.
>> 
>> This is what you are thinking of, where it's providing indirect feedback to 
>> an unknowable inbound queue on a remote system
>> 
>> >> But when it does this directly on the sending side, it doesn't matter what 
>> >> the senders want, their data WILL be managed to the priority/bandwidth 
>> >> that the AQM sets, and eventually their feedback is dropped packets, which 
>> >> everyone who is legitimate responds to.
>> 
>> when the AQM in on the sending side of the bottleneck, it now has direct 
>> control over the queue, and potentially has information over the available 
>> bandwidth as it changes. But even if it doesn't know what the available 
>> bandwidth is, it still can dispatch the data in it's queues 'fairly' 
>> (whatever that means to the particulat AQM algorithm), changes in the data 
>> rate just change how fast the queue drains.
>
> 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.

the delaying ack thing is only done when you are trying to manage the inbound 
traffic. When you are on the upstream side of the bottleneck, you don't mess 
with acks, you just dispatch/mark/discard the packets.

> Dropping helps clear your queue (the one in front of the bottleneck).

or ECN tagging, and as Dave pointed out, the 'fair' part of FQ_Codel and Cake 
provide fairness between users so that even in the face of overloads from one 
source, other traffic will still get through.

>> for a single TCP session,it has slow-start, but if you suddently start dozens 
>> or hundreds of TCP sessions, (bittorrent, other file transfer protocols, or 
>> just a website with hundreds of sub-elements), I think it's a bigger step 
>> than you are thinking.
> Doesn't each TCP session maintain and manage its own cwnd?

Yes, but when you have hundreds of TCP sessions running in parallel, each 
increasing their cwnd, the effect can be significant (especially on lower 
bandwidth links)

>> And again, I think the same issue exists on cell sites as users move from one 
>> cell to another.
> 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?

as others noted, busses/trains move a bunch of people from one cell zone to the 
next at the same time

>> > So what if the response you elicit in this way is to a queue scenario that 
>> > no longer applies?
>> 
>> you run the risk of under-utilizing the link for a short time (which may mean 
>> that you decide to run the queues a little bigger than with fixed links, so 
>> that when a chunk of data disappears from your queue, you still will keep 
>> utilization up, sacraficing some latency to improve overall throughput)

> So we're back to the "more buffer" scenario here, too.

more buffer compared to static links, or accept the link being less utilized

David Lang