1. I keep waffling on just what the subnet is to be taken as. Could you
clarify what you mean? (Class of address, variability of subnet mask,
confusing me).
2. Would this trace resolve under your scheme? (re subnet)
Version: Tiber v.1.1
Test: ip.traceroute
SourceIP: 206.58.0.45
TargetIP: 205.158.5.58
SourcePlatform: Slave Unix/0.0/Slave Arch
SourceApplication: STR v1.1
MaxHops: 30
NumProbes: 3
ProbeWait: 3000
TraceWait: 240000
StartTime: 3105220601
EndTime: 3105220613
TimeServerIP: 128.100.96.9
PacketSize: 40
RoutedIP: 1@206.58.0.10:2000,0;1000,0;1000,0
RoutedIP: 2@205.238.52.129:1000,0;1000,0;1000,0
RoutedIP: 3@205.238.56.53:1000,0;1000,0;2000,0
RoutedIP: 4@205.238.56.50:27000,0;40000,0;28000,0
RoutedIP: 5@205.238.56.90:40000,0;41000,0;40000,0
RoutedIP: 6@198.32.176.32:21000,0;18000,0;30000,0
RoutedIP: 7@207.88.0.25:18000,0;33000,0;31000,0
RoutedIP: 8@207.88.3.206:29000,0;18000,0;30000,0
RoutedIP: 9@*:0,*
RoutedIP: 9@205.158.128.66:32000,0;19000,0
On Wed, 24 Jun 1998, Tom Anderson wrote:
> Date: Wed, 24 Jun 1998 20:26:13 -0700 (PDT)
> From: Tom Anderson <tom@emigrant>
> To: geigudr@cs.washington.edu
> Cc: syn@cs
> Subject: Re: probe loss rates, calculation of
>
> I'd do this slightly differently (maybe this is what you meant).
>
> 1. Weight each unique traceroute invocation equally.
> (I wasn't sure if you were including more drop samples
> from those that had ***; if so, those traceroutes that had
> lots of drops would be overweighted.)
>
> 2. treat #4 like #1 if the subnet is the same (e.g., a proxy),
> and otherwise treat it as all drops (e.g., if there's a routing
> loop and you are going off to the ozone).
>
> 3. consider only the three measurements from the last sample -- don't
> try to average in all the prior *** measurements, unless they were the
> last sample. I realize this will underestimate the true drop
> probability: if the first time you would get to the destination, all
> the samples were dropped, traceroute will increment the hop count and
> try again until it gets through. But you can't disambiguate this from
> the case where traceroute really was one hop shy, and all the samples
> were dropped; since you don't count it when you are one hop shy and
> the samples get through, this would be an overestimate.
>
> This means you can simplify your cases -- if you got
> (near) to the destination, then take that sample (#1, #3, and #4 to
> the same subnet). If it didn't (case 2 and case 4 not to the same
> subnet), then treat it as three drops.
>
> Better to consistently underestimate, than to have a more complex
> relationship to reality.
>
> 4. Separately calculate number of times traceroute showed the
> destination was (temporarily) unavailable -- your case #2 and
> case #4 to the wrong subnet, and case #1 where there were
> several *** returns in a row.
> What's the probability distribution for unavailability?
> If some are very unavailable, while multihop routes to the
> same location are very available, then that implies we can improve
> availability with tunneling.
>
> tom
> --------
> Subject: probe loss rates, calculation of
> Message-ID: <Pine.OSF.3.96.980624194313.10533A-100000@orcas.cs.washington.edu>
> MIME-Version: 1.0
> Content-Type: TEXT/PLAIN; charset=US-ASCII
> Status: R
>
>
> Time to put my logic up for question. Traceroute sends out 3 probes, with
> increasing TTL. The question is, how many of the probes do we attribute
> to the target? Not as easy as it might look:
>
> (Note that it's common (enough) in the traces, to have a given targetIP
> respond as something else; ie, I trace to 128.95.2.175, and 128.95.2.173
> responds, and traceroute accepts that as good.)
>
>
> /* There are four cases to consider here:
> 1. The current TTL is not the max; then traceroute recieved a
> response from
> someone identifying themselves as the recipient. Take all failed
> probes
> at this TTL, plus all failed probes from all TTLs previous, where
> such
> a previous TTL had nothing resolve. (ie, * * *)
>
> 2. The current TTL is max, and nothing resolved. Then take all such
> complete failures, moving back, until at least one IP resolved
> for
> a given TTL, this last non-inclusive.
>
> 3. The current TTL is max, and the precise target resolved. Then
> treat this as
> case 1.
>
> 4. The current TTL is max, and something resolved, but it wasn't the
> precise target.
> Then we don't know, as this could either be a logical proxy for
> the target, or
> it could be something else. Punt.
> */
>
>
> Does this cover all the bases?
>
>
> Thanks,
> John
>
>
> _____________________________________________________________________________
> "The human mind is a 400,000-year-old legacy application...and you expected
> to find structured programming?" -- Randall Davis, 1996 AAAI Pres. Address
>
>
>
_____________________________________________________________________________
"The human mind is a 400,000-year-old legacy application...and you expected
to find structured programming?" -- Randall Davis, 1996 AAAI Pres. Address