[rmcat] Brief review of draft-alvestrand-rmcat-congestion-03

[Mirja Kühlewind <[e-mail]>]

Hi Stefan, hi all,

I've had a quick review of draft-alvestrand-rmcat-congestion-03 as an individual 
contributor (not as chairs). I have a couple of high level comments and a few 
more detail once.

In general I, now after just reading NADA and Scream, found it slightly hard to 
read your draft because you are often use a different terminology and different 
variable names. Especially for the arrival model I wonder if you make things 
more complicated than they are. If I get you right, you effectively also just 
want to estimate the queuing delay which is your case however is denoted w(i). 
While the other approaches simply compare the sender and receiver timestamps 
(which requires synchronized clocks or at least additional mechanism to 
compensate for not-synchronized clocks), you look at the inter-arrival times at 
the sender and the receiver and basically estimate the difference between the 
sending rate and receiving rate and therefore... the queue... What I don't 
really understand it why to you need to look at groups of packets?

Further you are using a Kalman filter. That's seem also complicated. Other 
schemes use much simpler filters (like the min of the last few values or a mean) 
and achieve acceptable estimates as well. I can only say this again: simplicity 
is also an important goal when designing a successful mechanism.

As just mention I'd really would like to see more meaningful variable names. 
That really helps the reader. Examples are:
- gamma_1(i) -> effectively this your delay target, often called target_delay; 
don't think you need denote this as a function by writing (i) because it's 
simply a variable in our implementation, right?
- A_hat -> this reflects the target sending rate where the other rmcat proposal 
usually maintain a congestion window for, called cwnd. Btw. how do you maintain 
the send-out process? Is this ack-clocked/report-clocked? In this case it would 
make sense to maintain a window in bytes. Or is it timer-based where you 
calculate the next send-out time based on the rate? Anyway I'd rather like to 
see a longer more meaningful name like target-rate or output_rate (not sure you 
really need the _hat because effectively all your variables are _hat).
- R_hat(i) -> for window based schemes this information is kept as flight_size 
(number of bytes in flight)

There is one sentence that really confuses me (detailed comment). In 4.4 you say
"On every update the delay-based estimate of the available bandwidth
    is increased, either multiplicatively or additively, depending on its
    current state."
Here you mean A_hat(i), right? Because I would call this the target rate, while 
R_hat(i) would be an delay-based estimate...?

A few more detailed questions regarding the calculation of R_hat(i). Is that 
done at receiver-side? Why are you using a window between 0.5 and 1 sec? 
Shouldn't that depend on the RTT and at best be one RTT? Can you maybe give 
pseudo code for basically the second paragraph on page 11?

In general I think it would helpful to not only provide mathematical formulas 
but also some pseudo code that is closer to the implementation (in a couple of 
cases).

Next and final point is on number, there are a couple of numbers where it is not 
clear where they came from and why they have been chosen. I guess most of these 
numbers should be parameter that could be tested in different scenarios. These are:
- update interval for R_hat(i): 0.5-1s (see above)
- 8% increase factor -> really no idea with this has been chosen; actually seems 
rather low to me...
- 100ms add-on to RTT for the response time -> really don't understand why you 
don't simply take the RTT; however this should at least not be a fixed value 
from my point of view (but a factor...?)
- maximum increase rate of 0.5 packets per response time (TCP RENO should 
actually increase by 1 packet/RTT which is now fixed in the Linux kernel, I think)
- upper limit of 1.5*R_hat(i) for A_hat(i)...?
- alpha [0.8, 0.95] where 0.86 is recommended...??? Reno uses 0.5, Cubic should 
use 0.7. Where does this recommendation comes from? Btw. the decrease factor is 
usually called beta while the increase factor/rate is called alpha in AIMD/MIMD 
systems.
- And the number that worries me most is the loss level threshold for the 
loss-based controller... 2% and 10% ???? That's a lot! TFRC is not comparable in 
this case because you are only looking at the loss rate since the last report 
while TFRC looks at an average over a slightly longer time scale. With 
loss-based congestion control you have this probing behavior where there are no 
losses for a couple of RTTs (depending on the size of the congestion window/link 
speed) and then there are a couple of losses within one window. This should give 
you a relative low average loss rate (much belower than 10% and usually even 
below 1%) and the congestion control should reduce its sending rate immediately 
as soon as one loss is detected! If you now induce a loss rate of 2-10% this 
should starve all other competing flows! I'd say, for stability reasons you need 
to decrease as soon as there is loss detected. As you already apply this 
multiplicative decrease rule (A_hat(i) = alpha * R_hat(i) ) for delay, I really 
don't see why you are not using the same rule for loss...? I've quickly looked 
at your evaluation results and sees that GCC is able to co-exists with TCP. 
However I'd assume that in this case still only the delay-based controller 
controls the rate and the loss-based controller doesn't kick in at all. Can you 
confirm/check this?

Now looking at the results, I'd like to request three more things (Thanks!):
- Can you run one more simulation with more than one TCP flow?
- What happen if the TCP stops after a while? Does the target delay value gamma 
actually go down again? Can you plot gamma as well in this sceanrio?
- And can you show the plots on slide 33 (multiple GCC flows) for more than 120s 
because the flows seem to de-converge again.

Thanks for all the work though!

Mirja