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 D5489704C22 for ; Mon, 29 Sep 2025 00:57:53 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by tuna.sandelman.ca (Postfix) with ESMTP id 15B801800D for ; Sun, 28 Sep 2025 18:57:52 -0400 (EDT) Received: from tuna.sandelman.ca ([127.0.0.1]) by localhost (localhost [127.0.0.1]) (amavis, port 10024) with LMTP id 74p620n8r2z7 for ; Sun, 28 Sep 2025 18:57:50 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sandelman.ca; s=mail; t=1759100270; bh=ocng3DC3AaNLmr/WN5HQHv0S6Ckte4oLp3bv2YjhhKU=; h=From:To:Subject:In-Reply-To:References:Date:From; b=F7vRWKRor0IjVlDDIk7X4Vnw3Fjk3+V6+ZvLdGZUs2Kf3hdZ7uh0z09/k/BLsJrCC Guy1PxxNzimLonDTKDqvIaIOU5BCl1RdQ7ezodCM6PVz6Og8sTTw2xQg07P/dust2v EMrVLeXoEc/HMgQqJ0+sR0r2mwPlHk8UkQ0zrDICbkWDeYj5gZ2hppMQrvS/EImM3B Ogh5UJTRb5hN5iwRxJvXqwUyjMxjiH0bWPSL8Dbiz+c7dF45gsR8aG2tTFqp753sCM T7EWc7RUQnXWbsCk4aem+D0Ot6ysWVHcoV1L9nDKPwuUG3kFrdBnhXDOhKj3AE1cXy ZoU1i4fdQoGrA== Received: from sandelman.ca (unknown [IPv6:2607:f0b0:f:2:b241:6fff:fe09:a92b]) by tuna.sandelman.ca (Postfix) with ESMTP id 747931800C for ; Sun, 28 Sep 2025 18:57:50 -0400 (EDT) Received: from obiwan.sandelman.ca (obiwan.sandelman.ca [127.0.0.1]) by sandelman.ca (Postfix) with ESMTP id 6B9FE200 for ; Sun, 28 Sep 2025 18:57:50 -0400 (EDT) From: Michael Richardson To: starlink@lists.bufferbloat.net In-Reply-To: <175909736500.1555.17525399538686390446@gauss> References: <175909736500.1555.17525399538686390446@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: Sun, 28 Sep 2025 18:57:50 -0400 Message-ID: <13785.1759100270@obiwan.sandelman.ca> Message-ID-Hash: M6BIZOIZTVJDSJO5CTNZ33Q22NQPVWQ2 X-Message-ID-Hash: M6BIZOIZTVJDSJO5CTNZ33Q22NQPVWQ2 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] SCONE, bandwidth indeterminacy and network to host signals (was Re: Re: Starlink Digest, Vol 53, Issue 14) List-Id: "Starlink has bufferbloat. Bad." Archived-At: List-Archive: List-Help: List-Owner: List-Post: List-Subscribe: List-Unsubscribe: The point of SCONE is allow end ("terminals") to better select (video) bandwidths that are going to be more sustainable. It's definitely driven = by 3GPP (LTE) operators so far. I give it a 40% chance of getting usefully deployed before the need is overtaken by other events. The promise is that 3GPP operators won't have to do expensive DPI anymore. It's true the the 3GPP people have a long-standing habit of doing often useless DPI, including ack pacing, ack-proxying, https://en.wikipedia.org/= wiki/TCP_pacing While I'm definitely in the smart-end-point, dumb-network camp, I also see that the lack of useful end-host<->network relationship/API has resulted in our inability to offer new kinds of services. (Ironically: "5G" operators need this more than anyone else. The ill-fate= d IETF APN BOF/WG was after that. Kinda. But not everyone knew that) I've often wanted a "less than best effort" service (as much as that's a terrible term), which would allow me to purchase unused bandwidth at low-p= eak times in order to do bulk data movement. I'd often be happy to do this in= a store-and-forward fashion. (Yes, I used to live on UUCP!) That's what we should be creating for space use; my understanding is that Bundle Protocol tries to be that, but that many think it is un-deploybale. (I haven't an opinion myself) I see no reason why any streaming service has to be live in the same way t= hat a video conference needs to be. Even people watching a "live" football ga= me would probably be happy with a feed that was 3-5 minutes behind, if it mea= nt they never stalled. -- ] 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 = [