If what you're saying is that it's not feasible to have both latency and
loss rate for all paths, then i'd suggest tracking just latency for each
path, and use the infamous savage/cardwell short flow metric that says
the optimum bandwidth you can get:
datasize
bw = ---------------------------------------------
RTT *[ 2 + log_{1.5}(datasize/(2*MSS) + 1) ]
Probably a good value of datasize is 10,000 (bytes), with MSS=1460 bytes.
Of course this just reduces to saying that bw = k/RTT, which just
says that goodness is inversely proportional to RTT, which is what you
would say even without a complicated formula! And And this still doesn't
deal with the criticism that it's just optimizing for one metric.
So what you really want is to have both loss rate and latency for all
paths and use, as the metric for an end-to-end path A->B, the TCP
performance you expect, as a function of both loss rate and RTT. For now,
i'd say just use the well-accepted formula for long flows:
bw = MSS * 0.87 where p = loss rate expressed as a fraction
-------------
RTT * sqrt(p)
When/if we come up with a closed-form formula that fits significantly
better than this, we can think about using that instead.
neal
On Tue, 6 Oct 1998, John Snell wrote:
>
> Question:
>
> The next phase of the measurement study has me generating a runtime graph
> of the network, whose edges are weighted acording to some measured
> property -- ie, latency, loss, hops, etc.
>
> Previously I'd thought to separately use both latency and loss (ie, do
> multiple alternate path measurements for the same path). This is proving
> to be too expensive, pushing me towards using one single metric.
>
> Tom had recommended using the Savage/Cardwell power metric. Anyone else
> have suggestions on a good metric?
>
> -John
>
>
> ---------- Forwarded message ----------
> Date: Mon, 5 Oct 1998 15:51:18 -0700 (PDT)
> From: Tom Anderson <tom@emigrant>
> To: geigudr@cs.washington.edu
> Subject: Re: one other thing...
>
> i got hammered at MIT for the fact that the latency graph
> is optimized for latency, and the drop rate graph is optimized
> for drops, but there is no guarantee you can get both.
>
> I'd rather get group feedback on this one. Can you pose it as
> a design question to the group?
>
> tom
>
>
>