Discussion

In an effort to involve the maximum number of applications to get a flexible diagnostic platform that works for many types of middleware, the group resolved to try to involve Mitch Kapor's Chandler effort and Penn State's Lionshare project in these discussions. While there was more desire to involve other peer-to-peer style architectures, the group didn't know of any other peer-to-peer solutions that were suitable for enterprise use, the environment in which these tools are intended to be most useful.

End-to-End Performance & Diagnostics

Matt, George, and Russ were on the call representing Internet2's End-to-End Performance Initiative, and related some experiences they've had in approaching similar problems. The initiative starts at the bottom of the protocol stack, tracing issues from the network on up through the application at the top. This is partly out of pragmatism, given that TCP seems to be a common feature of many problems they encounter. Maximum leverage when it comes to tuning the system seems to come from a bottom-up approach as well.

Matt noted that it will be important to evaluate where middleware diagnostics intersect end-to-end diagnostics and precisely where these boundaries should be drawn. However, the middleware diagnostics may have a slightly narrower focus in that there will be no attempt to handle application performance benchmarking or tuning.

Scenarios

Scott found Von Welch of NCSA's Grid diagnostic scenarios almost "humorous, because anyone who's worked in support would recognize everything. So, that might be a good way to involve people: 'If you've ever felt this kind of pain, join us.'" While his scenarios were focused on Grid deployment, one could very well have crossed out "Grid" and written in several other applications without changing much. Given this similarity, Mark suggested that at least three application scenarios would be sufficient to continue, while making sure to take note of novel architectures and other opportunities to expand the diagnostic tools.

Chas still wants to make an effort to canvas enough of the area to know what the most important applications from the ones selected are to constituent campuses, intending to collect "something like 16" opinions. From there, he would select particularly interested institutions for interviews and a tally of the most important features. Suspecting that many campuses already run applications that may differ from the setup of a more middleware-aware campus, Steven cited that one feature we might commonly find in members is password replication. In an effort to make an illusory SSO, some campuses may have a web front-end that proceeds to set the user's password, in Active Directory, the LDAP directory, etc. "Typically, these systems reset 3 of the 4 passwords, one fails, and the person ends up at the help desk a few days later."

Kevin related that, when he was with MCI, he saw a fascinating presentation from Sony regarding their monitoring capabilities for Everquest, a massively multiplayer game that averaged hundreds of thousands of simultaneous players. Given their need for powerful monitoring tools of the server farms, Kevin "walked away thinking they have better visibility into end-to-end Internet performance than anyone else." This may be another source of unique monitoring expertise that could have direct relevance to these projects.