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.15.19]) by mail.toke.dk (Postfix) with ESMTPS id 3415B93C3C4 for ; Sun, 09 Nov 2025 19:42:35 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmx.de; s=s31663417; t=1762713755; x=1763318555; i=moeller0@gmx.de; bh=7JMavns9wvBwRfUsODAOf2i5sDNrejGDaWNI0DK/7I0=; 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=q7fSMA1KwICtqu+7KnopkzJYuweWgiEpmHaqwaIA0J9oQdV1EZ4ddinTd5bbeQP0 GGJavYT6kY3Wqk0epXk3Ku7ottsSd+Ini6EaGM/3yvlp09FomBKu+g7SxJD8TSvXe JzWrO9hzKmykubh0PiOEZkRF7Zf40udc8GDv/ZLX6r/qRjiLLMJooj+QFaTLekjzB KYoof7g+J7nQCz7N6T5aH2l9/10f3ZwXcuZLd6DJHuOFja9arOrgwDP7la+W8BFq5 m139EiMxW+nCiIaDKVDplMBlLRy5lqD+C6HtznxA3QscSJyGsyMPi2eeRH/qMCnXv BXU+2ADPjRkUJ0nh0Q== X-UI-Sender-Class: 724b4f7f-cbec-4199-ad4e-598c01a50d3a Received: from smtpclient.apple ([95.119.251.78]) by mail.gmx.net (mrgmx004 [212.227.17.190]) with ESMTPSA (Nemesis) id 1MkYXs-1w3r8833mQ-00gHpA; Sun, 09 Nov 2025 19:42:34 +0100 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3826.700.81.1.3\)) From: Sebastian Moeller In-Reply-To: Date: Sun, 9 Nov 2025 19:42:23 +0100 Cc: starlink@lists.bufferbloat.net Content-Transfer-Encoding: quoted-printable Message-Id: <7A603AC1-0A9F-4A71-80E5-3C0B187266BA@gmx.de> References: <176254173597.1347.15997824594759319437@gauss> To: Ulrich Speidel X-Mailer: Apple Mail (2.3826.700.81.1.3) X-Provags-ID: V03:K1:pqA7Xl8Zz3tG7uFYPJr3K7MCSsbcOiO2hWdDdYIxE/JW/sci9zm WxyaiF9/HvoE7NdCA1dk+hVGpuHD/VSuFOQ6r3AXLtLFUxnjy7HdhmpHvrRJqvF5gAJRETX BtYxSZa/R/hcxvedw3IY5lgsSi7W9VyK0fcgBe+CR7Rp9lIcVHF5MZ1GROCEhYRFuJ4/lLo 4kFcDggCxaeiy2IIU+wPw== X-Spam-Flag: NO UI-OutboundReport: notjunk:1;M01:P0:ah38/u446fg=;TFQ2sR8CFpgOk3vA/wmiYTsIFFX srp3GaPYxBzo1qP2dUqkqTU0ijBsmj7wVd856+mmtjFZ6W4g1qhic5bigqgH7EhASkoJERA1I pb45Cqhx8Lkn/FYZlkRCast7ENqDizFt6rty2osjU5RLtkezW6HX/tYYc1v6RozcqUVzEPOXl eikku6/FUxeEUixZY1hBCoaNGsS9pUGalF9q0Uh52r1UDD+emAogXtX9q5dX1FTkxuwqs8E6c bJp+CHLwbcSQGKmWthQQw50jYOptaER+1LRMLTAZMAayXacuUhc3a0SpxnxV0EYBfR/FU9P7n Quz6+Fwknj18KP+ZyJI1Y3+HbUYP9PpUNriCLkdvFhkB7VBRYdwl+AuuEK72Kio28nN6nZiCU J69ZboumTj5bGUgUykGmwgSVwgTpmpl/pt13tc9FLa/EHHzjYtl2fGwoi5l0gPMb/RuC/U/nl DcKA+Hdr+o5SaGUljwDLPfOMuE0o7mXkyCp6VaBG749usfIO2ceZqCuEYkIS0TT4JRQqIGSbe R9vlQD9qTJUBAmx1Vn71xeHUyKZm4HktWpt3fmv980sRJj/FM+uXFYbjH0F0bKJ5OYr9P18dJ fBSGC2TTfT3jHdqV8Jem5HcrbndpyZOQUTjebtedCbr74OMTrUOWRgQ5Px6F6EjBUJ217LjXu fFJdA9hHzGFWyoIc4mLKp3DJCg0Ybm3nykvgbtdqx6z9ACZ3VpFNcQmW5YOjLNvUX3mPt7atW wIECwz47iLgQ4eGKlZuVdEiSfC7AY5C4sgcIUJ6XYWw0rIHtXvJhlbI6njIQA4i8DB/5X+IIr spsOxdhYROlzs5Vo/OnHKvH2itrGfJEgJCAFx0gWntWC6LyI/SQ4yCfBVrbOoR5+GGrhPf9bp Pw2VzDPFN4q7iCfuvJxgUfFeXU894jM98pgcJHfNuxdFvioalP9CIe0ihIJzyTieym/oc4RnC eZl2u1dHPV248Hok25rLSWAu1o4faD37snZdVY786Psxa7jM0smJQ6C34yxPQMF4U2NKASbxb V5kadSgA2tpzdIEzpZKQuBtMnWsMDiW3M5Ak3ckhNeXrPOfIG3XkaX3EMUFikQqCCMUR6Jxda ss6PaGs2u0aRxxGu8NzNri5RiqMgI7oKsfS4+9s0LVBk9iB0iTvmo+zkHghxrR5FgTphMgllc RD6hq3QNJ7O3izHZ5NqHae4Jd1tlfc/Rb/1pCNy1ix1mQGrXyerCGAYajQUj47kVItsyzt33s kPf7lsOPRrVon7QV1LQjaZdNZpzfJWTiKdD27j5s6JDKq+2q3rftuk0792BZSYLKS6RBzFSpG WEOQyHxM/LR28er/VV/yG7jWASVBXIQDFLbfTJ4efR0NbRAp30dNZqUPUOsLhiL3LeLDs/O/N hnWKAdIoNj42lFpS4/QjlPdfVFFnX0sO/xdlsu27feMM4MTYeP271grh4/NVHREs8bE7/TOOl 4F023f9Q1Z7hHZf0JefEOLj7pVH439l1HMmSb8l4/vzPZ/rwlFs4D+KpNC4Sz0s3FBI76SbZp MTJ5x6OCY6FtyZOIzvlbr7sOZoIAqIuSYHSCgoNpVhiQ+py8qp5kZNnFG3P+3BXKWECr882Oh 0FlXxCDPZAfllyOaW5/XvCU8D3Ke4eP0uxfHhDacDVAO4p74JDtrYShFdZz6z9sD7La9c7ya0 xeewUl1THhnyQxeRqWUbGXwar46SwPmw/VlXSJCoN/7/W8OQe98YDiptepzCuvN2Bzpk//uGV RckEfNfT2Nu7mp8ALtgtMpEFg1ax4X+LQlZPGLRmBHEuQnZD0MAMbbJK0VAPv7nVwi7KiJ++L 3QGb5dNMDnys0b5DBnF3nt9WptiboTA6wiGKubNpknTK5M8jHO4MO+vESaNZtHFfEK05GDN2A s59BAYwuP2M8+1f8zufGxZwKCmYfRWnvDMmFCq6LoUEDhhZInNmXhV+JaFoJQ5IjRZPFs2nPM 0BQ3Ev9lJmAHzBAeQNj2Ye92OI+ncXDoq6IP+GPFh2Vt/eiyGAPcgfZlGpgchVdQUt4Bgqnpx FJ/riSdAoH5RPDFEx6gcHhDypz5Hxw7Yzjf/aM/FiFbC8vhQzJFFJ4GwKARaAHXfjl0kylyo0 DU9xfWHMQjc3SVjKFULTNXC82htJR4s7BcsJ+Ov/SDMV5pPwy9bbKEOJ+FIRRwFKRFzUNU5Wm FH8XxpvQ27f+CLN+E86x9No+DjJxXIqHcxiUDrr/AkziVob0wFT7B7TP/xjU0NcDH5Tit9fWm S10KYYsz3eCCUbp/Vs6SVx48lciWE9ZQmVBf3XDcR8Mf/KZ63hzMWXZi5q68nfMq7MBp8JSxm Ke2Qt8bGfQCc2nCRQAGLnC8qVtYDL3g9eE/takS7scMccV/8eaP3XfuYZpIh7P/mjJNBwb1cu /VxqrOem1Njhr58+IcfDeisMGOQb+HX7DmsJgX8GuZAfhbbfYqE7T9C/ow3idKZN45Zu25JdY 8c8W3Kzvxv3MPykgk5zxh10aa7b0ccfax/2ow+1BQ9+xCQs32jIbKJqwLK+oaHyvqjQTUw9VZ I3MLgSi6vUPW62QIoV9WLHREiScX1R7Pz1GPTh1IKnB/+O98qi3Waphd7JvLEyYTg10jF/JoC HdUXbIAzrV5p8fOlzVU1DEiNt8CYQ3XxVrclbHpqo6Pv24YxEKowQVOsIpQM5XPGJEx8pr2YK gCnT9uwhIogctjeytZfeZFH3WSH7xPiQDFAkire0hFViLMNZEc+gTWL6Z7qga1tvwRxmC+EkE 5lI8l+HI6/rv0zPBciLsOnl+eV+6eXP8JMMiuWKVnEUvoV66TxGwl5CrwJxqTUCMhRM1LNrd7 F1gnC5ju5rhMeoFlEGsxfbk3N8Qw9F7MDqCHWZsZzIW1Y+zsh6Vg+4IDKZ0F68SGZu6gwdEDc HbOT4uo0zai6xe9olCHw8Xf90vDTSp2ZSPEhgfpGdGUH0HCFo0r2Z439tTaWnBaMfrKIFwRCN qymMNz0w9UFvSUIyH+xW07EhP7I3pwPMnIPf++wferwUCSFc/e6cyPFWEjVMl9Dhv9LXSiHB1 zPPg6ofPxvkeijuZDRQ+pPwzNqBtCQr6ptuib6hHR4yFq6qkJeK1gVoJPmXopmhS7Mqjp0jh4 eRy7crIh/fqN/43bvmvY0q0E9A1G/lybmtIiY9/lBIcjmhtpSDEOvjEgVBpfa+himxqxYjPX8 nyHJpJX2A9d3HgOE6T9WqDPs9gS5ZOqGQ2vgBRE05gugkhgVbrNKwmuFi03tqq+mebRry10vS mKyO4lptKSTDrvH9TGxiTtUO/E9o4z3oKJ0jkawlotFhl4MhA1pp5R0BLYRH591jdFZNKnpMI 25Tv1bD2tWucDHf/GfTyyy99en1zD5YR+jbuEAQdMxe+BTHYb+lQPHpfw2qDPwdrQLcGisDEs VAFmpbuSxhpYzbbOjc3iYJGxo875aD7NjImBv2uLFOnq12ocHnRUCSTXxR2G57ugC3iiSwPmJ 2CHEOdICpi6HBM3v6WZmfqxbUQDEImuoROv83iaQoQT5tKuTgLrX7jBp84+IPI8ZsSZfgAeZU mfPI957C0nIZbfbb4dlPMlCId7JeTASEPuYbHR9ANigQsp7gWIMfFSeJ3mdA6gG9Qm+kUumZv r7g3Gvw39LCp+w3+401qKShSkQG0anUCjA9y4i68OPu5k/BDd7aqaEIncGQ3P3k0BLc2dK43q x+/VhU2FEp/Pun6aPme/KUoD13+eLb5ydBfq1EPvJJCX5eDiJchB0RGQYROsIB1tMVgp7zaeV agsCYsMzQEbf0JZHpd9STIvZZQ6sbfO3+08Fsf2XX+j3RfLdIa1Y6YUuTyOsr85sJIX3fhSfW SfEW2mhsDEKtQ7xDchPL3OuOaKzFeXLitGmvXWbXHfxPbFyJFzCgVqhwXFBSZqLpOuOuENE+b MCaxz8vgQFzBrISt1Ugzs4GgXo6OBnuzAELavLsOQpBvTAgydzK41WuYlp2sgScNSO8EDGMBo /XrMC0by0K4P58o/4uOuP+WVVCbmaWSraGc9abxhxHDzCNP8uuI/pt7OrR57rSw8LW66Ybq/i 8s/ui4tytm+o+72Rtqz7h5oofvVVGxlGicVYAKSG9k86WqJB6nq+AMCSNhltQiV/uuj+b8ruV fjiu1UqiqD6WdYHNLOVVn5klqysylREEQjwkifCPB9Y3xoQqH6zLg3f3XT7EBtEM/UBIAioEn I68Kcf2zZdQnc1RN+t/hmBA5G8FiXggxv4ScPRPWJcdSk57GqekXWykeF137FbNfaCyu8JIBZ yNUpV+QhAA12Zml99s7/WqfE03f7fMgAnmq18a/yH+w24AbdEXLOCdGFsTimP98Uv8QjZ0xAr fbV35GFyOGM8bvzOmeJU9hRqg3RFapN7B9Wmv4Md1L8Zal+jBlGSiUb6MXvZdpWdHgHzlJ36W nWIdWj4Up0MKaGmO7W2orGM+vIuFHMpnWEGyJ2QeIJbopuDZyscOnsGdcENY2kCCFuPuPBod2 mUwmtM0L37k250NKtE73MIkD9/GUFmdPeXTOxZ8bcV5bENUHNzH9FM/sYjBbQEZFjoSy6HR8S dlNLMPjP6Hv718ZCShUWhmmqdk8ugCFpDkY3xXIzZg01fqSNwLW8WJHVx/r5Zep861C5kfISv OhoD4s35l8MNY23wjW2adBiFkwbR/tVebl4ckitDJJEfBUhcx4diu418rA0wjymYKrBmHM0fi 877Rp00B/lUITv1LOv2z98n1IUKBThJoTDbo2xBgoW0xFSWDeFHEKBej/k6tCM4GBgcNFxdzl dwSl3DRC4JcrG0m9vA/OWNF6qLvZxB87iEqjyfQMm77OoTbUrzRofFpa78LnuJAo+/UBJrrYC pccMPCjb5dhoYQp2uPk3dKbpV6KYxFM1sz22Of8wUCJTvHU0d9+QvjS6LwXJrlhANNPiVzYMq RCGxzlPD08bVGYhtJ4eWzBqnaocI6rjxSkOEnm1QEsKO7ybhQrmEGJyERRaOHUGGFn+FndfYt 2RufuO+GvzvSxwbebR5c6RRAUAHx3xtXDKFsUaCd4ykeF7Xb9dMN+N1yLo6xDDi8b7IksawuW UvvumAOX7dDLKkeoUc80g0Rds3Y1GVTg08sbYulJPvzhruwlU858EjeyuU4tcilz/9cm/PGDd 3zck965O5ssOs4LVy3e/i9kBZtAu6zNgAwl4RqseEXL8qObiub+bJqZ0+IRKSjS3UYx68MXDm 7Og8QXTjpwLy1S9DqSUwiRs9KL/eFf15cIWAEYLsGx+O7gNYHaA== Message-ID-Hash: 4JT5EPSVBDLBY6GP6SKXLYZ5HNKJR5KU X-Message-ID-Hash: 4JT5EPSVBDLBY6GP6SKXLYZ5HNKJR5KU 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: [LibreQoS] Re: Keynote: QoE/QoS - Bandwidth Is List-Id: "Starlink has bufferbloat. Bad." Archived-At: List-Archive: List-Help: List-Owner: List-Post: List-Subscribe: List-Unsubscribe: Hi Ulrich, > On 9. Nov 2025, at 02:03, Ulrich Speidel via Starlink = wrote: >=20 > Starlink is a bit unusual in terms of its packet loss mechanism. >=20 > In "normal" networks, we have damaged packets (low SNR or interference = leading to symbol errors in the modulation that then translate into bit = errors and failing checksums), queue drops as part of the normal = congestion control behaviour, and - not sure how much of a problem this = still is these days - receive window overflows. >=20 > In the case of Starlink and handovers, there appears to be an uplink = queue for uplink to each satellite on the gateway side of things. = Suppose your dishy talks to sat A first and then gets handed over to sat = B. Up until handover time, packets heading to your dishy get sent to the = queue for sat A, thereafter to the queue for sat B. These queues appear = to be different and - with different packets and different volume in = them - seem to lead to situations when a packet addressed to you that's = been enqueued for A hasn't reached the front of the queue by handover = time to B. As A now no longer talks to you, this packet is now on a road = to nowhere. >=20 > Of course, this loss only ever happens at handover time. No such thing = as a uniform distribution here. Moreover, it's NOT a loss that should be = interpreted as a congestion control signal to a TCP sender (or whatever = other protocol is trying to congestion control itself, e.g., some QUIC = implementation or somesuch). >=20 > On the latency vs. bandwidth debate: To me, this seems a bit like = arguing whether width or height are more important for area. Both = matter, and both are equally badly understood by marketing folk. >=20 > If your video needs to stream X Mb/s to the viewer, then the channel = between the sender and receiver needs B > X Mb/s of available and = accessible bandwidth. That's why bandwidth matters. Basta. Well, you are of course right. However for almost all interactive = use-cases the capacity that is actually usable by an application (and = where less capacity results in noticeably worse results, while more = capacity does not increase the perceived quality any more) is well below = the access capacities that are sold. For example page load times do generally not improve once the capacity = exceeds 20-25 Mbps, FullHD streaming needs 5-8 Mbps, 4K streaming (still = rare) 15-20 Mbps, videoconferencing typically also needs less than 20 = Mbps, and traditional VoIP only takes around 100 Kbps (per direction)... = even cloud gaming at high spatial and temporal resolutions (with short = time windows to compress the video) only requires more than 65 Mbps (for = 5K@120 Hz). And remote desktop is quite mild So if we are generous and/or want to allow multiple concurrent users = 50-100 Mbps is the capacity that will cover most typical interactive = use-cases quite well. And at that point halving the latency will result = in a bigger improvement than doubling the capacity... (I like your area = model conceptually, yet increasing latency does not improve things, = reducing does). >=20 > The "accessible" part of the bandwidth is where the latency comes in. = Remember the goal is to hit bandwidth-delay product on the lowest = bandwidth link along the forwarding chain of your packets, i.e., to make = sure you have that bit of pipe filled. It's a lofty goal because = whatever you do in terms of increasing or decreasing your sending rate = only has an effect some time later, by which time the conditions you're = trying to respond to may have changed. Your picture of the current = conditions is always outdated (and more outdated the longer the = latency), and just to add insult to injury, the conditions (available = bandwidth, RTT) can also change without your control input. That change = is among others driven by algorithms that are possibly trying to fill a = different pipe, or has at the very least a different (time-shifted) view = of the conditions at the pipe you're trying to fill. This is a = fundamental control problem, not a matter of BBR over BIC or Reno or = Vegas or whatever you've tried on ns2. >=20 > There are things that make this control problem a little easier: lower = latency obviously, but also exclusive links (or at least fewer competing = flows if you can't get exclusivity), fewer bandwidth bottlenecks along = your hops and bottlenecks that are more predictable, i.e., where the = input queues get processed at a constant processing rate. This is why = last mile fibre and Ethernet in your home are so nice (just because you = have your own WiFi router doesn't mean you have the channel to = yourself). It's also why CDNs are so popular: They combine low latency = with less competition for bandwidth and fewer hops. >=20 > Starlink's challenge is that their bandwidth per cell is limited. Not = quite to the point where it's a problem everywhere, but certainly to the = point where it's becoming a problem in some places. If you're being = asked to pay a congestion surcharge when you sign up, you're in one of = those places. Moving to fq_codel and bringing down the latency has made = more of that bandwidth accessible, but again there's a limit to what you = can do there - it's not like reducing latency increases total bandwidth. True, yet proper scheduling and AQM makes links that operate around = saturation point still quite usable even for interactive use-cases. >=20 > On 9/11/2025 8:57 am, J Pan via Starlink wrote: >> if there are no obstructions, starlink nowadays can achieve 1% packet >> loss, often 0.1%, mostly due to satellite handover, so for the = netflix >> open connect appliances inside starlink pop, they can do some >> starlink-specific optimization to mask away the handover for starlink >> users, e.g., = https://oac.uvic.ca/starlink/wp-content/uploads/sites/8876/2024/09/leonet2= 4-victor.pdf >> -- >> J Pan, UVic CSc, ECS566, 250-472-5796 (NO VM), Pan@UVic.CA, = Web.UVic.CA/~pan >>=20 >> On Sat, Nov 8, 2025 at 11:12=E2=80=AFAM David Fern=C3=A1ndez = wrote: >>> "making the link layer more reliable is "the way"", indeed. In the = wireless data link design projects I have participated, it has always = been the requirement to have packet loss rate (PLR) at IP layer due to = physical layer errors uniformly distributed and not higher than 0.1%, = for TCP, while for wireless links carrying only VoIP, using RTP and = G.729 codec, up to 1% PLR is acceptable. >>>=20 >>> Then, I have seen that Starlink routinely exceeds 1% PLR, reaching = up to 6% or more even, but TCP works anyway, somehow. It may be that = CUBIC and BBR are more robust to higher packet loss rates due to error = than Reno. >>>=20 >>> "now physical, link and network layer have more info for >>> the transport layer to make the right decision", but do they? I = mean, how is the transport layer getting info nowadays about the path = characteristics in terms of bandwidth, latency and packet losses from = the layers below or info like the one you mentioned about Starlink = handovers? I still have not seen this happening, have you? >>>=20 >>> Regards, >>>=20 >>> David >>>=20 >>> On Sat, 8 Nov 2025, 22:30 J Pan, wrote: >>>> yes, end-to-end congestion control was an add-on to tcp flow and = error >>>> control, and at that time, packet loss was the only reliable >>>> congestion signal without router collaboration, and the legacy = stays. >>>> from the experience of tuning tcp on cellular networks, making the >>>> link layer more reliable is "the way", at the cost of more buffers = and >>>> latency. but now physical, link and network layer have more info = for >>>> the transport layer to make the right decision, e.g., starlink >>>> handovers at 12th, 27th, 42nd and 57th second of every minute with >>>> delay spike and losses >>>> -- >>>> J Pan, UVic CSc, ECS566, 250-472-5796 (NO VM), Pan@UVic.CA, = Web.UVic.CA/~pan >>>>=20 >>>> On Fri, Nov 7, 2025 at 2:51=E2=80=AFPM David Fern=C3=A1ndez via = Starlink >>>> wrote: >>>>> Thanks for sharing this Frank. >>>>>=20 >>>>> In slide 3, I think that another effect not to be missed is packet = losses >>>>> due to errors, which could be analogous to pipe leaks. Sometimes, = it >>>>> happens that they are not negligible, in some cases with wireless = links, >>>>> mainly, but it could happen too in DSL. I remember that I had a = DSL line in >>>>> which the router had the option to disable interleaving, warning = that you >>>>> could get more errors, bad for watching video, they were saying, = but >>>>> reduced latency (good for videogames). When packet losses due to = errors are >>>>> misinterpreted as congestion by the transport protocols, the = result is also >>>>> a band quality of experience. >>>>>=20 >>>>> Regards, >>>>>=20 >>>>> David >>>>>=20 >>>>> Date: Fri, 7 Nov 2025 11:53:44 +0100 >>>>>> From: Frantisek Borsik >>>>>> Subject: [Starlink] Re: [LibreQoS] Re: Keynote: QoE/QoS - = Bandwidth Is >>>>>> A Lie! at WISPAPALOOZA 2025 (October 16) >>>>>> To: Cake List , bloat >>>>>> , = codel@lists.bufferbloat.net, >>>>>> Jeremy Austin via Rpm , = libreqos >>>>>> , Dave Taht via = Starlink >>>>>> , l4s-discuss@ietf.org >>>>>> Message-ID: >>>>>> >>>>> uhiQPd3KOg@mail.gmail.com> >>>>>> Content-Type: text/plain; charset=3D"UTF-8" >>>>>>=20 >>>>>> Hello to all, >>>>>>=20 >>>>>> Recording of our QoE/QoS panel discussion is out! It was really = great and >>>>>> believe you will like it: >>>>>>=20 >>>>>> https://www.youtube.com/watch?v=3DT1VET0VYQ6c >>>>>>=20 >>>>>> We have touch bandwidth, L4S, Starlink and more. >>>>>>=20 >>>>>> Here are the slides with additional reading: >>>>>>=20 >>>>>> = https://docs.google.com/presentation/d/1ML0I3Av3DCtQDiP8Djr_YGH2r4-UDZP25V= Ek-xyJcZE/edit?slide=3Did.p#slide=3Did.p >>>>>>=20 >>>>>> We hope to continue this conversation into more practical, = demo-like >>>>>> environment of sort, that we can see at IETF Hackathon and used = to see in >>>>>> the early WISPA event days, with Animal Farm. >>>>>>=20 >>>>>>=20 >>>>>> All the best, >>>>>>=20 >>>>>> Frank >>>>>>=20 >>>>>> Frantisek (Frank) Borsik >>>>>>=20 >>>>>>=20 >>>>>> *In loving memory of Dave T=C3=A4ht: *1965-2025 >>>>>>=20 >>>>>> https://libreqos.io/2025/04/01/in-loving-memory-of-dave/ >>>>>>=20 >>>>>>=20 >>>>>> https://www.linkedin.com/in/frantisekborsik >>>>>>=20 >>>>>> Signal, Telegram, WhatsApp: +421919416714 >>>>>>=20 >>>>>> iMessage, mobile: +420775230885 >>>>>>=20 >>>>>> Skype: casioa5302ca >>>>>>=20 >>>>>> frantisek.borsik@gmail.com >>>>>>=20 >>>>>>=20 >>>>>> On Wed, Oct 1, 2025 at 11:32=E2=80=AFPM Frantisek Borsik < >>>>>> frantisek.borsik@gmail.com> >>>>>> wrote: >>>>>>=20 >>>>>>> Let's say that I love it, channeling my inner Dave Taht. But = there were a >>>>>>> couple of voices asking if I won't consider to change it a bit, = to be >>>>>> "less >>>>>>> hostile" to our "bandwidth is king!" friends...and I was trying, = but this >>>>>>> was really sticky and I'm happy that it stayed this way. >>>>>>>=20 >>>>>>>=20 >>>>>>> All the best, >>>>>>>=20 >>>>>>> Frank >>>>>>>=20 >>>>>>> Frantisek (Frank) Borsik >>>>>>>=20 >>>>>>>=20 >>>>>>> *In loving memory of Dave T=C3=A4ht: *1965-2025 >>>>>>>=20 >>>>>>> https://libreqos.io/2025/04/01/in-loving-memory-of-dave/ >>>>>>>=20 >>>>>>>=20 >>>>>>> https://www.linkedin.com/in/frantisekborsik >>>>>>>=20 >>>>>>> Signal, Telegram, WhatsApp: +421919416714 >>>>>>>=20 >>>>>>> iMessage, mobile: +420775230885 >>>>>>>=20 >>>>>>> Skype: casioa5302ca >>>>>>>=20 >>>>>>> frantisek.borsik@gmail.com >>>>>>>=20 >>>>>>>=20 >>>>>>> On Wed, Oct 1, 2025 at 9:25=E2=80=AFPM dan = wrote: >>>>>>>=20 >>>>>>>> I actually really like the title ;) >>>>>>>>=20 >>>>>>>> It's that most of the time people are told they need more = bandwidth to >>>>>>>> solve a problem, when they really need lower latency and = jitter. So the >>>>>>>> vast majority of the time 'more bandwidth' as a solution really = is a >>>>>> lie. >>>>>>>> On Tue, Sep 30, 2025 at 2:47=E2=80=AFPM Frantisek Borsik via = LibreQoS < >>>>>>>> libreqos@lists.bufferbloat.net> wrote: >>>>>>>>=20 >>>>>>>>> Thanks, Jim. Well, true that - but I wanted to do it either = way, >>>>>> because >>>>>>>>> of >>>>>>>>> our dear Dave and - as a conversation starter. >>>>>>>>> As @Jason Livingood said - = "Bandwidth is >>>>>>>>> dead. Long live latency." >>>>>>>>>=20 >>>>>>>>>=20 >>>>>> = https://pulse.internetsociety.org/blog/bandwidth-is-dead-long-live-latency= >>>>>>>>> I will do my best to get the audio/video right and to share it = with you >>>>>>>>> all. >>>>>>>>>=20 >>>>>>>>> PS: Sending you separate email. >>>>>>>>>=20 >>>>>>>>> All the best, >>>>>>>>>=20 >>>>>>>>> Frank >>>>>>>>>=20 >>>>>>>>> Frantisek (Frank) Borsik >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>> *In loving memory of Dave T=C3=A4ht: *1965-2025 >>>>>>>>>=20 >>>>>>>>> https://libreqos.io/2025/04/01/in-loving-memory-of-dave/ >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>> https://www.linkedin.com/in/frantisekborsik >>>>>>>>>=20 >>>>>>>>> Signal, Telegram, WhatsApp: +421919416714 >>>>>>>>>=20 >>>>>>>>> iMessage, mobile: +420775230885 >>>>>>>>>=20 >>>>>>>>> Skype: casioa5302ca >>>>>>>>>=20 >>>>>>>>> frantisek.borsik@gmail.com >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>> On Tue, Sep 30, 2025 at 10:25=E2=80=AFPM James Forster < >>>>>> jim@connectivitycap.com> >>>>>>>>> wrote: >>>>>>>>>=20 >>>>>>>>>> Wow, that=E2=80=99s fantastic, Frantisek! Great work making = this happen. >>>>>>>>>>=20 >>>>>>>>>> These sort of titles aren=E2=80=99t my favorite. I think I = understand the >>>>>>>>>> sentiment but find the issues more nuanced than that. :-) >>>>>>>>>>=20 >>>>>>>>>> If you can get clear audio, not much quality is needed for = panels and >>>>>>>>>> talking beads. Best would be a feed right into an = iPhone/android. >>>>>>>>>>=20 >>>>>>>>>> Jim >>>>>>>>> _______________________________________________ >>>>>>>>> LibreQoS mailing list -- libreqos@lists.bufferbloat.net >>>>>>>>> To unsubscribe send an email to = libreqos-leave@lists.bufferbloat.net >>>>>>>>>=20 >>>>>>=20 >>>>> _______________________________________________ >>>>> Starlink mailing list -- starlink@lists.bufferbloat.net >>>>> To unsubscribe send an email to = starlink-leave@lists.bufferbloat.net >> _______________________________________________ >> Starlink mailing list -- starlink@lists.bufferbloat.net >> To unsubscribe send an email to starlink-leave@lists.bufferbloat.net >=20 > --=20 > **************************************************************** > Dr. Ulrich Speidel >=20 > School of Computer Science >=20 > Room 303S.594 (City Campus) >=20 > The University of Auckland > u.speidel@auckland.ac.nz > http://www.cs.auckland.ac.nz/~ulrich/ > **************************************************************** >=20 >=20 >=20 > _______________________________________________ > Starlink mailing list -- starlink@lists.bufferbloat.net > To unsubscribe send an email to starlink-leave@lists.bufferbloat.net