IETF Logo Mail Archive

Re: [MMUSIC] Congestion control

Cullen Jennings <fluffy@iii.ca> Tue, 11 June 2013 06:11 UTC

Return-Path: <fluffy@iii.ca>
X-Original-To: mmusic@ietfa.amsl.com
Delivered-To: mmusic@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7D13621F9A72 for <mmusic@ietfa.amsl.com>; Mon, 10 Jun 2013 23:11:01 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level:
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fLHdfK3Hi8qy for <mmusic@ietfa.amsl.com>; Mon, 10 Jun 2013 23:10:55 -0700 (PDT)
Received: from mxout-07.mxes.net (mxout-07.mxes.net [216.86.168.182]) by ietfa.amsl.com (Postfix) with ESMTP id 92C6D21F8EB3 for <mmusic@ietf.org>; Mon, 10 Jun 2013 23:10:55 -0700 (PDT)
Received: from sjc-vpn5-291.cisco.com (unknown [128.107.239.233]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id C067722E253; Tue, 11 Jun 2013 02:10:51 -0400 (EDT)
Content-Type: text/plain; charset="iso-8859-1"
Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\))
From: Cullen Jennings <fluffy@iii.ca>
In-Reply-To: <BLU169-W35E035EC4AC7AE5BBCCBBC93840@phx.gbl>
Date: Tue, 11 Jun 2013 15:10:49 +0900
Content-Transfer-Encoding: quoted-printable
Message-Id: <BAF96BD5-D167-4B78-AF92-DDB2DE780A32@iii.ca>
References: <20130530185619.4124.56395.idtracker@ietfa.amsl.com> <51A87F91.2080500@jitsi.org> <51AEA08D.8090103@cisco.com> <BLU403-EAS336A4AA94CDB5E97170F9A5939F0@phx.gbl>, <25B9903E-DC06-4BB0-92A1-C1E7A2AA569E@iii.ca> <BLU169-W609A2EAD331201B824EB6093980@phx.gbl>, <4D8F5FFC-F89B-4A5B-8464-3EF20E7D67E9@iii.ca> <BLU169-W35E035EC4AC7AE5BBCCBBC93840@phx.gbl>
To: Bernard Aboba <bernard_aboba@hotmail.com>
X-Mailer: Apple Mail (2.1503)
Cc: "mmusic@ietf.org" <mmusic@ietf.org>
Subject: Re: [MMUSIC] Congestion control
X-BeenThere: mmusic@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Multiparty Multimedia Session Control Working Group <mmusic.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/mmusic>, <mailto:mmusic-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/mmusic>
List-Post: <mailto:mmusic@ietf.org>
List-Help: <mailto:mmusic-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/mmusic>, <mailto:mmusic-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 11 Jun 2013 06:11:02 -0000

On Jun 11, 2013, at 4:16 AM, Bernard Aboba <bernard_aboba@hotmail.com> wrote:

> Cullen said: 
> 
>  
> " No O/A is request to stop sending RTP packets on a given stream. "
>  
> [BA]  So you're saying that you don't expect a=sendrecv/recvonly/sendonly to be used in Plan A to control streams described by individual m lines?    I had assumed that the O/A behavior described in RFC 3264 Sections 5.1 and 6.1 would apply in Plan A.  
>  

Bernard - do you really think the "a=sendrecv/recvonly/sendonly " is how we do congestion control for VoIP? I don't think that is the approach that WeRTC will take to congestion control. Of course "a=sendrecv/recvonly/sendonly  are part of SDP but they are not how anyone other than you has proposed to do congestion control. I think you would agree they would be a pretty non optimal way to do congestion control.

v2.23.0 | Report a Bug | By Email