Re: [MMUSIC] Congestion controll

Cullen Jennings <fluffy@iii.ca> Sat, 08 June 2013 04:44 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 644B821F8F6E for <mmusic@ietfa.amsl.com>; Fri, 7 Jun 2013 21:44:28 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.562
X-Spam-Level:
X-Spam-Status: No, score=-2.562 tagged_above=-999 required=5 tests=[AWL=0.038, 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 p1H0mMAWpSEw for <mmusic@ietfa.amsl.com>; Fri, 7 Jun 2013 21:44:22 -0700 (PDT)
Received: from mxout-07.mxes.net (mxout-07.mxes.net [216.86.168.182]) by ietfa.amsl.com (Postfix) with ESMTP id 3036C21F8F6D for <mmusic@ietf.org>; Fri, 7 Jun 2013 21:44:21 -0700 (PDT)
Received: from [10.70.232.148] (unknown [64.104.46.217]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id 15CC922E253; Sat, 8 Jun 2013 00:44:12 -0400 (EDT)
Content-Type: text/plain; charset=windows-1252
Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\))
From: Cullen Jennings <fluffy@iii.ca>
In-Reply-To: <BLU169-W609A2EAD331201B824EB6093980@phx.gbl>
Date: Sat, 8 Jun 2013 11:44:10 +0700
Content-Transfer-Encoding: quoted-printable
Message-Id: <4D8F5FFC-F89B-4A5B-8464-3EF20E7D67E9@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>
To: Bernard Aboba <bernard_aboba@hotmail.com>
X-Mailer: Apple Mail (2.1503)
Cc: Flemming Andreasen <fandreas@cisco.com>, Ari Keranen <ari.keranen@ericsson.com>, "mmusic@ietf.org" <mmusic@ietf.org>
Subject: Re: [MMUSIC] Congestion controll
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: Sat, 08 Jun 2013 04:44:28 -0000

I think everyone is on board with the fact that RTP represents what you would call an envelope from a congestion point of view. Exactly what can be changed inside that envelope and how might be a question and but that seems a very different one than the plan A / plan B discussion. Regardless of what happens with envelopes and congestion control, both plan A and B don't change and work with that answer. 

more inline … 


On Jun 7, 2013, at 2:31 AM, Bernard Aboba <bernard_aboba@hotmail.com> wrote:

> In a highly congested environment, signaling will also be likely to be disrupted.   Therefore if signaling is necessary for a sender to reduce the sending rate (e.g. for example, in order to reduce resolution or framerate), then that rate reduction would itself be disrupted by congestion, preventing the sender from reducing rate, and thereby potentially resulting in congestive collapse. 

Sure, I agree. I would say it as when we need to reduce the sending rate rapidly due to significant congestion, relying on round trips of signaling to do this may be too slow. 

>  
> The solution to this, which has been widely implemented, is to enable rate reductions (such as removal of simulcast or layered streams) without a dependency on signaling.  This is possible because the initial O/A exchange focuses on negotiating the *envelope* of acceptable resolutions, frame rates, streams, etc. rather than attempting to control what is actually being sent in realtime.  As a result, the sender can reduce rate very quickly by dropping streams, with no signaling dependency.

Of course. Agree

>  
> It would appear to me that both Plan A and Plan B use signaling not just to control the envelope of acceptable configurations, but to determine what is actually being sent at a given moment.

This is the part I strongly disagree with. I think both plan A and B allow any type of control that is acceptable in RTP / SDP for this including the use of RTCP. I can't see how plan A / B have anything to do with this. 


>   If an O/A exchange is required for a sender to drop a stream, rapid adaptation (including congestion control) is hampered. 

No O/A is request to stop sending RTP packets on a given stream. Plan A / B have nothing to do with that one way or another.

>  
>  
> 
>  
> > Subject: Congestion controll 
> > From: fluffy@iii.ca
> > Date: Thu, 6 Jun 2013 12:46:20 +0700
> > CC: fandreas@cisco.com; ari.keranen@ericsson.com; mmusic@ietf.org
> > To: bernard_aboba@hotmail.com
> > 
> > 
> > On Jun 5, 2013, at 9:41 AM, Bernard Aboba <bernard_aboba@hotmail.com> wrote:
> > 
> > > As they stand, both Plan A nor Plan B result in O/A exchanges that aren't needed and will break congestion control
> > 
> > Bernard - that's a pretty strong statement. Uh, you want to explain how either plan A or B break congestion control?
> > 
> >