o It seems like it would be cool to develop a version of this document
that we could give to people who are wondering why we're banging on their
traceroute server, or to give to people when we ask them if they could run
a traceroute server. Along the same lines, to make it easy for new people
to help out, it might be cool to have
o this document
o a traceroute CGI Perl script, ready to go
o and a place to click to send mail
o to let us know they've installed it
o to complain if we're hitting them too often
o In 1.2.2, you may want to distinguish that the cost metric is round trip
latency for 40-byte UDP packets (UNIX traceroute seems to use this by
default). This will give us a good notion of whether the n-gon (or just
"polygon"?) inequality holds for TCP acks, which should face the exact
same latency, since they're also 40 bytes. And hopefully it will be close
enough for the 576 byte and 1500 byte packets too.
o When the word "server" is used (lotsa places) you may wish to
distinguish whether you mean "traceroute server", "nexus", or "web
server". It's a little unclear sometimes (eg: for the definition of "Q").
o A nit: in 2.2.2, it seems that the stride algorithm would want to pick
the nodes whose key values are *less* than or equal the current time.
o Another nit: in 3.2, is that m = 60 *seconds*, i assume?
o In 3.2, we may want to use something like delta_min = 10min and
delta_max = 20min to provide a guarantee to our poor traceroute servers
that we won't ever hit them twice in the same 10min period. If we don't
care about this, we may want to use exponential inter-measurement times,
so we can enjoy the PASTA.
o In 3.2, where did l=60 (max # simultaneous traceroutes=60) come from? It
sounds reasonable, but i was just wondering...
o Along with the max number of traceroutes in progress (l=60), we might
want to state bounds on a peak expected rate of traceroutes. Something
like:
max <= 60 traceroutes/2 secs = 30 traceroutes per second.
max <= T servers / 15 min <= 150/15min = 10 traceroutes/min
o A bigger point: do we want to design in a bound on how often a site can
be tracerouted *to*? For instance, without this protection, we may end up
tracerouting to www.cnn.com 60 times within a minute interval.
o Can you get that berkeley URL to work?
http://www.net.berkeley.edu/cgi-bin/traceroute?www.cs.washington.edu
I don't see it on the list.
o Can we get a traceroute server up at UT-Austin?
o One big remaining question is where to traceroute *to*. Here are some
thoughts: 75% of flows are HTTP, so we could concentrate on web traffic.
It seems like we'd like to get a notion of paths from clients to servers,
and vice versa. So we could:
To get servers:
o traceroute to the (say) 100 most popular web sites, as ranked by
excite or yahoo or whoever does that sort of thing
To get clients:
o traceroute to a couple dozen american universities
o traceroute to the firewalls of a couple dozen large corporations
(though it may be tough to get the ip addresses that will lead our
traceroute packets there)
o traceroute to the modem banks of large ISPs
+ If we're serious, we could use (trial) accounts on AOL, MSN,
Earthlink,..., and dial up using numbers for various cities, and then
record the IP addresses we were assigned in each city (what a pain, huh?).
neal
On Sat, 16 May 1998, John Snell wrote:
>
> After much hashing about, a proper measurement proposal has been
> generated for the "triangle inequality failure" tests. The purpose of
> generating this proposal in no small part to solicit comment from the
> group on the validity of the statements and of the infrastructure
> presented therein.
>
> As Ed Bartles put it, "Thank you for your support."
>
> http://www.cs.washington.edu/homes/geigudr/tiber/Stride.ps
>
> _____________________________________________________________________________
> "One of these days, I'm going to implement a new method of controlling
> network flow: Selective Negative Acknowledgements. If for no other
> reason than the opportunity write about SNAKs."
>
>
>
>
>