[rmcat] Comments on draft-alvestrand-rmcat-congestion-02

[Ingemar Johansson S <[e-mail]>]

Hi

Had a look at http://www.ietf.org/proceedings/89/slides/slides-89-rmcat-5.pdf . I have done some studies around the problem that FTP starves out the media flow.

The algorithm proposed on page 3 seems to do the job. There is however a risk that the algo in itself causes self-inflicted congestion in that it increases a threshold against a measured value(and in the process causes the measured value to increase). 

I have experienced this behavior with another algorithm that I have worked on for a while, the details are not the same as in your algo but I suspect that you may get the same problem that I describe. In any case, the solution that I have tried out which seems to work is to blank the video every once in a while and sense the one way delay during these periods. If the one way delay (or RTT) drops consideraby during the blank period  then the threshold (or gamma in your case) should be reduced. I have tried out a one RTT blank every 10seconds and it seems to do the job. With that said, it should be possible to solve the problem I outline above.

Another, possibly more complicating matter, which I have not managed to solve is that the media (video) is eventually starved out by FTP if I stick to reasonable settings in the congestion/flow control. The only way to avoid this is to make the algorithm very insensitive to packet loss. 
I believe (hypothesis) that the root cause to this problem is that while the FTP has an unlimited source bitrate (there are always bytes available for the flow control to send if possible), the media has a limited source bitrate as it is not possible to queue up too many bytes (delay constraint), add the fact that the media source bitrate can change due to content... The effect of this is that the media sender must become even more opportunistic when it has data to send than FTP. 
In my implementation I adjust a beta value (similar to Cubic's beta value) to control the backoff in case of congestion events. If I set the beta value for very little backoff then I can avoid that media is starved out by FTP* and even get a fair split of the bandwidth. The problem is also that I increase the packet loss rate when the FTP load is removed, this is particularly obvious when I use a CoDel AQM in the bottleneck. I believe that I can see that the packet loss rate increases quite considerably on page 5 in your presentation when you switch on AT (right figure), this indicates an aggressive behavior. 

All this is not a rant against your algorithm, rather it makes me wonder how reasonable it is with test cases that involves parallel FTP and media over the same bottleneck. Guess it is Ok to try it out but one can question what weight it should have when a figure of merit or whatever is computed. 

Comments welcome, even if you punch a hole in my hypothesis above. 

* I can also allow more video frames to be queued up in the sender to always have data to send but that that causes a higher  e2e delay.

/Ingemar


  


=================================
Ingemar Johansson  M.Sc. 
Senior Researcher

Ericsson AB
Wireless Access Networks
Labratoriegränd 11
971 28, Luleå, Sweden
Phone [phone]
SMS/MMS [phone]
[e-mail]
www.ericsson.com

"I was gratified to be able to answer promptly, and I did. 
 I said I didn't know."
Samuel Clemens
=================================