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

From: "Ram Mohan R (rmohanr)" <[email-masked]>
Date: Tue, 25 Mar 2014 15:17:54 +0000

Hi all,

Certain media streams(For example audio, video) may require multiple
components (RTP, RTCP) each of which has to work for the media stream as a
whole to work. If consent fails for one of the component then the
application(JS) may decide to cease transmission of that media stream.

Is there a need to describe some text (RECOMMENDATION) on how fate-sharing
connections need to be handled when consent fails for one of the
components in Consent draft ?
Or should this be left out of this draft ?

Regards,
Ram

---

From: Ted Hardie <[email-masked]>
Date: Tue, 25 Mar 2014 09:25:06 -0700

> Or should this be left out of this draft ?
So, it's my understanding that the application may always decide to cease
transmission of a media stream even  when it has consent to continue, so
I'm not sure what language you are looking for here.  Can you be a bit more
direct on which section would need this recommendation and what it might
say?

Ted

> Regards,
> Ram
>
> _______________________________________________
> rtcweb mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/rtcweb
>

---

From: Bernard Aboba <[email-masked]>
Date: Tue, 25 Mar 2014 20:17:16 -0400

Where RTP and RTCP are multiplexed on the same port, they also share the same fate with respect to ICE consent; similarly, when audio/video/data channel are multiplexed, they also share consent fate. Where audio and video use different ports, the fates will not be shared, and it is possible that consent might be given to one and not the other, but it is probably best left up to the application to decide how to react. The one case which might be deserving of a recommendation is where RTP and RTCP aren't multiplexed and consent is given to one of RTP/RTCP but not the other.

> So, it's my understanding that the application may always decide to cease transmission of a media stream even  when it has consent to continue, so I'm not sure what language you are looking for here.  Can you be a bit more direct on which section would need this recommendation and what it might say?
> 
> Ted

---

From: "Ram Mohan R (rmohanr)" <[email-masked]>
Date: Wed, 26 Mar 2014 01:20:51 +0000

Please see inline

>
>
>From:  Ted Hardie <[email-masked]>
>Date:  Tuesday, 25 March 2014 9:55 pm
>To:  Ram Mohan Ravindranath <[email-masked]>
>Cc:  "[email-masked]" <[email-masked]>
>Subject:  Re: [rtcweb] Consent for fate-sharing connections (Do we need
>text in draft-ietf-rtcweb-stun-consent-freshness ?)
>
>
>On Tue, Mar 25, 2014 at 8:17 AM, Ram Mohan R (rmohanr)
><[email-masked]> wrote:
>
>Hi all,
>
>I'm not sure what language you are looking for here.
> Can you be a bit more direct on which section would need this
>recommendation and what it might say?

Currently there is no section that talks about this. One of the comments
given by Magnus some time back on this draft asks about scope of consent.
We (the authors of draft-ietf-stun-consent-freshness) were discussing
among ourselves on whether there is a need to have any text for
fate-sharing connections. We don¹t see a real need to have any
recommendation in this draft but wanted to bring this topic to mailer to
see if any one else have any different opinion.

As you said it is completely up to the application what to do if consent
fails. There may be many possibilities- For example for a single media
stream when RTP and RTCP are sent over different addresses (no mux used),
then if consent fails for one of the components, an application may choose
to cease that stream. There may be also cases where consent may fail for
audio but pass for video. Again it is up to the application (JavaScript)
to take a decision on what to do.

Since it is application that always decide, I am ok to just leave it and
not have any text in this document

Ram

---

From: Magnus Westerlund <[email-masked]>
Date: Thu, 27 Mar 2014 15:14:36 +0100

> to take a decision on what to do.

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.

>From a security point of view, what is important is that one can't treat
consent on one transport flow (5-tuple) to mean consent to send on any
other. Because then an attacker could create a session where he receives
the low-bitrate audio and consent to the media there and direct the
video to a target for the attack, where no consent is received.

But, I am personally mostly fine with saying nothing that a failure to
retain consent on one RTP session or data channel's transport flows, may
or may not mean that the transmission should be killed on another RTP
session or data channel, where consent has not yet failed.

One question is if one doesn't fate share all transport flows within the
peer connection if one should trigger a consent check when the failure
happens on some other transport flow? That way one can minimize the
delay of discovering revoked consent or path failure on all transport
flows.

Cheers

Magnus Westerlund

----------------------------------------------------------------------
Services, Media and Network features, Ericsson Research EAB/TXM
----------------------------------------------------------------------
Ericsson AB                 | Phone  +46 10 7148287
Färögatan 6                 | Mobile +46 73 0949079
SE-164 80 Stockholm, Sweden | mailto: [email-masked]
----------------------------------------------------------------------

---

From: Martin Thomson <[email-masked]>
Date: Thu, 27 Mar 2014 10:15:28 -0700

> Thus, no RTCP should mean no RTP either as you get no feedback on how it

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.

---

From: Harald Alvestrand <[email-masked]>
Date: Thu, 27 Mar 2014 20:01:31 +0100

> video quality was absolutely appalling.  Turns out, Lync was doing

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.

---

From: Magnus Westerlund <[email-masked]>
Date: Fri, 28 Mar 2014 09:11:44 +0100

>    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