On Tue, 30 Apr 2024, Eugene Y Chang wrote:
I’m not completely up to speed on the gory details. Please humor me. I am
pretty good on the technical marketing magic.
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.
I did not see a very big improvement on a 4/.5 dsl link, but there was
improvement.
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.
If you can put fq_codel on both ends of the link, you can usually skip capping
the bandwidth.
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.
If you can point at the dramatic decrease in latency, with no bandwidth losses,
that Starlink has achieved on existing hardware, that may help.
There are a number of ISPs around the world that have implemented active queue
management and report very good results from doing so.
But showing that their existing hardware can do it when their upstream vendor
doesn't support it is going to be hard.
David Lang
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.
Note:
Stage 1 is to show we have a pure software fix (that can work on their
hardware). The fix is “so dramatic” 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’t
think it is worth the trouble to enable it.) Nothing will happen unless we stay
engaged. We need to keep the subscribers engaged, too.
Should we have a conference call to discuss this?
Gene
----------------------------------------------
Eugene Chang
IEEE Life Senior Member
On Apr 30, 2024, at 3:52 PM, Jim Forster <j...@connectivitycap.com> wrote:
Gene, David,
‘m
Agreed that the technical problem is largely solved with cake & codel.
Also that demos are good. How to do one for this problem>
— Jim
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.
Shouldn’t 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’d be glad to participate in defining a demo and publicity campaign.
Gene
On Apr 30, 2024, at 2:36 PM, David Lang <da...@lang.hm <mailto:da...@lang.hm>>
wrote:
On Tue, 30 Apr 2024, Eugene Y Chang via Starlink wrote:
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’t shed light on the following scenarios.
While watching stream content, activating controls needed to switch content
sometimes (often?) have long pauses. I attribute that to buffer bloat and high
latency.
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.)
How can we deliver graceful performance to both persons in a household?
Is seeking graceful performance too complicated to improve?
(I said “graceful” to allow technical flexibility.)
it's largely a solved problem from a technical point of view. fq_codel and cake
solve this.
The solution is just not deployed widely, instead people argue that more
bandwidth is needed instead.
_______________________________________________
Starlink mailing list
Starlink@lists.bufferbloat.net
https://lists.bufferbloat.net/listinfo/starlink
