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

[Michael Welzl]

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