Re: [rtcweb] An input for discussing congestion control (Fwd: New Version Notification for draft-alvestrand-rtcweb-congestion-00.txt)

Henrik Lundin <hlundin@google.com> Mon, 19 September 2011 08:26 UTC

Return-Path: <hlundin@google.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 712FF21F87C2 for <rtcweb@ietfa.amsl.com>; Mon, 19 Sep 2011 01:26:46 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -105.092
X-Spam-Level:
X-Spam-Status: No, score=-105.092 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_FONT_FACE_BAD=0.884, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100]
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 tuzT5is5M0tC for <rtcweb@ietfa.amsl.com>; Mon, 19 Sep 2011 01:26:45 -0700 (PDT)
Received: from smtp-out.google.com (smtp-out.google.com [216.239.44.51]) by ietfa.amsl.com (Postfix) with ESMTP id 435EC21F84AD for <rtcweb@ietf.org>; Mon, 19 Sep 2011 01:26:45 -0700 (PDT)
Received: from hpaq13.eem.corp.google.com (hpaq13.eem.corp.google.com [172.25.149.13]) by smtp-out.google.com with ESMTP id p8J8T7nC014154 for <rtcweb@ietf.org>; Mon, 19 Sep 2011 01:29:07 -0700
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1316420947; bh=orUj2kb96oRoFL6nPBBYEh7557A=; h=MIME-Version:In-Reply-To:References:Date:Message-ID:Subject:From: To:Cc:Content-Type; b=BC9FBTrPeOmlBSAswDCR5hw9lXuQimm7uATW5iyroYqXFkfv4UrKFnMAJAOOlE1BE 1UDneGJg6ng1EGm1ARV3Q==
DomainKey-Signature: a=rsa-sha1; s=beta; d=google.com; c=nofws; q=dns; h=dkim-signature:mime-version:in-reply-to:references:date: message-id:subject:from:to:cc:content-type:x-system-of-record; b=a9Mul+q91q/GJp3Ft7xon4xfMJqTZAvQZKjPexpb+12zBrPn8Py9j7Nylfju9sb4s 37UBP1YGfZJtSY/zQeg1Q==
Received: from qyk31 (qyk31.prod.google.com [10.241.83.159]) by hpaq13.eem.corp.google.com with ESMTP id p8J8T47V020965 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT) for <rtcweb@ietf.org>; Mon, 19 Sep 2011 01:29:05 -0700
Received: by qyk31 with SMTP id 31so5079494qyk.15 for <rtcweb@ietf.org>; Mon, 19 Sep 2011 01:29:04 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=beta; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=Nmk0g1AnXW4fsMR6UODlcFOdLHJ/TuRalbknUNJZdWA=; b=xeKJvi8hrIKQlWisPZpCl2e38vNUqeHKMvw7vZYlaRAPSW8XcFtz53ljswMg3WJMRG oc50genXKooy1q/n/A8w==
Received: by 10.229.235.200 with SMTP id kh8mr1787675qcb.101.1316420943520; Mon, 19 Sep 2011 01:29:03 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.229.235.200 with SMTP id kh8mr1787664qcb.101.1316420943139; Mon, 19 Sep 2011 01:29:03 -0700 (PDT)
Received: by 10.229.55.139 with HTTP; Mon, 19 Sep 2011 01:29:03 -0700 (PDT)
In-Reply-To: <382A4C80-101D-4FD0-8473-04679248ACFB@phonefromhere.com>
References: <4E649FBD.1090001@alvestrand.no> <4E734E89.5010105@ericsson.com> <4E766C4C.2020201@jesup.org> <CAEdus3LcjV9x+gLdZm5vwKhh-ge6xzfWSEB_NxcHe1Gz_5DZ8g@mail.gmail.com> <4E76F544.1040108@jesup.org> <382A4C80-101D-4FD0-8473-04679248ACFB@phonefromhere.com>
Date: Mon, 19 Sep 2011 10:29:03 +0200
Message-ID: <CAOhzyfkXh=d2Ayd8YU0E8sgO7sxpP-=vD0P4NXpmB75PBza7tw@mail.gmail.com>
From: Henrik Lundin <hlundin@google.com>
To: Tim Panton <tim@phonefromhere.com>
Content-Type: multipart/alternative; boundary=0016e64ddbe2b0d50604ad47220a
X-System-Of-Record: true
Cc: Randell Jesup <randell-ietf@jesup.org>, rtcweb@ietf.org
Subject: Re: [rtcweb] An input for discussing congestion control (Fwd: New Version Notification for draft-alvestrand-rtcweb-congestion-00.txt)
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: Mon, 19 Sep 2011 08:26:46 -0000

Tim,

The problem that we are trying to attack with the proposal is perhaps better
described as "available bandwidth estimation" rather than congestion
control. I _would_ like to try and separated it from codecs. The bandwidth
estimator should inform the sender of the current feasible rate between two
endpoints, and it should then be up to the sending client (application,
codecs, channel coding, etc) to figure out a way to stay within that limit,
while maintaining an acceptable quality for the use-case at hand.

/Henrik



On Mon, Sep 19, 2011 at 10:21 AM, Tim Panton <tim@phonefromhere.com> wrote:

> On 19 Sep 2011, at 08:54, Randell Jesup wrote:
>
> > Open question to the list: should the congestion-control-geeks discuss
> here on the
> > list the nitty-gritty details required to build the requirements and
> especially to design
> > and debate a possible proposed "baseline" congestion-control algorithm?
> >
> > We can certainly do that detailed discussion by email and come back with
> a
> > draft;  I had been planning to do it by email, but recent discussion on
> rtcweb
> > made me think I should ask for opinions on this.  Given the structure, if
> there's
> > any significant support for "on-the-list" I'll do that.  Realize though
> that they may
> > get pretty long and detailed without really touching on the larger issues
> being
> > discussed here.
> >
> > Right now the bof members to discuss this and propose a draft would be
> myself,
> > Harald, Justin,  Stefan Holmer and Magnus.
> >
>
> I'd like to lurk  on any BoF list, if I may,
> but I have a feeling that congestion control isn't quite such a
> self-contained problem
> as forming a BoF list might imply.
>
> Roughly, my argument is that any modern congestion control for RTC needs to
> involve the application
> and the codec.
>
> Here's an example:
>        I'm in a video conference with 4 other people and I'm exceeding the
> available downlink
> bandwidth. What I want is that the video degrades (framerate of quality)
> without _any_ degradation
> of the video. I might even want to drop all the video but keep the audio
> and screenshare alive.
>        Conversely if I'm watching an ice hockey game - I'd rather lose
> audio quality than frame-rate.
>
> But in _both_ cases I'd like the app to try and tweak the encoder params to
> get within the available bandwidth
> before we start injecting delay or dropping frames.
>
> So my proposal is that the web app is given a chance to get within the
> available bandwidth
> before the system starts putting hard constraints on the RTP level.
>
> All of which makes it something we need to discuss in a holistic fashion
> with the rest of the API.
>
> Tim.
>
> _______________________________________________
> rtcweb mailing list
> rtcweb@ietf.org
> https://www.ietf.org/mailman/listinfo/rtcweb
>



-- 
Henrik Lundin | WebRTC Software Eng | hlundin@google.com | +46 70 646 13 41