[Starlink] impressed with my starlink today

[Starlink] impressed with my starlink today

[Dave Taht]

[-- Attachment #1.1: Type: text/plain, Size: 878 bytes --]

I just did a bunch of videoconferences all morning without many glitches.
(2 hours, only one download glitch, not recording so I do not know how good
the up was) Admittedly, I was
using galene.org rather than zoom, but I did do a couple up and downloads
while talking and they seemed to work pretty well.

I ran a few tests afterwards, to observe my overall bandwidth up was way
up, and tcp congestion controls pretty smoothly adapting to physical
changes in RTT and bandwidth for a change. I sat there and admired the
T+120 smoothnesss in this transition, in particular.

Anyone else seeing progress in long term behaviors? I think in part it was
just galene doing better, or perhaps it was because my baseline bandwidth
stayed above galene´s base.


-- 
Oct 30: https://netdevconf.info/0x17/news/the-maestro-and-the-music-bof.html
Dave Täht CSO, LibreQos

[-- Attachment #1.2: Type: text/html, Size: 1282 bytes --]

[-- Attachment #2: an_even_betteer.png --]
[-- Type: image/png, Size: 97382 bytes --]

[-- Attachment #3: respondingsmoothly.png --]
[-- Type: image/png, Size: 94369 bytes --]

[-- Attachment #4: t120transition.png --]
[-- Type: image/png, Size: 108741 bytes --]

Re: [Starlink] impressed with my starlink today

[Livingood, Jason]

[-- Attachment #1: Type: text/plain, Size: 1882 bytes --]

IMO I don’t think you can judge that by using Galene – you need to use the large market-share platforms. Also, given the density issues facing LEO services, a single sample can’t be taken as particularly representative – you’d need more users across a broader range of density/terrain types.

JL

From: Starlink <starlink-bounces@lists.bufferbloat.net> on behalf of Dave Taht via Starlink <starlink@lists.bufferbloat.net>
Reply-To: Dave Taht <dave.taht@gmail.com>
Date: Friday, September 15, 2023 at 18:45
To: Dave Taht via Starlink <starlink@lists.bufferbloat.net>
Subject: [Starlink] impressed with my starlink today

I just did a bunch of videoconferences all morning without many glitches. (2 hours, only one download glitch, not recording so I do not know how good the up was) Admittedly, I was
using galene.org<https://urldefense.com/v3/__http:/galene.org__;!!CQl3mcHX2A!AwJw0pjxf076FkQM4rXF8f3rISzxQCURREhzLa7IZFgxvmgtQP16gVm8yjle-XsLqPa92ijxNko7aWsEdoQbf9jW__cpI23ESQ$> rather than zoom, but I did do a couple up and downloads while talking and they seemed to work pretty well.

I ran a few tests afterwards, to observe my overall bandwidth up was way up, and tcp congestion controls pretty smoothly adapting to physical changes in RTT and bandwidth for a change. I sat there and admired the T+120 smoothnesss in this transition, in particular.

Anyone else seeing progress in long term behaviors? I think in part it was just galene doing better, or perhaps it was because my baseline bandwidth stayed above galene´s base.


--
Oct 30: https://netdevconf.info/0x17/news/the-maestro-and-the-music-bof.html<https://urldefense.com/v3/__https:/netdevconf.info/0x17/news/the-maestro-and-the-music-bof.html__;!!CQl3mcHX2A!AwJw0pjxf076FkQM4rXF8f3rISzxQCURREhzLa7IZFgxvmgtQP16gVm8yjle-XsLqPa92ijxNko7aWsEdoQbf9jW__eDsNR67A$>
Dave Täht CSO, LibreQos

[-- Attachment #2: Type: text/html, Size: 4667 bytes --]

Re: [Starlink] impressed with my starlink today

[Dave Taht]

[-- Attachment #1: Type: text/plain, Size: 3958 bytes --]

On Mon, Sep 18, 2023 at 6:19 AM Livingood, Jason <
Jason_Livingood@comcast.com> wrote:

> IMO I don’t think you can judge that by using Galene – you need to use the
> large market-share platforms.
>

Only a few years ago, there were no large market share platforms. Given
that multiple corps I work with now will not use zoom at all, others will
only use msteams, others still fleeing from google,
and in my world, p2p (via skype, telegram, matrix, signal), and group
(matrix is trialing a stacked SFU based on the pion library), dominates in
general I do not buy the "must test the mass market surveillance capitalism
videoconferencing tool", concept...  rather... one that takes 10 minutes to
setup, control the source code to, and servers it runs on, as well as the
statistics it collects.

What is research today will be common one day, and I for one would welcome
the end of metered, centralized, and surveilled videoconferencing. Stuff
built around the pion library is currently best in class for what can be
achieved over webrtc, in terms of latency. Zoom went the other way,
preserving video quality, at the expense of interactivity.


> Also, given the density issues facing LEO services, a single sample can’t
> be taken as particularly representative – you’d need more users across a
> broader range of density/terrain types.
>
>
I 110% agree, which is why I asked here, which has multiple researchers
engaged in wider scale and long term studies.  2? (3?) weeks back I was
seeing, about once every 5 minutes, a jump to a 70ms baseline latency,
which I do not see in the past week´s worth of data. I would also typically
see worse behavior on a downshift of available bandwidth. I can (and do)
pick these out via a CDF plot over time but the data is noisy as heck.

Given that I have no particularly good tools for measuring a zoom
conference, I am kind of leveraging making a recording of a podcast, and
counting glitches with a stopwatch.

How far we have come s-s-s-since m-m-m-max headroom!

https://www.youtube.com/watch?v=cYdpOjletnc

How far we have to go!


>
>
> JL
>
>
>
> *From: *Starlink <starlink-bounces@lists.bufferbloat.net> on behalf of
> Dave Taht via Starlink <starlink@lists.bufferbloat.net>
> *Reply-To: *Dave Taht <dave.taht@gmail.com>
> *Date: *Friday, September 15, 2023 at 18:45
> *To: *Dave Taht via Starlink <starlink@lists.bufferbloat.net>
> *Subject: *[Starlink] impressed with my starlink today
>
>
>
> I just did a bunch of videoconferences all morning without many glitches.
> (2 hours, only one download glitch, not recording so I do not know how good
> the up was) Admittedly, I was
>
> using galene.org
> <https://urldefense.com/v3/__http:/galene.org__;!!CQl3mcHX2A!AwJw0pjxf076FkQM4rXF8f3rISzxQCURREhzLa7IZFgxvmgtQP16gVm8yjle-XsLqPa92ijxNko7aWsEdoQbf9jW__cpI23ESQ$>
> rather than zoom, but I did do a couple up and downloads while talking and
> they seemed to work pretty well.
>
>
>
> I ran a few tests afterwards, to observe my overall bandwidth up was way
> up, and tcp congestion controls pretty smoothly adapting to physical
> changes in RTT and bandwidth for a change. I sat there and admired the
> T+120 smoothnesss in this transition, in particular.
>
>
> Anyone else seeing progress in long term behaviors? I think in part it was
> just galene doing better, or perhaps it was because my baseline bandwidth
> stayed above galene´s base.
>
>
>
>
>
> --
>
> Oct 30:
> https://netdevconf.info/0x17/news/the-maestro-and-the-music-bof.html
> <https://urldefense.com/v3/__https:/netdevconf.info/0x17/news/the-maestro-and-the-music-bof.html__;!!CQl3mcHX2A!AwJw0pjxf076FkQM4rXF8f3rISzxQCURREhzLa7IZFgxvmgtQP16gVm8yjle-XsLqPa92ijxNko7aWsEdoQbf9jW__eDsNR67A$>
>
> Dave Täht CSO, LibreQos
>


-- 
Oct 30: https://netdevconf.info/0x17/news/the-maestro-and-the-music-bof.html
Dave Täht CSO, LibreQos

[-- Attachment #2: Type: text/html, Size: 7234 bytes --]

Re: [Starlink] impressed with my starlink today

[Juliusz Chroboczek]

> Admittedly, I was using galene.org

Full credit where credit is due: the congestion controller in the
downstream direction lives in the browser, so full credit to the folks
behind libwebrtc.  As to the upstream direction, we're using our homebrew
code, which is not very good.

We're currently using receiver-driven congestion control, which is
deprecated in WebRTC.  The plan is to switch to sender-driven congestion
control at some point (I'm no big fan, but that's what everyone is
implementing, and we better be compatible with the rest of the universe).
That will mean using Pion's congestion controller in the downstream
direction, and libwebrtc's one in the upstream.  And I'm told Pion's
congestion controller is not very good.

(I could in principle use receiver-driven for the downstream and
sender-driven for the upstream, thus using libwebrtc's excellent
controllers in both directions, but it really feels like a hack.  I'd
much rather not negociate receiver-driven at all.)

-- Juliusz

Re: [Starlink] impressed with my starlink today

[Michael Richardson]

[-- Attachment #1: Type: text/plain, Size: 1204 bytes --]


Juliusz Chroboczek via Starlink <starlink@lists.bufferbloat.net> wrote:
    > We're currently using receiver-driven congestion control, which is
    > deprecated in WebRTC.  The plan is to switch to sender-driven congestion
    > control at some point (I'm no big fan, but that's what everyone is
    > implementing, and we better be compatible with the rest of the universe).

...

    > (I could in principle use receiver-driven for the downstream and
    > sender-driven for the upstream, thus using libwebrtc's excellent
    > controllers in both directions, but it really feels like a hack.  I'd
    > much rather not negociate receiver-driven at all.)

If I understand correctly, galene would support p2p media streams?
The web page seems to focus on lecture style.

It seems to me that if you have multiple outgoing streams, that if there are
problems with any of them, a sender-driven system allows for better use of
what is typically a smaller uplink.

--
]               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    [


[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 511 bytes --]

Re: [Starlink] impressed with my starlink today

[Frantisek Borsik]

[-- Attachment #1: Type: text/plain, Size: 3097 bytes --]

The problem with Galene and in general, with almost everything open-source
based per se, is its ANTI user GUI, setup process, documentation…

Unnecessary barriers to entry for regular people we want to help, right?
But instead of doing everything in our powers to tear these barriers down,
most of the open source projects IMHO is even taking a big pride in this
clunkiness, terrible geeky way of doing stuff, feeling like an “inner
circle” of those that are “in the know.”

“Only 10 minutes to setup” - means no general public will ever use it en
masses!

It’s shooting our own foot.

If we really want to actually help the people, we should do anything
possible in order to improve UX/UI, to give the world (general public) know
what we (insert anything open source, like Galene as an alternative to Zoom
and the like) actually do and why it’s not only an alternative but why it’s
actually better.

It means (in no particular order) better UX/UI, sharing information on
social media, easy setup and onboarding, better and more accessible (almost
to my grandmother) documentation -
going above and beyond.

Galene should be great - I’m willing to help to make it usable as easily as
fucking Zoom. But are Galene guys really willing to make that leap?


All the best,

Frank
Frantisek (Frank) Borsik

https://www.linkedin.com/in/frantisekborsik
Signal, Telegram, WhatsApp: +421919416714
iMessage, mobile: +420775230885
Skype: casioa5302ca
frantisek.borsik@gmail.com


On Mon, 18 Sep 2023 at 8:40 PM, Michael Richardson via Starlink <
starlink@lists.bufferbloat.net> wrote:

>
> Juliusz Chroboczek via Starlink <starlink@lists.bufferbloat.net> wrote:
>     > We're currently using receiver-driven congestion control, which is
>     > deprecated in WebRTC.  The plan is to switch to sender-driven
> congestion
>     > control at some point (I'm no big fan, but that's what everyone is
>     > implementing, and we better be compatible with the rest of the
> universe).
>
> ...
>
>     > (I could in principle use receiver-driven for the downstream and
>     > sender-driven for the upstream, thus using libwebrtc's excellent
>     > controllers in both directions, but it really feels like a hack.  I'd
>     > much rather not negociate receiver-driven at all.)
>
> If I understand correctly, galene would support p2p media streams?
> The web page seems to focus on lecture style.
>
> It seems to me that if you have multiple outgoing streams, that if there
> are
> problems with any of them, a sender-driven system allows for better use of
> what is typically a smaller uplink.
>
> --
> ]               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
> https://lists.bufferbloat.net/listinfo/starlink
>

[-- Attachment #2: Type: text/html, Size: 4528 bytes --]

Re: [Starlink] impressed with my starlink today

[Juliusz Chroboczek]

> Galene should be great - I’m willing to help to make it usable as easily as
> fucking Zoom.  But are Galene guys really willing to make that leap? 

What leap?  If you're suggesting I should stop teaching and participate in
a startup, then no, I'm not willing to do that.

If you're suggesting that you want to redo the UI from scratch, the I'd be
thrilled.  I'm completely incompetent at UI, and I'd love to be able to
concentrate on the networking side.

-- Juliusz

Re: [Starlink] impressed with my starlink today

[Frantisek Borsik]

[-- Attachment #1: Type: text/plain, Size: 871 bytes --]

The later.

Will get back to you in the separate email.


All the best,

Frank
Frantisek (Frank) Borsik

https://www.linkedin.com/in/frantisekborsik
Signal, Telegram, WhatsApp: +421919416714
iMessage, mobile: +420775230885
Skype: casioa5302ca
frantisek.borsik@gmail.com


On Mon, 18 Sep 2023 at 9:57 PM, Juliusz Chroboczek <jch@irif.fr> wrote:

> > Galene should be great - I’m willing to help to make it usable as easily
> as
> > fucking Zoom.  But are Galene guys really willing to make that leap?
>
> What leap?  If you're suggesting I should stop teaching and participate in
> a startup, then no, I'm not willing to do that.
>
> If you're suggesting that you want to redo the UI from scratch, the I'd be
> thrilled.  I'm completely incompetent at UI, and I'd love to be able to
> concentrate on the networking side.
>
> -- Juliusz
>

[-- Attachment #2: Type: text/html, Size: 1592 bytes --]

Re: [Starlink] impressed with my starlink today

[Juliusz Chroboczek]

> If I understand correctly, galene would support p2p media streams?

No, Galene only does client-server media.  Before I wrote Galene,
I experimented with peer-to-peer WebRTC, and it worked beautifully in
small groups, but collapsed somewhere around 4 to 5 participants.

The problem is not the amount of data (Galene uses at most 700kbit per
flow in the default configuration), but the fact that current WebRTC
implementations require you to encode the video separately for each peer.

> It seems to me that if you have multiple outgoing streams, that if there are
> problems with any of them, a sender-driven system allows for better use of
> what is typically a smaller uplink.

In the sender-driven approach, the receiver gives very detailed feedback
to the sender (lost packets, packet arrival timestamps), who runs the
congestion control algorithm.  In the receiver-driven approach, the
receiver runs the congestion control algorithm, and sends a single integer
to the sender, the maximum allowed rate.  There's nothing that prevents
the sender from reducing the rate below what the receiver requested even
in the receiver-driven algorithm.

Does one of the approaches give more flexibility to the sender?  I'm
frankly not convinced, but perhaps I'll change my mind once I've
implemented it.

-- Juliusz

Re: [Starlink] impressed with my starlink today

[David Lang]

[-- Attachment #1: Type: text/plain, Size: 1252 bytes --]

I work remotely and routinely use Starlink for video calls while doing other 
uploads/downloads. As do several others at my company. Some of us are in rural 
areas, I'm in Southern California, but in a place that doesn't have fiber 
available (predicted to arrive at my address sometime next year)

Starlink occasionally has hiccups, but not significantly more so than other 
people's network connections.

David Lang

On Fri, 15 Sep 2023, Dave Taht via Starlink wrote:

> I just did a bunch of videoconferences all morning without many glitches.
> (2 hours, only one download glitch, not recording so I do not know how good
> the up was) Admittedly, I was
> using galene.org rather than zoom, but I did do a couple up and downloads
> while talking and they seemed to work pretty well.
>
> I ran a few tests afterwards, to observe my overall bandwidth up was way
> up, and tcp congestion controls pretty smoothly adapting to physical
> changes in RTT and bandwidth for a change. I sat there and admired the
> T+120 smoothnesss in this transition, in particular.
>
> Anyone else seeing progress in long term behaviors? I think in part it was
> just galene doing better, or perhaps it was because my baseline bandwidth
> stayed above galene´s base.
>
>
>