Re: [tcpm] WGLC: NCR draft-ietf-tcpm-tcp-dcr-06.txt ENDS 27 Jan 2006

> I've been out of the loop for a while, so can someone
> please refresh me on the requirement for fairness.
> 
> I understand the requirement to prevent the next
> Internet meltdown, but not a requirement for fairness.

I am not sure there is a "requirement for fairness".  It's certainly a
little bit of a fuzzy issue in a case like NCR tries to combat.  For
instance, say over a given path two flows can get X bps given the
current congestion and reordering state of the network.  But, if NCR is
used on one flow and that flow gets 3*X bps and the first flow still
gets X bps is that unfair?  For sure the flows have different rates.
So, using something like Jain's fairness index (i.e., just measuring the
spread of rates amongst all flows) might say this is unfair.  But, to
me, neither flow is sending at an inappropriate rate for the given
context.  I.e., the flow sending at X bps cannot send any faster and the
flow sending at 3*X bps is just using what is available.

(Another example of this would be one flow using an advertised window of
Y and another using 5*Y and obtaining better performance.)

Of course, it gets thornier if the flow that gets 3*X bps ends up
stealing some of those bps from the other flow such that it sends at N*X
(for some N < 1).  Now, the reordering robust flow is not just using
spare capacity, but also getting some of its performance boost at the
expense of the non-NCR flow.  We might say that is unfair and say we
have to try to design something into NCR to avoid this - or, largely
mitigate it.  On the other hand, we might decide that the disadvantage
is not great and that this is part of the natural evolutionary path of
TCP, whereby older TCPs don't compete as well as newer TCPs and
therefore, we view this as an incentive to upgrade.  This would be a bit
of engineering judgment after we have a solid set of experiments to look
over, IMO.

allman