From mboxrd@z Thu Jan 1 00:00:00 1970 Authentication-Results: mail.toke.dk; spf=pass smtp.mailfrom=sandelman.ca; dkim=pass header.d=sandelman.ca; arc=none (Message is not ARC signed); dmarc=none Received: from tuna.sandelman.ca (tuna.sandelman.ca [IPv6:2607:f0b0:f:3:216:3eff:fe7c:d1f3]) by mail.toke.dk (Postfix) with ESMTPS id 415456F0517 for ; Thu, 25 Sep 2025 19:45:13 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by tuna.sandelman.ca (Postfix) with ESMTP id D9EDF18014 for ; Thu, 25 Sep 2025 13:45:11 -0400 (EDT) Received: from tuna.sandelman.ca ([127.0.0.1]) by localhost (localhost [127.0.0.1]) (amavis, port 10024) with LMTP id e_xQv9S8KDTD for ; Thu, 25 Sep 2025 13:45:10 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sandelman.ca; s=mail; t=1758822310; bh=tpWc6LdfEmHsp27PVv59Xl+alXqZbcvjXJDgZFF/MN4=; h=From:To:Subject:In-Reply-To:References:Date:From; b=S/Qm1VY1F/WoArKHKUci1SE+cZQN2aCX+gpbHyo11CFb9RlE/HsHcGOJ2sXby+AsF NuppxxIoNkIhQF2+8zlV8b0N6N7N86rM1lYbTAwSfJ7ykR8DKKMotuOb3KiKGjpAiM ZR3iB+feqPs2kD7gFAD+aF6HIinEXAAKSDzBKx+UuM0HkJ8Btob3v0wh+/ApHhziqF gFYco6KE7DrDhbC+z8NSSVeHtyM+gjOkRu2Ep8pXmHWKg6mpWft/vZZq+OQ9Rv4bDp 5glA6h1M+cIEDvQb4wShXhmihpGMt4ne0bvomR4brrFgIwWPKioXBTxZGpvH0a6XgN Xythf2XGBWL/A== Received: from sandelman.ca (obiwan.sandelman.ca [209.87.249.21]) by tuna.sandelman.ca (Postfix) with ESMTP id 4020E18012 for ; Thu, 25 Sep 2025 13:45:10 -0400 (EDT) Received: from obiwan.sandelman.ca (obiwan.sandelman.ca [127.0.0.1]) by sandelman.ca (Postfix) with ESMTP id 3D8E21C0 for ; Thu, 25 Sep 2025 13:45:10 -0400 (EDT) From: Michael Richardson To: starlink@lists.bufferbloat.net In-Reply-To: <175876550514.1555.8294777204829819629@gauss> References: <175876550514.1555.8294777204829819629@gauss> X-Mailer: MH-E 8.6+git; nmh 1.8+dev; GNU Emacs 28.2 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0;<'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Content-Transfer-Encoding: quoted-printable Date: Thu, 25 Sep 2025 13:45:10 -0400 Message-ID: <30473.1758822310@obiwan.sandelman.ca> Message-ID-Hash: GFQE6GQKJU4PCWAMB7CFU3VC77A3ZJ2R X-Message-ID-Hash: GFQE6GQKJU4PCWAMB7CFU3VC77A3ZJ2R X-MailFrom: mcr@sandelman.ca X-Mailman-Rule-Misses: dmarc-mitigation; no-senders; approved; loop; banned-address; emergency; member-moderation; nonmember-moderation; administrivia; implicit-dest; max-recipients; max-size; news-moderation; no-subject; digests; suspicious-header X-Mailman-Version: 3.3.10 Precedence: list Subject: [Starlink] Re: Starlink looking less niche as its retail presence expands List-Id: "Starlink has bufferbloat. Bad." Archived-At: List-Archive: List-Help: List-Owner: List-Post: List-Subscribe: List-Unsubscribe: {resending without signature, since new list can't cope with attachments y= et} Luis A. Cornejo via Starlink wrote: > Since Starlink controls all the wireless parts of their system. Does > anybody here know what they could do to mitigate the limits of > classical wireless comms, like Shannon-Hartley Capacity Theorem or t= he > interference? I don't know much about this part. I am kinda hijacking this thread, but I think there is a connection. Dr.Pan gave a talk about Starlink measurements last week in Ottawa. (The time slot was way too short. Very nice talk) I was thinking about the many places where bandwidth can go up and down, b= oth for Starlink's various mis-attachment situations, but also for OneWeb's Po= lar orbit mechanism. (I didn't know it was doing that). And just getting redirected to a different downlink/base-station, and then have to cross over Starlink's internal network to the same exit point. (Too bad MobileIP never took off) I think the only thing worse than bufferbloat is varying bandwidth rates. That's because the only way to use that bandwidth is to introduce bufferbl= oat :-) It was the cablemodem burst mechanism that clued Jim into bufferbloat. So my related question is, if they could mitigate, they likely can't do it continuously, so things will up/down. The IETF now has a SCONE WG, with t= he aim of inserting signals into QUIC traffic about bandwidth available. Yes, meddling by middle boxes. Ick. Could Starlink even do this given the lack of L3 processing along the entire link? At least according to Dr. Pan's diagrams. (An L2 hop could well mess with packets too). Ideally, one or more of the satellites involved in the ISL would know what the current bandwidth to a given terminal is, and could inform t= he end system. The two questions: 1. are the limits/conditions stable enough for long enough that the availa= ble bandwidth could be communicated back to the uplink? 2. assuming, yes, what would the best place to do the SCONE marking? >> Let's recap: Spectrum's boxed in, and power is boxed in. That impos= es >> a hard limit on total capacity (look up the Shannon-Hartley Capacit= y >> Theorem if you don't believe me). This capacity is all that Starlin= k >> has to share among its users in a cell. No matter how many satellit= es >> they launch or how big the rocket. Add more users in a cell, and th= e >> capacity per user there has to go down. Law of nature. And users will need to know what they have on a minute-by-minute basis so that they avoid screwing themselves, let alone their neighbours. Packets going up the link, then being dropped, is just wasted. ps: I have been watching: https://www.youtube.com/playlist?list=3DPL-_93BVApb5= 8SXL-BCv4rVHL-8GuC2WGb where they have powered up 50+ year old Apollo Transponders. -- ] Never tell me the odds! | ipv6 mesh networ= ks [ ] Michael Richardson, Sandelman Software Works | IoT architect= [ ] mcr@sandelman.ca http://www.sandelman.ca/ | ruby on rails = [