[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?