Re: [rtcweb] Consent for fate-sharing connections (Do we need text in draft-ietf-rtcweb-stun-consent-freshness ?)

[Harald Alvestrand <[e-mail]>]

On 03/27/2014 06:15 PM, Martin Thomson wrote:
> On 27 March 2014 07:14, Magnus Westerlund
> <[e-mail]> wrote:
>> I do think RTP MUST be fate shared with its RTCP. Because revoking
>> consent for RTCP should not be a way of turning off congestion control.
>> Thus, no RTCP should mean no RTP either as you get no feedback on how it
>> behaves.
> I would hope that a congestion control algorithm for RTP would a) use
> RTCP as its feedback mechanism, and b) react fairly harshly if RTCP
> suddenly disappeared.  Such that loss of consent on RTCP would
> essentially cut bandwidth to zero, or close to.
>
> I remember having this issue with Lync: we were dropping RTCP and the
> video quality was absolutely appalling.  Turns out, Lync was doing
> both a and b.

That's one of the properties of the "circuit breaker" algorithm that 
Colin Perkins has been editing: Lose RTCP for 3 RTCP reporting 
intervals, cut transmission.

draft-ietf-avtcore-rtp-circuit-breakers-03.txt

And our very own rtp-usage requires that we support circuit-breaker:
draft-ietf-rtcweb-rtp-usage-11.txt

7.1.  Boundary Conditions and Circuit Breakers

    In the absence of a concrete congestion control algorithm, all WebRTC
    implementations MUST implement the RTP circuit breaker algorithm that
    is in described [I-D.ietf-avtcore-rtp-circuit-breakers].  The RTP
    circuit breaker is designed to enable applications to recognise and
    react to situations of extreme network congestion.  However, since
    the RTP circuit breaker might not be triggered until congestion
    becomes extreme, it cannot be considered a substitute for congestion
    control, and applications MUST also implement congestion control to
    allow them to adapt to changes in network capacity.  Any future RTP
    congestion control algorithms are expected to operate within the
    envelope allowed by the circuit breaker.