Subject: [rmcat] draft-ietf-rmcat-coupled-cc: Several unequally weighted flows may not use the whole bandwidth capacity available

From: "Flohr, Julius" <[email-masked]>
Date: Thu, 18 Oct 2018 10:40:28 +0000

Hi everyone,

I’ve implemented draft-ietf-rmcat-coupled-cc-07 in my INET simulations model and came across an issue I couldn’t find in the list archive. I’m sorry if it’s been discussed before.

So apparently the issue is that the document ignores the fact that most RTP sources have a maximum sending rate (R_max, i.e. the highest possible bandwidth the media source can produce). For example, in NADA R_max is defined to be 1.5Mbps.
The consequent problem is that this can lead to situations where flows with a lower priority get less bandwidth, even though the bottleneck is not saturated.

As an example I’ve attached a plot I’ve created with my simulation setup. RTP flow 1 has priority 1.0, RTP flow 2 has 0.5. The bottleneck capacity is 4Mbps and both flows are using NADA as congestion control (thus R_max is 1.5 Mbps). 
As you can see, RTP flow 1 quickly hits R_max and stays there, while RTP flow 2 gets somewhere around 0.9 Mbps.

What I think happens here ist the following:

The rate update equation of FSE is

S_CR = S_CR + CCR_i - FSER_i

with S_CR being the sum of all sending rates, CCR_i the new desired sending rate of flow i and FSER_i the sending rate calculated by FSE for flow i during the last iteration of the algorithm.
The whole idea behind the FSE algorithm is that S_CR converges to the bottleneck capacity over time so that it can be split among all flows according to their priority.

This fails if we’re not limited by the bottleneck, but rather by the media source:
When we compute a FSER for a flow which is bigger than R_max, we are still only able to send with R_max. This leads to the rate update equation being wrong during the next iteration of the algorithm.

I hope it gets somewhat clear what the issue is here.

I have a somewhat easy fix for this issue I’m willing to present in Bangkok, if this turns out to be a real issue.

Best,

Julius 

=====================================
Julius Flohr, M.Sc.
University of Duisburg-Essen
Computer Networking Technology Group

Room SL-408
Schützenbahn 70
D-45326 Essen/Germany

E-Mail:  [email-masked]
Phone: +49-201-183-7667
Fax:     +49-201-183-7673
=====================================

---

From: Safiqul Islam <[email-masked]>
Date: Fri, 19 Oct 2018 14:41:52 +0000

Hi Julius,

Thanks a lot for playing with draft-ietf-rmcat-coupled-cc-07. It would be great to see the fix/results. I hope there is a room for this on the agenda.

Regards,
Safiqul

> On 18 Oct 2018, at 12:40, Flohr, Julius <[email-masked]> wrote:
> 
> Hi everyone,
> 
> <4mbps_p1_1_p2_0,5.pdf>