Subject: [rmcat] Issues with draft-welzl-rmcat-coupled-cc-01

From: Michael Welzl <[email-masked]>
Date: Thu, 1 Aug 2013 15:05:27 +0200

Hi,

Thanks to everyone who gave comments on our draft, draft-welzl-rmcat-coupled-cc-01, in the RMCAT meeting just now. I'm glad to see that this raised some interest!

I think it would be great if we could continue the discussion on the list. So, if you have specific concerns or questions, please shoot!
e.g. the draft has been called "confusing" and "complicated"; we actually tried hard to make this as easy to read as possible, so we'd greatly appreciate getting more concrete hints about what parts should be improved.

At the end of the presentation, Lars raised a concern about the complexity about what he called "another control loop interacting with the control loops". Here I have to agree, obviously our mechanism changes the dynamics of the controllers involved, and we're doing our best to evaluate what this really entails; this work is only just beginning. As you have seen, in simple scenarios with TFRC (which we used because we didn't have code of a more suitable RMCAT mechanism available to simulate,, plus its dynamics are relatively well known), the overall effect seems to be pretty positive.  But yes, it will have to be evaluated with every new mechanism to really see the dynamic behaviour arising from it. In theory, it should even be possible to couple different congestion controllers with our scheme, and then the dynamics are even less obvious  :)

Cheers,
Michael

---

From: Michael Welzl <[email-masked]>
Date: Fri, 2 Aug 2013 00:38:22 +0200

Following up,

in hallway conversations, I learned that the meaning of "greedy" and "non-greedy" traffic was not clear to some.
"Greedy" traffic is FTP-like traffic which always sends as fast as the congestion controller allows. "non-greedy" traffic is traffic that is limited by the application because the application does not always have traffic to send at a rate at which the congestion controller demands it.

We used these two traffic types as a simple starting point, and are planning to use more realistic RMCAT traffic later.

Cheers,
Michael

---

From: "Eggert, Lars" <[email-masked]>
Date: Fri, 2 Aug 2013 07:23:08 +0000

Hi,

ah. I wish you would have used "application-limited" and "bulk" to describe those types, which would have been clearer to me at least.

Lars

---

From: Varun Singh <[email-masked]>
Date: Fri, 2 Aug 2013 09:56:01 +0200

Yes, my assumption was that both the flows were media, greedy and
non-greedy were characteristics of the media application. (Since all
flows use tfrc.)

Regards,
Varun

----
http://www.netlab.tkk.fi/~varun

> On 2.8.2013, at 9.23, "Eggert, Lars" <[email-masked]> wrote:
>
> Hi,
>

---

From: Michael Welzl <[email-masked]>
Date: Fri, 2 Aug 2013 10:19:11 +0200

Apologies. The intention was to start with something simple, then go to more realistic media traffic profiles.

We were also told that the variable names aren't good - e.g. CR means "calculated rate", which is supposed to be an input: the rate that a congestion controller has calculated. It could, however, be misunderstood to mean the rate that the FSE has calculated. We're going to improve that. Any more comments are very welcome, please keep them coming!

BTW, regarding the dynamics of the scheme, I don't think it's correct to call it a "control loop", as our "Flow State Exchange" (FSE) only operates on the time scale of the congestion controllers that use it. As with RFC2140, this is really only about a few shared variables. We think it makes sense to consider the code that you have seen as a part of the FSE, but it could really be included *in* the congestion control mechanisms just as well. Then it's just the code that a congestion control mechanism uses to read and update the variables.

Cheers,
Michael