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 11:08 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 32C1121F8B1E for <rtcweb@ietfa.amsl.com>; Mon, 3 Oct 2011 04:08:38 -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 rKvhQrwZEqnk for <rtcweb@ietfa.amsl.com>; Mon, 3 Oct 2011 04:08:34 -0700 (PDT)
Received: from smtp-out.google.com (smtp-out.google.com [216.239.44.51]) by ietfa.amsl.com (Postfix) with ESMTP id 1394821F8AAC for <rtcweb@ietf.org>; Mon, 3 Oct 2011 04:08:33 -0700 (PDT)
Received: from wpaz17.hot.corp.google.com (wpaz17.hot.corp.google.com [172.24.198.81]) by smtp-out.google.com with ESMTP id p93BBZAU000303 for <rtcweb@ietf.org>; Mon, 3 Oct 2011 04:11:35 -0700
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1317640295; bh=A8kxvYmn8ErC3ujq9ANoS77bx0I=; h=MIME-Version:In-Reply-To:References:Date:Message-ID:Subject:From: To:Cc:Content-Type; b=Ka+ZGRczHQmBeLreQgNfMKQiHlPg7hf4p/sA3W0Lczmlj4uztxaEaylFtIcrn/wNP +SmAUnLALrqd4AU7v/ceQ==
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=Vb3/EbQz7rUX3AvD0P8PU1pFt/5kXTxHSciw5uLjF4Oq3soNT4bvcENjXyX/m+cp0 I+l5DhuCFtrPKB5/i5zqA==
Received: from gyd12 (gyd12.prod.google.com [10.243.49.204]) by wpaz17.hot.corp.google.com with ESMTP id p93BAiBN002987 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT) for <rtcweb@ietf.org>; Mon, 3 Oct 2011 04:11:34 -0700
Received: by gyd12 with SMTP id 12so3289292gyd.3 for <rtcweb@ietf.org>; Mon, 03 Oct 2011 04:11:30 -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=5Eewa3k/o3tXyclaF77TpdhlYo0DemNcVppbKOKytiw=; b=e5KuFaJ1qH88tUHHQxm7VEYDOd71/LBV6iGHooZsfe4QlUpu+eEPR3z/Y93Jb8OOcX NWhoDj+BTGOUcWW/+sKQ==
Received: by 10.100.207.8 with SMTP id e8mr12513201ang.158.1317640289645; Mon, 03 Oct 2011 04:11:29 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.100.207.8 with SMTP id e8mr12513191ang.158.1317640289484; Mon, 03 Oct 2011 04:11:29 -0700 (PDT)
Received: by 10.100.166.9 with HTTP; Mon, 3 Oct 2011 04:11:29 -0700 (PDT)
In-Reply-To: <DBB1DC060375D147AC43F310AD987DCC36AE894DEB@ESESSCMS0366.eemea.ericsson.se>
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> <CAOhzyf=c5+X+ScgV5CXkJJVM_ev1Hog7QP9FBCeA67z-R=oOcg@mail.gmail.com> <DBB1DC060375D147AC43F310AD987DCC36AE894DEB@ESESSCMS0366.eemea.ericsson.se>
Date: Mon, 3 Oct 2011 13:11:29 +0200
Message-ID: <CAOhzyf=YVC-GFL9jzRsOgTrSvk0d27L+o9rw5Ha4Hx2-deqPKQ@mail.gmail.com>
From: Henrik Lundin <hlundin@google.com>
To: Ingemar Johansson S <ingemar.s.johansson@ericsson.com>
Content-Type: multipart/alternative; boundary=001636b431ef657e7b04ae6309bf
X-System-Of-Record: true
Cc: Randell Jesup <randell-ietf@jesup.org>, "rtcweb@ietf.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 11:08:38 -0000

On Mon, Oct 3, 2011 at 12:55 PM, Ingemar Johansson S <
ingemar.s.johansson@ericsson.com> wrote:

> **
> Hi
>
> I guess one thing that should be considered is that a mobile user may make
> handover between different radio access types with large differences in
> terms of e.g throughput. You may have scenarios such as handover from LTE to
> GPRS or perhaps you have handover from WiFi to HSPA if a user walks away
> from a café. I would expect that these scenarios will become very common in
> the future. It is also worth mention that handover between  WiFi and 3GPP is
> standardized in 3GPP, which in practice means that this will ultimately
> happen without end user interaction. What the endpoints will notice is
> potentially a large and sudden change in throughput.
>
> In cases like these thoughput may drop rapidly. Of course you can sense
> this with the outlined algoritms that signals feedback only when needed but
> that assumes that you receive packets that you can infer enough statistics
> on. Problem is that on the receiver side don't really know that you are
> about to receive a packet.
> With ACK-clocked algorithms like TCP and TFWC the sender simply stops
> sending packets when ACK's are not received anymore. Receiver based algos
> are a bit more complicated as the risk is higher that the sender will
> continue to send packets for some time even though the channel throughput
> has dropped considerably, resulting in excessive congestion somewhere along
> the path.
>
> Is this a problem ?. I don't know, I guess time will tell.
>
I guess it is a problem.


>
> /Ingemar
>
>  ------------------------------
> *From:* Henrik Lundin [mailto:hlundin@google.com]
> *Sent:* den 3 oktober 2011 10:13
> *To:* Jim Gettys
> *Cc:* Randell Jesup; rtcweb@ietf.org
> *Subject:* Re: [rtcweb] An input for discussing congestion control (Fwd:
> New Version Notification for draft-alvestrand-rtcweb-congestion-00.txt)
>
> 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 <%2B46%2070%20646%2013%2041>
>
>
>


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