[Bloat] Easiest/most effective way to test software against adverse networks?

[Bloat] Easiest/most effective way to test software against adverse networks?

[Sean DuBois]

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

I am working on improving Pion's Google Congestion Control algorithm
https://github.com/pion/interceptor/tree/master/pkg/gcc. As I start to use
it in more real world networks I find flaws.

How are people testing software today? Is 'Traffic Control' the best option?

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

Re: [Bloat] Easiest/most effective way to test software against adverse networks?

[Dave Taht]

GREAT to hear from you sean! (I added you as "accept" to the bloat
list, but did not subscribe you. You can subscribe if you want to stay
on) I am delighted to see all the places pion is popping up now, most
recently I hear it is in matrix´s stacked SFU implementation? That is
a very interesting case of multiple control loops, that makes my head
hurt.

We have very few tests for videoconferencing performance in the world
today. I have no idea how good any of the ones I have heard of, are.
Have you looked over what the FCC uses? Samknows? Cloudflare? Do you
have one or more you like?

This paper that just went by was quite pleasing:
https://tma.ifip.org/2023/wp-content/uploads/sites/12/2023/06/tma2023-final37.pdf

But I do not know enough about their method.

I have been hoping, with the public testbeds the libreqos project
runs, and/or with the co-operation of one or more of the ISPs that use
it, to somehow be able to accurately test & simulate the behaviors of
videoconferencing traffic, but someone with funding, interest and
time, has not shown up yet. (we know it is superlative, as most calls
about videoconferencing problems just vanish on deployment of
libreqos)

We are able now (via ebpf) to gather and analyze all sorts of stats at
scale, and substitute different qdiscs like fifo or pie, than the ones
(fq_codel, cake) we use in production. We do not have a good wifi or
lte emulation however.

So you are welcome to attempt to leverage our testbed for your
analyses or setup your own. The source code for libreqos is on github.
   The main server has a demo here: https://payne.taht.net - click
"bandwidth test", drill down - but is only testing greedy and
voip-like traffic in the test suite, presently.

 I am passionately interested in further understanding how well google
congestion control is working in the field today, as well as in other
videoconferencing methods. Please feel free to also drop by in the
chat:

https://matrix.to/#/#libreqos:matrix.org

On Sat, Aug 5, 2023 at 10:37 AM Sean DuBois via Bloat
<bloat@lists.bufferbloat.net> wrote:
>
> I am working on improving Pion's Google Congestion Control algorithm https://github.com/pion/interceptor/tree/master/pkg/gcc. As I start to use it in more real world networks I find flaws.
>
> How are people testing software today? Is 'Traffic Control' the best option?
> _______________________________________________
> Bloat mailing list
> Bloat@lists.bufferbloat.net
> https://lists.bufferbloat.net/listinfo/bloat



--
Podcast: https://www.youtube.com/watch?v=bxmoBr4cBKg
Dave Täht CSO, LibreQos

Re: [Bloat] Easiest/most effective way to test software against adverse networks?

[Stephen Hemminger]

On Sat, 5 Aug 2023 13:35:40 -0400
Sean DuBois via Bloat <bloat@lists.bufferbloat.net> wrote:

> I am working on improving Pion's Google Congestion Control algorithm
> https://github.com/pion/interceptor/tree/master/pkg/gcc. As I start to use
> it in more real world networks I find flaws.
> 
> How are people testing software today? Is 'Traffic Control' the best option?


Netem works but there are artifacts from the emulation.

But my view on congestion control is that this sounds like Google
doing NIH reinvention. Happens when you hire a lot of smart people

"Those who don't know history are doomed to repeat it"

Re: [Bloat] Easiest/most effective way to test software against adverse networks?

[Dave Taht]

Dear Stephen:

Google gcc is a hybrid delay/loss webrtc protocol that is part of most
browsers today, and quite a few SFUs. It has been around since 2012 or
so. An RFC for it was started, here:
https://datatracker.ietf.org/doc/html/draft-ietf-rmcat-gcc-02

But as it grew to dominate the market, the source code(s) for it
became the best reference, and the effort to standardize, abandoned.

It is, IMHO, more an IH, than NIH.

That said, an awful lot of videoconferencing takes place over more
proprietary implementations of congestion control today, and only the
authors know how it works.


On Sat, Aug 5, 2023 at 12:30 PM Stephen Hemminger via Bloat
<bloat@lists.bufferbloat.net> wrote:
>
> On Sat, 5 Aug 2023 13:35:40 -0400
> Sean DuBois via Bloat <bloat@lists.bufferbloat.net> wrote:
>
> > I am working on improving Pion's Google Congestion Control algorithm
> > https://github.com/pion/interceptor/tree/master/pkg/gcc. As I start to use
> > it in more real world networks I find flaws.
> >
> > How are people testing software today? Is 'Traffic Control' the best option?
>
>
> Netem works but there are artifacts from the emulation.
>
> But my view on congestion control is that this sounds like Google
> doing NIH reinvention. Happens when you hire a lot of smart people
>
> "Those who don't know history are doomed to repeat it"
> _______________________________________________
> Bloat mailing list
> Bloat@lists.bufferbloat.net
> https://lists.bufferbloat.net/listinfo/bloat



-- 
Podcast: https://www.youtube.com/watch?v=bxmoBr4cBKg
Dave Täht CSO, LibreQos