[R-C] [Iccrg] draft-alvestrand-rtcweb-congestion-01 - A Google Congestion Control Algorithm for Real-Time Communication on the World Wide Web

[Randell Jesup]

On 11/8/2011 5:38 AM, Henrik Lundin wrote:
> On Mon, Nov 7, 2011 at 2:58 AM, Wesley Eddy <wes at mti-systems.com
> <mailto:wes at mti-systems.com>> wrote:
>
>     On 11/1/2011 10:34 AM, Lars Eggert wrote:
>     (3)
>     In the definition of w(i), do you also intend to account for other
>     sources of delays in the end systems' software?  Why do we think that
>     white noise is the right model?  This seems like a big assumption,
>     unless there's actually data that shows it holds under a very wide
>     range of settings.
>
> [HL] I'm quite sure that additive Gaussian white noise it *not* the
> right model. However, as usual in signal processing, there are two
> reasons to make the AWGN assumption: (1) we do not know any better
> model, and (2) it results in tractable formulas. Formally, you would
> have to re-derive the Kalman filter equations based on a new noise
> assumption. If we are not in the business of re-deriving the Kalman
> filter, the assumption has no practical meaning, since we'll apply the
> same filter equations anyway.

Right - it's very likely closer to a power-law tail than a Gaussian one, 
and I'm sure it's also somewhat nodal/discrete and not fully smooth, 
depending on the source.  All of which is of relatively minor importance 
in practice, I believe.


>     (5)
>     The algorithm at the receiver side is clueless about packet losses,
>     and seems like it would see them only when the loss period ends (when
>     a packet survives) and then would see them as really long inter-arrival
>     times rather than losses?  (or did I miss something really important?)
>
> [HL] Yes, you cannot detect a packet loss until you see the gap in
> between two other packets. (Not even then you can be sure it's a loss;
> it may be a re-ordering.) If a frame is lost, the Kalman filter will be
> updated with the inter-arrival time and timestamp delta between the
> frames that actually did arrive. In that respect, the filter does not
> discriminate between losses and frames willfully dropped by the sender
> before encoding.

Right - packet losses should be dealt with separately in the algorithm. 
  Normally you can't tell if a loss is a congestion loss, or (for 
example) a WiFi-induced loss, or simply a very late packet.  Note that 
for filter updates we may want to update it with data from packets too 
late to be played (jitter buffer underflowed), but still arrived within 
X of when they "should" have arrived.

>     (6)
>     The rules about 2% and 10% in the sender-side algorithm seem ... odd.
>     Unless the report interval is sufficiently long in relation to the frame
>     rate, the percentages may not work well.  These parameters have to be
>     balanced, or the algorithm will be fragile.
>
> [HL] Quite likely, yes.

At minimum we need to define what 2% and 10% are measured over, and how 
the sender knows (RR reports I assume).

I gave some detailed comments about some of this earlier; check the 
archives of the R-C list.

>     (7)
>     Shouldn't the sender estimate of available bandwidth be able to go lower
>     than the TFRC equation output if the delay has been increasing (though
>     packets are not yet being lost)?
>
> [HL] "In words: The sender-side estimate will never be larger than
> the receiver-side estimate, and will never be lower than the
> estimate from the TFRC formula." I see now that this wording is *wrong*.
> It should say something like:
> "The sender-side estimate will never be larger than the receiver-side
> estimate. A reduction of the sender-side estimate triggered by loss and
> RTT reports will never result in an estimate lower than that from the
> TFRC formula." We expect the receiver-side to be much faster in response
> time -- simply because it is delay sensing, and not loss sensing as the
> sender-side -- and therefore the receive-side estimate will limit the
> send-side estimate in most cases. The send-side can be seen as a slave
> in that case. The send-side estimate is mostly there to provide a
> fall-back option in the case of no feedback from the receiver.

We may not need a fallback for webrtc when talking to another webrtc 
client.  When talking to non-webrtc, we might need one.

>     (8)
>     Startup is a big topic that isn't yet addressed.
>
> [HL] Yes, it is, but I'm not sure it should be stipulated in this
> document. The application will probably have a lot to say about this.
> For instance, it can know something about previous calls, and it can
> also implement some kind of pre-probing algorithm.

Agreed - the algorithm should adapt no matter the starting point (and 
really must) - though we can recommend practices to avoid slow 
convergence (up or down).

-- 
Randell Jesup
randell-ietf at jesup.org