Subject: [rmcat] Comments on draft-welzl-rmcat-coupled-cc-03

From: Ingemar Johansson S <[email-masked]>
Date: Thu, 19 Jun 2014 11:57:15 +0000

Hi

I have finally read draft-welzl-rmcat-coupled-cc-03 and the paper (ref tech-report-fse ).
One odd thing is when I look at th figures 7 to 10 in the paper (section 4). One can see that the average queue depth decreases when FSE is used with TFRC but still the packet loss rate increases (with RAP there is very little difference), your analysis points at a likely reason to it.  It is good to see that you have also tried the framework with rate limited sources as this is actually something that complicates the design of congestion control algorithms.

One question that arise is how well this works with bufferbloated access where one need to rely on algorithms that react also to a change in the e2e delay and not just to packet losses. I have seen in simulations with LTE test cases that especially rate based algorithms can occasionally experience a high e2e delay if throughput drops rapidly and this behavior seems to get worse with higher mobility.  This likely means that the bitrate estimates are lagging a bit behind with the consequence that each flow may be allocated a share of an overly optimistic bandwidth estimate. On the other hand the performance should not be worse than if FSE is not used. Also I understand that you plan to run tests with delay based algorithms in the future so I guess only time can tell.

I tried to imagine how this framework can be combined with the the self-clocking approach in draft-johansson-rmcat-scream-cc-01. In this case the total bandwidth estimate(S_CR in your draft) is readily available as cwnd*8/rtt where cwnd is the congestion window in bytes and rtt is the round trip time. In draft-johansson-rmcat-scream-cc-01 (beginning of section 3 and figure 2) I propose that the media packets are be picked either in a round robin fashion or according to a priority order. This should do the rate distribution trick. If we consider the two video flows in figure 2 ,  suppose that the priority of the left video flow is set higher than the priority for the video flow on the right side. If congestion occurs then the flow with the lower priority would then need to reduce the bitrate more in order to avoid its sender queue from growing. I have however not tried this out so I cannot rule out that a framework like the one that you propose is needed for a more precise control the behavior.

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

Ericsson AB
Wireless Access Networks
Labratoriegränd 11
971 28, Luleå, Sweden
Phone +46-1071 43042
SMS/MMS +46-73 078 3289
[email-masked]<mailto:[email-masked]>
www.ericsson.com

"The difference between stupidity and
genius is that genius has its limits."
Albert Einstein
=================================

---

From: Safiqul Islam <[email-masked]>
Date: Thu, 19 Jun 2014 15:55:47 +0200

Hello,

Thanks for reading our draft. Comments inline.

> One question that arise is how well this works with bufferbloated access where one need to rely on algorithms that react also to a change in the e2e delay and not just to packet losses. I have seen…

We are currently looking at LEDBAT. Our plan was to pick 3 mechanisms, representing 3 classes, focusing on things that are not "in flux”. Therefore, we chose RAP (AIMD), TFRC (because it's rate based and represents a class of stuff, in a way), and LEDBAT (because it represents a variety of delay-based schemes). 

> I tried to imagine how this framework can be combined with the the self-clocking approach in draft-johansson-rmcat-scream-cc-01. In this case the total bandwidth estimate(S_CR in your draft) is rea…

I think this is an architectural issue. Your framework requires a common network congestion controller and a packet scheduler. It’s better that your architecture has a central congestion controller per destination which dictates the rates for all streams. However, if I am not mistaken, RMCAT is not restrictive to RTCWeb; It should be open to  other applications too. Hence, our approach is designed to work with potentially different congestion control mechanisms.

Regards,
Safiqul

> [email-masked]
> www.ericsson.com
>  
> “The difference between stupidity and