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?
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?
Same paragraph: "Since our assumption that v(i) should be zero mean
WGN is less accurate in some cases" => why?
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.
Equation 5: I don't think that m(i) and v(i) have been defined
before. (even though it seems obvious what is meant)
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.
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)
I hope that's useful,
Cheers
Michael
