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

From: Harald Alvestrand <[email-masked]>
Date: Mon, 05 Sep 2011 12:09:01 +0200

There is a congestion control algorithm inside the Google WebRTC 
codebase that hasn't been documented publicly before, and might be 
interesting as input when we get around to discussing what congestion 
control should be mandatory-to-implement in this group.

It's not forwarded as a candidate for what the result should be; I think 
there can be better solutions (see the "further work" section in this 
draft).

The code is available through www.webrtc.org,  and the IPR statements 
covering the code are found here: 
https://sites.google.com/site/webrtc/license-rights

                     Harald

-------- Original Message --------
Subject: 	New Version Notification for 
draft-alvestrand-rtcweb-congestion-00.txt
Date: 	Mon, 05 Sep 2011 03:03:38 -0700
From: 	[email-masked]
To: 	[email-masked]
CC: 	[email-masked], [email-masked]

A new version of I-D, draft-alvestrand-rtcweb-congestion-00.txt has been successfully submitted by Harald Alvestrand and posted to the IETF repository.

Filename:	 draft-alvestrand-rtcweb-congestion
Revision:	 00
Title:		 A Google Congestion Control for Real-Time Communication on the World Wide Web
Creation date:	 2011-09-05
WG ID:		 Individual Submission
Number of pages: 14

Abstract:
    This document describes two methods of congestion control when using
    real-time communications on the World Wide Web (RTCWEB); one sender-
    based and one receiver-based.

    It is published to aid the discussion on mandatory-to-implement flow
    control for RTCWEB applications; initial discussion is expected in
    the RTCWEB WG&#39;s mailing list.

The IETF Secretariat

---

From: Randell Jesup <[email-masked]>
Date: Tue, 06 Sep 2011 18:21:42 -0400

> control should be mandatory-to-implement in this group.

Where is this in the webrtc drop?  I looked but didn't see anything 
hooked up to RTPReceiverVideo::EstimateBandwidth().  There's something 
in this genre for iSAC, though I didn't have time to look closely but it 
appears to be somewhat specialized for iSAC.

>
> It's not forwarded as a candidate for what the result should be; I 
> think there can be better solutions (see the "further work" section in 
> this draft).

Harald et al: this definitely answers my suggestion/request that we make 
congestion control mandatory, and that we target something similar to 
Radvision's NetSense, which this appears to have similar characteristics to.

A few comments:

In 3. (Receiver-side):

    When an over-use is detected the system transitions to the decrease
    state, where the available bandwidth estimate is decreased to a
    factor times the currently incoming bit rate.

      A_hat(i) = alpha*R_hat(i)

    alpha is typically chosen to be in the interval [0.8, 0.95].

May I suggest that there's more information available here than a single 
bit of "over-bandwidth".  We have an estimate here how *much* we're 
over-bandwidth, though cross-traffic and other fixed streams (audio) are 
part of that too, so it needs to be used with a grain of salt - but that 
slope is useful information.

    In either case we want to
    measure the highest incoming rate during the under-use interval:

      R_max = max{R_hat(i)} for i in 1..K

    where K is the number of frames of under-use before returning to the
    normal state.  R_max is a measure of the actual bandwidth available
    and is a good guess of what bit rate we should be able to transmit
    at.  Therefore the available bandwidth will be set to Rmax when we
    transition from the hold state to the increase state.

This is good, but it might make sense to explain why this is the case 
(as the draft does for other parts); I assume the argument is that if 
the delay is reducing after a bottleneck, then from the router that was 
buffering to us (usually just on the far end of the bottleneck) packets 
are flowing through from there as fast as they can.

In fact, the rate they're getting through *while* you're over-bandwidth 
is actually the best estimate of total bandwidth you're likely to get.  
So in fact you can estimate it well in all cases except when you're in 
"increase" mode (buffers drained and stable), pretty much.

I would also suggest that the rate to use is R_max * gamma (where gamma 
< 1.0)

BTW, the description of directions here is confusing; the receiver is 
determining the apparent bandwidth the sender should be using; "we 
should be able to transmit at" is both wrong and confusing (probably 
should be "the sender should be able to transmit at").

Sender-side control:  10% seems rather high.  My experience was more 
aggressive in the face of loss, both in the limit at which it reacts and 
the amount it reduces - over maybe 5% loss I would cut sender bandwidth 
by 10 or 15% on top of whatever the slope told me to do.

Interop -  the receiver could incorporate packet loss into the estimate 
used for TMMBR, which might improve talking to senders who don't follow 
this algorithm.  We should consider how to handle cases that involve 
interop and if and how to detect them; the algorithm may want to be 
different for those cases.

Future:
We very much want to merge all the info we can from all the streams, so 
we can control where the bandwidth restrictions are applied instead of 
running it on N streams independently.  (For example, if we're sending 
two video streams we may want to apportion the bandwidth according to 
their size/framerate instead of equally, and we'll very much want to 
consider for data channels (and perhaps media) a 'priority' factor ala 
RTFMP.)

I'll have more comments, but I need to turn into a pumpkin now and 
wanted to get what I have on the wire.  I haven't spent a lot of time 
fleshing them out or editing, so take them as a starting point for 
discussion.

-- 
Randell Jesup
[email-masked]

---

From: Harald Alvestrand <[email-masked]>
Date: Wed, 07 Sep 2011 11:03:04 +0200

> https://sites.google.com/site/webrtc/license-rights
Slightly offtopic, but I got a question about where the code is found in 
the repository ... here are the most important links:

http://code.google.com/p/webrtc/source/browse/trunk/src/modules/rtp_rtcp/source/bandwidth_management.h 
<http://code.google.com/p/webrtc/source/browse/trunk/src/modules/rtp_rtcp/source/bandwidth_management.h>
http://code.google.com/p/webrtc/source/browse/trunk/src/modules/rtp_rtcp/source/bandwidth_management.cc 
<http://code.google.com/p/webrtc/source/browse/trunk/src/modules/rtp_rtcp/source/bandwidth_management.cc> 

http://code.google.com/p/webrtc/source/browse/trunk/src/modules/rtp_rtcp/source/overuse_detector.h 
<http://code.google.com/p/webrtc/source/browse/trunk/src/modules/rtp_rtcp/source/overuse_detector.h>
http://code.google.com/p/webrtc/source/browse/trunk/src/modules/rtp_rtcp/source/overuse_detector.cc 
<http://code.google.com/p/webrtc/source/browse/trunk/src/modules/rtp_rtcp/source/overuse_detector.cc>
http://code.google.com/p/webrtc/source/browse/trunk/src/modules/rtp_rtcp/source/remote_rate_control.h 
<http://code.google.com/p/webrtc/source/browse/trunk/src/modules/rtp_rtcp/source/remote_rate_control.h>
http://code.google.com/p/webrtc/source/browse/trunk/src/modules/rtp_rtcp/source/remote_rate_control.cc 
<http://code.google.com/p/webrtc/source/browse/trunk/src/modules/rtp_rtcp/source/remote_rate_control.cc>
http://code.google.com/p/webrtc/source/browse/trunk/src/modules/rtp_rtcp/source/Bitrate.h 
<http://code.google.com/p/webrtc/source/browse/trunk/src/modules/rtp_rtcp/source/Bitrate.h>
http://code.google.com/p/webrtc/source/browse/trunk/src/modules/rtp_rtcp/source/bitrate.cc 
<http://code.google.com/p/webrtc/source/browse/trunk/src/modules/rtp_rtcp/source/bitrate.cc>

Enjoy!

---

From: Magnus Westerlund <[email-masked]>
Date: Fri, 16 Sep 2011 15:26:33 +0200

Hi,

As an Individual I do have a few comments and question on this document
and its algorithm.

1. Section 3: As delay based congestion control has been tried a number
of times and meet with less than stellar success I wonder if you have
any understanding of how this relates to the issues previously encountered:

- Stability (especially on short RTTs)
- How it competes with TCP flows, which was a real issues for TCP Vegas
but may be less of an issue here.

2. Section 3, I don't see any discussion of the startup issue. Is my
assumption correct, that you will simply start at some rate and then
adapt from that?

3. Section 3, I guess this mechanism would get significant issues with
any sender side transmission filtering. Burst transmitting I-frames over
a network, especially for high resolution video can easily result in
packet loss in switch fabrics if there is any cross traffic in the
switch fabric. Thus having a bit of send filtering for frame
transmission is a good idea. Are I understanding it correctly that this
could result in over-use indication if I has such mechanism which
filters a packet to a slower transmission rate than what a single or
small burst can achieve over the same path?

4. Section 4.

"This algorithm is run every time a receive report arrives at the
   sender, which will happen [[how often do we expect? and why?]].  If
   no receive report is recieved within [[what timeout?]], the algorithm
   will take action as if all packets in the interval have been lost.
   [[does that make sense?]]"

The transmission of receiver reports is highly dependent on RTP profile,
the RTCP bandwidth, trr-int parameter and any feedback events.

If I start with assuming AVPF which seems reasonable in most browser to
browser case with our current proposals for RTP support. Then if there
are no feedback events the transmission of receiver reports will occur
as often as the bandwidth allows, but no more often than the value of
trr-int parameter.

Here is might be worth mentioning that I do expect trr-int to be set to
avoid RTCP reporting to often due to the relatively high RTCP bandwidth
values that will be set due to the multiplexing of audio and video in a
single RTP session. Thus avoiding that RTCP rates are as high or larger
than the audio streams they report in steady state.

When feedback events occur the stack will have the choice of sending a
RTCP RR, that is a choice provided due to the reduced size RTCP
specification included. But if the loss cumulative count diff is
non-zero it might be worth mandating that the RR/SR is included in any
such feedback RTCP packet.

For that reason causing a feedback event when there is losses and
schedule them using the early algorithm may be a good choice to ensure
timely reporting of any loss.

If one uses AVP then the RTCP timing rules will give you when you
transmit RTCP feeedback and thus the parameterization becomes central
here. A clear issue is if people uses the minimal interval of 5 seconds
or the 360/Session_BW(in kbps). I would note that 5 seconds is very long
in adaptation situations.

I think the timeout should be based on the RTT and possible reporting
rate. But there clearly need to be some upper limit, either explicitly
or mandating RTCP bandwidth rates.

5. Section 4:
"We motivate the packet loss thresholds by noting that if we have
   small amount of packet losses due to over-use, that amount will soon
   increase if we don't adjust our bit rate.  Therefore we will soon
   enough reach above the 10 % threshold and adjust As(i).  However if
   the packet loss rate does not increase, the losses are probably not
   related to self-induced channel over-use and therefore we should not
   react on them."

I am personally worried that a packet loss threshold of 10% is so high
that it might push a lot of other traffic out of the way. Thus being
quite aggressive towards other flows.

TCP has this relation between the average packet loss rate and the
highest sustainable rate which can be interpreted as TCP gets more
sensitive to loss the higher the average data rate becomes. Thus in
certain situation the sender side algorithm part will be extremely
aggressive in pushing TCP out of the way. The receiver part may
compensate for this pretty well in a number of situations.

But, I do wonder why for example the A(i) isn't bounded to be between
TFRC's rate and some multiple of TFRC rate, not unbounded by other than
the receiver side algorithm.

I do understand this document is to start a discussion. But I think we
need to be sensitive to that it is difficult to get even something that
is self-fair over the wide range of conditions the Internet has to provide.

Thus I would appreciate what issues with for example TFRC that you
attempt to fix with the various new components you add.

Cheers

Magnus Westerlund

----------------------------------------------------------------------
Multimedia Technologies, Ericsson Research EAB/TVM
----------------------------------------------------------------------
Ericsson AB                | Phone  +46 10 7148287
Färögatan 6                | Mobile +46 73 0949079
SE-164 80 Stockholm, Sweden| mailto: [email-masked]
----------------------------------------------------------------------

---

From: Randell Jesup <[email-masked]>
Date: Sun, 18 Sep 2011 18:10:20 -0400

> As an Individual I do have a few comments and question on this document
As said on the call, I'm going to work with Harald (and Justin, and anyone
else interested) to provide requirements and likely a suggested algorithm.
At this point, I believe we'll specify the mechanism for telling the other
side the apparent bandwidth, but leave the algorithm for finding that out
open for innovation.  I plan to propose a baseline algorithm.  On the sender
side, I expect to optionally involve the application in deciding how the
bits are allocated among the channels, and the option to add or remove
channels based on bandwidth.  I expect that we will mandate that if the
application doesn't choose, the rtcweb/webrtc code will.  This is all still
to be hammered out; anyone else interested in helping write the draft
requirements let me know.

> any understanding of how this relates to the issues previously encountered:
Do you have any pointers to these earlier attempts?  My separate experience
with this class has been extremely successful, though perhaps with a set of
real-world use-cases that don't cover the situations you're referring to.
My understanding is that Radvision's NetSense is very similar from their
description of it.

> but may be less of an issue here.
Perhaps Google can comment here about what tests they've done.  If anything,
this class of algorithm when faced with aggressive TCP flows will eventually
have problems, because TCP will tend to fill up the buffers at the bottleneck.
Since this algorithm senses buffers starting to fill up, it will tend to back
off before TCP is likely to see a loss event.  Now, it's more complex than
that of course, and multiple flows make it more complex still.  It's also
sensitive to the adaptation rate of this algorithm and speed of backoff.
If I remember, TFRC tends to back off more slowly than TCP but also increase
more slowly; I suspect Google's algorithm is similar.

Web Browser traffic can be especially aggressive at filling large buffers at
a bottleneck router, and will become more so as the initial window of 10
rolls out.

> assumption correct, that you will simply start at some rate and then
Startup is an open question; you have to start somewhere, and there's
no way to always get the start "right".  History of previous sessions may
be useful here; it's theoretically possible to use perhaps some of the
ICE negotiation for a first-level guess or we could send an initial packet
train and measure dispersion.  But that's just speculation; history can be
very wrong if you've changed networks or the other person has a very different
network than the last call (or last call with that person).  I'm not sure if
we should mandate something here, or use something more open to encourage
innovation.

> small burst can achieve over the same path?
Well, such send filtering amounts to a bottleneck in practice at the sending
node, so that actually might be ok.  I'm assuming you're talking about pacing
the actual send()s of large dumps of fragmented IDRs/i-frames to some
maximum packet rate or bitrate (almost the same thing).  I think the algorithm
looks at all the fragments and the time they came in to calculate the bandwidth.
If so, it would only think it was over-bandwidth if the pacing slowed them down
to less than the actual bottleneck rate; I suspect this would rarely be the case
outside of high-bandwidth LANs at very high resolutions.

> than the audio streams they report in steady state.
Agreed.  This is where my plans to suggest a baseline algorithm that melds
the reception data of all the streams in the PeerConnection may be a
significant advantage over doing bandwidth estimation on each stream
independently.  We'll see if I can make the idea work, but there are some
significant advantages if it does.  If not, we can estimate in each channel
independently as per the Google algorithm.

You can also use rtcp-fb PLI/etc events to hang these reports off of, increasing
the frequency they get through with minimal extra bandwidth use.

> such feedback RTCP packet.
Exactly - or a TMMBR with the results of the receiver-side bandwidth
calculations.

> in adaptation situations.

Yes.

> quite aggressive towards other flows.
Yes; I want to visit these tuning parameters and how packet loss is
reacted to and at least tweak it.

> the receiver side algorithm.
Good question; we should look into it.

> attempt to fix with the various new components you add.
Magnus: Welcome to my little congestion-control bof... :-)

-- 
Randell Jesup
[email-masked]

---

From: Stefan Holmer <[email-masked]>
Date: Mon, 19 Sep 2011 09:06:15 +0200

> My understanding is that Radvision's NetSense is very similar from their
I'm interested in any references you may have as well.

> more slowly; I suspect Google's algorithm is similar.

As you're saying, it will always be hard for delay based congestion control
algorithms to compete with a packet loss based algorithm. The delay based
algorithm will detect over-use much earlier than the packet loss based one,
and that's basically what we've seen in the tests we've been running as
well. I do think we would benefit from more tests in this area. For
instance, we might want to go with an additive increase approach rather than
the current one which is multiplicative, this would likely help improve the
algorithms self fairness as well.

> Good question; we should look into it.
The idea behind those bounds is that if we believe in the TFRC equation, we
should be able to transmit with that rate while still being fair to TCP.

> Magnus: Welcome to my little congestion-control bof... :-)
I'm interested in continued discussions as well.

> --
> Randell Jesup
> [email-masked]
>
>
> ______________________________**_________________
> rtcweb mailing list
> [email-masked]
> https://www.ietf.org/mailman/**listinfo/rtcweb<https://www.ietf.org/mailman/listinfo/rtcweb>
>

---

From: Randell Jesup <[email-masked]>
Date: Mon, 19 Sep 2011 03:54:44 -0400

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.

On 9/19/2011 3:06 AM, Stefan Holmer wrote:
> On Mon, Sep 19, 2011 at 12:10 AM, Randell Jesup 
> <[email-masked] <mailto:[email-masked]>> wrote:
>

I doubt you'll find many/any, as the first published discussion I saw of 
delay-sensing
congestion control for RTP data was Radvision's posts about Netsense 
last year
and in their Android webcasts; and  that was pretty detail-free until 
their recent
blog posts.  There's plenty of un-published experience with them at 
various companies
I believe....  Not just Google and Radvision.

> As you're saying, it will always be hard for delay based congestion 
> control algorithms to compete with a packet loss based algorithm. The 
> delay based algorithm will detect over-use much earlier than the 
> packet loss based one, and that's basically what we've seen in the 
> tests we've been running as well. I do think we would benefit from 
> more tests in this area. For instance, we might want to go with an 
> additive increase approach rather than the current one which is 
> multiplicative, this would likely help improve the algorithms self 
> fairness as well.

Probably; additive increase is probably better, or possible using a 
fraction-of-
predicted-bandwidth increase.  If you use additive increase, it should 
probably be
partly proportional to the maximum "good" bandwidth seen during the 
connection.
This provides some needed scaling of the ramp-up rate to the absolute 
magnitude
of bandwidth available.

-- 
Randell Jesup
[email-masked]

---

From: Henrik Lundin <[email-masked]>
Date: Mon, 19 Sep 2011 10:04:47 +0200

Add me to the bof members list.

/Henrik L

On Mon, Sep 19, 2011 at 9:54 AM, Randell Jesup <[email-masked]>wrote:

> made me think I should ask for opinions on this.  Given the structure, if
> there's
> get pretty long and detailed without really touching on the larger issues
> being
> discussed here.
>
> congestion control for RTP data was Radvision's posts about Netsense last
> year
> and in their Android webcasts; and  that was pretty detail-free until their
> recent
> blog posts.  There's plenty of un-published experience with them at various
> companies
> control algorithms to compete with a packet loss based algorithm. The delay
> based algorithm will detect over-use much earlier than the packet loss based
> one, and that's basically what we've seen in the tests we've been running as
> Randell [email-masked]
>
>
> _______________________________________________
> rtcweb mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/rtcweb
>
>

-- 
Henrik Lundin | WebRTC Software Eng | [email-masked] | +46 70 646 13 41

---

From: Varun Singh <[email-masked]>
Date: Mon, 19 Sep 2011 11:08:09 +0300

I'd be interested in this as well.

Regards,
Varun

----
http://www.netlab.tkk.fi/~varun

On 19.9.2011, at 11.04, Henrik Lundin <[email-masked]> wrote:

/Henrik L

---

From: Henrik Lundin <[email-masked]>
Date: Mon, 19 Sep 2011 10:12:39 +0200

A few comments on the nitty-gritty details inline.

/Henrik

On Mon, Sep 19, 2011 at 9:06 AM, Stefan Holmer <[email-masked]> wrote:

> Yes, the algorithm looks at the arrival of complete frames. And you are
right, Randell, as long as you do not spread the packets more than the
bottleneck link does, the over-use detector won't trigger.

> In the proposed algorithm, the RTCP interval adds to the system response
time. The response time governs the bandwidth increase rate so that the step
into over-use will have a limited delay build-up before it can be detected
and mitigated. Thus, a long RTCP interval results in a slow adaptation, but
it should still be stable.

---

From: Tim Panton <[email-masked]>
Date: Mon, 19 Sep 2011 09:21:22 +0100

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

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.

---

From: Henrik Lundin <[email-masked]>
Date: Mon, 19 Sep 2011 10:29:03 +0200

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

---

From: Varun Singh <[email-masked]>
Date: Mon, 19 Sep 2011 16:15:10 +0300

Hi,

> while maintaining an acceptable quality for the use-case at hand.

I would agree that the sending application+codec should decide what
trade-off it wants to make, if any. However, it should still be open
to discussion if the congestion control is a sender driven (e.g. TFRC)
or receiver driven (e.g. TMMBR) or a combination of sender and
receiver driven.

-- 
http://www.netlab.tkk.fi/~varun/

---

From: Randell Jesup <[email-masked]>
Date: Mon, 19 Sep 2011 09:16:03 -0400

On 9/19/2011 4:29 AM, Henrik Lundin wrote:
> 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.

Right - I think we're in agreement (and Tim is) that this is the best 
tack to take on the problem - involve the application in figuring out 
how to meet the bandwidth limits.  This part of it will largely be an 
API specification problem; figuring out how to set up the API to tell 
the JS app what is available, and the interfaces for responding to that.

>
> On Mon, Sep 19, 2011 at 10:21 AM, Tim Panton <[email-masked] 
> <mailto:[email-masked]>> wrote:
>
>

Absolutely agree.

>     of the video.

I'm a little confused by that wording, but I suspect we agree.  The app 
might want ask the senders to cut their framerate or cut their 
resolution, or cut quality but keep framerate & resolution, or ask the 
senders to switch to lower-bandwidth parameters unless the VAD decides 
the person is talking, etc.  No one answer is the 'right' one for every 
app or situation.

>     I might even want to drop all the video but keep the audio and
>     screenshare alive.
>

Exactly.

>     But in _both_ cases I'd like the app to try and tweak the encoder
>     params to get within the available bandwidth

-- 
Randell Jesup
[email-masked]

---

From: Soo-Hyun Choi <[email-masked]>
Date: Tue, 20 Sep 2011 14:37:43 +0900

A question and a suggestion.

> it should still be stable.

I wonder how would you guarantee that such a long RTCP interval
doesn't result in instability when estimating bandwidth? Typically, a
delay-based CC algorithm can be vulnerable when timer become
inacurate. I suspect the delayed RTCP feedback can calculate available
bandwidth correctly. Why not use per-packet based feedback (using
AVPF, for example) in order not to cause any harm with this kind of
situation?

I would think that a CC mechanism, at least, should be able to
calculate and suggest right/correct rate to the upper layer's codec so
that it could determine whether it actually increase/decrease encoding
rate or not, depending upon CC's suggested rate.

Kind regards,
Soo-Hyun

---

From: Henrik Lundin <[email-masked]>
Date: Tue, 20 Sep 2011 07:58:49 +0200

> AVPF, for example) in order not to cause any harm with this kind of
I agree that more frequent feedback does improve the bandwidth estimation.
No doubt about that.

---

From: Soo-Hyun Choi <[email-masked]>
Date: Tue, 20 Sep 2011 16:07:35 +0900

> I agree that more frequent feedback does improve the bandwidth estimation.

Well, the problem of the inaccurate feedback timer is that it could
make the whole things go wrong.

I.e., Inaccurate BW estimation could lead into providing inaccurate
information about the available BW to the upper layer, which
eventually result in instability at the codec's encoding rate.

Wouldn't we need to be a little more careful on choosing/designing CC
algos, which I believe we are capable of?

Kind regards,
Soo-Hyun

---

From: Harald Alvestrand <[email-masked]>
Date: Tue, 20 Sep 2011 13:47:34 +0200

> algos, which I believe we are capable of?
One prayer....

let's avoid unquantifiable terms in our discussions. "A little more 
careful" is an unquantifiable term.

If we want to say "I think the algorithm must guarantee that the 
bandwidth estimate is updated within 1.5 seconds when the available 
bandwidth changes from 2 Mbit/sec to 1 Mbit/sec", let's say something 
like that - focus on what the requirements are.

We can always be a little more careful. But it doesn't tell us when 
we're close enough.

              Harald

---

From: Soo-Hyun Choi <[email-masked]>
Date: Tue, 20 Sep 2011 21:36:24 +0900

Harald,

On Tue, Sep 20, 2011 at 20:47, Harald Alvestrand <[email-masked]> wrote:
>
> let's avoid unquantifiable terms in our discussions. "A little more careful"
> is an unquantifiable term.
>
> If we want to say "I think the algorithm must guarantee that the bandwidth
> estimate is updated within 1.5 seconds when the available bandwidth changes
> from 2 Mbit/sec to 1 Mbit/sec", let's say something like that - focus on
> what the requirements are.
>
> We can always be a little more careful. But it doesn't tell us when we're
> close enough.
>

Sorry if my previous email looked that way to you (of course, I didn't
mean to just pray for the mere hope). I was talking about some general
CC principles in the high level for real-time interactive multimedia
applications, like some of us did too in this thread.

One of the critical metrics of a delay-based CC algo is an accurate
measurement of inter-packet interval (IPI) and timely report of IPI to
the sender so it can update the send rate correctly, which we all
agreed in this email thread. Although everyone in this list seemed to
aware of this, I have highlighted again that the relatively
course-grained RTCP carrying the IPI measurement data can cause
instability at the encoder's output bitrate due to the following
reason.

> eventually result in instability at the codec's encoding rate.

So, my original question/suggestion was why not use AVPF (which is
smaller packet than the standard RTCP) to generate/report more
frequently to the sender in your algorithm. Or alternatively, I have
already designed a window-version's of TFRC that re-introduces a
TCP-like Ack-clocking, so-called TFWC (TCP-Friendly Window-based CC),
which performs reasonably well (as good as TFRC) for the similar
situations (RTC environment).

I would like to ask to this list (or Harald) if suggesting alternative
CC algo idea could fit into the RTCWEB Charter's scope - if so, I
could elaborate more by writing an I-D or so. In the mean time, you
could check my document at http://tfwc.hackerslab.eu/ if you are
interested.

Kind regards,
Soo-Hyun

---

From: Harald Alvestrand <[email-masked]>
Date: Tue, 20 Sep 2011 14:44:12 +0200

On 09/20/11 14:36, Soo-Hyun Choi wrote:
> Harald,
>
> On Tue, Sep 20, 2011 at 20:47, Harald Alvestrand<[email-masked]>  wrote:
Sorry, not intended to point at anyone in particular - I have been 
worried about several conversations that seemed to be straying very far 
from the "brass tacks" here.
> instability at the encoder's output bitrate due to the following
The draft's suggestion is to avoid the need for communicating all the 
IPI information from the receiver to the sender by doing part of the 
processing and estimation at the receiver. I think we need to send the 
resulting information quickly when it changes, but don't need to send it 
so often when it remains stable. What "quickly" means in this context is 
a good question - 0.1 second? 1 second? Certainly less than 5 seconds?
> could check my document at http://tfwc.hackerslab.eu/ if you are
I am certainly looking for input on where we can best have this 
discussion, too!
Algorithm design is outside of RTCWEB's charter, but I think 
requirements/criteria for what "good enough" means for RTCWEB is inside it.

---

From: Dzonatas Sol <[email-masked]>
Date: Tue, 20 Sep 2011 08:35:17 -0700

On 09/20/2011 05:44 AM, Harald Alvestrand wrote:
>>> bandwidth
>>> we're
> worried about several conversations that seemed to be straying very 
> far from the "brass tacks" here.
> resulting information quickly when it changes, but don't need to send 
> it so often when it remains stable. What "quickly" means in this 
> context is a good question - 0.1 second? 1 second? Certainly less than 
> 5 seconds?

In the context of RTCWEB, I have constrained the meaning of quick to an 
ICE path. Or, any information known *before* the duration of any session 
is "quick", yet that does not include any actual connection delay.

-- 

---
<i>The wheel.</i metro-link=t dzonatasolyndra>

---

From: Randell Jesup <[email-masked]>
Date: Tue, 20 Sep 2011 11:51:52 -0400

On 9/20/2011 8:44 AM, Harald Alvestrand wrote:
> On 09/20/11 14:36, Soo-Hyun Choi wrote: One of the critical metrics of 
> a delay-based CC algo is an accurate

I agree with Harald here; the entire algorithm doesn't need to run on 
the sender side alone.  An RFC can contain algorithms for calculating 
values (see RTCP jitter for an example), but I think here we want to 
make sure that the mechanisms we provide allow things to work when the 
implementations at the send and receive side are different.  For 
example, for the classic one-stream CC model like Google/GIPS's 
algorithm their use of TMMBR - it should work with anyone supporting 
TMMBR.  In our case we may find we need to add a new FB message, since 
the existing ones may not cover what we need to convey (and we probably 
don't want to go the RTCP APP route).  Or we may find it makes most 
sense to use a RTP header extension.  We'll see.

> requirements/criteria for what "good enough" means for RTCWEB is 

Agree (mostly) with Harald there, but I agree we don't want to specify 
the CC algorithm in total.  We may very well want to document a proposed 
baseline algorithm that meets the requirements we lay down in the spec, 
however.

-- 
Randell Jesup
[email-masked]

---

From: Soo-Hyun Choi <[email-masked]>
Date: Wed, 21 Sep 2011 16:59:15 +0900

Harald,

> The draft's suggestion is to avoid the need for communicating all the IPI
> information from the receiver to the sender by doing part of the processing
> and estimation at the receiver. I think we need to send the resulting
> information quickly when it changes, but don't need to send it so often when
> it remains stable. What "quickly" means in this context is a good question -
> 0.1 second? 1 second? Certainly less than 5 seconds?

Sure - one may not need to send the receiver report every so often
when network is stable. But the question is "how long stable is
stable?". Perhaps, the definition of "stable" might fall into
unquantifiable term, too? Anyway, when I said "quickly", I meant "at
least once in an every RTT" (borrowing from the TCP SACK analogy), in
which the use of the standard RTCP RR is not suitable in this level of
granularity.

> I am certainly looking for input on where we can best have this discussion,
> too!

Question: Isn't your draft also proposing a new CC mechanism in the
context of RTCWEB?

Kind regards,
Soo-Hyun

---

From: Harald Alvestrand <[email-masked]>
Date: Wed, 21 Sep 2011 10:23:28 +0200

> which the use of the standard RTCP RR is not suitable in this level of
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.
> Question: Isn't your draft also proposing a new CC mechanism in the
No, to quote from the draft:

    It is published to aid the discussion on mandatory-to-implement flow
    control for RTCWEB applications; initial discussion is expected in
    the RTCWEB WG's mailing list.

It's describing an algorithm that already exists outside of the IETF. It 
seems to have succeeded in stimulating the discussion.
If the conclusion of the discussion is that something along these lines 
should be standardized, I hope the ADs and chairs of the IETF can give 
us guidance on where the discussion of this standardization should take 
place.

---

From: Randell Jesup <[email-masked]>
Date: Wed, 21 Sep 2011 09:28:56 -0400

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

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.

-- 
Randell Jesup
[email-masked]

---

From: Jim Gettys <[email-masked]>
Date: Wed, 21 Sep 2011 09:43:50 -0400

On 09/21/2011 09:28 AM, Randell Jesup wrote:
> 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

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

> a TCP header extension or design an RTP equivalent that can carry it
> in the reverse-direction
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.