[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