February 15, 2005

SPEAKERS:
Matt Zekauskas, Internet2 [PDF] | [PPT]
Jörg Micheel, NLANR

AGENDA [PPT]

ATTENDEES
Warren Matthews, Greg Wickham, Connie Logg, Joe Metzger, Brian Tierney, Tony McGregor, John Estabrook, Kevin Tso, Paul Schopis, Alan Whinery, Roy Hackett, Jeff Bartig, Stanislav Shalunov, Jim Ferguson, Ronn Ritke, Jeff Boote, John Hicks, Andy Germain, Russ Hobby, Rich Carlson, Steven Senger, Livio Ricciulli, Eric Boyd, Jörg Micheel, Matt Zekauskas, and Susan Evett


Matt Zekauskas opened the meeting and outlined the agenda: passive internet analysis nodes, E2E TAG roadmap paper discussion, and open discussion. Russ noted that he’s been seeing increasing interest in measuring multicast and wondered if anyone else had heard about it. Jeff noted that, using BWCTL, it would be Unicast masquerading as multicast – there may be other ways to do this, but he cannot yet think of other options and would welcome input.

Jörg presented a review of problems he has encountered with passive measurements; good side is that it is the most precise way of observing packet level network dynamics, there are a broad range of potential uses in network research, operations, security, etc. It promises to scale with many parallel applications on the same systems – in all, it is very powerful and promising.

However, the bad side is that the hardware is both difficult to install and very expensive; equipment never seems to be in the right place when you need it, it is slow to deploy, software applications are hard to find (for end users and NOC staff – most are designed for network researchers!), there are major security and authentication problems and, most importantly, it is difficult to share the data – anonymity is difficult to ensure and, when ensured, the value of the data is greatly diminished.

Jörg suggested ways to fix the bad side – let experts fix the problems, share the gear (to keep the costs down per user), understand the needs of NOC staff/end users, get the researchers to develop suitable applications, and understand legal issues and develop acceptable Passive Measurement Policy. AA and security models for access to data are imperative – Jörg noted that this will require several iterations and repetitions of steps until all involved parties are happy. He suggested some solutions: 1) acquire lambdaMONs, which are more expensive but allow 160 measurements concurrently, 2) PIANOs, which allow multiple links to be tapped with a single system (great flexibility).

Jörg asked for the groups input on several issues; what are the needs/interests of networks and researchers? Also we need researchers with an interest in network security and authentication and legal issues. He noted that the biggest issue is funding – are you willing to pay and how much? For what?

Matt noted that there were several nodes on which he wishes he had a passive monitor; one participant commented that he thought the group should be talking with the Internet2 lawyers. Matt commented that the data from Abilene is anonymized; to allow the data to be used non-anonymized runs risks. He said that if one goes to lawyers with a question like this, they would say “NO!” of course. Jörg noted that Abilene data is not being stored (in a pure form) so that it cannot be subject to a subpoena. Jörg noted that, currently, he does not look at IP addresses (when looking at payload) or, when he looks at header information, he scrambles the IP addresses. By reviewing the payload, he can determine the degree to which worms and viruses are affecting the network but he cannot identify which machine is affected because he is not ‘allowed’ under current policy, to look at the IP address when looking at payload data.

Matt said that if you inject known traffic, you can find it in the payload (using pattern matching). Jeff Boote commented that various sets of groups that find particular pieces interesting so a single data set is transformed multiple times – and, once done, can it be reverse engineered?

Matt presented on the TAG Roadmap Whitepaper; he gave an overview of the group (showed the membership) and the reason for the whitepaper. The initial charge to the initiative was for a 3-year effort (based on the Fat PiPEs are Not Enough whitepaper in 2001); the TAG began brainstorming on what areas still needed work, what new areas should be addressed, and what funding/division of work was possible. Briefly, paper charged the E2Epi with improving an extending infrastructure (focusing on getting members of the community involved in this)

Conclusions of the whitepaper (in no particular order) were to 1) continue work on the global measurement infrastructure (try to deploy to campuses, for example) – but they also noted that layer 2 data, SNMP info and passive measurement data are largely ignored – and 2) they wanted the group to work on diagnostic end-user tools, 3) create a searchable repository of case studies (encourage community building) [although Stanislav Shalunov noted that it was less useful to build a ‘commiseration circle’ than to work on solving common problems and disseminating information on how to solve those problems wherever they occcur], and 4) better support networked applications (examples of requirements, guidelines, software libraries, development standards).

The group offered conclusions which included: 1) keep doing what you’re doing, 2) common language for interoperation (GGF NMWG schemas and Internet2-GEANT2 architecture design collaboration), 3) secure access, and 4) cross-domain testing. They wanted tools to use the infrastructure (reiterating that 1 st mile is still very important) and workshops to spread information. They suggested support for applications developers to inform them about problems encountered and ways to a) avoid the problem and b) debug the problems within the application.

The group was concerned about the current focus on ‘security’ which often translates into problems with performance; they recommended that the E2Epi group work closely with the S@LSA group, correlate work with the middleware end-to-end diagnostics group, and look at other groups that might affect or be affected by e2e problems (HOPI effort, for example).

Recent comments to the document (received after publication) include revisiting the problems NOC staff encounter. Matt asked for comments from the group – asking if network engineers had a wish list. Ways to understand network routing. Abolish NATs. Raising the consciousness of users (they don’t know or care how bad their performance is) on expectations. Instrument the code (get app writers to do this!). TCP has not scaled to current performance ability; when are we going to see practical applications? Stas noted that, with sufficient application of expert knowledge, high performance is always possible; current efforts are aimed at making ‘good’ performance available to all users. What is the focus of this group – fix problems? Solve problems? Get other folks to solve problems? Or alert communities to get them to do the work? (by ‘this group’ the participant was referring to the Internet2 E2Epi). How do you deal with new applications that radically change network utilization? [Matt noted that, for some projects, BitTorrent might be useful but it is currently associated largely with illegal file sharing.]

Matt noted that we’ve seen 6-7 Mbps of TCP flows; Matt has recently seen 6 Mbps of UDP flows. There are new programs available but they don’t all play well with others. Matt asked folks to send him comments.