Subject: [rmcat] Fairness

From: Michael Welzl <[email-masked]>
Date: Wed, 20 Nov 2013 16:00:17 +0100

Hi,

I write this because the requirements draft mentions that fairness is hard to define, and we have gone into the direction of rather defining "unfairness" and all that... as usual, I think it's overcomplicating the situation and I have a much simpler solution, and as usual, it's probably broken: as you already know, I keep trying to simplify things here, and often fail in doing so. I therefore suspect that the simple view I'm going to present here is going to be met with the same reaction, so apologies in advance - let's not have a long and boring discussion: if someone can make it clear that this idea is rubbish, fine, let's just stop there.

With that disclaimer out of the way, let me try to define fairness, for the case of fairness between flows of a single congestion control type (more below about TCP):

***
Send at roughly the same rate under similar conditions.
***

Define "similar conditions":
- conditions that influence the behavior of the congestion controller (rtt, packet loss... but also how much the sending application wants to send)

Why this definition?

While it's known that fairness is in principle a much more complicated story (I guess most of us know the "dismantling a religion" paper: http://www.sigcomm.org/sites/default/files/ccr/papers/2007/April/1232919-1232926.pdf ), we have to start somewhere.

e.g.: if we have a mechanism that, irrespective of the RTT, always converges to the exact same rate, then producing a different form of fairness becomes a matter of locally applying a weight (multiplier). I'd argue that any form of fairness could be achieved by applying local weights.

Demanding "irrespective of the RTT" is maybe a bit too much as it limits the design of the controller (it's possible, but not really a simple thing). Most congestion controls are RTT-dependent, so I guess this is something we'll just have to live with. But, then, if we don't require them to roughly get the same rate in case of the same sender behavior, same RTT and same packet loss, we just get something uncontrollable and useless. For instance, applying weights as described in the previous paragraph won't ever get us what we want if we don't have a known starting point.

Again, this is not an argument in favor of "flow rate fairness", against the arguments in Bob Briscoe's paper - it's an argument that, when we don't know if we have e.g. conex or coupled congestion control operating, "flow rate fairness" gives us a starting point to work with and a "known" behavior for all congestion controllers, and that's perhaps just what we need to request.

My definition is a bit vague - it doesn't talk about the time to converge, it doesn't define "roughly", but I guess we'll have to live with some slack here anyway.

Thoughts?  :-)

About TCP, I think we just need to state that:

***
An RMCAT congestion control should not starve competing TCP flows and not be starved by them.
***

Cheers,
Michael

PS: please don't get this discussion mixed up with our proposal for coupled congestion control: this can enforce any kind of fairness and actually eliminates the need for a fairness requirement - but we probably can't simply assume that all rmcat flows will always have coupled congestion control installed.

PPS: sorry for sending this so late! It only occurred to me now that this simpler solution might be possible...