[R-C] [ledbat] LEDBAT vs RTCWeb
Harald Alvestrand
harald at alvestrand.no
Tue Apr 24 13:23:19 CEST 2012
My take on the 1000-foot level:
- The RTPCongestion effort will result in an algorithm that works in 2
modes:
- "Queueing delay is comfortably low, and we're working to keep it
that way"
- "Queueing delay is uncomfortably high, and we're trying to get our
fair share"
- TCP is the main contender for bandwidth *now*
- LEDBAT is a possible contender for bandwidth in the near future
- TCP and LEDBAT will (I hope) be detectable as different patterns of
"conflict"
- An important output of RTPCongestion is *instrumentation* - knowing
which mode we're in, and who we're contending with
- Once we get large scale RTCWEB deployment, and with it large scale
deployment of RTPCongestion algorithms, in applications that read this
instrumentation and harvest the results, my hope (perhaps unrealistic)
is that we'll be in a better position to make *informed* decisions about
where the problems are, and what the places of maximum bang-for-the-buck
are to "make things better".
Very short summary of the above:
Let's put instrumentation in as a primary goal.
Harald
More information about the Rtp-congestion
mailing list