Re: [rtcweb] Congestion Control proposal

Wesley Eddy <wes@mti-systems.com> Thu, 06 October 2011 22:44 UTC

Return-Path: <wes@mti-systems.com>
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DC4FB21F8BAB for <rtcweb@ietfa.amsl.com>; Thu, 6 Oct 2011 15:44:28 -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 T9ha7zbq48q6 for <rtcweb@ietfa.amsl.com>; Thu, 6 Oct 2011 15:44:27 -0700 (PDT)
Received: from omr6.networksolutionsemail.com (omr6.networksolutionsemail.com [205.178.146.56]) by ietfa.amsl.com (Postfix) with ESMTP id 4B1C721F8BA9 for <rtcweb@ietf.org>; Thu, 6 Oct 2011 15:44:27 -0700 (PDT)
Received: from cm-omr8 (mail.networksolutionsemail.com [205.178.146.50]) by omr6.networksolutionsemail.com (8.13.6/8.13.6) with ESMTP id p96MlZPT011345 for <rtcweb@ietf.org>; Thu, 6 Oct 2011 18:47:38 -0400
Authentication-Results: cm-omr8 smtp.user=wes@mti-systems.com; auth=pass (PLAIN)
X-Authenticated-UID: wes@mti-systems.com
Received: from [184.244.4.16] ([184.244.4.16:45538] helo=[68.245.171.115]) by cm-omr8 (envelope-from <wes@mti-systems.com>) (ecelerity 2.2.2.41 r(31179/31189)) with ESMTPA id CF/DA-24569-4003E8E4; Thu, 06 Oct 2011 18:47:35 -0400
Message-ID: <4E8E3005.3090307@mti-systems.com>
Date: Thu, 06 Oct 2011 18:47:33 -0400
From: Wesley Eddy <wes@mti-systems.com>
Organization: MTI Systems
User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:7.0.1) Gecko/20110929 Thunderbird/7.0.1
MIME-Version: 1.0
To: rtcweb@ietf.org
References: <4E8DCA06.5060506@jesup.org>
In-Reply-To: <4E8DCA06.5060506@jesup.org>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Subject: Re: [rtcweb] Congestion Control proposal
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.12
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: Thu, 06 Oct 2011 22:44:29 -0000

On 10/6/2011 11:32 AM, Randell Jesup wrote:
>
> Data channels:
>
> If we use SCTP-DTLS-UDP, we can rely on SCTP's congestion-control, perhaps
> modified to "play nice" with the media streams, and to have some amount of
> known priority relative to them. (For example, if the media streams need
> to back off and the data streams are using a consistent amount of data, it
> could reduce the amount or rate data is sent.) We also could pre-allocate
> some amount of bandwidth to data, and so long as it's not using it media
> could. Note that SCTP's congestion control is supposed to be in some
> manner pluggable, so we could modify/replace it fairly easily.
>
> Worst case: it acts as a separate, TCP-friendly flow we compete with.
>
> If we have to use TCP-over-UDP, then that will be congestion-controlled for
> each individual flow, but the non-reliable channels will need separate
> congestion control. Simplest would be to add RTP-like timestamps to the
> non-reliable data channels so they could pulled into the framework of the
> RTP channels as if they were bursty RTP data.
 >
 > ...
>
> JS Interface:
>
> We need to tell the application about bandwidth changes, and give it the
> option of making choices, both in the allocation of bits among the various
> streams of data, and of the actual streams themselves (adding or shutting
> down streams, or switching modes (mono/stereo, codecs possibly, etc)). If
> the application doesn't care to make a choice we'll do it for them. We'll
> also want the JS application to be able to affect the congestion-control
> status of the data channels, so it could take bits from the data channels
> without engendering a tug-of-war and temporary over-bandwidth/buffering.
>


I can't claim to fully understand the intended architecture from the
description in this email, but something struck me as odd when in one
breath it seems like data is flowing over TCP or SCTP (layered over
UDP) and in another there's a separate algorithm (the Google one, or
some modification) running for estimating bandwidth.  Those seem
mutually exclusive to me, unless I completely misunderstand the goal
(which is entirely possible).

Reporting changes to the application is another matter with its own
challenges in either case, since the way the application responds will
limit what the CC can do afterwards (without additional probing).

If running TCP or SCTP, the congestion window (cwnd) and RTT should be
sufficient to convey the available bandwidth at a point in time.  If
anything lower is reported to the app, the cwnd will never open up
because it will be application-limited, and if anything higher is
reported, it will build up a queue in the sender that won't be
drained any faster than the cwnd allows.

-- 
Wes Eddy
MTI Systems