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
- Re: [tcpm] WGLC: NCR draft-ietf-tcpm-tcp-dcr-06.t… Lars Eggert
- [tcpm] WGLC: NCR draft-ietf-tcpm-tcp-dcr-06.txt E… Ted Faber
- Re: [tcpm] WGLC: NCR draft-ietf-tcpm-tcp-dcr-06.t… Mark Allman
- Re: [tcpm] WGLC: NCR draft-ietf-tcpm-tcp-dcr-06.t… Lars Eggert
- Re: [tcpm] WGLC: NCR draft-ietf-tcpm-tcp-dcr-06.t… Jakob Heitz
- Re: [tcpm] WGLC: NCR draft-ietf-tcpm-tcp-dcr-06.t… Jeremy Harris
- Re: [tcpm] WGLC: NCR draft-ietf-tcpm-tcp-dcr-06.t… Mark Allman
- Re: [tcpm] WGLC: NCR draft-ietf-tcpm-tcp-dcr-06.t… Mark Allman
- Re: [tcpm] WGLC: NCR draft-ietf-tcpm-tcp-dcr-06.t… Mark Allman
- Re: [tcpm] WGLC: NCR draft-ietf-tcpm-tcp-dcr-06.t… Wesley Eddy
- Re: [tcpm] WGLC: NCR draft-ietf-tcpm-tcp-dcr-06.t… Ted Faber