[R-C] proposing a WG on RTP congestion control

Wesley Eddy wes at mti-systems.com
Tue Jan 3 16:51:28 CET 2012


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


More information about the Rtp-congestion mailing list