[R-C] Charter

[Matt Mathis]

Although I like the seeming simplicity of "congestion avoidance", that
precise pair of words is used to refer to the +1 per RTT behavior of
TCP during the AIMD sawtooth.    How about just "avoid congestion",
which has a similar sense but is less specific and unlikely to cause
any confusion.

Thanks,
--MM--
The best way to predict the future is to create it.  - Alan Kay


On Tue, Aug 7, 2012 at 6:10 AM, John Leslie <john at jlc.net> wrote:
> 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>
> _______________________________________________
> Rtp-congestion mailing list
> Rtp-congestion at alvestrand.no
> http://www.alvestrand.no/mailman/listinfo/rtp-congestion