Subject: Re: [rtcweb] Draft proposal for updating Multiparty topologies in draft-ietf-rtcweb-rtp-usage

From: Magnus Westerlund <[email-masked]>
Date: Fri, 2 May 2014 10:39:42 +0200

On 2014-04-30 23:56, Cullen Jennings (fluffy) wrote:
> 
> On Apr 15, 2014, at 9:14 AM, Magnus Westerlund
> <[email-masked]> wrote:
> 
>> This limitation means that some of the RTP middlebox-based
>> topologies are not suitable for use in the WebRTC environment.
>> Specifically:
>> 
>> o  Video switching MCUs (Topo-Video-switch-MCU) SHOULD NOT be
>> used, since they make the use of RTCP for congestion control and
>> quality of service reports problematic (see Section 3.8 of 
>> [I-D.ietf-avtcore-rtp-topologies-update]).
> 
> I think this is deserving of some WG discussion as people may not be
> up to speed of what this is allowing or not allowing. My
> understanding was several companies at the last WebRTC Expo
> conference were demonstrating system that used this type of MCU.
> 
> If SRTP were more flexible and there was a way to a mixer work
> without giving it the keys to the decrypt the media, I think people
> would be keener on mixers but right it seems like the pro / cons
> invovle a trade off between significant security functionally loss
> and possible loss of some RTCP data which many systems totally
> ignore.  Anyway, not taking any opinion other than this seems like a
> significant enough change to have some discussion on it.
> 

WG,

The change is in the document currently in WG last call. So please
review the whole context, and please do read the topologies document so
that you have a real understanding of what a topology means. The
topology names can be misinterpreted if one only looks at the high
level, not the details of the RTP/RTCP behaviour the topology discusses.

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: Harald Alvestrand <[email-masked]>
Date: Fri, 02 May 2014 11:03:06 +0200

On 04/30/2014 11:56 PM, Cullen Jennings (fluffy) wrote:
> On Apr 15, 2014, at 9:14 AM, Magnus Westerlund <[email-masked]> wrote:
>
>> This limitation means that
>>    some of the RTP middlebox-based topologies are not suitable for use
>>    in the WebRTC environment.  Specifically:
>>
>>    o  Video switching MCUs (Topo-Video-switch-MCU) SHOULD NOT be used,
>>       since they make the use of RTCP for congestion control and quality
>>       of service reports problematic (see Section 3.8 of
> I think this is deserving of some WG discussion as people may not be up to speed of what this is allowing or not allowing. My understanding was several companies at the last WebRTC Expo conference were demonstrating system that used this type of MCU.
>
> If SRTP were more flexible and there was a way to a mixer work without giving it the keys to the decrypt the media, I think people would be keener on mixers but right it seems like the pro / cons invovle a trade off between significant security functionally loss and possible loss of some RTCP data which many systems totally ignore.  Anyway, not taking any opinion other than this seems like a significant enough change to have some discussion on it.
>
Seems the discussion of what the effects are belongs to the threads on 
topologies-update.

RTCWEB implementations that ignore RTCP are going to break all our 
attempts at congestion control anyway, so I'm inclined to leave them out 
of the spec. They'll break on their own.

---

From: "Cullen Jennings (fluffy)" <[email-masked]>
Date: Sat, 17 May 2014 21:08:44 +0000

On May 2, 2014, at 4:03 AM, Harald Alvestrand <[email-masked]> wrote:

> Seems the discussion of what the effects are belongs to the threads on topologies-update.
> 
> RTCWEB implementations that ignore RTCP are going to break all our attempts at congestion control anyway, so I'm inclined to leave them out of the spec. They'll break on their own.
> 

FWIW … Things doing audio only at relatively low bit rates that ignore RTCP will probably continue to work fine.

---

From: Harald Alvestrand <[email-masked]>
Date: Sat, 17 May 2014 23:16:11 +0200

> FWIW … Things doing audio only at relatively low bit rates that ignore RTCP will probably continue to work fine.
As long as "relatively low" means "low relative to the available 
bandwidth", I agree.

They'll break when that doesn't hold.

---

From: Bernard Aboba <[email-masked]>
Date: Sun, 18 May 2014 09:58:05 -0700

Cullen said:

"My understanding was several companies at the last WebRTC Expo conference
were demonstrating system that used this type of MCU."

[BA] Indeed, this type of MCU is likely to be popular, because at some
point the browser itself becomes the limitation.  For example, tests seem
to show rendering limits kicking in at roughly a dozen streams (though
there have been some successful test with up to 20 streams rendered
simultaneously).  One way for the MCU to deal with this is to only show the
"last N" speakers.  This does not necessarily imply usage of the "video
switching" topology, but a number of vendors are implementing it this way.

Cullen also said:

"If SRTP were more flexible and there was a way to a mixer work without
giving it the keys to the decrypt the media, I think people would be keener
on mixers"

[BA] This issue also affects Scalable Forwarding Units, not just "mixers".
 There have been some studies of "codec-specific encryption" that show the
performance effects of this, as well as the security impact. [1]

[1] Efficient In-Network Adaptation of Encrypted H.264/SVC Content (2009)
by by Hermann Hellwagner , Robert Kuschnig , Thomas Stütz , Andreas Uhl

On Wed, Apr 30, 2014 at 2:56 PM, Cullen Jennings (fluffy)
<[email-masked]>wrote:

> I think this is deserving of some WG discussion as people may not be up to
> speed of what this is allowing or not allowing. My understanding was
> several companies at the last WebRTC Expo conference were demonstrating
> system that used this type of MCU.
>
> If SRTP were more flexible and there was a way to a mixer work without
> giving it the keys to the decrypt the media, I think people would be keener
> on mixers but right it seems like the pro / cons invovle a trade off
> between significant security functionally loss and possible loss of some
> RTCP data which many systems totally ignore.  Anyway, not taking any
> opinion other than this seems like a significant enough change to have some
> discussion on it.
>
>
>
>
>
> _______________________________________________
> rtcweb mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/rtcweb
>