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

[Sally Floyd <[e-mail]>]

> 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..

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).

> 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.

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.

> 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.

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

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

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

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

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.

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

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".)

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

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

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

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/