[Tsvwg] re: draft-floyd-tsvwg-besteffort-00b.txt
Erblichs <erblichs@earthlink.net> Wed, 08 August 2007 08:43 UTC
Return-path: <tsvwg-bounces@ietf.org>
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IIh8J-0003P0-VC; Wed, 08 Aug 2007 04:43:11 -0400
Received: from tsvwg by megatron.ietf.org with local (Exim 4.43) id 1IIh8I-0003Oq-El for tsvwg-confirm+ok@megatron.ietf.org; Wed, 08 Aug 2007 04:43:10 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IIh8I-0003Oi-2P for tsvwg@ietf.org; Wed, 08 Aug 2007 04:43:10 -0400
Received: from elasmtp-galgo.atl.sa.earthlink.net ([209.86.89.61]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IIh8G-00024u-N0 for tsvwg@ietf.org; Wed, 08 Aug 2007 04:43:10 -0400
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=earthlink.net; b=m4W4Lu/AyH5gAak01OHrCCqrKl1VByG0T1Hfj+hjh+KcqXKUqju6anT1965CzNhd; h=Received:Message-ID:Date:From:X-Sender:X-Mailer:X-Accept-Language:MIME-Version:To:Subject:Content-Type:Content-Transfer-Encoding:X-ELNK-Trace:X-Originating-IP;
Received: from [68.164.93.14] (helo=earthlink.net) by elasmtp-galgo.atl.sa.earthlink.net with asmtp (Exim 4.34) id 1IIh8G-0000ww-A2 for tsvwg@ietf.org; Wed, 08 Aug 2007 04:43:08 -0400
Message-ID: <46B98225.DDBBFD56@earthlink.net>
Date: Wed, 08 Aug 2007 01:43:17 -0700
From: Erblichs <erblichs@earthlink.net>
X-Sender: "Erblichs" <erblichs@earthlink.net@smtpauth.earthlink.net> (Unverified)
X-Mailer: Mozilla 4.72 [en]C-gatewaynet (Win98; I)
X-Accept-Language: en
MIME-Version: 1.0
To: tsvwg@ietf.org
Content-Type: text/plain; charset="iso-8859-2"
Content-Transfer-Encoding: 7bit
X-ELNK-Trace: 074f60c55517ea841aa676d7e74259b7b3291a7d08dfec7933b610622f7e01a4778343d95d175c3b350badd9bab72f9c350badd9bab72f9c350badd9bab72f9c
X-Originating-IP: 68.164.93.14
X-Spam-Score: 0.0 (/)
X-Scan-Signature: a2c12dacc0736f14d6b540e805505a86
Subject: [Tsvwg] re: draft-floyd-tsvwg-besteffort-00b.txt
X-BeenThere: tsvwg@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Transport Area Working Group <tsvwg.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/tsvwg>, <mailto:tsvwg-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:tsvwg@ietf.org>
List-Help: <mailto:tsvwg-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/tsvwg>, <mailto:tsvwg-request@ietf.org?subject=subscribe>
Errors-To: tsvwg-bounces@ietf.org
0) Why isn't best-effort really more appropriate to IP than to TCP/UDP??? Routing is done via IP, and isn't best effort the attempt to route one or more pkts from a src to a dst???????? ie, if a route doesn't exist from a src to a dst, then IMO, no effort of TCP or UDP or whatever is going to change the outcome.. ====== 1) some Nits first: 2.1 The Usefulness of Simple Best-Effort Traffic weaknessas as well as many of the strengths of simple best-effort -----> spelling : weaknessas > weaknesses =============== the consensus goal for resourse allocation in the Internet, either in ------>spelling : resourse > resource ================ 5.1. From the IETF policy issues concerning the approproate granularity of a "flow", and ------->spelling: approproate > appropriate 2) 2.2.1 QoS Some users would be happy to pay for more bandwidth, less delay, less jitter, or fewer packet drops. It is desirable to accommodate such goals in the Internet architecture while preserving a sufficient amount of bandwidth for best-effort traffic. --->while preserving a sufficient amount of bandwidth for best-effort traffic. WOULD this be more appropriate???? while allowing unused bandwidth to be used for best-effort traffic. Are some applications inflexible to acceptance of any disturbance of a somewhat constant bit rate flow? And decreasing packet drops, etc within a application with a higher bit-cost may be an acceptable alternative. =============== 3) 3. On Flow-Rate Fairness for Simple Best-Effort Traffic This section argues that rough flow-rate fairness is a perfectly acceptable goal for simple best-effort traffic. Interesting.... Simple Best-Effort Traffic is defined in the 1.0 Introduction "Simple best-effort traffic" in the current Internet uses end-to-end transport protocols (e.g., TCP, UDP, or others)" So how does "FAIRNESS" apply to a UDP and a TCP flow? Doesn't any CC algorithm within TCP degrade performance versus a UDP flow? Why aren't these two items discussed to accept a level of inequality between UPD and TCP flows? Actually don't we accept a level of "unfairness" even between two TCP flows at one point in time? A simple case compares slow start versus congestion avoidance. Are the doubling in flowrate per timeframe identifies a level of unfairness or is the higher bitrate of a CA state flow? 4) 3.2. The Limitations of Flow-Rate Fairness ??? Packets or bytes: Does this include the effective throughput (total bytes - headers) or the total number of bytes including the header bytes? Does the fairness go to the IP/TCP flow that has more bytes or more packets? Both would mean fragmentation decreases fairness TOWARDS the IP/TCP flow that is fragmenting. Right??? Unicast versus multicast : finally multicast.. Are any CC algors wrt TCP really apply to multicast? IS it acceptable when one or more flows not reaching a dst from a src when MC is involved?