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