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

Harald Alvestrand <harald@alvestrand.no> Sat, 17 May 2014 21:16 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 BA10C1A015F for <rtcweb@ietfa.amsl.com>; Sat, 17 May 2014 14:16:18 -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 2p_AoG1Iodk7 for <rtcweb@ietfa.amsl.com>; Sat, 17 May 2014 14:16:15 -0700 (PDT)
Received: from mork.alvestrand.no (mork.alvestrand.no [158.38.152.117]) by ietfa.amsl.com (Postfix) with ESMTP id E24C71A022B for <rtcweb@ietf.org>; Sat, 17 May 2014 14:16:14 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by mork.alvestrand.no (Postfix) with ESMTP id C9FF67C0783; Sat, 17 May 2014 23:16:13 +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 YD9QNohxQayK; Sat, 17 May 2014 23:16:12 +0200 (CEST)
Received: from [IPv6:2001:470:de0a:27:dd76:d3d1:6691:e380] (unknown [IPv6:2001:470:de0a:27:dd76:d3d1:6691:e380]) by mork.alvestrand.no (Postfix) with ESMTPSA id 96DED7C06F5; Sat, 17 May 2014 23:16:12 +0200 (CEST)
Message-ID: <5377D19B.5030608@alvestrand.no>
Date: Sat, 17 May 2014 23:16:11 +0200
From: Harald Alvestrand <harald@alvestrand.no>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.5.0
MIME-Version: 1.0
To: "Cullen Jennings (fluffy)" <fluffy@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> <53635F4A.5040508@alvestrand.no> <1B57A7DB-DF0B-4956-A6B8-1DA0B9A7FC1E@cisco.com>
In-Reply-To: <1B57A7DB-DF0B-4956-A6B8-1DA0B9A7FC1E@cisco.com>
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 8bit
Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/Bo6dHNG0md3PYnT1oPxhXWFPkXo
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: Sat, 17 May 2014 21:16:18 -0000

On 05/17/2014 11:08 PM, Cullen Jennings (fluffy) wrote:
> On May 2, 2014, at 4:03 AM, Harald Alvestrand <harald@alvestrand.no> wrote:
>
>> 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.
>>
> 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.