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

From: Mirja Kuehlewind <[email-masked]>
Date: Fri, 11 Oct 2013 18:14:30 +0200

Hi Michael,

just realized that I never replied to this mail because I was one of the 
persons who had the feeling that it's complicated...

First of all, I did not mean to say that the draft is complicated, but the 
algorithm your are proposing seems quite 'complicated'. Mainly I'm wondering 
if we can't find a solution that is as most simple as possible and keep most 
of the complexity in the actual congestion control loop of each single flow. 
And that's also the point I was concerned about: I would like to avoid that 
your mechanism basically disabled or overwrites the congestion control 
decision itself.

Not sure if this feedback is already too late as I know your are working on a 
new revision. Anyway I hope that's helpful.

Mirja

On Thursday 01 August 2013 15:05:27 Michael Welzl wrote:
> 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

-- 
-------------------------------------------------------------------
Dipl.-Ing. Mirja Kühlewind
Institute of Communication Networks and Computer Engineering (IKR)
University of Stuttgart, Germany
Pfaffenwaldring 47, D-70569 Stuttgart

tel: +49(0)711/685-67973
email: [email-masked]
web: www.ikr.uni-stuttgart.de
-------------------------------------------------------------------

---

From: Michael Welzl <[email-masked]>
Date: Sat, 12 Oct 2013 08:28:37 +0200

> persons who had the feeling that it's complicated...

We're thankful for this general "it's complicated" feedback that we got, because it put us on what we think is the right track: the only way we saw to simplify things was to devise an active variant, which is conceptually closer to RFC 2140. There will be a trade-off between using an active or passive variant, so it's good to have both. I don't want to go into more details now because we're just finishing it, and it's potentially a waste of time to discuss details of a moving target.

> new revision. Anyway I hope that's helpful.

It's not too late, as you already gave this feedback in Berlin too (not sure this specific details are in the minutes, perhaps - but anyway I remember you saying that).

I understand that the complexity concern isn't so much the algorithm itself, but the arising dynamics. I don't think it's correct to say that our mechanism disables the congestion control decision, but yes it overwrites it, and I think overwriting is inevitable (that's also what's done in RFC 2140). Somehow, the rate decision must be influenced by knowledge about other flows sharing the same bottleneck, that's the whole point. The only alternatives I see for doing that are to #1 directly embed such knowledge in the congestion control algorithm (which is what MPTCP does), or to #2 do "split connections" as in some TCP middleboxes and play around with the congestion control in the splitter.

#1 doesn't seem any simpler to me, it also requires understanding the resulting dynamics per mechanism (the mechanism that you changed). Our goal was to be more flexible, and minimize the changes that have to be done to congestion controllers. And I don't see how #2 could be done efficiently here, or be any better than what we propose.

Actually the dynamics aren't so complex if we remove the dust of all the features that we had added to get the mechanism we showed in Berlin. Essentially, if you have 2 flows at equal priority, and one sends at 1/4 the capacity and one sends at 1/2 of the capacity, what our scheme does is to say: the total rate is 3/4 of the capacity, and each one of you gets half of that. When it's their turn, they will still continue trying to probe for the bandwidth, and they will still react to congestion, but their behavior is coupled by considering the total rate of all flows and not only the single flow's rate as input.

Cheers,
Michael