From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mout.gmx.net (mout.gmx.net [212.227.17.21]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by lists.bufferbloat.net (Postfix) with ESMTPS id 84C7A3CB40 for ; Wed, 1 May 2024 17:27:38 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmx.de; s=s31663417; t=1714598850; x=1715203650; i=moeller0@gmx.de; bh=Ch0Hd7aUUgFKvkbjcvSBwjTLZkdswVzkBIZtYjEIPE0=; 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=Uz3OGANLqW6R9KpfWlImqdM3/nRSmTIfDxBPDAcA2VAP9tPfVlcRca8FWua3Kt9h yv/XTo0gaIjn7GKq5eAGANd4xItt69cNVo8wAjtQUGqPPElFpZ8Pxq+mQBF4iXcZq QUjfJ/BFhrsfo+5V7vB89sYWfaRt+lGxFKi+mu+qJza5FucWkO+XR0OY2HFm5wPcT MR6ZgEZaZ3lTkNAhBnuOPdRGTsi3cjG4c93sCGCnKmZjgULaX/ysAxadxmBrmqyyL bQqyeBjDBPDWBxo0p/wJg+yKUjOD7gDtyd/Z3cIbB8edSh1xpmu3/wSix5PAP4/90 AymnHzZ6ekOiUGT3zA== X-UI-Sender-Class: 724b4f7f-cbec-4199-ad4e-598c01a50d3a Received: from smtpclient.apple ([78.50.101.245]) by mail.gmx.net (mrgmx104 [212.227.17.168]) with ESMTPSA (Nemesis) id 1Mr9Bu-1sOdt9492s-00mbW5; Wed, 01 May 2024 23:27:30 +0200 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3774.500.171.1.1\)) From: Sebastian Moeller In-Reply-To: Date: Wed, 1 May 2024 23:27:18 +0200 Cc: David Lang , Dave Taht via Starlink , Colin_Higbie Content-Transfer-Encoding: quoted-printable Message-Id: <3FF32F52-4A93-496B-85FF-00020FA4A48B@gmx.de> References: <438B1BC4-D465-497A-B6BA-700E1D411036@ieee.org> <79C02ABB-B2A6-4B4D-98F4-6540D3F96EBB@ieee.org> <7E918B58-382A-4793-A144-13A7075CA56C@connectivitycap.com> <13rq2389-9012-p95n-s494-q3pp070s497n@ynat.uz> <6qop2p3o-351p-788q-q1q2-86sosnq3rn21@ynat.uz> To: Eugene Y Chang X-Mailer: Apple Mail (2.3774.500.171.1.1) X-Provags-ID: V03:K1:mYXGfVW47xPfKu2cmOhOhIMZQGlQ4G8AWwG6Vl0GK3d3s/EHGaS UVIMKI321dsnFE8vdn7uxBw6bdPy3fTGjqV6s3lBAmHEchc3y0fN6Ak9JUrBARGuOH+Xm+D 2xwcd0rAdW7ktzB/87C5cAyfyhvtr3LhwqCq6TLAenL6ZQwtNwGwhM2+pn3tmTwIpyI8ANT h+HvFwkSC4xzaTx3uLYvQ== X-Spam-Flag: NO UI-OutboundReport: notjunk:1;M01:P0:C7IKzPFrTEk=;Qz+Vg/ukW15AAw8ieCBJ87rfmzc lksBO9Z+mnpY+Qi0mRR9KGm0XvtblOXinAZxfcDlWo0F+T/0ab8O5I+UP5LGcIFYuBahJnqSV ZPAiWP5r0Qe7pPuA6A0g1wGmrhzMRj74ISe8d4m5J2qBbPprmm2lLeZJGKPU2vqar3qJqTMmR 1G7a5FiDzGAvZbHCHhBDArBDw1LgQCTjsXxBY7ponesRx98pC7lIg/ttkJawhn8BM1lSSHWp3 6U4S40ziof8ybiNxHAsS0CFUuVe8xnkmQytIDqkNnA6hBwMfaZPoUxg/LGgj9Z+tBrUJAjheS k8G91ZTaeiQUW5T9x/PSpfYSBII2UX5Jj6/MEk533QVC5Jaws291fbkoN0xsHC3VdAbQ6eBoV VjZ2XoJ+6LYwn19hdfLFS5OwCDh3NZjFM3ZXJFpxMo2BsVKyjvbHueefEBucURr3CVg87BYIn 2WJJPvcgLS4vMoRYw1lA7buA6GIEe3F6QUVsG3/q+uCRhredki73GNwhAow+2Ao7EvwCYBIKf /KFb2dVBUsTKp8aswQIh/dIboQpZKj+Ocyg9CfSzoxj5kS0lCG4U1WJHs0ZKAxXgob+7mHXh+ n4VoF8bOx/v2ab3q5kPsplrmDZtAqBg9VbIQHH7a6LbObmm7TctGjJ1KoUW92jZnONxizNBFZ RqMaI5Bab45W2az851R15gHRpl+7iV0hWfVureLaN9JD24Rdsmp87luq4KC8YacRhgsTeAUd8 84Rp3PR63ERWwXJ2//nx481kQn+LBdDOdzTJgPWB7LuAEYO/vt6InFA16JlaaT3MjwTv4bmh4 pTVw/Yh3MpvZqzak7coqpWcJ8/tHo15axJLX0ZhaFx++U= Subject: Re: [Starlink] =?utf-8?q?It=CA=BCs_the_Latency=2C_FCC?= X-BeenThere: starlink@lists.bufferbloat.net X-Mailman-Version: 2.1.20 Precedence: list List-Id: "Starlink has bufferbloat. Bad." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 May 2024 21:27:38 -0000 Hi Gene, > On 1. May 2024, at 23:12, Eugene Y Chang via Starlink = wrote: >=20 > Thank you David. >=20 > Now, shifting the focus a bit. Would a gamer experience some = improvement if they made a change in their router? [SM] It depends... mostly what the root cause of the gaming issues = are... fq_codel/cake can only fix issues related to bottleneck queuing = and isolation of different flows (so big transfers do not interfere with = low rate low latency flows). It will not magically make you a better = gamer or fix upstream network issues like bad peering/transit of your = ISP or overloaded game servers... > What needs to be done for a gamer to get tangible improvement? [SM] Keep static latency low ish, more importantly keep dynamic latency = variation/jitter low, and that essentially requires to isolate gaming = flows from the effect of concurrent bulk flows... Regards Sebastian >=20 > Gene > ---------------------------------------------- > Eugene Chang > IEEE Life Senior Member > IEEE Communications Society & Signal Processing Society, =20 > Hawaii Chapter Chair > IEEE Life Member Affinity Group Hawaii Chair > IEEE Entrepreneurship, Mentor > eugene.chang@ieee.org > m 781-799-0233 (in Honolulu) >=20 >=20 >=20 >> On May 1, 2024, at 9:18 AM, David Lang wrote: >>=20 >> On Wed, 1 May 2024, Eugene Y Chang wrote: >>=20 >>> Thanks David, >>>=20 >>>=20 >>>> On Apr 30, 2024, at 6:12 PM, David Lang wrote: >>>>=20 >>>> On Tue, 30 Apr 2024, Eugene Y Chang wrote: >>>>=20 >>>>> I=E2=80=99m not completely up to speed on the gory details. Please = humor me. I am pretty good on the technical marketing magic. >>>>>=20 >>>>> What is the minimum configuration of an ISP infrastructure where = we can show an A/B (before and after) test? >>>>> It can be a simplified scenario. The simpler, the better. We can = talk through the issues of how minimal is adequate. Of course and ISP = engineer will argue against simplicity. >>>>=20 >>>> I did not see a very big improvement on a 4/.5 dsl link, but there = was improvement. >>>=20 >>> Would a user feel the improvement with a 10 minute session: >>> shopping on Amazon? >>> using Salesforce? >>> working with a shared Google doc? >>=20 >> When it's only a single user, they are unlikely to notice any = difference. >>=20 >> But if you have one person on zoom, a second downloading something, = and a third on Amazon, it doesn't take much to notice a difference. >>=20 >>>> if you put openwrt on the customer router and configure cake with = the targeted bandwith at ~80% of line speed, you will usually see a = drastic improvement for just about any connection. >>>=20 >>> Are you saying some of the benefits can be realized with just = upgrading the subscriber=E2=80=99s router? This makes adoption harder = because the subscriber will lose the ISP=E2=80=99s support for any = connectivity issues. If a demo impresses the subscribers, the ISP still = needs to embrace this change; otherwise the ISP will wash their hands of = any subscriber problems. >>=20 >> Yes, just upgrading the subscriber's device with cake and configuring = it appropriately largely solves the problem (at the cost of sacraficing = bandwith because cake isn't working directly on the data flowing from = the ISP to the client, and so it has to work indirectly to get the = Internet server to slow down instead and that's a laggy, imperect = work-around. If the ISPs router does active queue management with = fq_codel, then you don't have to do this. >>=20 >> This is how we know this works, many of use have been doing this for = years (see the bufferbloat mailing list and it's archives_ >>=20 >>>> If you can put fq_codel on both ends of the link, you can usually = skip capping the bandwidth. >>>=20 >>> This is good if this means the benefits can be achieved with just = the CPE. This also limits the changes to subscribers that care. >>=20 >> fq_codel on the ISPs router for downlink, and on the subscribers = router for uplink. >>=20 >> putting cake on the router on the subscriber's end and tuning it = appropriately can achieve most of the benefit, but is more work to = configure. >>=20 >>>>=20 >>>> unfortunantly, it's not possible to just add this to the ISPs = existing hardware without having the source for the firmware there (and = if they have their queues in ASICs it's impossible to change them. >>>=20 >>> Is this just an alternative to having the change at the CPE? >>> Yes this is harder for routers in the network. >>=20 >> simple fq_codel on both ends of the bottleneck connection works quite = well without any configuration. Cake adds some additional fairness = capabilities and has a mode to work around the router on the other end = of the bottleneck not doing active queue management >>=20 >>>> If you can point at the dramatic decrease in latency, with no = bandwidth losses, that Starlink has achieved on existing hardware, that = may help. >>>=20 >>> This is good to know for the engineers. This adds confusion with the = subscribers. >>>=20 >>>>=20 >>>> There are a number of ISPs around the world that have implemented = active queue management and report very good results from doing so. >>>=20 >>> Can we get these ISPs to publically report how they have achieved = great latency reduction? >>> We can help them get credit for caring about their subscribers. It = would/could be a (short term) competitive advantage. >>> Of course their competitors will (might) adopt these changes and = eliminate the advantage, BUT the subscribers will retain glow of the = initial marketing for a much longer time. >>=20 >> several of them have done so, I think someone else posted a report = from one in this thread. >>=20 >>>> But showing that their existing hardware can do it when their = upstream vendor doesn't support it is going to be hard. >>>=20 >>> Is the upstream vendor a network provider or a computing center? >>> Getting good latency from the subscriber, through the access network = to the edge computing center and CDNs would be great. The CDNs would = harvest the benefits. The other computing configurations would have make = the change to be competitive. >>=20 >> I'm talking about the manufacturer of the routers that the ISPs = deploy at the last hop before getting to the subscriber, and the router = on the subscriber end of the link (although most of those are running = some variation of openWRT, so turning it on would not be significant = work for the manufacturer) >>=20 >>> We wouild have done our part at pushing the next round of adoption. >>=20 >> Many of us have been pushing this for well over a decade. Getting = Starlink's attention to address their bufferbloat issues is a major = success. >>=20 >> David Lang >>=20 >>> Gene >>>=20 >>>>=20 >>>> David Lang >>>>=20 >>>>>=20 >>>>> We will want to show the human visible impact and not debate good = or not so good measurements. If we get the business and community = subscribers on our side, we win. >>>>>=20 >>>>> Note: >>>>> Stage 1 is to show we have a pure software fix (that can work on = their hardware). The fix is =E2=80=9Cso dramatic=E2=80=9D that = subscribers can experience it without debating measurements. >>>>> Stage 2 discusses why the ISP should demand that their equipment = vendors add this software. (The software could already be available, but = the ISP doesn=E2=80=99t think it is worth the trouble to enable it.) = Nothing will happen unless we stay engaged. We need to keep the = subscribers engaged, too. >>>>>=20 >>>>> Should we have a conference call to discuss this? >>>>>=20 >>>>>=20 >>>>> Gene >>>>> ---------------------------------------------- >>>>> Eugene Chang >>>>> IEEE Life Senior Member >>>>>=20 >>>>>=20 >>>>>=20 >>>>>> On Apr 30, 2024, at 3:52 PM, Jim Forster = wrote: >>>>>>=20 >>>>>> Gene, David, >>>>>> =E2=80=98m >>>>>> Agreed that the technical problem is largely solved with cake & = codel. >>>>>>=20 >>>>>> Also that demos are good. How to do one for this problem> >>>>>>=20 >>>>>> =E2=80=94 Jim >>>>>>=20 >>>>>>> The bandwidth mantra has been used for so long that a technical = discussion cannot unseat the mantra. >>>>>>> Some technical parties use the mantra to sell more, faster, = ineffective service. Gullible customers accept that they would be happy = if they could afford even more speed. >>>>>>>=20 >>>>>>> Shouldn=E2=80=99t we create a demo to show the solution? >>>>>>> To show is more effective than to debate. It is impossible to = explain to some people. >>>>>>> Has anyone tried to create a demo (to unseat the bandwidth = mantra)? >>>>>>> Is an effective demo too complicated to create? >>>>>>> I=E2=80=99d be glad to participate in defining a demo and = publicity campaign. >>>>>>>=20 >>>>>>> Gene >>>>>>>=20 >>>>>>>=20 >>>>>>>> On Apr 30, 2024, at 2:36 PM, David Lang >> = wrote: >>>>>>>>=20 >>>>>>>> On Tue, 30 Apr 2024, Eugene Y Chang via Starlink wrote: >>>>>>>>=20 >>>>>>>>> I am always surprised how complicated these discussions = become. (Surprised mostly because I forgot the kind of issues this = community care about.) The discussion doesn=E2=80=99t shed light on the = following scenarios. >>>>>>>>>=20 >>>>>>>>> While watching stream content, activating controls needed to = switch content sometimes (often?) have long pauses. I attribute that to = buffer bloat and high latency. >>>>>>>>>=20 >>>>>>>>> With a happy household user watching streaming media, a second = user could have terrible shopping experience with Amazon. The = interactive response could be (is often) horrible. (Personally, I would = be doing email and working on a shared doc. The Amazon analogy probably = applies to more people.) >>>>>>>>>=20 >>>>>>>>> How can we deliver graceful performance to both persons in a = household? >>>>>>>>> Is seeking graceful performance too complicated to improve? >>>>>>>>> (I said =E2=80=9Cgraceful=E2=80=9D to allow technical = flexibility.) >>>>>>>>=20 >>>>>>>> it's largely a solved problem from a technical point of view. = fq_codel and cake solve this. >>>>>>>>=20 >>>>>>>> The solution is just not deployed widely, instead people argue = that more bandwidth is needed instead. >=20 >=20 > _______________________________________________ > Starlink mailing list > Starlink@lists.bufferbloat.net > https://lists.bufferbloat.net/listinfo/starlink