From mboxrd@z Thu Jan 1 00:00:00 1970 Authentication-Results: mail.toke.dk; spf=pass smtp.mailfrom=; dkim=pass header.d=gmx.de header.i=moeller0@gmx.de; arc=none (Message is not ARC signed); dmarc=pass (Used From Domain Record) header.from=gmx.de policy.dmarc=quarantine Received: from mout.gmx.net (mout.gmx.net [212.227.17.22]) by mail.toke.dk (Postfix) with ESMTPS id C849C703971 for ; Sun, 28 Sep 2025 20:52:06 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmx.de; s=s31663417; t=1759085525; x=1759690325; i=moeller0@gmx.de; bh=4bjgPxQO9Pj/ZtLPbpWQ/G0L3KlritIhYijnMHtt2/o=; h=X-UI-Sender-Class:Content-Type:Mime-Version:Subject:From: In-Reply-To:Date:Cc:Content-Transfer-Encoding:Message-Id: References:To:cc:content-transfer-encoding:content-type:date:from: message-id:mime-version:reply-to:subject:to; b=qPAV7iHDRP3zcfL4ODKGb2lcMLvsKN9hUgQ1pFln6vwBgOYDlmv/RCEU139f9oM/ AawEaaZxIGvR8Jms+DZGHoxMcQ22eohaxPPUvFCFQXCIDtr3I38EwMA9gFJwFWER+ GUznjQ4ujfhpGfvisZ0eGl9myoj8WDSTRV4VKZh9yVwDqOS0qg9ALb/Ivi+MRKp26 R2lo3uxbVg4EcdIulmREZHNGMqBUgxo3eIlcdlBXgFL5BZMvsy+W6WoUquFFNB7tP V53OrJABup89W8t1gYl3tuD5e3/fcZpAqwBjx/30LlxfvvV5Q/Ve7+ZfPP7fbKN6r /CwIHc9+VI0brvR2bw== X-UI-Sender-Class: 724b4f7f-cbec-4199-ad4e-598c01a50d3a Received: from smtpclient.apple ([77.14.22.119]) by mail.gmx.net (mrgmx104 [212.227.17.168]) with ESMTPSA (Nemesis) id 1MOA3F-1ueYvM14Hp-00RRvQ; Sun, 28 Sep 2025 20:52:05 +0200 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3826.700.81\)) From: Sebastian Moeller In-Reply-To: Date: Sun, 28 Sep 2025 20:51:54 +0200 Cc: starlink Content-Transfer-Encoding: quoted-printable Message-Id: <0299A202-8726-4919-AB7B-697325BCC4AB@gmx.de> References: <175900400148.1561.6981645218542924150@gauss> To: =?utf-8?Q?David_Fern=C3=A1ndez?= X-Mailer: Apple Mail (2.3826.700.81) X-Provags-ID: V03:K1:yKa1MuJzEuRhNrTvDl+JpFfN6MWBJNBKFaR+Sfka81DV4VsR8hM xK0fQTBKT4aWv+s1WUxqWhHyfAlfG2h8JHg2mnkG9+oYogQ6TCOZ9U6SVDGJUeHBXWikFuf cEWct/QURhqXSMtqz8MVOnUz4HpTIdOGNNhvKk+yd+6ikRbdoRSqEN21H8ZslGeHjfEJZeV 3dQ1uDagnQBWaaU+Jo91Q== X-Spam-Flag: NO UI-OutboundReport: notjunk:1;M01:P0:UqnBEk+/7+w=;P73AFYQg28zOnVmkArdiQoyNxoo CmmMeCt3wLWtZFxSGx5lmG1Q/nOcOpYAC0cQZhL5GU1jrXcZ4zBLTbNJ9h4YX+hE3oLDra88x QNuaV5gMsBiZcgDw60gH3DuEEYchq+tilDZqfdjTojYVUgM+I9OhX3fjS07s8nvyAc/vciz0+ KQNqZzmbnx4PYyfgSpJDNkqeQMBrzszYR9wfrmZBebGqItNXyBZE/08mzW+O8IIjY2sViHBff Z6E1aNfLLkOy1iil73wqZWVFF2mbJftAUMTYGFPfBZQykydP6l8kGZpBhPJtQILp+cngEP8vO 30VUmIoir17YTGdUGzdaehK5mDMysITrDvuMX5Iy25rl9beCANTb24WrDcjvaP9aqUVocemNw bB1T7fZB+OE5x4J0AIbe3yZW6Fbm2M4a7ectIs1oZ80aBQARLx8VsEmZwLJaKhsF9zo0qICnp snjKp7Cv8AqPTUKc/N2YJ9ftchiVvw5laXjI8Ckn/JAEipP9HnKraUDph8Kt2fAoBkU7KI0Zq pLUflzvtbg/q/wbCSUMkAooV/zpo/1diYzw2kjUWUn2DtnDmcxHF0mskKJmtajtAA9e/JOYAN VemNOKiU+L86BiF6TOKa4ajnoPQmsKV67O5ofYcfyC8Zk9M8bkuCRPINuVr9AP+4efTfYJNN9 2iqyXBC8mBWnQFJ4TYB5/OgVOeH+dt07L6Ubq7pl+ITgZoTBHZKn/oGYZWFKbsUCM6l58/GDa Myz6Y4i30niNPazyEV/ZdNVquVxHqWjwn0libdORqMdMVJBhtEGbeYnFN3DfkUXi1abaE7haZ RPplEE1+DObwqbRxX+4SKbOgOhg0xQskoZeyd6XurhTzZnzlxziNdb3RMXM9x0qVSMucUrz9m Y4fgFKUjov0Sjyn3D8wrVI2CR8Gmgmmy52X7Ne6pmPdk0aKxr4a0Zt2QJdqgCrF6mE0F0RIQx p4Sbf0plt1vuXj0IAMkTsHYdDdds6/D0Ivr5sb44Af/0Bgj9iwu9PMNDoBE88lJ+e8jR9dLVz QgdsyIKuLRaK0qioOsEGS562OUcgMzNj9LEWezNYwVJ3WSGrUL6DzR+jHrsdJi3A6H+F+1aoa NFodhi6hEM6FfCDMEGDKhnAkFw11dEBSiyy5wHMTzUGCQlavBXBHH5vCONurQe+OPg8WKOnyo Durg+LK6wODu1pcDMd0C4E3Vy1q6LDYZjrYcSmMQK9IPZxd71RDfksu1CemipbS62MSwZ68ZU 0R2NzgbcCIQhx7pR6SpaFdeRTD/WnsMRlPwLzwrQJbEm+aKHu+GSS3EJEJb17yIvUYx3UH46L tAqalJ6xsDUsiCogewZWugu/TSCEbZFk0AqPLO8gGAaV+PxdGzYuM1EadATfS5qzYVATisnpc 7eFfFxc0UL6bDh8aidFxmZHeW8r7mQl5UzEo6HlC6gqT//xqU0hN6WEv0K6SobartIKXxjBC2 8hlfkg8pusA2PgNSWLwws5lbVl8zpJhA+YTNyjIAGIjgLwh1Btn8OmK99UO2n1bbEo4uuKHEu TI9wbg3DlcznTmldztd7Kku5JTMcOgoMZx2IioJfXgfrayk4fhTreHrI0KeSqmMz4+0/IS8xW r/C7JmvVmz0Oy7UvqkWdhwUp/b0eT2PskBIRwxtlRbiNruQPjdiPxWP+nmgm4OJJKwrVT3Nfc Jl1U91q0MmfMSODC1FkzIYPKUWgwZ9nKRrk2LFz2RDYOVQZ5pXAZMguJmJM2O0SrCNFVim85W LXOA92Y2HQJqI8Lbx03EgGEUAEY93b2be53LvHI4NDjmB5ZCNPTJMGJ/GDatMzBiOKI1h3jNZ xsN5JSqdtyvg8Y18RJPCrlK5wxJfDUcC9UZjGSx77+tIOJNpatQCEEQ3AluydGrKNOOIFqCMa fb14PGDCJMXPaScLV8RK5QkRvjJJR5Yu/Vn7g0Innx+Zso3MxzKqWSVLZbQLWVEs1HtLugzyw IyhRHsHC2cokdS929J2SMLhDKhSQytSFqS12PBW5RUbuSIKORDOTOYb93bbDmXc2q5+moxYwO tB/o9fuLx2gl/UlZkjSNX1J7iPET0aYqNOYliefhlwqCacjK7DIcZp2wtLcDEat6GB1t7T1gZ JF/pb099c7A1MFwBLcNczMUORXvchxc3FXcf8Hx5PKh3KVovQKaE4i+/agqVF2fppMHvydUMH t9lKXZSsaaOYxVkmqKbyCanccl0vlOFIRJP5LUTXZfNs1fyOkGAHVHZJ5elvTyBk40zqU7i5v fNYfV/QVPJSbgYpFmso/RMp5CtRIWcr7NVLR081UT6i3gHdO8ICOijxB1kEthW8HCyOR4GcVx EdT7n4Z62n5Cg0tP1rkjEHOEHb6FJNPrxoCdDBvwFyyR+zzFFbrJa0IomR5D5af8L1Ad+d/Jz 4xs5sYLFA2ForYink458XAtzTQIJZbPqawQ5NShsxmAUmXwZnoFaV70gEQqC7CWiuL80poQxZ cu2puxpTtKCaijAtM44a6EDH7OcRkgq8sDoPWhYvLIqay9a3riMHMCGI35kfN93SJYomV7pnw 0ExrvkHb0AWXzycgG4tiCZvky3pM+9vLIN8nejoo3lgHq2Ld8R0PFLJOw0bzq4fc98KiaMS2Y XZ0r5YYaakPmdEqLl4ai2rg9VH+4QUJnyMKNwGLOGgnEUc34V8io2Rnkm63YKZZ9Kd/aoU+a2 dAwSVmm1j0KFvJW1x54bizjS0NsolKR1wcvrRvOGL1DsuKkYw+UU6EovRu5QcDyJgLOslUS2R PCVT2l+vObnzxbssY3Mhz9EyRLyFCjC5gO1t1OIgz4ScZw0tlQTHGUhnyDJXzOiTEAtf2BFq2 1OKz502C3typpIEUm6xW9w4Bw87MZlrUp5Oys28Qfn7cIo1r5fwNvgpKIx8JW3eNP/2ivKzGF t9GItauVNWF3VxY/tV6jslLx8T2IRk+yFt7S6NYXu4EfGd4I6y8rOgcofBWLKJtR2klvN+OZO gIcVPshyvs4OxeASj17A5+gFnt/kZuJmrG73WUyBOy718rrllx+dYLLB10jCVSUOWHiNkpeUo wrhjJYn4n9adUCj6h9NsTQFTCpqQn5nOUNFyMFNXJ0Gi8SvM3K9J5iVFSF0DuhUpNy2ugfgwO 67OWeP1i6Ac93ES5g8dydsSlxLt+H0CdS52HwUBV/TxLqwQDn5rwHurqT5ChMRh2aY5XDiEgH 52KqVaETy24x0tcdIXkqUyAhAs+mVpLXzF+1Y20ebrp2uNnXMtAvTtD3kSKgKZkDW39hJQVv9 iXfXKcVjKxUW4Wp/R8TuVoV4RyBlMClj7s/W8T+1HpnXm968KLVDEC7QMqRzxjwIZ7ZAeoJuh ZQYppk6+H7HF0G6R3g4mB2PqrMxHRKZyq8Gv+mCf6Lq5+WimvYDCHl2XxIgT0l4fEqp+/pero WHzuJf2muZQcEpfxtzqL/7eO/DBY3Vw+ImgWmkzZ0Hh4ZQx9e6MdYqumT/7ccLgtFPw0mu6a8 KM3eBhsD9nwhWy7dkb379OytN2k5mdXGhcPw9rwmOmh8go8TVb09lgthWmWqgq3JjvF2VypTv qZ+Y6r0I/xVX6pghSl5FD9GdooXPRXFQRzqYtbmkuMQ278JdCQTMZBYd6jxO/C0v7I9wiwlTe 1Pl0rnT90ivARUKdLnWUSq608P9CjL69WMXSnJ0w2AK2Mfi7fxSEcZ88pSFdWSg/xEas1WIuN ovo7BgZo+Gyx5oyb+kqeZHyM3ESRLR/n+HXnNeCrWQSoWLBFL1NZJVZRbmr2nzFDm5ME9AN0q jvjOgvAi15jO48HTQ8bwdLWLGvbjn7fYFGQT2TGoce8WWUnHfurp9LcFSE3a5QzW2yRidEiNZ 8d9iwH6CxrYVFgsBqYn4AMF9AkTNrjSEC8clyBSMscuGm5TzBf6cYoaxZf/knfXg6k9IU3aWG dlIcB+G5D/GMGJB3pOVkvJ/MalZYMPsTMCKAj+MQXrIZbDfNe24cnUUU86Dv/KtvH/tMNojn7 MeGwcjI48nIFP8flnNTA0fRTQUHGp+ijFVKi+b3cKVOcnBHPcrwLczVzTvLCtTzOKpKvKuhsn h3RflbIb1qy7TJZ4y4kZq1n5KEUzvVUZLcWtOMFEBUJOVcnRIqzSxWjO7h+n1MSgdcoQkEGqq FBUEgAWyqwyYGQZQSSxK502hPzInJyM1lOmCUL88pm/yfA+40QVVVYxPxX/8TfpB/glOGf69M dYY6Ut8MCBQbnjXTrWK4hmoogLTEh2s8okZfyJg0YEW+gHIDS+dCDwPkEz0/64uH9IM5CoJED MLHTLxMezA9E7RullfVgFrGbhEMOihRF6sflM63QhIjIqHCfqvsuF3XcruUIhhkcSU3uWWUzF 0ttmKwyvF5lxCkb3sqxrYT2jZrlWssMgG8SVuLMS/P3c6cloylgUUah17aNu6TQQUh5ZIlyzk bC/iK7DDgovb0XUQBceuKjlTQtFLmb3i9Vq1foJQ4k3QuVO+ev1glMPJFf59EAD+eHrC2wlj1 8RJ03ATLwz14/UlI1GgVyrpT32EmAJlbr8wsTlhsPpvygB5kmljFGrGiHKozJOTvqB005w9Yv 9HVS/zLGpW+1yzc/lu8XMd//2Yk3jj7DRofkAnhnpiV9JsNjRBFA+XgQ3h4HJn+YWkPUGxDgn YgMbiz/AuWj4GQzeFvlK2N0QV3ZKoMK6Pxu8uRaLdxU2dcnyO6PiOpHTT7pVkzA68H6DKud84 vxPBwGmJGzHkVEO4IWQTQA8i0UrZFY35vS3UJCqVxw17LGvm6T7/DJVnIOxCgy8poXFhgPq+u 6yNqejwDzFTYxwq6I1JOypqNLNWAtE/0l7ANX3UB5zGCJnkbkrD4ye5spxPU2tBbEGDIeMBDI HwLnG/Cr4SuckDdvAUSbTM6HmEOmTr/pXZeAtpRsoeYNtDsGayhlBH8LX2FNxQyDWvgQx+OLw 7X43z1GyOnce3ErJar3xxak+6D0/JT46J3MhRJ7HjbFNu+HY5rHz5eHrmIZWL3tJkZ4JZXXKf 9CY5BKHMiGt3SI6qnzPOpAQRqTP+p4ADIJSrinSPTy1B2qMZ1P9y0iu3PNje54X2xflh2QYAS Jtitg== Message-ID-Hash: 2BUGGMPGOUK4KDCJZRKFSKI3WZDRLWQU X-Message-ID-Hash: 2BUGGMPGOUK4KDCJZRKFSKI3WZDRLWQU X-MailFrom: moeller0@gmx.de 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 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: Hi David, let me expand on this tangent a bit... > On 28. Sep 2025, at 19:32, David Fern=C3=A1ndez via Starlink = wrote: >=20 > Hi, >=20 > I understand that SCONE info about maximum possible bandwidth = (bottleneck > maximum possible bandwidth, not zero, of course) available on the path > between a QUIC client and server is not to define a steady state = (although > it could be), but may be better used to set the size of the initial = burst > of packets after a connection is established, during the slow start = phase, Yeah, that is quite optimistic, that a network node is willing to track = individual flows and taylor a specific maxuimum depending on the life = cycle of a flow. In theory that might work (and in IETF prose), but in practice I do not = see this happen. > to a value that can be more optimal than just a fixed value like 10 = (RFC > 6928), which was updated as networks became faster (with more = capacity). Sorry, I disagree, if we want less hostile slow-start, we need to give = the flow more veridical information about the currently used capacity, = not some hypothetical maximum. >=20 > In any case, if that info can be useful to make any user experience = better, > of course, is to be demonstrated. I fully agree and am quite puzzled to find zero references in the SCONE = draft for any experiments, let alone successful ones that demonstrate = the value SCONE might deliver. In my world one starts with such experiments and only writes an internet = draft if these experiments demonstrated that an idea has legs to stand = on. >=20 > QUIC may never replace TCP completely, which is very optimized for = bulk > data transfers, while QUIC was developed to improve the web browsing I disagree... QUIC seems mostly developed to hide as much information = from the transport layer/providers as possible. The argument seems to be = that it is hard to abuse information one has not available. That sounds = not incorrect at first, but given that the ones pushing QUIC are = companies like google that make a living out of (ab-)using their users = information, and QUIC does pretty much zero to stop the endpoint server = from snooping on you, so all it does is keep that information exclusive = to google... (depending on your stance on privacy and how intrusive the = local government is, I see how this can be reasonably considered a good = or a bad thing). > experience, making it more interactive. It is a case different from = IPv6. > QUIC is the transport for HTTP/3, which is now having a quota of 35.8% = ( > https://w3techs.com/technologies/details/ce-http3) and steadily = increasing > in the last years (slowly). Most popular websites already use HTTP/3 = and > browsers support it and it is the preferred option, if available. Yeah, but that really means that the main browser maker(s) and the main = content providers think QUIC is helping them, see above for one = dimension where this can be helpful. What the relative large fraction of QUIC traffic is IMHO NOT is a vote = of confidence by the users, as I bet almost nobody actively opted-in to = using QUIC. >=20 > The advantage of QUIC vs. TCP for web browsing should be an increased > interactivity, less RTTs to do connections, more responsiveness of = sites, Except for shaving off 1 single digit number of RTTs at startup of = encrypted sessions, how that? (Not a big fan of QUIC's yet another layer = of multiplexing). > less lag and latency, Yeah, not sure I buy this. > although it seems people is not really noticing the > difference after sites start using HTTP/3 vs. HTTP/2. Yepp, that pust the claims about QUIC's superiority for end users = somewhat into perspective ;) >=20 > For example, today, the following site was reported as recently = starting > using HTTP/3: > Pokemon.com (https://w3techs.com/sites/info/pokemon.com) >=20 > If anybody made a survey to usual Pokemon site visitors, I wonder if = they > noticed that change. Good question. >=20 > Regards, >=20 > David >=20 >=20 >> Date: Sat, 27 Sep 2025 16:13:16 -0400 (EDT) >> From: "David P. Reed" >> Subject: [Starlink] Re: Starlink Digest, Vol 53, Issue 14 >> To: starlink@lists.bufferbloat.net >> Cc: starlink@lists.bufferbloat.net >> Message-ID: <1759003996.780613387@apps.rackspace.com> >> Content-Type: text/plain; charset=3D"UTF-8" >>=20 >>=20 >>=20 >> On Saturday, September 27, 2025 02:01, >> starlink-request@lists.bufferbloat.net said: >>=20 >>=20 >>=20 >>> Date: Fri, 26 Sep 2025 15:11:23 +0200 >>> From: Sebastian Moeller >>> Subject: [Starlink] Re: Starlink looking less niche as its retail >>> presence expands >>> To: Michael Richardson >>> Cc: starlink@lists.bufferbloat.net >>> Message-ID: >>> Content-Type: text/plain; charset=3Dus-ascii >>>=20 >>>=20 >>>=20 >>>> On 25. Sep 2025, at 19:45, Michael Richardson via Starlink >>> wrote: >>>>=20 >>>> {resending without signature, since new list can't cope with >> attachments >>> yet} >>>>=20 >>>> 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 = the >>>>> interference? >>>>=20 >>>> 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) >>>>=20 >>>> I was thinking about the many places where bandwidth can go up and >> down, >>> both >>>> for Starlink's various mis-attachment situations, but also for = OneWeb's >>> Polar >>>> 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) >>>>=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. >>>> Yes, meddling by middle boxes. Ick. >>>=20 >>> Regarding SCONE: >>> "The Standard Communication with Network Elements (SCONE) protocol = is >>> negotiated by QUIC endpoints. This protocol provides a means for >>> network elements to signal the maximum available sustained >>> throughput, or rate limits, for flows of UDP datagrams that transit >>> that network element to a QUIC endpoint." >>=20 >> Absolutely agree. Trying to have the network elements define a = "steady >> state" for all entities communicating over a path in the "near = future" puts >> the control in the wrong place. (Well, many at IETF are "net-heads" = who >> think they should tell applications what they "need", and view the = network >> elements as a consortium run by all-powerful communications operators = like, >> say, the PTTs and the Comcasts). >>=20 >> The best (most accurate) signal is still a "dropped packet" that = results >> from queue overflow. And it tells you only that the source sent too = much. >>=20 >> There are no "guarantees" unless you run a central scheduler that = takes >> all demand known to happen in the next period P (after the current >> operation period P-1), and distribute a "fair share" (according to a >> committee of network operators) among all users, then not admitting = packets >> during the period P, except for those allocated. >>=20 >> In my view this kind of network-control is the opposite of good = Internet >> design. It's almost as bad as having ChatGPT write design documents - = pure >> artificial bullshittery. >>=20 >> There is an end-to-end style approach that suggests that there is no >> steady state end-to-end requirement at all - just the most fair = sharing of >> the achievable "responsiveness" or "low latency" of the end-to-end >> applications. >>=20 >> To achieve that, "throughput" matters very little. Queueing delay is = what >> matters. >>=20 >> The current Internet tries to make ALL queues as close to zero in = length >> as possible. It doesn't succeed, of course - it can't predict what = "end >> users" will try to start and when. There's no "statistical predictor" = of >> short-term demand that works (yeah, you all took classes that said = "assume >> an average load of X", and never asked "why assume that?" I did and = the >> answer is, that's not reality or close to it). >>=20 >> So the best answer of SCONE is "the maximum you can expect" has a >> denominator of the number of possible flows that can go through that >> network element, and a numerator of some fixed number. >>=20 >> And by Little's Lemma, the latency you will get, if you fully = allocate it, >> is "infinity seconds". >>=20 >>=20 >>=20 >>=20 >>>=20 >>> That is going nowhere productive... >>> a) restricting this to QUIC is fine only if you believe that QUIC = will >> take over >>> all traffic soon (keep in mind what we expected for IPv6) >>> b) "signal the maximum available sustained throughput" on a shared >> network like >>> the internet has a simple true answer "0B"... >>>=20 >>> IMHO what we will end up doing, after exhaustively attempting and >> failing with >>> more ambitious schemes like SCONE is tp collect something like the >> maximum of >>> current capacity use in percent of all nodes along a path and have = the >> endpoints >>> use this to track changes in left over capacity and try to control = their >> rates >>> accordingly. That is better rate-control that is still driven by the >> endpoints. >>>=20 >>>=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 >>> "long enough" is a relative term... but sure if the = latency/"frequency of >>> signalling" is substantially slower than the expected capacity >> fluctuations then >>> this will not gain much, but if enough of those fluctuations are = "slow" >> compared >>> the RTT of a flow this scheme can have overall beneficial effects. >>>=20 >>>>=20 >>>> 2. assuming, yes, what would the best place to do the SCONE = marking? >>>=20 >>> In our dreams.... in reality instead use the kind of marking that = has >> already been >>> shown to work in the real life... if I sound disillusioned about = SCONE >> it is >>> because I am, we knew even before L4S was ratified, that it is "too >> little, too >>> late" and again instead of doing the proven thing IETF contemplates >> another >>> academic proposal. I wonder who has the actual problem of a missing >> advisory >>> signal that SCONE offers to solve. >>>=20 >>>>=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. >>>=20 >>> That is what feed-back-based rate-control and some modicum of = healthy >> (transient >>> shock-absorber-style) buffering is for, no? >>>=20 >>>> Packets going up the link, then being dropped, is just wasted. >>>=20 >>> Sure, if we veridically knew which packts will get dropped, we could >> avoid sending >>> them in the fist place ;) >>>=20 >>>=20 >>>>=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 >>>=20 >>>=20 >>> ------------------------------ >>>=20 >>> Subject: Digest Footer >>>=20 >>> _______________________________________________ >>> Starlink mailing list -- starlink@lists.bufferbloat.net >>> To unsubscribe send an email to starlink-leave@lists.bufferbloat.net >>>=20 >>>=20 >>> ------------------------------ >>>=20 >>> End of Starlink Digest, Vol 53, Issue 14 >>> **************************************** >>>=20 > _______________________________________________ > Starlink mailing list -- starlink@lists.bufferbloat.net > To unsubscribe send an email to starlink-leave@lists.bufferbloat.net