Hi Michael, On Wed, Mar 28, 2012 at 1:16 AM, Michael Welzl <michawe@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@alvestrand.no http://www.alvestrand.no/**mailman/listinfo/rtp-**congestion<http://www.alvestrand.no/mailman/listinfo/rtp-congestion>