|
|
|
| E2E Tools
Tutorial:
Internet2 Fall Member Meeting Session
Summary
|
September 27 from
3:00 - 4:00 pm (CDT)
SPEAKERS
Bob Riddle, Internet2
Stanislav Shalunov, Internet2
ATTENDEES
James Deaton, David Matthews-Morgan, Gerry Creager, George Brett, Yang Xia, Jim Diamond, Connie Logg, Todd Reed, Lee Varian, Steve Kapinos, Kevin Walsh, Brian Tierney, Don Choi, Eric Boyd, Stanislav Shalunov, David Lapsley, Susan Evett, Rich Carlson, leobino Sampais, Athamassios Liakopoulos, Jose Montiero, Borje josefsson, Jiunn-Jye Chen, herb Kuryliw, Larry Dunn, Laurie Kirchmeier, and Tom Bray.
This is the sixth Tools Tutorial offered by Internet2’s E2Epi. Russ Hobby opened the meeting by introducing the two presenters: Bob Riddle and Stanislav Shalunov.
The Internet2 Detective
Riddle discussed the development of The Internet2 Detective – it was developed without a budget and aimed at the majority of desktop users (built for a Windows platform using Visual Basic). After it was released on Windows, Internet2 heard from campuses that, although they didn’t need it for Unix (because they already knew how to run traceroute, etc.), it would be useful for Mac OS X. The newer releases of The Detective are also offered for Mac OS, using Real Basic.
Riddle discussed where The Detective has been, where it is going, and what purposes it serves. Primary goal of The Detective was to answer the question: “Is there any hope my application will work?” This allows users to call networking experts and say “I need multicast and I don’t have it” or “I need 30 Mbps and The Detective says I’m only getting 15!” The Detective only gives users hope that the application will work – if the test response is red lights, it won’t work. The Detective just gives the average end-user the information to tell network people what isn’t happening. The Detective is intended as a “finger pointing tool.”
Riddle reported on the new beta version of The Detective that will test for IPv6 – unless the user is trying to run this on Windows 90 or 2000, which do not supports IPv6. The NDT details button points the user to the Network Diagnostic Tool and the piPEs link points you to web pages for that project. These are redirects, rather than information included within The Detective itself, because they require more knowledge than the average user would have but many Detective users can still run them.
CANARIE has a Detective of their own, based on the code Internet2 provided them after the last release of The Detective. SURFnet tested out our Detective and it didn’t meet their needs – they had a goal to have it run a variety of tests. They based it on the runtime library (freely accessible) called Rebol – the code is not necessarily available but the library is. You could create a Detective for yourself running some, all, or only one of their tests – the configuration file identified with one(s) of the options to make available.
The Future of The Internet2 Detective:
- If my Detective could talk to their Detective…
- If my Detective could talk to their server…
- If my Detective could run on all common platforms…
- If all the Detectives shared a common code base…
- If my Detective was configured both as an “is there any hope” and “in-depth network diagnostic tool,” more in line with NDT work…
Riddle reported that he is meeting with one of The Detective code developers this week and will meet with the SURFnet developers, as well, to get these options made available. He asked what folks were looking for in the tool.
Q&A
Q: Right now, it’s an end-user application; are there things you could pop into a standard API for application developers? The application developers could use pieces of the tool to help self-diagnose.
A: That is one of the things the SURFnet version of the tool addresses. The world has become more complicated since Internet2 started this – the tools have to get past firewalls, NATs, and even desktop firewalls now.
Q: UDP performance is an issue – the SURFnet reporting on UDP can be inaccurate. Is there a way to do a simple UDP test?
A: Actually, the Internet2 Detective runs UDP as an “is there hope?” test. Back when DDoS attacks started being a problem, places started filtering ping; The Detective doesn’t use ping – it uses EchoA, which isn’t filtered because “who uses it?”
THRULAY
Stanislav Shalunov gave a presentation on the Thrulay tool he developed to test network capacity and delay; it was developed because there were no existing tools that could test both simultaneously. This was developed to run FAST TCP tests (since FAST TCP is delay-based rather than loss-based) but delay is as important as throughput. Shalunov looked at a range of tools (including Iperf, netper, nettest, nuttcp, etc.) but they did not allow you to measure delay and throughput together. Then, Shalunov reported on his Thrulay findings and possible uses:
- Internal (in host) queues
- FAST TCP testing
- Better Understanding of TCP Behavior
Shalunov showed an example of machine-readable output – but noted that you could send it straight as a Gnuplot data file. It reports on Mbps, RTT, MS min, MS avg, andMS max.
Q: Is it true that you never see a loss because this is a tcp stream?
A: I send blocks that may be split into different packets, each of which contain time stamps; when they return, the end timestamp is compared to the start time. (This does not work as well on modem networks.) The data that the server sends is packed onto acks.
Internal Queues
These are a very common problem when windows are large – not so much on FreeBSD, but in standard Linux, there are persistent, small delays. Matt Zekauskas pointed out that being windows-bound allows Linux to get over the 75% barrier because there will always be something to send from the huge delay. Shalunov pondered if internal queues are good or evil and considered that they were somewhat evil since there shouldn’t be a need for a very large internal queue.
He showed a slide of delays for a bulk Reno TCP, with actual and minimum delays – Zekauskas asked why the spikes were so sharp – was it because a whole window was omitted at this point? Shalunov said he was going to get to that in a minute – likely an arrival of acks. The experiment for which this tool was originally designed, FAST TCP testing, was between several well-connected machines (four at the Sox GigaPoP, two at the Pacific Northwest GigaPoP, one at the NC-ITEC, and one at PSC). One stream was conventional TCP, sent so testers could see how the other three streams affected conventional traffic. He showed the delays during the test – there was a brief period of congestion but otherwise a very flat line.
The tests indicated that FAST doesn’t seem to have a negative affect on conventional TCP throughput or delay. The result of the experiment is that delay measurement in performance tests seems useful – it might uncover some details (such as internal queues) that would not be obvious or available otherwise. Shalunov has not compared these results with Web100 results – it would be especially interesting to look at Linux.
Summary
Delay measurements can reveal internal queues, which provides a new way to understand the behavior of TCP, where losses occur, and gives extra confidence that a loss actually happened. The special flavors of TCP that are delay-based have good reason to look at internal queue delays but even the traditional TCP might be interested.
To download, see: http://www.internet2.edu/~shalunov/thrulay/.
|
|
|
|
|
|
