Subject: [Tsvwg] re: draft-floyd-tsvwg-besteffort-00b.txt

From: Erblichs <[email-masked]>
Date: Wed, 08 Aug 2007 01:43:17 -0700

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?

---

From: Sally Floyd <[email-masked]>
Date: Wed, 8 Aug 2007 19:59:34 -0700

>    IMO, no effort of TCP or UDP or whatever is going to

Yep, best-effort is about IP and about the transport protocol.

> 1) some Nits first:

Thanks.  The nits were fixed in draft-floyd-tsvwg-besteffort-00.txt
(June 2007).

> while allowing unused bandwidth to be used for best-effort traffic.

I don't think so.  I personally don't think it would be a desirable
or appropriate goal to allow QoS-enabled traffic to use all of the
bandwidth, if so desired, with no unused bandwidth "left over" for
best-effort traffic.  And your rephrased sentence leaves open the
issue of whether the QoS traffic is managed to leave some "unused
bandwidth" for best-effort traffic.

> within a application with a higher bit-cost may be an acceptable

Yep.  This document is not trying to specify how QoS-enabled or
higher-cost services might be delivered.

Good point.  I will add a discussion in Section 3.2 on "The Limitations
of Flow-Rate Fairness" about UDP.

> of unfairness or is the higher bitrate of a CA state flow?

Section 3.2 of draft-floyd-tsvwg-besteffort-00.txt makes
it pretty clear that we accept a level of unfairness between
two TCP flows.  But I will it as an explicit discussion point.

> or the total number of bytes including the header bytes?

I will add this as a question.  (This is explicitly addressed in
RFC 4828, on " TCP Friendly Rate Control (TFRC): The Small-Packet
(SP) Variant".)

> the IP/TCP flow that is fragmenting. Right???

I think this depends on the details of the transport protocol.
(Meaning that I don't know off-hand.)

> not reaching a dst from a src when MC is involved?

Well, unicast vs. multicast is all open questions.  Fortunately, this
document doesn't try to answer any of them...

- Sally
http://www.icir.org/floyd/