[Tmrg] Fwd: Re: TCP evaluation suite round-table
Lawrence D. Dunn
ldunn at cisco.com
Thu Aug 23 10:22:33 PDT 2007
tmrg-interest folks,
In response to Lachlan's post on an evaluation suite round-table,
I sent him a couple thoughts unicast.
Lachlan felt they might be relevant/interesting to the list members
(I wasn't totally sure) ;-)
so I'm forwarding my note, below.
I'll also send his quite-thoughtful reply in a second...
Larry
--
>Date: Tue, 21 Aug 2007 09:08:33 -0500
>To: l.andrew at ieee.org, ld
>From: "Lawrence D. Dunn" <ldunn at cisco.com>
>Subject: Re: [Tmrg] TCP evaluation suite round-table
>Cc:
>Bcc:
>X-Attachments:
>
>Lachlan, (unicast),
> ( I almost sent this to the list, but figured, since parts sound
> like a bit of a tangential ramble, I'd start with a unicast,
> and if I feel the same way in a day or so, maybe send it to the list... ;-)
>
> I think this one *might* generate some discussion/debate.
>
> For example, your last sentence (..."useful"...) seems to imply
> that giving all capacity to single-hop flows is somehow bad, or wrong.
> Though I probably agree, it seems that maybe this connects
> "utilization" to some notion of "fairness" (i.e. on what basis
> have we concluded that behavior-X is bad/wrong/misleading?)
> Are utilization and fairness meant to be coupled, or orthogonal,
> or varies-by-scheme-and-that's-OK?
>
> Also, it might be worth considering, for link utilization,
> whether a single-valued metric is the right choice.
> For example, is a "square wave" w/ average utilization
> of 50% somehow "better" or "worse" that a somewhat-noisy
> utilization that seems to hover near 50%? Do we care?
> Maybe we should stay away from better/worse judgements at this
> early stage, but a single-valued metric (average of the sums
> or sum of averages in your example below? )
> probably means that we can't tell the difference.
> On one hand, maybe it's best not to complicate things.
> On another hand, maybe adding standard-deviation,
> or some other metric(s)-of-your-choice, might at least help
> capture differentiation between two behaviors
> that is useful.
>
> Or not. Maybe I'm over-thinking it. ;-)
>
> Is it correct to assume that we're excluding exotica like some
> TCP proxy that "fans-out" a single flow, multicast-fashion,
> to multiple downstream receivers? I suspect that if such
> a proxy were placed after the bottleneck, it might wreak havoc
> with the sum-of-receive-rates approach.
> (East counter-point: "well, that's not really TCP" - perhaps so,
> but it makes me think that the tighter we can bound what
> is in/out of the measurement bounds, the fewer disputes
> we might have later on. OTOH, tighter-bounds might stifle
> some cool/creative approaches, so maybe it's best to not
> worry about it).
>
> Having hinted at conflicting sides of most/all points, I'll
> try to be quiet for a bit... ;-)
>
>Best regards,
>Larry
>--
>
>At 10:06 PM -0700 8/20/07, Lachlan Andrew wrote:
>>Greetings again,
>>
>>On 20/08/07, Lachlan Andrew <lachlan.andrew at gmail.com> wrote:
>>
>>> - a measure of total link utilization
>>
>>Again, I think this should be easy to agree on.
>>
>>Rather than simply measuring total bit/s over the link (which can be
>>achieved by inducing congestion collapse), I would advocate using the
>>sum of the *receive* rates of the flows using each link.
>>
>>For multi-link topologies, this would count the rate of multi-hop
>>flows multiple times, and so is different from the "total network
>>throughput" (sum of all flow rates). It is also more "useful" than
>>measuring the total network throughput, since the latter is maximized
>>by giving all capacity to any single-hop flows using a link.
>>
>>Thoughts?
>>
>>Lachlan
>>
>>--
>>Lachlan Andrew Dept of Computer Science, Caltech
>>1200 E California Blvd, Mail Code 256-80, Pasadena CA 91125, USA
>>Phone: +1 (626) 395-8820 Fax: +1 (626) 568-3603
>>_______________________________________________
>>Tmrg-interest mailing list
>>Tmrg-interest at ICSI.Berkeley.EDU
>>http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/tmrg-interest
More information about the Tmrg-interest
mailing list