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

Ingemar Johansson S <> Mon, 03 October 2011 10:53 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 58D2121F8B24 for <>; Mon, 3 Oct 2011 03:53:21 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -5.043
X-Spam-Status: No, score=-5.043 tagged_above=-999 required=5 tests=[AWL=0.671, BAYES_00=-2.599, HTML_FONT_FACE_BAD=0.884, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id pckC7aSwl7oF for <>; Mon, 3 Oct 2011 03:53:17 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 5981D21F8AE9 for <>; Mon, 3 Oct 2011 03:53:12 -0700 (PDT)
X-AuditID: c1b4fb39-b7bfdae000005125-b7-4e8994cd42d8
Received: from (Unknown_Domain []) by (Symantec Mail Security) with SMTP id 1F.58.20773.DC4998E4; Mon, 3 Oct 2011 12:56:13 +0200 (CEST)
Received: from ([]) by ([]) with mapi; Mon, 3 Oct 2011 12:55:11 +0200
From: Ingemar Johansson S <>
To: Henrik Lundin <>, Jim Gettys <>
Date: Mon, 3 Oct 2011 12:55:09 +0200
Thread-Topic: [rtcweb] An input for discussing congestion control (Fwd: New Version Notification for draft-alvestrand-rtcweb-congestion-00.txt)
Thread-Index: AcyBpE2UIRiG7Lx4S3WXU1HWwteK4QAAYQrg
Message-ID: <>
References: <> <> <> <> <> <> <> <> <> <> <> <> <> <> <> <>
In-Reply-To: <>
Accept-Language: sv-SE, en-US
Content-Language: en-US
acceptlanguage: sv-SE, en-US
Content-Type: multipart/alternative; boundary="_000_DBB1DC060375D147AC43F310AD987DCC36AE894DEBESESSCMS0366e_"
MIME-Version: 1.0
X-Brightmail-Tracker: AAAAAA==
Cc: Randell Jesup <>, "" <>
Subject: Re: [rtcweb] An input for discussing congestion control (Fwd: New Version Notification for draft-alvestrand-rtcweb-congestion-00.txt)
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Real-Time Communication in WEB-browsers working group list <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Mon, 03 Oct 2011 10:53:21 -0000


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.


From: Henrik Lundin []
Sent: den 3 oktober 2011 10:13
To: Jim Gettys
Cc: Randell Jesup;
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.


On Wed, Sep 21, 2011 at 3:43 PM, Jim Gettys <<>> 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).

As far as the transient bufferbloat problem caused by web traffic, and why IW10 is a problem in my view at this time, see:

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<>

Henrik Lundin | WebRTC Software Eng |<> | +46 70 646 13 41<tel:%2B46%2070%20646%2013%2041>