February 2012 - Rtp-congestion

Request for agenda time in Paris to discuss RTP congestion control proposals
by Harald Alvestrand 01 Mar '12

01 Mar '12

Hello, our transport AD, Wesley Eddy, suggested I should contact you about the issue of getting discussion time at the Paris IETF for the problem of congestion control for RTP-carried real-time media. We (a small group of people working on the rtp-congestion(a)alvestrand.no mailing list) have come up with a few drafts, mainly based on work done at Global IP Sound and Google: - draft-alvestrand-rtcweb-congetsion-01 - draft-alvestrand-rmcat-remb-00 These drafts suggest that one implement a delay-based, recipient-measured estimation algorithm for bandwidth estimation over RTP flows, and define a feedback message (analogous to TMMBR) for the recipient telling the sender how much data to send at any time. There has also been discussion on the rtcweb mailing list about the desirable properties of such congestion control, including how it should interact with congestion control in SCTP, which is suggested for a data channel transport in the RTCWEB effort. In an informal lunch meeting in Taipei, we discussed having a three-pronged approach: - Defining a set of best practices for what one should really not do with RTP flows (such as saying "when packet loss exceeds some percentage, reduce send rate significantly"); this seems like appropriate work for AVTCORE - Define a set of feedback messages that can be used to implement algorithms like the one mentioned above, or others, without standardizing the algorithm itself - Creating a working group for publishing the ideas and pushing a long term effort for standardizing a congestion control algorithm. A draft charter is here: http://www.ietf.org/iesg/evaluation/rmcat-charter.txt Due to bad planning, we did not get a BOF request in for the Paris meeting, but would really like to have a place to have this discussion in that timeframe; also, the ICCRG should have quite a few people whose input we would definitely want into this discussion. Can you consider whether or not you can offer us some time on the ICCRG agenda for this? Harald Alvestrand

2 2

A plan of attack for Paris - background
by Harald Alvestrand 28 Feb '12

28 Feb '12

This discussion has been far too quiet for the last month or two while everyone's been busy with JSEP and implementations.... to recap the discussion in Taipei, the conclusions I noted for actions to be taken were: - define the circuit-breaker conditions "stop when you see this" (AVTCORE) - define the feedback messages for receiver bandwidth estimate and timestamps (AVTEXT) - create a working group for publishing the ideas and pushing a long term algorithm standard (TSV area) We had a charter circulated some time ago, but the IESG considered this and decided they would prefer to see a BOF first; we promptly followed up by missing the BOF deadline for Paris. What Wesley suggested earlier we discuss before the BOF, and prepare before the meeting, was: 1 - problem statement(s) (there are pieces of a few emails that could be a good start to this) 2 - requirements (again, there are a few emails that could be a starting point for this) 3 - proposed algorithms and other mechanisms (there is at least one I-D that fits this, more would be good, especially as there are multiple facets of the problem to be addressed) 4 - thoughts on how to test and evaluate algorithms (there seem to be less concrete thoughts on this so far?) So much for the recap. Query: Do we all agree that this is where we are?

2 2

BOF in Paris - who's leading?
by Harald Alvestrand 17 Feb '12

17 Feb '12

I think we all agreed in December that we need a BOF in Paris for this work. But I've lost track of where we are on that in all the RTCWEB-interim and other stuff happening. Who's got the token? How can I help? Harald

2 1