o I sympathize with Tom's urge to keep it simple.
o A simple method: Look at the last line (TTL) of the traceroute result.
o If it's ***, assume the host is unreachable, and chalk it up in a
special "unreachable" category (like Tom's suggestion).
o If it's not ***, but, say **T or *TT or TTT, where "T" is a response
from any host, then assume that T is the target host and use the responses
from the last line to calculate the loss probability (in this case, 2/3,
1/3, or 0/3, respectively).
o Why do i think this?
o I can't think of any cases off hand where a response on the last line
of the traceroute doesn't come, essentially, from the target host (except
firewalls). If there is no response from any host on the last line of the
traceroute, that probably indicates that the target host is unreachable.
If not, then we've underestimated the loss rate.
o Using anything but the last line results to calculate the loss rate on
the path to the target host seems odd too me, since doing so would much
more closely reflect loss patterns at small-TTL hops nearer to the
traceroute source.
neal
On Wed, 24 Jun 1998, John Snell wrote:
> There's a few possible problems with the Subnet calculation:
>
> 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
>
>