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

[Magnus Westerlund <[e-mail]>]

On 2014-03-27 20:01, Harald Alvestrand wrote:
> 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.
> 

Martin and Harald,
(as individual)

Yes, you are both correct that we have mechanisms that also is intended
to react to this happening.

I didn't meant to imply that these would not be present. Still, I think
for the consent mechanism it needs to at least perform consent and kill
on what ICE refers to as "Media Stream", i.e. where RTP and RTCP
transport flows when not performing RTP/RTCP multiplexing would be
different components, that failure to acquire consent on all components
revoke the rights on all those components. Because, if not then you can
end up in strange conditions where you still send some traffic. If we
turn the issue around and consent is revoked for RTP but not RTCP. Then
the RTCP stream continues to send. An application may considered this a
failed case as this higher layer is likely to considered RTP and RTCP as
a unit and not care about the distinction.


Also, I realize that circuit breakers have an issue when it comes to
protecting the network if an attacker can set the RTCP bandwidths
sufficiently low on their own. As all the breakers are calculated based
on reporting intervals, if one sets the RTCP RR bandwidth to 1 bps, then
the reporting interval will be very long, even a two SSRC RTP session
with minimal RTCP packets will get an Td= 2730,67 s, i.e. ~45 minutes.

I need to think a bit more, but I think we might require that one
provision RTCP with sufficient RTCP bandwidth that the minimal fixed
interval of 5 seconds is going to be the largest term when using the
circuit breaker. I will bring this up in AVTCORE.

Cheers

Magnus Westerlund

----------------------------------------------------------------------
Services, Media and Network features, Ericsson Research EAB/TXM
----------------------------------------------------------------------
Ericsson AB                 | Phone  [phone]
Färögatan 6                 | Mobile [phone]
SE-164 80 Stockholm, Sweden | mailto: [e-mail]
----------------------------------------------------------------------