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

Wesley Eddy <weddy@grc.nasa.gov> Mon, 23 January 2006 15:05 UTC

Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F13G5-0005Oo-7p; Mon, 23 Jan 2006 10:05:29 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F13G3-0005OC-2C for tcpm@megatron.ietf.org; Mon, 23 Jan 2006 10:05:27 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA25647 for <tcpm@ietf.org>; Mon, 23 Jan 2006 10:03:58 -0500 (EST)
Received: from mx1.grc.nasa.gov ([128.156.11.68]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F13PL-00017H-HL for tcpm@ietf.org; Mon, 23 Jan 2006 10:15:04 -0500
Received: from lombok-fi.grc.nasa.gov (seraph1.grc.nasa.gov [128.156.10.10]) by mx1.grc.nasa.gov (Postfix) with ESMTP id C9812C2CE for <tcpm@ietf.org>; Mon, 23 Jan 2006 10:05:10 -0500 (EST)
Received: from apataki.grc.nasa.gov (apataki.grc.nasa.gov [139.88.112.35]) by lombok-fi.grc.nasa.gov (NASA GRC TCPD 8.12.10/8.12.10) with ESMTP id k0NF593C012813; Mon, 23 Jan 2006 10:05:09 -0500 (EST)
Received: from apataki.grc.nasa.gov (localhost [127.0.0.1]) by apataki.grc.nasa.gov (NASA GRC TCPD 8.13.1/8.13.1) with ESMTP id k0NF59UU029495; Mon, 23 Jan 2006 10:05:09 -0500 (EST)
Received: from drpepper.grc.nasa.gov (gr2134391.grc.nasa.gov [139.88.44.123]) by apataki.grc.nasa.gov (NASA GRC TCPD 8.13.1/8.13.1) with ESMTP id k0NF58HB029480; Mon, 23 Jan 2006 10:05:08 -0500 (EST)
Received: by drpepper.grc.nasa.gov (Postfix, from userid 501) id B9F7C4FD91; Mon, 23 Jan 2006 10:05:20 -0500 (EST)
Date: Mon, 23 Jan 2006 10:05:20 -0500
From: Wesley Eddy <weddy@grc.nasa.gov>
To: Mark Allman <mallman@icir.org>
Subject: Re: [tcpm] WGLC: NCR draft-ietf-tcpm-tcp-dcr-06.txt ENDS 27 Jan 2006
Message-ID: <20060123150520.GA25197@grc.nasa.gov>
References: <43D156B4.8020802@redback.com> <20060123145250.231D077A9D9@guns.icir.org>
Mime-Version: 1.0
In-Reply-To: <20060123145250.231D077A9D9@guns.icir.org>
User-Agent: Mutt/1.5.5.1i
X-Spam-Score: 0.0 (/)
X-Scan-Signature: f4c2cf0bccc868e4cc88dace71fb3f44
Cc: tcpm@ietf.org
X-BeenThere: tcpm@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
Reply-To: weddy@grc.nasa.gov
List-Id: TCP Maintenance and Minor Extensions Working Group <tcpm.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/tcpm>, <mailto:tcpm-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:tcpm@ietf.org>
List-Help: <mailto:tcpm-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/tcpm>, <mailto:tcpm-request@ietf.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============0118090548=="
Sender: tcpm-bounces@ietf.org
Errors-To: tcpm-bounces@ietf.org

On Mon, Jan 23, 2006 at 09:52:50AM -0500, Mark Allman wrote:
> 
> 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.

More compactly, the question is how closely NCR can achieve a Pareto
optimum, or max-min fairness, in competition with other types of flows.

-Wes

-- 
Wesley M. Eddy
Verizon Federal Network Systems
_______________________________________________
tcpm mailing list
tcpm@ietf.org
https://www1.ietf.org/mailman/listinfo/tcpm