[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