- Rtp-congestion - alvestrand.no

Congestion control requirements - I-D format, -01a version
by Harald Alvestrand 05 Mar '12

05 Mar '12

These requirements are Randell's text, mostly, cropped into an I-D format and annotated a bit by me. I'll upload this to the I-D server tomorrow. Randell, is it OK to submit it with your name in the I-D name? Comments are welcome for 24 hours starting .... now .... Harald

5 13

Fwd: New Version Notification for draft-jesup-rtp-congestion-reqs-00.txt
by Harald Alvestrand 04 Mar '12

04 Mar '12

And ... it's out! Thanks for the quick feedback during the weekend! Harald -------- Original Message -------- Subject: New Version Notification for draft-jesup-rtp-congestion-reqs-00.txt Date: Sun, 04 Mar 2012 06:19:29 -0800 From: internet-drafts(a)ietf.org To: harald(a)alvestrand.no CC: randell-ietf(a)jesup.org A new version of I-D, draft-jesup-rtp-congestion-reqs-00.txt has been successfully submitted by Harald Alvestrand and posted to the IETF repository. Filename: draft-jesup-rtp-congestion-reqs Revision: 00 Title: Congestion Control Requirements For Real Time Media Creation date: 2012-03-04 WG ID: Individual Submission Number of pages: 7 Abstract: Congestion control is needed for all data transported across the Internet, in order to promote fair usage and prevent congestion collapse. The requirements for interactive, point-to-point real time multimedia, which needs by low-delay, semi-reliable data delivery, are different from the requirements for bulk transfer like FTP or bursty transfers like Web pages, and the TCP algorithms are not suitable for this traffic. This document attempts to describe a set of requirements that can be used to evaluate other congestion control mechanisms in order to figure out their fitness for this purpose. The IETF Secretariat

1 0

IETF 83 - RTP Congestion agenda (rtp-congestion@alvestrand.no)
by Harald Alvestrand (Google Docs) 01 Mar '12

01 Mar '12

I've shared an item with you: IETF 83 - RTP Congestion agenda https://docs.google.com/document/d/1vGWk3pu_w7NmSPHbcxZoUEgVb-4RquIkVF-iZ67… It's not an attachment -- it's stored online at Google Docs. To open this document, just click the link above. My notes for the RTP congestion control session in Paris. Please report your appropriate Google accounts so that I can share the document for commenting/editing with you.

1 0

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

Fwd: New Version Notification for draft-alvestrand-rmcat-remb-00.txt
by Harald Alvestrand 19 Jan '12

19 Jan '12

This is the broken-out version of the REMB message that was published in an appendix of the congestion-control draft I posted just before Taipei. After discussions inside Google, we decided that the timestamp header extension didn't offer enough value over the RFC 5450 send-time offset header extension, so we dropped it from the draft. Harald -------- Original Message -------- Subject: New Version Notification for draft-alvestrand-rmcat-remb-00.txt Date: Tue, 17 Jan 2012 04:54:00 -0800 From: internet-drafts(a)ietf.org To: harald(a)alvestrand.no CC: harald(a)alvestrand.no A new version of I-D, draft-alvestrand-rmcat-remb-00.txt has been successfully submitted by Harald Alvestrand and posted to the IETF repository. Filename: draft-alvestrand-rmcat-remb Revision: 00 Title: RTCP message for Receiver Estimated Maximum Bitrate Creation date: 2012-01-17 WG ID: Individual Submission Number of pages: 7 Abstract: This document proposes an RTCP message for use in experimentally- deployed congestion control algorithms for RTP-based media flows. The IETF Secretariat

2 3

suggesting a BoF in Paris
by Wesley Eddy 16 Jan '12

16 Jan '12

Hello folks, as you know, I'd circulated a charter to the IESG for "internal review", proposing to start a working group on this topic. Based on feedback and discussion with fellow ADs, I've decided to slow down a little, and would like to suggest that some of you work up a TSV BoF proposal for Paris. I would hope this could be a WG-forming BoF, and that in the time leading up to it, we could be formulating a few things into I-Ds to discuss, in order to test/demonstrate that the group is on the same page: 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?) Holding a WG-forming BoF would be a bit more conventional process, but potentially lead to greater success and seem less like we are creating a WG out of thin air. Another big advantage that was pointed out to me is that the BoF does help draw attention and perhaps bring more people and expertise to the group. BoF proposals are due 2/13 according to the cut-off dates list. Some procedures and guidelines are: http://www.ietf.org/iesg/bof-procedures.html -- Wes Eddy MTI Systems

1 0

proposing a WG on RTP congestion control
by Wesley Eddy 11 Jan '12

11 Jan '12

Hello all, following up on our discussion in Taipei, I have proposed a working group in the TSV area to work on RTP congestion control. This is scheduled to be discussed by the IESG on 1/5 in "internal review". The draft charter is at: http://www.ietf.org/iesg/evaluation/rmcat-charter.txt I would welcome participants in this list to comment on this, particularly if/when it moves to "external review", as I would expect the folks currently on this list to be some of the main participants in the proposed WG. I had previously had this reviewed by the TSV Directorate, and got fairly good responses and strong interest expressed from many of the directorate in participating as well. Happy New Year! -- Wes Eddy MTI Systems

6 8

Re: [R-C] [Iccrg] draft-alvestrand-rtcweb-congestion-01 - A Google Congestion Control Algorithm for Real-Time Communication on the World Wide Web
by Harald Alvestrand 14 Dec '11

14 Dec '11

[limiting to mailing list and original posters] Henrik, Stefan, do we have measurements we can share? On 12/05/2011 09:21 AM, Saverio Mascolo wrote: > hi all, > > the model could be weak....however before going into "theoretical > questions" can we look at measurements? > > > thanks > saverio > > On Mon, Nov 7, 2011 at 2:58 AM, Wesley Eddy <wes(a)mti-systems.com > <mailto:wes@mti-systems.com>> wrote: > > On 11/1/2011 10:34 AM, Lars Eggert wrote: > > This may be of interest to the RG: > http://wiki.tools.ietf.org/html/draft-alvestrand-rtcweb-congestion-01 > > > > Here are my comments on this (also copied to the authors and the > mailing list for RTCWEB congestion control): > > (1) > I think the model tries to correct for some effects later, but this > part only makes sense if all frames are the same size, and none of > the timestamps are subject to jitter being introduced by OS > scheduling, > MAC layer (e.g. wireless) issues, etc: > """ > We define the (relative) inter-arrival time, d(i) as > > d(i) = t(i)-t(i-1)-(T(i)-T(i-1)) > """ > > (2) > > This part doesn't quite make sense to me, but I think it's just in > the wording and not in the math: > """ > Since the time ts to send a frame of size L over a path with a > capacity of C is > > ts = L/C > > > we can model the inter-arrival time as > > L(i)-L(i-1) > d(i) = -------------- + w(i) = dL(i)/C+w(i) > C > """ > That's not a model of the inter-arrival time, it's a model of the > difference between the delta timestamps and delta reception times > based on difference in packet length. > > > (3) > In the definition of w(i), do you also intend to account for other > sources of delays in the end systems' software? Why do we think that > white noise is the right model? This seems like a big assumption, > unless there's actually data that shows it holds under a very wide > range of settings. > > (4) > It should probably be understood clearly that the i values are sample > numbers, but that the generation of samples comes from the behavior of > the plant, and they aren't taken at the filter/controller regularly. > This seems to be quite different than when the document says: > """ > In this document we make the assumption that the rate control > subsystem is executed periodically and that this period is constant. > """ > > (5) > The algorithm at the receiver side is clueless about packet losses, > and seems like it would see them only when the loss period ends (when > a packet survives) and then would see them as really long > inter-arrival > times rather than losses? (or did I miss something really important?) > > > (6) > The rules about 2% and 10% in the sender-side algorithm seem ... odd. > Unless the report interval is sufficiently long in relation to the > frame > rate, the percentages may not work well. These parameters have to be > balanced, or the algorithm will be fragile. > > (7) > Shouldn't the sender estimate of available bandwidth be able to go > lower > than the TFRC equation output if the delay has been increasing (though > packets are not yet being lost)? > > (8) > Startup is a big topic that isn't yet addressed. > > > > > -- > Wes Eddy > MTI Systems > > _______________________________________________ > Iccrg mailing list > Iccrg(a)cs.ucl.ac.uk <mailto:Iccrg@cs.ucl.ac.uk> > http://oakham.cs.ucl.ac.uk/mailman/listinfo/iccrg > > > > > -- > Prof. Saverio Mascolo > Dipartimento di Elettrotecnica ed Elettronica > Politecnico di Bari > Via Orabona 4, 70125 Bari Italy > Tel. +39 080 5963621 > Fax. +39 080 5963410 > email:mascolo@poliba.it <mailto:email%3Amascolo@poliba.it> > > http://c3lab.poliba.it > > > ================================= > This message may contain confidential and/or legally privileged > information. > If you are not the intended recipient of the message, please destroy it. > Any unauthorized dissemination, distribution, or copying of the > material in > this message, and any attachments to the message, is strictly forbidden.

2 1