[Starlink] Starlink hidden buffers

[David Lang]

On Mon, 15 May 2023, Sebastian Moeller wrote:

>> I have two starlink dishes in the southern california area, I'm going to put one on the low-priority mobile plan shortly. These are primarily used for backup communication, so I would be happy to add something to them to do latency monitoring.
>
>
> 	[SM] I would consider using irtt for that (like running in for 15 minutes with say 5ms spacing a few times a day, sometimes together with a saturating load sometimes without), this is a case where OWDs are especially interesting and irtt will also report the direction in which packets were lost. Maybe Dave (once back from his time-off) has an idea about which irtt reflector to use?
>
>
>> In looking at what geo-location reports my location as, I see it wander up and down the west coast, from the Los Angeles area all the way up to Canada.
>
> 	[SM] Demonstrating once more that geoIP is just a heuristic ;)

and/or demonstrating that starlink is connecting me to different ground stations 
at different times.

>>>> I think that active queue management on the sending side of the bottleneck will handle it fairly well. It doesn't have to do calculations based on what the bandwidth is, it just needs to know what it has pending to go out.
>>
>>> 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?
>>
>> AQM allocates the available bandwidth between different connections (usually different users)
>
> 	[SM] Not sure AQM is actually defined that stringently, I was under the impression anything other that FIFO with tail drop would already count as AQM, no?

technically true, but I think that doing anything other than FIO with tail drop 
is allocating the bandwidth. I think it makes for a nice shorthand explination 
without getting into mechanisms.

>> 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.
>
> 	[SM] Hmm, ACKs where intended to be a feed-back mechanism for the sender to use to asses the in-flight data, so I am not sure whether delaying ACKs is something that was never envisaged by TCP's creators?

It was not, it seems to work in practice, but imperfectly.

>> 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.
>
> 	[SM] Some more quickly than others though, looking at you BBR ;)
>
>
>> But even if they don't respond (say a ping flood or DoS attack), the AQM will limit the damage to that connection, allowing the other connections trying to use that link to continue to function.
>
> 	[SM] Would that not require an AQM with effectively a multi-queue scheduler? I think it seems clear that starlink uses some form of AQM (potentially ARED), but on the scheduler/queue side there see to be competing claims ranging from single-queue FIFO (with ARED) to FQ-scheduler. Not having a starlink-link I can not test any of this so all I can report is competing reports from starlink users...

no, it just requires a AQM that drops packets from a flow. It doesn't matter if 
it does this with multiple queues, or by just dropping packets from a busy 
connection when the queue is close to full while allowing other connections to 
get added to the queue.

And I didn't mean to imply that all AQMs achieve the goal of isolating the 
problem traffic, just that they all attempt to do so.

David Lang