Peering point speed publicly available?
k claffy
kc at caida.org
Fri Jul 2 04:19:07 UTC 2004
On Thu, Jul 01, 2004 at 05:14:10PM -0700, Bill Woodcock wrote:
> I have a question regarding information on my ISP's peering relationships.
> Are the speeds of some or all peering relationships public knowledge, and if
> so, where can I find this? By speed, I mean bandwidth (DS3, OC3, 100Mbps,
> 1Gbps, etc.). I am trying to transfer large stuff from my AS, through my
> ISP, through another ISP, to another AS, and I'm wondering how fast the
> peering point is between the ISPs.
ISPs don't register it or publish it anywhere, generally, and if you ask
salescritters, they're likely to say "At the speed of LIGHT!!!" or some
such. But the two methods people would generally use to determine this
externally would be first to do a bidirectional traceroute and look
closely at the in-addr DNS names associated with the router interfaces on
the IX or crossconnect, which, if you trust them, may give you some
indication of speed. Next, if you have time, you could run pathchar
across the link.
-Bill
um, pathchar will attempt to do a capacity-per-link over a whole
forward path, but it struggles with the complexities of real world
infrastructure (alas, who doesn't) after about 1997, when it was
last supported. van let caida index the tool at
http://www.caida.org/tools/utilities/others/pathchar/
it is 100% van's knightly work. but i think van moved on to
other things after concluding that the task of accurately
identifying capacities of links many hops away via layer 3
measurement on the global Internet was 'sub-possible.'
a few others agree w him.
professor constantine dovrolis and his amazing grad students
ravi and manish at GA tech have taken on a slightly smaller
windmill: measurement of capacity and available bandwidth for a
given -path- (which means the narrow and tight links along the path,
see http://www.pathrate.org for excellent brief description and
source codes). note that neither tool requires root privileges
but both require installing software at both ends of the path,
which render them less useful for the specific application above.
see constantine's IEEE Network paper
http://www.cc.gatech.edu/fac/Constantinos.Dovrolis/Papers/NetDov0248.pdf
if you want high signal techie survey paper on the field,
including a table listing a bunch of tools on page 12.
caida has a summer student from UNC this year working
on evaluating the accuracy of some of these tools in a
controlled lab setting.
i personally can't believe you knights put up with not being
able to measure capacity and available bandwidth of your peers'
paths, but i guess it puts the anycast drama into perspective. :)
the bottom line is that the research community has made some
progress in the field in the last 5 years, but it's a harder
problem than it seems. and it seems pretty bloody hard.
as an operator the best thing you can do to advance this particular
research ball is to use these tools on paths where you actually
know the available bandwidths, and give the tool authors feedback
to help make them more accurate or otherwise more conducive to
your needs. it's the single largest barrier standing between
these tools and these tools being more useful to you.
(besides funding and strong-stomached coders of course)
</brokenrecord>
k
More information about the NANOG
mailing list