Subject: [rmcat] Several comments about RRTCC

From: Michael Welzl <[email-masked]>
Date: Sat, 29 Dec 2012 14:30:39 +0100

Dear all,

I / we have found a number of potential issues with draft-alvestrand-rtcweb-congestion-03, and would like to share them with the group. I have shared some but not all of these thoughts directly with the authors in the past, but I think it's useful to have them put together in a list.

1)
The RRTCC acronym. The draft luckily doesn't contain it, but I think the mechanism should have an acronym anyway. I have to search through my mailbox every time to see if RRTCC is really what it was called… may I propose "DemiResi" ?  (Delay minimization with reduced signaling)     "Resi" also gives you plenty of nice associations to mountains… cows… yodeling… red-white plaid skirts and Lederhosen!  Easier to remember than RRTCC, no doubt! To get you guys used to the idea, I will call it DemiResi in my text below  :-)

2)
Given that minimizing the amount of feedback seems to be a goal, this feedback becomes very important. Losing a TCP ACK isn't a big deal, but losing a DemiResi feedback message is. Given the minimal space needed (essentially, one bit … plus a little more, to avoid ambiguity etc.), I think we should introduce "acks-of-acks", i.e. a message that says "I got your feedback". Yes, that message would only appear at the receiver within one RTT, but if the sender's timeout (2x t_max_fb_interval)  is larger than an RTT, it could help to make the receiver retransmit its feedback early when that message is missing. Personally I'm not convinced that it's a good idea to send less than a message / RTT anyway, in which case such ACKs-of-ACKs could still be useful, as they would disambiguate forward from backward loss. For instance, the next message could then tell the sender "don't reduce your rate because of the loss that you see, it's only the backward path".

3)
The TCP steady-state throughput equation from RFC3448 (in what follows, I will call it "TFRC equation") is rather sensitive to the correct usage of p, the packet loss event ratio. The way it is used in the draft, p is packet loss but not the loss event ratio. Correct usage would require sending loss events from the receiver to the sender (DCCP has a way to do this), or, which would strike me as being much simpler, calculating this equation on the receiver side. The receiver has all the information about packet loss available. This would require the receiver to have some notion of the RTT, which it could get e.g. if item 2) above is implemented.

4)
The text on page 12 of the draft reads as if it would be impossible for the receive-side estimate of the available bandwidth A(i) to go below the value obtained with the TFRC equation. If it does, however, DemiResi becomes like some form of TFRC, even in the absence of other TCPs. Can we be sure that this won't happen? It could be an idea to fall back to such TFRC-like behavior only if loss is large enough to indicate that we're competing with TCP… we might not always, and when we're not, we should keep delay low.

5)
The thresholds on page 12 seem troublesome to me: the behavior stays unchanged in the 2-10% loss regime (this is high loss!), it is reduced in proportion to the loss ratio in case of above 10% (seems reasonable, except that 10% is already quite extreme), BUT: "As long as less than 2% of the packets have been lost As(i) will be increased as As(i)=1.05(As(i-1)+1000)"
…. this latter item means that, as long as we're below 2% loss, the mechanism increases its rate, making 2% its loss target?!  This strikes me as rather odd for a mechanism that's supposed to avoid loss and delay and keep queues low. Again, if this is done for interoperation with TCP, it could be an idea to do it only when loss is above a certain percentage (as it would be caused by TCP).

6)
Rather obviously, ECN should be incorporated...

Surely there's more stuff to find. I guess my main criticism is that we still don't have a paper, a technical report, simulation code or a simple standalone implementation to play with. Simply not enough data.

I hope this was constructive...

Cheers,
Michael

---

From: Sergio Garcia Murillo <[email-masked]>
Date: Mon, 31 Dec 2012 10:58:32 +0100

El 29/12/2012 14:30, Michael Welzl escribió:
> [..]

If i understood the paper correctly, if both sender and receiver 
implements it, the overuse detector will be triggered before the 2-10% 
ratio is reached, so in theory it is safe to increase the rate as the 
packets lost would not be associated to congestion. The problem comes 
when the receiver doesn't not implement its part, and then I agree with 
you that a 2-10% loss without any extra mechanism would provide a very 
bad experience. If FEC/RED are used, then maybe the loss is not 
noticeable, but haven't tried that myself yet. Also, there may be some 
other codec specific solutions that could make the  2-10% loss to not be 
a problem, like periodic intra refresh, disposable frames, etc..

> [..]

I have been trying to implement the algorithm myself in my MCU and found 
quite some problems, especially with the initial values of the 
parameters, but after checking the google webrtc implementation I have 
quite positive results with the overuse detector.  Haven't got much luck 
yet with the bitrate estimator. I am also starting to implement some 
testing tools to help me in the implementation and troubleshooting, I 
will keep you posted when they are stable enough for playing.

Maybe it is stupid, but on the bitrate estimator, given that "Not until 
over-use has been detected for at least gamma_2 milliseconds and at 
least gamma_3 frames, a definitive over-use will be signaled.", couldn't 
we use the bitrate received during that period as a valid bitrate 
estimation of the available bandwidth?

On a last note, I believe that the algorithm will work much better if 
the codecs are able to produce output bitrates as closed as the target 
bitrate as possible (i.e. almost CBR). Which seems to be confirmed by a 
comment in google's code:

   // We try to filter out very late frames. For instance periodic key
   // frames doesn't fit the Gaussian model well.

Best regards
Sergio

---

From: Michael Welzl <[email-masked]>
Date: Mon, 31 Dec 2012 12:06:35 +0100

On Dec 31, 2012, at 10:58 AM, Sergio Garcia Murillo <[email-masked]> wrote:

> If i understood the paper correctly, if both sender and receiver implements it, the overuse detector will be triggered before the 2-10% ratio is reached, so in theory it is safe to increase the rate as the packets lost would not be associated to congestion. The problem comes when the receiver doesn't not implement its part, and then I agree with you that a 2-10% loss without any extra mechanism would provide a very bad experience. If FEC/RED are used, then maybe the loss is not noticeable, but haven't tried that myself yet. Also, there may be some other codec specific solutions that could make the  2-10% loss to not be a problem, like periodic intra refresh, disposable frames, etc..

Assuming that up to 2% loss isn't necessarily due to congestion also means that the mechanism rather heavily relies on delay. Whether we use OWD, IPG… either way, it's a pretty unreliable signal, e.g. noise can be introduced by multiple bottlenecked links, and it loses granularity when AQM is used or queues are short. I'm not arguing against the general use of a delay measure - but I'm not sure I like the idea of assuming: unless a delay based over-use detector fires, losses are not due to congestion.

> I have been trying to implement the algorithm myself in my MCU and found quite some problems, especially with the initial values of the parameters, but after checking the google webrtc implementation I have quite positive results with the overuse detector.  Haven't got much luck yet with the bitrate estimator. I am also starting to implement some testing tools to help me in the implementation and troubleshooting, I will keep you posted when they are stable enough for playing.

Cool!

I'll leave it to the authors to answer your notes below (my own answer would be "not sure, would have to dig deeper into the scheme again").

Cheers,
Michael

> Maybe it is stupid, but on the bitrate estimator, given that "Not until over-use has been detected for at least gamma_2 milliseconds and at least gamma_3 frames, a definitive over-use will be signaled.", couldn't we use the bitrate received during that period as a valid bitrate estimation of the available bandwidth?
> 
> On a last note, I believe that the algorithm will work much better if the codecs are able to produce output bitrates as closed as the target bitrate as possible (i.e. almost CBR). Which seems to be confirmed by a comment in google's code:
>