[R-C] Comments on draft-alvestrand-rtcweb-congestion-01

[Stefan Holmer]

Hi Michael,

On Wed, Mar 28, 2012 at 1:16 AM, Michael Welzl <michawe at ifi.uio.no> wrote:

> Hi all,
>
> I have read draft-alvestrand-rtcweb-**congestion-01.
>
>
> High-level comments:
>
> Today, this has been called a "strawman proposal". I agree with this way
> of looking at it. There are some quite interesting ideas there; however, a
> lot seems to appear "out of the blue", leaving the reader puzzled about the
> rationale behind some design choices. I wonder if these design choices are
> based on some academic papers out there - could citations help? Anyway,
> instead of trying to discuss the algorithm "in the air", it would be better
> to first work with some data: how does the mechanism really work in a
> real-life system? How does it interact with TCP? How sensitive is this
> mechanism to the typical issues raised for delay-based controls (the
> latecomer unfairness problem, behavior with very small queues, ..)? How
> likely is it for the derived rate of the mechanism to fall below the
> TFRC-function limit, under what conditions will this happen?
>

We are currently working on producing some numbers on performance. It is
very helpful to get suggestions on what kind of measurements and scenarios
are most interesting.


>
> As for the writing style, around the middle of section 3.2 you depart from
> what I would consider a reasonable amount of equations for an RFC. It might
> be better to point to a document where the derivation is given.
>
>
>
> Finer-grain comments:
>
> I got confused by your usage of "frame" - typically, to me, a frame is a
> packet at the link layer, or a picture in a video. Generally I have the
> impression that you use the word "frame" to refer to packets, but then
> towards the end of section 3.2 you talk about "the highest rate at which
> frames have been captured by the camera".  On a side note, that is anyhow
> inappropriate, I guess, as this mechanism shouldn't necessarily be
> restricted to video (could be audio too), right?
>

In the draft a frame refers to a video frame. However, if an extension such
as http://tools.ietf.org/html/rfc5450 is used frames can be substituted for
packets. I agree that the draft shouldn't mention video, as it might as
well act on audio frames.


>
> Same paragraph: "Since our assumption that v(i) should be zero mean WGN is
> less accurate in some cases" => why?
>

Assuming that the jitter has a WGN distribution is a very strong
assumption. For instance there are situations where a frame *i* is queued
up behind another frame *i-1* and in that situation the jitter will not
even be white.


>
> Section 3.1: "Since the time ts to send a frame of size L over a path with
> a capacity C is" => this should at least say "roughly", as it omits a lot
> of (arguably, perhaps irrelevant) factors.
>

Agreed.


> Equation 5: I don't think that m(i) and v(i) have been defined before.
>  (even though it seems obvious what is meant)
>

Probably makes sense to refer to them from the text. E.g., "Breaking out
the mean m(i) of w(i), leaving us with the zero mean process v(i), we get"


>
> Section 3.4: it's confusing to talk about increasing or decreasing "the
> available bandwidth" - if I got this right, what you do increase or
> decrease is the *receiver-side estimate* of the available bandwidth.
>

Yes, I agree that should be clarified.


>
> Section 4: par 3, "This algorithm is run every time a receive report
> arrives..." => so in case of severe congestion, when nothing else arrives,
> this algorithm waits for 2 * t_max_fb_interval... so can we rely on the
> mechanism to react to this congestion after roughly an RTO or not? (sounds
> like not)  Is that bad?  (I guess)
>

There is a need for some emergency break mechanism if no feedback gets
through.


>
> I hope that's useful,
>
>
> Cheers
> Michael
>
> ______________________________**_________________
> Rtp-congestion mailing list
> Rtp-congestion at alvestrand.no
> http://www.alvestrand.no/**mailman/listinfo/rtp-**congestion<http://www.alvestrand.no/mailman/listinfo/rtp-congestion>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.alvestrand.no/pipermail/rtp-congestion/attachments/20120329/04b5e833/attachment.html>