February 15 , 2005

SPEAKERS
Jeff Boote, Internet2 [PPT]
Rich Carlson, Internet2 [PDF] | [PPT]

ATTENDEES
40+ (SRO) – (note – some folks left for lack of chairs)

Eric Boyd opened the meeting and introduced the focus of the meeting (overview of the updates to specific tool – NDT – and the joint architecture currently under development with GEANT)

Rich Carlson gave an overview of the updates to NDT (Network Diagnostic Tool); under a recent NSF grant, they are focusing research on creating a duplex mismatch detection algorithm (paper on this at PAM2005). He gave a brief overview of the history of NDT development and then focused on current and future work.

He identified the problems with detecting duplex mismatch – they started by identifying when collisions occur. To generate analysical models for loss, they tried 3 methods: 1) Stanislav Shalunov modified his Thrulay package to generate Poisson streams, 2) they used UDP packet trains, and 3) they used TCP data (from NDT). They created a test environment to create paths that could be modified to create all 4 different configurations that exist during duplex mismatch problems.

Stanislav generated a graph of mismatch loss probability, using Thrulay and, after running and plotting the results of 10 tests, he found that it graphed on the predicted curve. This allowed them to identify several mismatch behaviors:

1) Remote server with a local client (switch = full, host = half) – full duplex side keeps sending but the ½ duplex side keeps stopping whenever a collision occurs (which happens over and over because the switch doesn’t stop sending and the host keeps restarting in the middle of a stream of messages coming from the switch).
2) Remote source with a local client (switch = half, host = full) – the acks get lost on the ½ duplex side; timeouts occur and losses (one packet, time out, one packet, time out – with 2 duplicate packets and one ack each send); this seriously affects the throughput!

Underlying assumption is that the model is correct if the inter-packet gap is less than time to generate and transmit ack packet, however, tight links (T1, DSL, cable modem) violate this assumption – thus a mismatch on a home LAN would not be detected by a remove server because of the time between packets.

Rich reported on conclusions they are gathering; the duplex mismatch detection algorithm is under development, they are analyzing existing race files, and talking with NDT administrators to review their log files. They expect to be investigating packet train model and re-releasing NDT with this new feature in the near future.

Jeff Boote gave an overview of the existing tools and activities: BWCTL is both stable and fairly well used; he has several feature request but has not had time to modify the code since September 2004 (parallel streams, multicast). OWAMP specification has been significantly modified via IETF working group and has been submitted for publication via the IESG. He hopes to have another version of our implementation before the Spring Member Meeting (May 2005) – it will not be backward compatible because of the changes to the specification that is being approved by the IETF standards process. He intends to change the port number so that the two versions could be running concurrently; Jeff will run them concurrently on Abilene, watch who is still running the old version, and, over time, contact users – directly and via the email list – to get them to switch over in a reasonably timely manner.

He noted that there is a PMP registry (see http://e2epi.internet2.edu/pipes/pmp/pmp-dir.html) and encouraged people with measurement points (running the piPEs tools or others) to list them. He introduced the Internet2 Detective and talked about how this is being revised to use the SURFnet Detective as a basis – this is a way to introduce naïve users to these tools.

Jeff described the current effort with GEANT2 – rather than build 2 separate interoperable frameworks, we decided to build a single framework (guaranteed to be interoperable) that has sufficient flexibility to allow any framework user to control the pieces they would like to implement without forcing them to use all of it. Eric Boyd noted that, up to now, the participants in these discussions have been Internet2, GEANT developers, and ESnet – we would like to have more input from other campuses, networks, and developers. He is the point person for being added to these discussions and can be contacted at eboyd@internet2.edu.

Jeff gave a list of the design goals for the framework – these include the fact that networks are dynamic, with tools and equipment being added and removed on a constant basis, and the framework needs to be able to deal with this. The framework needs to evolve over time to meet the needs of new applications and users; it needs to be services-based so that new services can be added as they are needed. The basic services included in the design include: lookup, authentication, measurement point, resource protector (which includes authorization – the resource needs to be available and the user needs to have authorization to use it at the requested time!), measurement archive, and transformation (topology, etc.).

He described how tests are requested in this framework – the discovery of lookups and authentication/authorization portions are the most challenging at this point. The plan is to have data shared in a P2P manner – lookup services would know where each other are, measurement points would know where to find each other, etc. Jeff went into details about each of the services and how they are expected to work.

Matt Zekauskas asked how much privacy would be required for tests? For data? Jeff noted that the users would probably need to provide more identification data for test requests than for access to existing data. He noted that privacy becomes a concern when the framework extends to the desktop – if the test requests are only coming to/from NOCs, there is less of a privacy concern, but end-users will need more privacy to be willing to participate in the framework. This is a known, eventual concern so it is being carefully considered in the development of the framework.

He described the process flow – from the client end, it would start with discovery (find lookup servers, use the lookup serves to find MPs), then authenticate, and finally request and execute tests (that are approved). Jeff noted that the resource protector service could be chained to control aggregations of shared resources; the policy could restrict types of users or a component of users to access resources within specific limits. For example, on a campus, the measurement node may be a single box – having chained resource protectors for each tool could review the authentication and accessibility of resources for both the tool and the host individually. A client resource protector could deny a test because another resource protector for a specific tool was already running a test.

Jeff noted that the general framework is still being refined – we are developing use cases to validate the architecture and creating a simple prototype within the framework. This will be simplistic but will contain the service-to-service flow; the ‘deadline’ for development is summer 2005. This project is open source shared development; currently considering Modified Berkeley Licensing unless the European community is uneasy. We are splitting into development groups at this point.

There are 3 ways for participants to participate: 1) deploy nodes, 2) read the design documents and consider your own use-cases and challenge the development document if necessary, and 3) help as a developer (code writing, reviewing, etc.).

Q: Nodes spread out, one of my folks reports a problem between site A and B. how do you prevent the test nodes from being bombarded.
A: we are discussing pre-emption (NOC engineer can jump in front of the list, for example); it is also based on ‘best-effort’ – if you can’t find an agreed upon time slot, out of luck. Another option is that whenever the test has already been run within x timeframe, the test is automatically denied with a pointer to the existing data. This is a good case tho and we’d like to have you document it for us.

Q: Can a test requester view the tests scheduled at any given time?
A: We haven’t gotten specific on this but will consider it, in the future.

Q: Is there a plan to co-locate services? Are they required to be co-located?
A: We’ve carefully arranged to have the services as interchangeable parts – this, unfortunately, allows a deployer to make choices. As we go along, we will have a set of ‘recommended’ deployments with rationale’s for each.

Q: Any interest in deployment in Australia? We have APAN but not AARNET.
A: The AARNET folks are running their own measurement infrastructure.

Q: Do I need root privileges to install OWAMP, NDT, and BWCTL?
A: Not at this time – OWAMP may, in the future, but doesn’t at this point and BWCTL and NDT will never require root privileges for installation.

Eric closed the meeting with an overview of the focus of piPEs efforts for the upcoming year (framework and prototype development, tool development, and deployment) and contact information: http://e2epi.internet2.edu/ with links to piPEs (overview and software), tools (BWCTL, OWAMP, and NDT), and a directory of available measurement points. He noted that part of this deployment focus will be on getting the GigaPoPs to deploy the nodes and then hold a workshop to get campuses connected to that GigaPoP to begin deploying boxes and setting up regular measurements between these nodes. Internet2 is spearheading an effort to begin this process with a workshop scheduled in Atlanta and one under consideration in Minnesota. Eric explained that, in addition to working with networks the group also wants to work with research communities (currently working with HENP and VLBI) that would benefit from having nodes up on various networks the groups cross.