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 AA73F3B2A4 for ; Wed, 31 Aug 2022 16:28:10 -0400 (EDT) Received: from dlang-mobile (unknown [10.2.2.70]) by mail.lang.hm (Postfix) with ESMTP id AFEA51459A5; Wed, 31 Aug 2022 13:28:09 -0700 (PDT) Date: Wed, 31 Aug 2022 13:28:09 -0700 (PDT) From: David Lang To: "David P. Reed" cc: starlink@lists.bufferbloat.net In-Reply-To: <1661975488.138231368@apps.rackspace.com> Message-ID: <7q848925-o6qn-1934-n4s9-n493n9sp9op9@ynat.uz> References: <1661975488.138231368@apps.rackspace.com> MIME-Version: 1.0 Content-Type: multipart/mixed; BOUNDARY="===============3118893131765226916==" Subject: Re: [Starlink] Starlink "beam spread" 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: Wed, 31 Aug 2022 20:28:10 -0000 This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. --===============3118893131765226916== Content-Type: text/plain; format=flowed; charset=US-ASCII On Wed, 31 Aug 2022, David P. Reed via Starlink wrote: > My point is that the discussion here has focused entirely on achievable bitrate maximum, with no load and no burstiness. well, to be fair, some of that is in response to 'just looking at the bitrate, starlink cannot possibly perform well' posts > This isn't fixed by having more spatial control, to the extent that is > possible. agreed, the spactial control discussion is just a response to 'it can't possibly...' posts > It *is* fixable by suitable Automatic Queue Management in the > satellite path (which will be the "bottleneck link" between the home and the > public Internet), plus suitable end-to-end protocol congestion management that > responds to drops or ECN. (I don't know if the satellite looks at the packet > hard enough and has enough state to set the ECN bit or that it has enough > state to achieve bloom filter based fair queue dropping). if the sats are going to have the ability to route through other satellites, they have to be looking at the packets, and once you start doing that, looking at ECN should not be a significant load. David Lang --===============3118893131765226916== Content-Type: text/plain; CHARSET=utf-8 Content-Transfer-Encoding: BASE64 Content-ID: <1sss6osr-5722-p58q-s649-9s67178r995@ynat.uz> Content-Description: Content-Disposition: INLINE X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KU3Rhcmxpbmsg bWFpbGluZyBsaXN0ClN0YXJsaW5rQGxpc3RzLmJ1ZmZlcmJsb2F0Lm5ldApodHRwczovL2xpc3Rz LmJ1ZmZlcmJsb2F0Lm5ldC9saXN0aW5mby9zdGFybGluawo= --===============3118893131765226916==--