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, 03 October 2011 08:09 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 5224321F8AEA for <rtcweb@ietfa.amsl.com>; Mon, 3 Oct 2011 01:09:52 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -104.259
X-Spam-Level:
X-Spam-Status: No, score=-104.259 tagged_above=-999 required=5 tests=[AWL=0.833, 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 II6DaGK5DMib for <rtcweb@ietfa.amsl.com>; Mon, 3 Oct 2011 01:09:51 -0700 (PDT)
Received: from smtp-out.google.com (smtp-out.google.com [74.125.121.67]) by ietfa.amsl.com (Postfix) with ESMTP id D4DB121F8AB0 for <rtcweb@ietf.org>; Mon, 3 Oct 2011 01:09:50 -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 p938CkPA022239 for <rtcweb@ietf.org>; Mon, 3 Oct 2011 01:12:46 -0700
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1317629566; bh=EjjsVXMkYvd+UdGKBbNMiRHnk6k=; h=MIME-Version:In-Reply-To:References:Date:Message-ID:Subject:From: To:Cc:Content-Type; b=HbfghAHJdDyU489Y6RC6ald3CELZro8EE3kY1gz6BrtT1Ne+m1E9dAs/4rsvKL1F0 +8cVLelHZtYfBqc8hbahA==
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=EWARUibVA0iarPuHLrwPdYGe5M5w4bRUtRPI2fvjim45LepCWTEasRO1BnnqaYugQ fDxvj6zGtzIugDwyqFa5Q==
Received: from ywp17 (ywp17.prod.google.com [10.192.16.17]) by hpaq13.eem.corp.google.com with ESMTP id p938CD66024249 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT) for <rtcweb@ietf.org>; Mon, 3 Oct 2011 01:12:45 -0700
Received: by ywp17 with SMTP id 17so3752892ywp.41 for <rtcweb@ietf.org>; Mon, 03 Oct 2011 01:12:45 -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=Mpz59UU8m3Znp49Jr7bTZVM4nIGYN1yy8w2SximMN84=; b=l7iD+XzVBz71Cu8kLmJF8NmnlbfH8iIk/oisFYqTGDKCZJC4ouBGR7xrDRrwOX8oXK 7W+UpbqDFPwEypyqQGvQ==
Received: by 10.100.56.25 with SMTP id e25mr12449584ana.70.1317629564918; Mon, 03 Oct 2011 01:12:44 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.100.56.25 with SMTP id e25mr12449575ana.70.1317629564332; Mon, 03 Oct 2011 01:12:44 -0700 (PDT)
Received: by 10.100.166.9 with HTTP; Mon, 3 Oct 2011 01:12:44 -0700 (PDT)
In-Reply-To: <4E79EA16.7070909@freedesktop.org>
References: <4E649FBD.1090001@alvestrand.no> <4E734E89.5010105@ericsson.com> <4E766C4C.2020201@jesup.org> <CAEdus3LcjV9x+gLdZm5vwKhh-ge6xzfWSEB_NxcHe1Gz_5DZ8g@mail.gmail.com> <CAOhzyf=MqsgsGUi521oJ5N6+T+K1N01MjeHYPpX_VZK8uyQksw@mail.gmail.com> <CAKkvrEkx0mqnDWqNYse3r9WUMbYKNZhrBqQ0SPUAnTtKrA5bLg@mail.gmail.com> <CAOhzyf=_n3VhNi1GgxdKJpyzEMLORcKX2499+YZHQnGqYURxjg@mail.gmail.com> <CAKkvrEnXxoiJZJ3a3eg_Ybz0POCM+UTxU7nnWCf8Xt331jiXLA@mail.gmail.com> <4E787D56.8060106@alvestrand.no> <CAKkvrEnpMusPu8py2-98NffDY493z=tA_giW9X-p6c1LtgL+XA@mail.gmail.com> <4E788A9C.40105@alvestrand.no> <CAKkvrEk0_L6UfDsUHQea_5XXfYXGWQ-8dJm_mP+nTSeVeL90rQ@mail.gmail.com> <4E799F00.8030602@alvestrand.no> <4E79E698.2090905@jesup.org> <4E79EA16.7070909@freedesktop.org>
Date: Mon, 3 Oct 2011 10:12:44 +0200
Message-ID: <CAOhzyf=c5+X+ScgV5CXkJJVM_ev1Hog7QP9FBCeA67z-R=oOcg@mail.gmail.com>
From: Henrik Lundin <hlundin@google.com>
To: Jim Gettys <jg@freedesktop.org>
Content-Type: multipart/alternative; boundary=0016e647661c20ac0604ae608a90
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, 03 Oct 2011 08:09:52 -0000

Sorry for my late response. (I've been away for some time.) I'd just like to
add my two cents to the discussion on feedback latency.

Frequent and rapid feedback is important to ensure stability of the CC; I
think we all agree. However, with an algorithm similar to the suggested one,
having a receive-side processing and analysis function, the key feature is
that feedback _can_ be sent quickly when needed. When everything is ok,
feedback can be quite sparse, as long as the rate increments are somewhat
adjusted for the system response time (including the feedback latency). When
congestion is detected by the receiver, it is important that a feedback
message can be sent more or less immediately (say, within 100 ms). However,
I do not see the need for constant feedback every RTT or so.

/Henrik





On Wed, Sep 21, 2011 at 3:43 PM, Jim Gettys <jg@freedesktop.org> wrote:

>
> On 09/21/2011 09:28 AM, Randell Jesup wrote:
>
> On 9/21/2011 4:23 AM, Harald Alvestrand wrote:
>
> I think receiver->sender reporting every RTT (or every packet, which is
> frequently less frequent) is overkill, but that's a statement with a lot of
> gut feeling and very few numbers behind it.
>
> One advantage we have in RTCWEB is that we can assume that if audio and
> video work OK across the network, we're in a good place. We don't have to
> worry about getting gigabyte file transfers to utilize 90% of the link -
> even thogh we have to worry about audio and video functioning while those
> gigabyte transfers are taking place.
>
>
> Agreed.  Also, in practice the TCP flows we're competing with are rarely
> long-lived
> high-bandwidth flows like GB file transfers.  Normally they're flurries of
> short-lived TCP
> (which is important to consider since these short-lived flows can suddenly
> cause buffering
> without warning).
>
>
> You get to deal with some of each. Both cause havoc in the face of
> bufferbloat.  The long lived flows keep the buffers in your OS/Home
> router/broadband gear near full, inserting lots of delay.  This includes
> doing backups (local or remote), uploading videos, downloading videos to
> disk, bittorrent, etc. The netalyzr data is quite grim, particularly when
> you realise it's a lower bound on the problem (the netalyzr test is
> sensitive to cross traffic and more importantly, tops out by the time it
> gets to 20Mbps).
>
>
> http://gettys.wordpress.com/2010/12/06/whose-house-is-of-glasse-must-not-throw-stones-at-another/
>
> As far as the transient bufferbloat problem caused by web traffic, and why
> IW10 is a problem in my view at this time, see:
>
> http://www.ietf.org/id/draft-gettys-iw10-considered-harmful-00.txt
>
>
>
> As for 1 feedback/RTT, I agree.  And if you wanted to use one feedback/RTT,
> I'd put the feedback in
> a TCP header extension or design an RTP equivalent that can carry it in the
> reverse-direction
> media flow (when available).  But that's a different argument.
>
>  I like timestamps, if only to make it easy to tell the user: you are
> losing, and it's because of your broken network.
>
> For TCP, the TCP timestamp option is on by default in Linux, and I think
> may be on by default on other modern systems (anyone have any data?).
>                         - Jim
>
>
> Other protocols may not be so nice.
>
> _______________________________________________
> 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