Just to summarize what I currently understand about LEDBAT as compared to the scenario that RTCWEB envisions..... - RTCWEB assumes a set of media streams, possibly supplemented by a set of data streams carrying data with real-time requirements. LEDBAT assumes that there is some amount of data that needs transferring, and that it's appropriate to delay data if congestion occurs. - RTCWEB wants to make sure delay is low as long as it's not fighting with TCP, and wants its "fair share" when competing with TCP. LEDBAT wants to back off when encountering TCP, and uses low delay as a signal of "no competition is occuring"; it doesn't care about the specific delay. - RTCWEB's RTP streams consists of unidirectional streams with (currently) fairly infrequent feedback messages. LEDBAT assumes an acknowledgement stream with nearly the same packet intervals as the forward stream. My conclusion: When discussing behaviour of specific models, we can learn from LEDBAT's experiences and the scenarios it was tested in, but the design goals of LEDBAT do not resemble the design goals for congestion control in the RTCWEB scenario, and we should not expect specific properties of the implementation to fit. If I'm totally off base on any of the above, please holler..... Harald