1. Internet Monitoring Les Cottrell – SLAC
Presented at NUST Institute of Information Technology (NIIT) Rawalpindi, Pakistan, March 15, 2005
Partially funded by DOE/MICS Field Work Proposal on Internet End-to-end Performance Monitoring (IEPM), also supported by IUPAP

2. Overview Why is measurement difficult yet important? LAN vs WAN SNMP
Effects of measurement interval
Passive
Active
Tools including some results on Digital Divide
Trouble shooting
Tools, how to find things & who to tell
New challenges
How do we measure the QoS
Introduction to PingER and active end-to-end measurement methodology
Problem areas illustrated by results from PingER:
Generally, e.g. S. America, Spain, China, Germany to .edu & .ca
How do E. Europe & Russia look?
How does performance affect applications
Validating ping measurements and impact on FTP & Web performance
Overview of impact of performance on applications including , web, FTP, interactive apps
Detailed look at bulk data transfer expectations for HENP sites
Detailed look at critical performance metrics (RTT, loss, jitter, availability) and impact on VoIP
What can be done to improve QoS:
More bandwidth
Reserved bandwidth
Differentiated services

3. Why is measurement difficult?
Internet's evolution as a composition of independently developed and deployed protocols, technologies, and core applications
Diversity, highly unpredictable, hard to find “invariants”
Rapid evolution & change, no equilibrium so far
Findings may be out of date
Measurement not high on vendors list of priorities
Resources/skill focus on more interesting an profitable issues
Tools lacking or inadequate
Implementations poor & not fully tested with new releases
ISPs worried about providing access to core, making results public, & privacy issues
The phone connection oriented model (Poisson distributions of session length etc.) does not work for Internet traffic (heavy tails, self similar behavior, multi-fractals etc.)

4. Add to that … Distributed systems are very hard
A distributed system is one in which I can't get my work done because a computer I've never heard of has failed. Butler Lampson
Network is deliberately transparent
The bottlenecks can be in any of the following components:
the applications
the OS
the disks, NICs, bus, memory, etc. on sender or receiver
the network switches and routers, and so on
Problems may not be logical
Most problems are operator errors, configurations, bugs
When building distributed systems, we often observe unexpectedly low performance
the reasons for which are usually not obvious
Just when you think you’ve cracked it, in steps security
Network is by design transparent so hard to find out information about how it is working etc. GGF Grid High Performance Network group is trying to bring together networkers/applications writers/users by creating documents on “Top ten things network engineers wish grid programmers knew” and vice versa.
Understanding is hard: Immense, moving target, traditional (e.g. Poisson distributions) mathematical tools don’t work, looking for invariants, need parsimonious models. See Vern Paxson’s work, e.g.
The top three networking problems according to a paper by Claudia DeLuna of JPL, are Ethernet duplex, host configuration and bad media.
Failure cause breakdown for 3 Internet sites indicated 51% caused by operator error. “Self Repairing Computers”, Scientific American, June 2003
Reviewing user reported long lasting (typically days, i.e. does not include router reboots, or time out for reconfiguration) WAN problems that SLAC over the last two years, the biggest contributors (30%) were a combination of mis-configured routers (loose unicast RPF filters, wrong buffer size, poorly chosen backup route), misconfigured switches (needed reboot, PVC incorrectly rate limited), firewalls (limit throughput, reset window scaling option). Note these are mainly engineering problems or bugs as opposed to problems we need to research to know how to fix each one individually. However, we do need to investigate how to accurately and automatically identify and report on the location and cause of such problems for the end-user.

5. Why is measurement important?
End users & network managers need to be able to identify & track problems
Choosing an ISP, setting a realistic service level agreement, and verifying it is being met
Choosing routes when more than one is available
Setting expectations:
Deciding which links need upgrading
Deciding where to place collaboration components such as a regional computing center, software development
How well will an application work (e.g. VoIP)
Application steering (e.g. forecasting)
Grid middleware, e.g. replication manager

6. LAN vs WAN Measuring the LAN Measuring the WAN
Network admin has control so:
Can read MIBs from devices
Can within limits passively sniff traffic
Know the routes between devices
Manually for small networks
Automated for large networks
Measuring the WAN
No admin control, unless you are an ISP
Can’t read information out of routers
May not be able to sniff/trace traffic due to privacy/security concerns
Don’t know route details between points, may change, not under your control, may be able to deduce some of it
So typically have to make do with what can be measured from end to end with very limited information from intermediate equipment hops.

7. SNMP (Simple Network Management Protocol)
Example of an Application, usually built on UDP
Defacto standard for network management
Created by IETF to address short term needs of TCP/IP
Consists of:
Management Information Bases (MIBs)
Store information about managed object (host, router, switch etc.) – system &status info, performance & configuration data
Remote Network Monitoring (RMON) is a management tool for passively watching line traffic
SNMP communication protocol to read out data and set parameters
Polling protocol, manager asks questions & agent responds

8. SNMP Model
Agent
MIB
NMS contains manager software to send & receive SNMP messages to Agents
Agent is a software component residing on a managed node, responds to SNMP queries, performs updates & reports problems
MIBs resides on nodes and at NMS and is a logical description of all network management data.
Agent
MIB
Agent
MIB
TCP/IP net
Agent
MIB
Agent
MIB
Agent
MIB
Network Management Station(NMS)

9. SNMP version 1 limitations
Authentication is inadequate:
Password (community string) placed in clear in SNMP messages
MIB variables must be polled separately, i.e. entire MIB cannot be fetched with single command
SNMPv2 and v3 attempt to address these and other limitations
Despite limitations, SNMP has been a huge success
Provides device and link utilization (byte, packets) and errors
Lot of facilities/tools built around SNMP to provide reports for sites
Security concerns limit access typically to very limited set of owner/admins
E.g. ISPs won’t let you poll their devices

10. SNMP Examples Using MRTG to display Router bits/s MIB variable CERN
trans-
Atlantic
traffic

11. Averaging/Sampling intervals
Typical measurements of utilization are made for 5 minute intervals or longer in order not to create much impact.
Interactive human interactions require second or sub-second response
So it is interesting to see the difference between measurement made with different time frames.

12. Utilization with different averaging times
5 secs
Same data, measured Mbits/s every 5 secs
Average over different time intervals
Does not get a lot smoother
May indicate multi-fractal behavior
5 mins
1 hour

13. Averages vs maxima
Maximum of all 5 sec samples can be factor of 2 or more greater than the average over 5 minute intervals

14. Lot of heavy FTP activity
The difference depends on traffic type
Only 20% difference in max & average

15. Passive vs. Active Monitoring
Active injects traffic on demand
Passive watches things as they happen
Network device records information
Packets, bytes, errors … kept in MIBs retrieved by SNMP
Devices (e.g. probe) capture/watch packets as they pass
Router, switch, sniffer, host in promiscuous (tcpdump)
Complementary to one another:
Passive:
does not inject extra traffic, measures real traffic
Polling to gather data generates traffic, also gathers large amounts of data
Active:
provides explicit control on the generation of packets for measurement scenarios
testing what you want, when you need it.
Injects extra artificial traffic
Can do both, e.g. start active measurement and look at passively

16. Passive tools
SNMP
Hardware probes e.g. Sniffer, NetScout, can be stand-alone or remotely access from a central management station
Software probes: snoop, tcpdump, require promiscous access to NIC card, i.e. root/sudo access
Flow measurement: netramet, OCxMon/CoralReef, Netflow

17. Example: Passive site border monitoring
Use Cisco Netflow in Catalyst 6509 with MSFC, on SLAC border
Gather about 200MBytes/day of flow data
The raw data records include source and destination addresses and ports, the protocol, packet, octet and flow counts, and start and end times of the flows
Much less detailed than saving headers of all packets, but good compromise
Top talkers history and daily (from & to), tlds, vlans, protocol and application utilization
Use for network & security

18. SLAC Traffic profile SLAC offsite links:
OC3 to ESnet, 1Gbps to Stanford U & thence OC12 to I2
OC48 to NTON
Profile
bulk-data xfer dominates
HTTP
Mbps in
iperf
Last 6 months
2 Days
Mbps out
SSH
FTP
bbftp

19. Top talkers by protocol
Hostname 1
100
10000
Volume dominated by single
Application - bbcp
MBytes/day (log scale)

20. Flow sizes SNMP Real A/V AFS file server
Heavy tailed, in ~ out, UDP flows shorter than TCP, packet~bytes
75% TCP-in < 5kBytes, 75% TCP-out < 1.5kBytes (<10pkts)
UDP 80% < 600Bytes (75% < 3 pkts), ~10 * more TCP than UDP
Top UDP = AFS (>55%), Real(~25%), SNMP(~1.4%)

21. Flow lengths 60% of TCP flows less than 1 second
Would expect TCP streams longer lived
But 60% of UDP flows over 10 seconds, maybe due to heavy use of AFS

22. Some Active Measurement Tools
Ping connectivity, RTT & loss
flavors of ping, fping, Linux vs Solaris ping
but blocking & rate limiting
Alternative synack, but can look like DoS attack
Sting: measures one way loss
Traceroute
How it works, what it provides
Reverse traceroute servers
Traceroute archives
Combining ping & traceroute,
traceping, pingroute
Pathchar, pchar, pipechar, bprobe, abing etc.
Iperf, netperf, ttcp, FTP …

23. Ping ICMP client/server application built on IP
Client send ICMP echo request, server sends reply
Server usually in kernel, so reliable & fast
User can specify number of data bytes. Client puts timestamp in data bytes. Compares timestamp with time when echo comes back to get RTT
Many flavors (e.g. fping) and options
packet length, number of tries, timeout, separation …
Ping localhost ( ) first, then gateway IP address etc.

24. Ping example syrup:/home$ ping -c 6 -s 64 thumper.bellcore.com
PING thumper.bellcore.com ( ): 64 data bytes
72 bytes from : icmp_seq=0 ttl=240 time=641.8 ms
72 bytes from : icmp_seq=2 ttl=240 time= ms
72 bytes from : icmp_seq=3 ttl=240 time= ms
72 bytes from : icmp_seq=4 ttl=240 time=758.5 ms
72 bytes from : icmp_seq=5 ttl=240 time=482.1 ms
--- thumper.bellcore.com ping statistics packets transmitted, 5 packets received, 16% packet loss round-trip min/avg/max = 482.1/880.5/ ms
Packet size
Remote host
Repeat count
RTT
Missing seq #
Summary

25. Lost packet or router ignores
Traceroute
UDP/ICMP tool to show route packets take from local to remote host
-q 1 -m 20 lhr.comsats.net.pk
traceroute to lhr.comsats.net.pk ( ), 20 hops max, 40 byte packets
1 RTR-CORE1.SLAC.Stanford.EDU ( ) ms
2 RTR-MSFC-DMZ.SLAC.Stanford.EDU ( ) ms
3 ESNET-A-GATEWAY.SLAC.Stanford.EDU ( ) ms
4 snv-slac.es.net ( ) ms
5 nyc-snv.es.net ( ) ms
6 nynap-nyc.es.net ( ) ms
7 gin-nyy-bbl.teleglobe.net ( ) ms
8 if bb5.NewYork.Teleglobe.net ( ) ms
9 if bb6.NewYork.Teleglobe.net ( ) ms
( ) ms
( ) ms
12 islamabad-gw2.comsats.net.pk ( ) ms
13 *
14 lhr.comsats.net.pk ( ) ms
Max hops
Remote host
Probes/hop
No response:
Lost packet or router ignores

26. Reverse traceroute servers
Reverse traceroute server runs as CGI script in web server
Allow measurement of route from other end. Important for asymmetric routes. See e.g.
CAIDA map of reverse traceroute servers

27. Pingroute Run traceroute, then ping each router n times
helps identify where in route the problems start to occur
Routers may not respond to pings, or may treat pings directed at them, differently to other packets

28. Path characterization
sends multiple packets of varying sizes to each router along route
measures minimum response time
plot min RTT vs packet size to get bandwidth
calculate differences to get individual hop characteristics
measures for each hop: BW, queuing, delay/hop
can take a long time
Pipechar/abing
Also sends back-to-back packets and measures separation on return
Much faster
Finds bottleneck
Bottleneck
Min spacing
At bottleneck
Spacing preserved
On higher speed links

29. Network throughput Iperf Client generates & sends UDP or TCP packets
Server receives receives packets
Can select port, maximum window size, port , duration, Mbytes to send etc.
Client/server communicate packets seen etc.
Reports on throughput
Requires sever to be installed at remote site, i.e. friendly administrators or logon account and password

30. Iperf example Total throughput =3*15.3Mbits/s = 45.9Mbits/s
-p w 512K -P 3 -c sunstats.cern.ch
Client connecting to sunstats.cern.ch, TCP port 5008
TCP window size: 512 KByte
[ 6] local port connected with port 5008
[ 5] local port connected with port 5008
[ 4] local port connected with port 5008
[ ID] Interval Transfer Bandwidth
[ 4] sec MBytes Mbits/sec
[ 5] sec MBytes Mbits/sec
[ 6] sec MBytes Mbits/sec
Total throughput =3*15.3Mbits/s = 45.9Mbits/s
3 parallel streams
TCP port 5006
Max window size
Remote host

31. Active Measurement Projects
PingER – running at NIIT
AMP – coming soon to NIIT
One way delay:
Surveyor (now defunct), RIPE (mainly Europe), owamp
IEPM-BW – running at NIIT
NIMI (mainly a design infrastructure)
NWS (mainly for forecasting)
Skitter
All projects measure routes
For a detailed comparison see:

32. AMP http://amp.nlanr.net/AMP/
AMP uses dedicated PCs as monitors, ~ 150 (June, 2005)
Today mainly does pings
Oriented to Internet 2, ~ 10 countries
Does mainly full mesh pinging
Being re-written to provide support for more probes

33. PingER Measure the network performance for developing regions
From developed to developing & vice versa
Between developing regions & within developing regions
Use simple tool (PingER/ping)
Ping installed on all modern hosts, low traffic interference,
21 pings each 30 mins to remote hosts (< 100bits/s average)
Provides very useful measures
Originated in High Energy Physics, now focused on DD
Persistent (data goes back to 1995), interesting history
Looks like chicken pox
For Brazil thanks to Alberto Santoro for UERJ, and Sergio Novaes for UNESP, for Pakistan thanks to Arshad Ali for NIIT
Pakistan monitors 4 .pk hosts plus CERN & SLAC, routes go via London (even between .pk sites).
Sao Paolo monitors about 25 sites in 16 countries. Within Brazil direct connections (5-30 msec) else goes via AMPATH/FIU (even Chile and Uruguay)
Bangalore just starting to take data, thanks to Anil Srivastava & Subramanian N
PingER is arguably the most extensive set of measurements of the
end-to-end performance of the Internet going back almost ten years.
Measurements are available from over 30 sites in 13 countries to
sites in over 100 countries. We will use the PingER results
to: demonstrate how the Internet
performance to the regions of the world has evolved over the last 9
years; identify regions that have poor connectivity, how far
they are behind the developed world and whether they are catching up
or falling further behind; and illustrate the correlation
between the UN Technology Achievement Index and Internet performance.
PingER coverage Feb 2005
Monitoring site
Remote site

34. Examples:World View
C. Asia, Russia, S.E. Europe, L. America, M. East, China: 4-5 yrs behind
India, Africa: 7 yrs behind
S.E. Europe, Russia: catching up
Latin Am., Mid East, China: keeping up
India, Africa: falling behind
Important for policy makers
Spreadsheet \cottrell\iepm\esnet-to-all-longterm.xls
CERN data only goes back to Aug-01. It confirms S.E. Europe & Russia are catching up, and India & Africa are falling behind
PingER is arguably the most extensive set of measurements of the
end-to-end performance of the Internet going back almost ten years.
Measurements are available from over 30 sites in 13 countries to
sites in over 100 countries. We will use the PingER results
to: demonstrate how the Internet
performance to the regions of the world has evolved over the last 9
years; identify regions that have poor connectivity, how far
they are behind the developed world and whether they are catching up
or falling further behind; and illustrate the correlation
between the UN Technology Achievement Index and Internet performance.
Ghana, Nigeria and Uganda are all satellite links with ms RTTs. The losses to Ghana & Nigeria are 8-12% while to Uganda they are 1-3%. The routes are different. The route from SLAC to Ghana uses ESnet-Worldcom-UUNET, Nigeria goes CalREN-Qwest-Teiianet-New Skies satellite, Uganda goes Esnet-Level3-Intelsat. For both Ghana and Nigeria there are no losses (for 100 pings) until the last hop when over 40 of 100 packets were lost. For Uganda the losses (3 in 100 packets) also occur at the last hop.
Worksheet: for trends: \\Zwinsan2\c\cottrell\iepm\esnet-to-all-longterm.xls
for Africa: \\Zwinsan2\c\cottrell\iepm\africa.xls
Many institutes in developing world have less performance than a household in N. America or Europe

35. Losses
US residential Broadband users have better access than sites in many regions

36. Loss to Africa (example of variability)
Facts on African Countries, see
From PingER project

37. Compare with TAI UN Technology Achievement Index (TAI)
Measures creation & diffusion of technology and building human skills
The United Nations Development Programme (UNDP) introduced the Technology Achievement Index (TAI) to reflects a country's capacity to participate in the technological innovations of the network age. The TAI aims to capture how well a country is creating and diffusing technology and building a human skill base. It includes the following dimensions: Creation of technology (e.g. patents, royalty receipts); diffusion of recent innovations (Internet hosts/capita, high & medium tech exports as share of all exports); Diffusion of old innovations (log phones/capita, log of electric consumption/capita); Human skills (mean years of schooling, gross enrollment in tertiary level in science, math & engineering). Figure 14 shows December 2003's derived throughput measured from the U.S. vs. the TAI. The correlation is seen to be positive and medium to good. The US and Canada are excluded since the losses are not accurately measureable by PingER and the RTT is small. Hosts in well connected countries such as Finland, Sweden, Japan also have their losses poorly measured by PingER and  since they have long RTTs the derived throughput is likely to be low using the Mathis formula and if no packets are lost then assuming a loss of 0.5 packets in the 14,400 sent to a host in a month.
Note that we have measurements to more African countries but there is no TAI for them.
Note how bad Africa is

38. E2E Troubleshooting
Solving the E2E performance problem is the critical problem for the user
Improve e2e throughput for data intensive apps in high-speed WANs
Provide ability to do performance analysis & fault detection ins Grid computing environment
Provide accurate, detailed, & adaptive monitoring of all distributed components including the network

39. Hey, this is not working right!
Anatomy of a Problem
Hey, this is not working right!
Others are
getting in ok
Not our problem
Applications
Developer
Applications
Developer
LAN
Administrator
LAN
Administrator
Talk to the other guys
System
Administrator
Everything is
AOK
System
Administrator
Campus
Networking
Campus
Networking
The computer
Is working OK
No other
complaints
Looks fine
May not be realistic to try and solve this as shown. Need to divide and conquer, e.g. ID the AS responsible for where the problem is and report to them with relevant supporting information. To do this need tools to partition problem.
Gigapop
Gigapop
All the lights
are green
How do you solve
a problem along a path?
Backbone
We don’t see
anything wrong
From an Internet2 E2E presentation
by Russ Hobby
The network is lightly loaded

40. Needs
Measurement tools to quickly, accurately and automatically identify problems
Automatically take action to investigate and gather information, on-demand measurements
Standard ways to discover request and report results of measurements, for applications
GGF/NMWG schemas
Share information with people and apps across a federation of measurement infrastructures
Web services are in their early days, they have a steep learning curve, the schemas and not mature

41. Trouble shooting Ping to localhost, ping to gateway & to remote host
Use IP address to avoid nameserver problems
Look for connectivity, loss & RTT
May need to run for a long time to see some pathologies (e.g. bursty loss dues to DSL loss of sync)
Use synack or sting if ICMP blocked
Traceroute to remote host
Reverse traceroute from remote host to you
Ping routers along route
Look at history plots (PingER, AMP), when did problem start, how big an effect is it?

42. Trouble shooting
Try user application
Iperf to test throughput

43. Where is a host? Name server lookup to find hostname given IP address
Server: localhost
Address:
Name: lhr.comsats.net.pk
Address:
Triangulate position based on RTT measurements made to unknown host from several hosts at known locations.

44. Whereis a host Do a Google search on IP address to location, e.g.

45. Hi-perf Challenges Packet loss hard to measure by ping
For 10% accuracy on BER 1/10^8 ~ 1 day at 1/sec
Ping loss ≠ TCP loss
Iperf/GridFTP throughput at 10Gbits/s
To measure stable (congestion avoidance) state for 90% of test takes ~ 60 secs ~ 75GBytes
Requires scheduling implies authentication etc.
Using packet pair dispersion can use only few tens or hundreds of packets, however:
Timing granularity in host is hard (sub μsec)
NICs may buffer (e.g. coalesce interrupts. or TCP offload) so need info from NIC or before
Security: blocked ports, firewalls, keys vs. one time passwords, varying policies … etc.
Slow start on 200ms RTT takes about 8secs on 10Gbps, on 1Gbps takes ~ 6 secs
BER of 1/10^8 is not that high. For example the “SURA Optical Network Cookbook” (see suggests that a BER of 1/10^9 is typical.

46. Dedicated Optical Circuits
Could be whole new playing field, today’s tools no longer applicable:
No jitter (so packet pair dispersion no use)
Instrumented TCP stacks a la Web100 may not be relevant
Layer 1 & 2 switches make traceroute less useful
Losses so low, ping not viable to measure
High speeds make some current techniques fail or more difficult (timing, amounts of data etc.)

47. More Information Tutorial on monitoring RFC 2151 on Internet tools
RFC 2151 on Internet tools
Network monitoring tools
Ping
IEPM/PingER home site
www-iepm.slac.stanford.edu/
IEEE Communications, May 2000, Vol 38, No 5, pp

48. Simplified SLAC DMZ Network, 2001
Dial up &ISDN
2.4Gbps
OC48 link
NTON
(#)
rtr-msfc-dmz
155Mbps
OC3 link(*)
Stanford
Swh-dmz
ESnet
Internet2
slac-rt1.es.net
OC12 link
622Mbps
swh-root
Etherchannel 4 gbps
SLAC Internal Network
1Gbps Ethernet
(*) Upgrade to OC12 has been requested
(#) This link will be replaced with a OC48 POS card for the 6500 when available
100Mbps Ethernet
10Mbps Ethernet

49. Flow lengths Distribution of netflow lengths for SLAC border
Log-log plots, linear trendline = power law
Netflow ties off flows after 30 minutes
TCP, UDP & ICMP “flows” are ~log-log linear for longer (hundreds to 1500 seconds) flows (heavy-tails)
There are some peaks in TCP distributions, timeouts?
Web server CGI script timeouts (300s), TCP connection establishment (default 75s), TIME_WAIT (default 240s), tcp_fin_wait (default 675s)
ICMP
TCP
UDP

50. Traceroute technical details
Rough traceroute algorithm
ttl=1; #To 1st router
port=33434; #Starting UDP port
while we haven’t got UDP port unreachable {
send UDP packet to host:port with ttl
get response
if time exceeded note roundtrip time
else if UDP port unreachable
quit
print output
ttl++; port++ }
Can appear as a port scan
SLAC gets about one complaint every 2 weeks.

51. Time series
UDP
TCP
Cat q
vs. ISL
Incoming
Outgoing

52. Power law fit parameters by time
Just 2 parameters
provide a reasonable
description of the flow
size distributions

53. Not your normal Internet site
Ames IXP: approximately 60-65% was HTTP, about 13% was NNTP
Uwisc: 34% HTTP, 24% FTP, 13% Napster

54. PingER cont.
Monitor timestamps and sends ping to remote site at regular intervals (typically about every 30 minutes)
Remote site echoes the ping back
Monitor notes current and send time and gets RTT
Discussing installing monitor site in Pakistan
provide real experience of using techniques
get real measurements to set expectations, identify problem areas, make recommendations
provide access to data for developing new analysis techniques, for statisticians etc.

55. PingER PingER Measurements from
38 monitors in 14 countries
Over 600 remote hosts
Over 120 countries
Over 3300 monitor-remote site pairs
Measurements go back to Jan-95
Reports on RTT, loss, reachability, jitter, reorders, duplicates …
Uses ubiquitous “ping” facility of TCP/IP
Countries monitored
Contain over 80% of world population
99% of online users of Internet

56. Surveyor & RIPE, NIMI
Surveyor & RIPE use dedicated PCs with GPS clocks for synchronization
Measure 1 way delays and losses
Surveyor mainly for Internet 2
RIPE mainly for European ISPs
NIMI (National Internet Measurement Infrastructure) more of an infrastructure for measurements and some tools (I.e. currently does not have public available data,regularly updated)
Mainly full mesh measurements on demand

57. Skitter
Makes ping & route measurements to tens of thousands of sites around the world. Site selection varies based on web site hits.
Provide loss & RTTs
Skitter & PingER are main 2 sites to monitor developing world.

58. “Where is” a host – cont.
Find the Autonomous System (AS) administering
Use reverse traceroute server with AS identification, e.g.: …
14 lhr.comsats.net.pk ( ) [AS COMSATS] 711 ms (ttl=242)
Get contacts for ISPs (if know ISP or AS):
Gives ISP name, web page, phone number, , hours etc.
Review list of AS's ordered by Upstream AS Adjacency
Tells what AS is upstream of an ISP
Look at real-time information about the global routing system from the perspectives of several different locations around the Internet
Use route views at
Triangulate RTT measurements to unknown host from multiple places

59. Who do you tell Local network support people
Internet Service Provider (ISP) usually done by local networker
Use puck.nether.net/netops/nocs.cgi to find ISP
Use to find upstream ISPs
Give them the ping and traceroute results

60. Achieving throughput
User can’t achieve throughput available (Wizard gap)
Big step just to know what is achievable
Spreadsheet \cottrell\iepm\wizard.xls
Most users are unaware of the bottleneck bandwidth on the path