[R-C] LEDBAT vs RTCWeb

[Harald Alvestrand]

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