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

Harald Alvestrand <harald@alvestrand.no> Fri, 02 May 2014 09:03 UTC

Return-Path: <harald@alvestrand.no>
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 2AEC31A0A62 for <rtcweb@ietfa.amsl.com>; Fri, 2 May 2014 02:03:15 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.551
X-Spam-Level:
X-Spam-Status: No, score=-2.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.651] 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 3g0Wf7cJlEob for <rtcweb@ietfa.amsl.com>; Fri, 2 May 2014 02:03:12 -0700 (PDT)
Received: from mork.alvestrand.no (mork.alvestrand.no [IPv6:2001:700:1:2::117]) by ietfa.amsl.com (Postfix) with ESMTP id E99CE1A0371 for <rtcweb@ietf.org>; Fri, 2 May 2014 02:03:11 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by mork.alvestrand.no (Postfix) with ESMTP id 353AE7C5513; Fri, 2 May 2014 11:03:09 +0200 (CEST)
X-Virus-Scanned: Debian amavisd-new at alvestrand.no
Received: from mork.alvestrand.no ([127.0.0.1]) by localhost (mork.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NsZDxDMlYiYp; Fri, 2 May 2014 11:03:07 +0200 (CEST)
Received: from [IPv6:2001:470:de0a:27:f4ea:ffbe:da72:7373] (unknown [IPv6:2001:470:de0a:27:f4ea:ffbe:da72:7373]) by mork.alvestrand.no (Postfix) with ESMTPSA id D2DB07C54E1; Fri, 2 May 2014 11:03:06 +0200 (CEST)
Message-ID: <53635F4A.5040508@alvestrand.no>
Date: Fri, 02 May 2014 11:03:06 +0200
From: Harald Alvestrand <harald@alvestrand.no>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.4.0
MIME-Version: 1.0
To: "Cullen Jennings (fluffy)" <fluffy@cisco.com>, Magnus Westerlund <magnus.westerlund@ericsson.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>
In-Reply-To: <BEE377D4-4E1F-4958-8F59-842F92606C5B@cisco.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/hadA4XA1_9MnlAb5a_uEpYGuogQ
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: Fri, 02 May 2014 09:03:15 -0000

On 04/30/2014 11:56 PM, Cullen Jennings (fluffy) 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.
>
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.