Hi Wesley, The charter looks comprehensive. Apologies for top posting. need clarification/comment: - The congestion control for uni-directional media may be different from bi-directional or conversational media because of relaxed constraints: timing, buffering and available repair mechanisms, rate-switching etc. Should the charter clarify if it is looking at only streaming or only conversational or both scenarios for congestion control? Extending on the above: does the charter need say something about the applicability of algorithm to point-to-point scenarios or keep it open and discuss this in the requirements document? Cheers, Varun On Tue, Jan 3, 2012 at 18:03, Wesley Eddy <wes@mti-systems.com> wrote:

On 1/3/2012 8:44 AM, Harald Alvestrand wrote:

...

On 01/02/2012 07:56 PM, Wesley Eddy wrote:

...

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!

Happy new year!

I like the charter as written, as it seems to cover the ground we've gone over in discussion fairly well and in some detail.

As a matter of planning, I'm a bit leery of the schedule; the first milestone of the WG is in November 2012, and the last milestone is in December 2012, corresponding to the second of the five bullets under "The working group is chartered to...".

My two worries are:

- If we don't do even speculative planning for the further steps up to "publish standards track RFCs", we're not setting expectations in the community. This could be bad. - Waiting 11 months from now before we start adopting documents for possible Experimental publication seems like an awfully long time. If the RTCWEB WG wants (likely experimental) documents to refer to in its output, that means that those documents have to be RTCWEB work product or independent submissions, meaning that we first have to publish them outside this WG, then pull them back in; that seems to be a bit of a circuitous route.

Do you have a more detailed image of how the work should progress, that gives some sense of what the steps that need to be taken are between now and November 2012?

The milestone dates had very little thought put into them on my part. We should adapt them to whatever folks think is more reasonable, based on discussion.

There are possibly other milestones that could be added for things like common evaluation and test methodology, requirements, etc. that would possibly be happening early on in parallel with algorithms starting to be proposed and reviewed.  I think the need for these should be discussed.

I would expect chairs to help define the workflow for accepting proposals as WG items and moving them forward.  It can be difficult, for instance, if a proposal is accepted before much data has been reviewed, the group may later want to un-accept it.  Although dropping documents has been done before, it may not be pleasant.  I, personally, would think it makes more sense to keep documents as individual submission proposals to the working group until there is strong consensus that a proposal is indeed something that the group is happy to publish.

-- Wes Eddy MTI Systems _______________________________________________ Rtp-congestion mailing list Rtp-congestion@alvestrand.no http://www.alvestrand.no/mailman/listinfo/rtp-congestion

-- http://www.netlab.tkk.fi/~varun/

On 1/3/2012 10:07 AM, Randell Jesup wrote:

On 1/2/2012 1:56 PM, Wesley Eddy wrote:

...

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!

Thanks Wesley.

First a nit:

"Other algorithms developed in light of experience with TFRC are felt to be motivated." Perhaps instead: "Experience with TFRC has motivated demand for alternative algorithms."

While I very much do not want to do anything to delay progress on this, I should note that most aspects of such congestion control mechanisms would not be specific to RTP, though some implementation details might be. We should attempt to define these algorithms such that they'd be applicable to any flow with similar characteristics and requirements (certainly other media flows), while providing specifics of how they apply to RTP flows.

Good point; I will try to reflect this in the next revision, though I think we do need to clearly have RTP/RTCP as the target for a concrete instantiation of the algorithms.

Some aspects that are developed in this process might be useful in other similar domains as well, such as congestion control of multiple TCP flows between a pair of hosts. I would not explicitly include TCP in this effort at this point to avoid feature creep, but we may want to have a dependent/follow-on effort for TCP.

I should note that for WebRTC/RTCWeb, we hope to be able to share a congestion domain with the data channels, currently expected to be handled via SCTP, though the details of how this will occur have not been decided.

Thank you; this is a very good point, and I will attempt to reflect it in the next revision. -- Wes Eddy MTI Systems