[R-C] Charter

John Leslie john at jlc.net
Tue Aug 7 15:10:05 CEST 2012


Stefan Holmer <stefan at webrtc.org> wrote:
> On Tue, Aug 7, 2012 at 9:54 AM, Michael Welzl <michawe at ifi.uio.no> wrote:
>>
>> Thanks for all your inputs! I agree with all of them, from Matt and John,
>> except:
>>...
>> [John Leslie wrote:] 
>> 
>>> In case the above isn't sufficient to start some flame-wars, I also
>>> strongly suggest adding language better defining the problem, to cover:
>>> - RMCAT strongly wants low delay and low jitter
>>> - RMCAT can tolerate loss better than high delay
>>> - RMCAT prefers consistent bandwidth to inconsistent high bandwidth
>>> - we posit that RMCAT can reasonably adjust slower than TCP
>>
>> because, indeed, as Randell says, this edges towards a solution space. Low
>> delay has always been there, I added "and low jitter" now - but the other
>> things are assumptions that I think we shouldn't make (in particular the
>> third item). They may or may not be correct, depending on the codec in use,
>> and so this gets too narrow IMO if we write it in the charter.

   I'm not particular about the wording, but I think the charter needs
at least a hint that the congestion-avoidance aims are different than
TCP.

> In addition this is not only focused on video or audio streams, but also
> data streams which may prefer inconsistent high bandwidth than a lower
> consistent bandwidth.

   Indeed, there may be data streams included which would prefer TCP
congestion-management rules; but these _are_ under our control, and
almost by definition are incidental to the overall RMCAT congestion
issues. We can give them incidental (arguably spare) bandwidth while
still keeping our delay low.

   (I'm quite happy to let Michael wordsmith how big the hint should
be: I just don't want to abandon mention of the differing aims.)

--
John Leslie <john at jlc.net>


More information about the Rtp-congestion mailing list