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
_______________________________________________
Starlink mailing list
[email protected]
https://lists.bufferbloat.net/listinfo/starlink
