From mboxrd@z Thu Jan 1 00:00:00 1970 Authentication-Results: mail.toke.dk; spf=pass smtp.mailfrom=viagenie.ca; dkim=pass header.d=viagenie-ca.20230601.gappssmtp.com; arc=none (Message is not ARC signed); dmarc=none Received: from mail-qt1-x82e.google.com (mail-qt1-x82e.google.com [IPv6:2607:f8b0:4864:20::82e]) by mail.toke.dk (Postfix) with ESMTPS id E9AC56F08D5 for ; Thu, 25 Sep 2025 20:31:57 +0200 (CEST) Received: by mail-qt1-x82e.google.com with SMTP id d75a77b69052e-4d41154079aso7853941cf.0 for ; Thu, 25 Sep 2025 11:31:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=viagenie-ca.20230601.gappssmtp.com; s=20230601; t=1758825114; x=1759429914; darn=lists.bufferbloat.net; h=to:references:message-id:content-transfer-encoding:cc:date :in-reply-to:from:subject:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=IJnNRG5y79d+WihOItmP0bPUt/fxLs7JHVv+qPJeDzk=; b=ePbbDnctGBg9gweiE+/VRm+myTiuhnlf2bggDewk0BZRrVlEWY4NGQY7N7H84GAgdt dnkM32WdTKM8pdfgOXv5wRwxiOvmtbas7NwC9/pO+DP5jcyevMg+IglO85OmZHXTc8D7 wPmloXy0+Dsla2WK8jhH90cyBD8g5UfI2sypALm049IhQiQJrzQvEYrW4ar1odAzydtU 9wu71LJ2I/g32ubrMO8vXNt+FoKmcN5MIi7P4MJzpvQxuyo2AZcf0n9XweajWit2XjGl Bq9OwJB039EMZY63k+SygnxQ4OzNB9PJgqDDklUNmP5iS4L8BN7Uknfn/c97+sTbOcGY +WgQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1758825114; x=1759429914; h=to:references:message-id:content-transfer-encoding:cc:date :in-reply-to:from:subject:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=IJnNRG5y79d+WihOItmP0bPUt/fxLs7JHVv+qPJeDzk=; b=uYFeo8PmVC157rtBKzzwxy0EMRCPLwt586fM2K5V+uhAfweDKgQhEkObkmMNJWSzpk 8JSu2Lu3DEwUIot68acoEQAT8E66fE7zSiwNgZpDqhI7BMLXTdXqGIl6UEsOA3WtycfJ G+l0nCOf2c8I9P3SDwSaDktFMxC3fprlyYWLQQ6+GCf8l1Vz1QLFT76fVEoMpwV+T8jd 2WgUcSg0NW41E3NMmt20TAO1ps24uc0hOzclQMv54hWO/fPXr1z9enHsKZ3HTCabRzRX g4ST7BBZdkPD0MEtF9mTLObNCtjlimA4jFBhB9LA1qCw2Dzn+VMs5Qh0CqVj81Og718h +MaQ== X-Gm-Message-State: AOJu0YxMVUfqjPizdyn/dr/V04CnJqBl7yvTQOW6/7VcMZb/ZCHDjs4e gkDx1DennPFjynUaQoJsBnTE1RcNgwGx1i+LEOPpz2kPoAovRTtWZoQaVmTyRe6NZ1WLByWKGwT 5/hbv X-Gm-Gg: ASbGncuOEfumrVpRwu/DbH17mHhYYRmPux9Cx//vssTPHh8b76pLRTou2Cs5sCtfb6a Bd+8ulYat4biFly5egFZypFePyqjX31xCrECmatpmYLv5OsMNUKRX645ET9Buv3+NVi59mUeWLr 6i+z9vf54CcnXepp95rJMPmbgVH2ycPvDgZUzsPNKv3995BaEk3UuDQ/FujEhAVdlvjUPSorXIW 8YSf9ZVqdsd/NzDzoU1UZb7nDHL4+MXfQDYFwEpULhoCtU9Ck6Mug8KKyWK8cqhOzjvip2swE0a YDsKmDvADiCVcEmOCDszw+POjrq+relfDzIcW+dHQ9aY7/2epGCtvC9x2Cr4lrCBUOOaYSageiQ VQ6gB1N+Re0x9YIZxSfBy78hnumhU8decMwUiTp6ZPK79W0Oa4OHW0uBlL9jFIKekuxhDyMEne2 NapnTIjHS9wnfAiMco40/y+NNepR3xYEjNmg== X-Google-Smtp-Source: AGHT+IHhp+E+d8QTtjq3z4tHo/1KImQgO1pJRH45TErnpzk1qNEKZ8AX0Ri37zL/OT73xCSTVZLgbQ== X-Received: by 2002:a05:622a:11c8:b0:4d0:e65b:cf with SMTP id d75a77b69052e-4da485b715dmr58825471cf.29.1758825114105; Thu, 25 Sep 2025 11:31:54 -0700 (PDT) Received: from smtpclient.apple (modemcable108.66-162-184.mc.videotron.ca. [184.162.66.108]) by smtp.gmail.com with ESMTPSA id d75a77b69052e-4db119f05a0sm14212121cf.43.2025.09.25.11.31.51 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Thu, 25 Sep 2025 11:31:53 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3864.100.1.1.5\)) From: Marc Blanchet In-Reply-To: <30473.1758822310@obiwan.sandelman.ca> Date: Thu, 25 Sep 2025 14:31:40 -0400 Cc: starlink@lists.bufferbloat.net Content-Transfer-Encoding: quoted-printable Message-Id: <8138BCB2-5CA5-437B-B12B-C3AFB1F2C669@viagenie.ca> References: <175876550514.1555.8294777204829819629@gauss> <30473.1758822310@obiwan.sandelman.ca> To: Michael Richardson X-Mailer: Apple Mail (2.3864.100.1.1.5) Message-ID-Hash: 3WN22JZKDG6ZHCSMZH37KDS6WMNRNUWC X-Message-ID-Hash: 3WN22JZKDG6ZHCSMZH37KDS6WMNRNUWC X-MailFrom: marc.blanchet@viagenie.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: > Le 25 sept. 2025 =C3=A0 13:45, Michael Richardson via Starlink = a =C3=A9crit : >=20 > {resending without signature, since new list can't cope with = attachments yet} >=20 > Luis A. Cornejo via Starlink wrote: > 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) MobileIP required cooperative routers "everywhere". And did not really = address the fact that a transport connection is based on the four-tuple. = Transport mobility (aka QUIC 0RTT connection migration) is the right = level where mobility should happen. And this is way more easy when the = identifier of the connection is not the four-tuple but just a random id = within the connection. >=20 > 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 = bufferbloat :-) > It was the cablemodem burst mechanism that clued Jim into bufferbloat. >=20 > 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 the > aim of inserting signals into QUIC traffic about bandwidth available. But scone is a 1.5 RTT mechanism and it requires updated L3 forwarders = in the path.=20 Remains to be seen if this will have enough traction for LEO = constellations. Marc. > Yes, meddling by middle boxes. Ick. >=20 > 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 the > end system. >=20 > The two questions: > 1. are the limits/conditions stable enough for long enough that the = available > bandwidth could be communicated back to the uplink? >=20 > 2. assuming, yes, what would the best place to do the SCONE marking? >=20 >>> Let's recap: Spectrum's boxed in, and power is boxed in. That = imposes >>> a hard limit on total capacity (look up the Shannon-Hartley Capacity >>> Theorem if you don't believe me). This capacity is all that Starlink >>> has to share among its users in a cell. No matter how many = satellites >>> they launch or how big the rocket. Add more users in a cell, and the >>> capacity per user there has to go down. Law of nature. >=20 > 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. >=20 > ps: > I have been watching: = https://www.youtube.com/playlist?list=3DPL-_93BVApb58SXL-BCv4rVHL-8GuC2WGb= > where they have powered up 50+ year old Apollo Transponders. >=20 > -- > ] Never tell me the odds! | ipv6 mesh = networks [ > ] Michael Richardson, Sandelman Software Works | IoT = architect [ > ] mcr@sandelman.ca http://www.sandelman.ca/ | ruby on = rails [ > _______________________________________________ > Starlink mailing list -- starlink@lists.bufferbloat.net > To unsubscribe send an email to starlink-leave@lists.bufferbloat.net