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

Bernard Aboba <bernard.aboba@gmail.com> Sun, 18 May 2014 16:58 UTC

Return-Path: <bernard.aboba@gmail.com>
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 42FC51A0166 for <rtcweb@ietfa.amsl.com>; Sun, 18 May 2014 09:58:29 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.099
X-Spam-Level:
X-Spam-Status: No, score=-0.099 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZVyTRX82sjMB for <rtcweb@ietfa.amsl.com>; Sun, 18 May 2014 09:58:27 -0700 (PDT)
Received: from mail-we0-x22e.google.com (mail-we0-x22e.google.com [IPv6:2a00:1450:400c:c03::22e]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 261AC1A014F for <rtcweb@ietf.org>; Sun, 18 May 2014 09:58:26 -0700 (PDT)
Received: by mail-we0-f174.google.com with SMTP id k48so4508235wev.19 for <rtcweb@ietf.org>; Sun, 18 May 2014 09:58:26 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=8lkgGDnpcngTMQ64RfWeKJF+aAfmsYE57oumh4xpOIE=; b=vkDOgnqlw6ZLk2UVAkGuAmcOxT1hJgqxoIuroSjar0e4sRj8ev6WBmSwzoNSx4BOVf FwTCGnHrumwlKAAGNqflIQMw9x6vkwuORcVmPD3EqXzbVH7Hd94sUlbfz1h1hSKjMYEk 2rMcJ7C+m46P7p4cL1VeJCUP3WyaVDzYJ4yA89shAgCAas5X9HzHsC2MJ2ZHtR0agBgY z/fBrI3/7skPCFtlGaDjk00F/mT0ZoHYJFMQjgVWF27rmq2FzsNdWfEJDf1ViWCvUZ90 4R0E8fTrqQrVtLPjgQHKWJtP83MhrSg3gjuW5M5VrktFaPGSQu9qKLJElzqgCO/e8BtQ m4nQ==
X-Received: by 10.195.17.169 with SMTP id gf9mr25483262wjd.10.1400432306035; Sun, 18 May 2014 09:58:26 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.216.102.130 with HTTP; Sun, 18 May 2014 09:58:05 -0700 (PDT)
In-Reply-To: <BEE377D4-4E1F-4958-8F59-842F92606C5B@cisco.com>
References: <533E7A50.5040909@ericsson.com> <53425DDE.2030005@alvestrand.no> <534288C2.6010906@ericsson.com> <5342ABBB.9050300@alvestrand.no> <534D4CC4.9040107@ericsson.com> <BEE377D4-4E1F-4958-8F59-842F92606C5B@cisco.com>
From: Bernard Aboba <bernard.aboba@gmail.com>
Date: Sun, 18 May 2014 09:58:05 -0700
Message-ID: <CAOW+2dtir8c64rqB4eDQCdWONS+mz2HQB3Z2PMuSknXZfxLw_Q@mail.gmail.com>
To: "Cullen Jennings (fluffy)" <fluffy@cisco.com>
Content-Type: multipart/alternative; boundary=089e01681bfc2224cb04f9af8e66
Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/Vt5SXOm0aGIpTGZaYudg3NE01Kg
Cc: "rtcweb@ietf.org" <rtcweb@ietf.org>
Subject: Re: [rtcweb] Draft proposal for updating Multiparty topologies in draft-ietf-rtcweb-rtp-usage
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Real-Time Communication in WEB-browsers working group list <rtcweb.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/rtcweb>, <mailto:rtcweb-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/rtcweb/>
List-Post: <mailto:rtcweb@ietf.org>
List-Help: <mailto:rtcweb-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/rtcweb>, <mailto:rtcweb-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sun, 18 May 2014 16:58:29 -0000

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)
<fluffy@cisco.com>wrote;wrote:

>
> On Apr 15, 2014, at 9:14 AM, Magnus Westerlund <
> magnus.westerlund@ericsson.com> 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.
>
>
>
>
>
> _______________________________________________
> rtcweb mailing list
> rtcweb@ietf.org
> https://www.ietf.org/mailman/listinfo/rtcweb
>