Re: [MMUSIC] Congestion controll

Bernard Aboba <> Thu, 06 June 2013 19:31 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 8F64821F947C for <>; Thu, 6 Jun 2013 12:31:46 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -101.9
X-Spam-Status: No, score=-101.9 tagged_above=-999 required=5 tests=[AWL=0.697, BAYES_00=-2.599, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id s8pe-maWWr8k for <>; Thu, 6 Jun 2013 12:31:40 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 05CC521F93F8 for <>; Thu, 6 Jun 2013 12:31:39 -0700 (PDT)
Received: from BLU169-W60 ([]) by with Microsoft SMTPSVC(6.0.3790.4675); Thu, 6 Jun 2013 12:31:40 -0700
X-TMN: [xZMKq0xKbT8ga6v1sz670sBA4UvxU+B+]
X-Originating-Email: []
Message-ID: <BLU169-W609A2EAD331201B824EB6093980@phx.gbl>
Content-Type: multipart/alternative; boundary="_5457cab5-e4e8-4998-98a7-d4399ebf3eaa_"
From: Bernard Aboba <>
To: Cullen Jennings <>
Date: Thu, 06 Jun 2013 12:31:39 -0700
Importance: Normal
In-Reply-To: <>
References: <> <> <> <BLU403-EAS336A4AA94CDB5E97170F9A5939F0@phx.gbl>, <>
MIME-Version: 1.0
X-OriginalArrivalTime: 06 Jun 2013 19:31:40.0187 (UTC) FILETIME=[77CA3EB0:01CE62EC]
Cc: Flemming Andreasen <>, Ari Keranen <>, "" <>
Subject: Re: [MMUSIC] Congestion controll
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Multiparty Multimedia Session Control Working Group <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Thu, 06 Jun 2013 19:31:48 -0000

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. 
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.
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.   If an O/A exchange is required for a sender to drop a stream, rapid adaptation (including congestion control) is hampered. 

> Subject: Congestion controll 
> From:
> Date: Thu, 6 Jun 2013 12:46:20 +0700
> CC:;;
> To:
> On Jun 5, 2013, at 9:41 AM, Bernard Aboba <> 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?