From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail.lang.hm (unknown [66.167.227.145]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by lists.bufferbloat.net (Postfix) with ESMTPS id AFF2B3B29E for ; Mon, 15 May 2023 07:07:55 -0400 (EDT) Received: from dlang-mobile (unknown [10.2.2.69]) by mail.lang.hm (Postfix) with ESMTP id 5503D18EA4F; Mon, 15 May 2023 04:07:54 -0700 (PDT) Date: Mon, 15 May 2023 04:07:54 -0700 (PDT) From: David Lang To: Sebastian Moeller cc: David Lang , Ulrich Speidel , "starlink@lists.bufferbloat.net" In-Reply-To: Message-ID: References: <0no84q43-s4n6-45n8-50or-12o3rq104n99@ynat.uz> <48b00469-0dbb-54c4-bedb-3aecbf714a1a@auckland.ac.nz> <728orr66-1432-751p-263q-sqopr12s20sq@ynat.uz> <077e6ad1-d7cc-2d57-39f8-e9646bea32a5@auckland.ac.nz> <09552rq0-0n24-0pqo-4085-n918r0n71138@ynat.uz> <9q29o7n2-69rs-3os1-s93q-0795262qs3o1@ynat.uz> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Subject: Re: [Starlink] Starlink hidden buffers X-BeenThere: starlink@lists.bufferbloat.net X-Mailman-Version: 2.1.20 Precedence: list List-Id: "Starlink has bufferbloat. Bad." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 May 2023 11:07:55 -0000 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