From: David Lang <david@lang.hm>
To: "David P. Reed" <dpreed@deepplum.com>
Cc: Dave Taht <dave.taht@gmail.com>,
Make-Wifi-fast <make-wifi-fast@lists.bufferbloat.net>,
Anthony Minessale II <anthm@freeswitch.org>,
Cake List <cake@lists.bufferbloat.net>,
Ken Rice <krice@freeswitch.org>,
cerowrt-devel <cerowrt-devel@lists.bufferbloat.net>,
bloat <bloat@lists.bufferbloat.net>
Subject: Re: [Cerowrt-devel] [Cake] mo bettah open source multi-party videoconferncing in an age of bloated uplinks?
Date: Fri, 27 Mar 2020 12:12:27 -0700 (PDT) [thread overview]
Message-ID: <nycvar.QRO.7.76.6.2003271209340.24223@qynat-yncgbc> (raw)
In-Reply-To: <1585335604.839628636@apps.rackspace.com>
On Fri, 27 Mar 2020, David P. Reed wrote:
>
> Congestion control for real-time video is quite different than for streaming. Streaming really is dealt with by a big enough (multi-second) buffering, and can in principle work great over TCP (if debloated).
>
> UDP congestion control MUST be end-to-end and done in the application layer, which is usually outside the OS kernel. This makes it tricky, because you end up with latency variation due to eh OS's process scheduler that is on the order of magnitude of the real-time requirements for air-to-air or light-to-light response (meaning the physical transition from sound or picture to and from the transducer).
at some level this is correct, but if the link is clogged with TCP packets, it
doesn't matter what your UDP application attempts to do, so installing cake to
keep individual links from being too congested will allow your UDP application
have a chance to operate.
David Lang
next prev parent reply other threads:[~2020-03-27 19:12 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-03-27 17:27 [Cerowrt-devel] " Dave Taht
2020-03-27 19:00 ` [Cerowrt-devel] [Cake] " David P. Reed
2020-03-27 19:12 ` David Lang [this message]
2020-03-27 19:36 ` Dave Taht
2020-03-27 20:32 ` Dave Taht
2020-03-28 19:58 ` Toke Høiland-Jørgensen
2020-03-28 23:15 ` David P. Reed
2020-03-30 10:57 ` Toke Høiland-Jørgensen
2020-03-28 6:53 ` [Cerowrt-devel] " Anthony Minessale II
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: https://lists.bufferbloat.net/postorius/lists/cerowrt-devel.lists.bufferbloat.net/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=nycvar.QRO.7.76.6.2003271209340.24223@qynat-yncgbc \
--to=david@lang.hm \
--cc=anthm@freeswitch.org \
--cc=bloat@lists.bufferbloat.net \
--cc=cake@lists.bufferbloat.net \
--cc=cerowrt-devel@lists.bufferbloat.net \
--cc=dave.taht@gmail.com \
--cc=dpreed@deepplum.com \
--cc=krice@freeswitch.org \
--cc=make-wifi-fast@lists.bufferbloat.net \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox