Report from the 1st QIG Meeting

Rüdiger Geib, Doug Pearson, Dave Martin

1. Management Summary

The QIG kickoff meeting took place on December 1st, 1998, and was hosted by Northwestern University in Evanston, IL. The meeting was opened by Ben Teitelbaum who presented the organizational structure, the decision process and some statistics of the QBone. QBone participation was decided by the QBone Facilitation Group (QFC). Only QBone proposals offering reasonable resources to implement the Premium service within the 1st quarter of 1999 are eligible to participate in the work of the QBone Interoperability Group (QIG). The QIG deals with issues related to interoperability of different QBone IP DiffServ domains, and aims to have an implementation of a Premium service ready to support demonstrations of applications using the service during the April 1999 Internet2 member meeting. The QIG is a subgroup of the QBone Solutions Group (QSG). The QSG also includes QBone proposals which may join the QIG at a later stage, and deals with intra-domain IP DiffServ issues.

During the discussion it was agreed to produce a relatively stable version of the Draft QBone Architecture before the next meeting (January 26th, 1999). The Draft QBone Architecture describes the QBone Premium service ("virtual leased line") and defines some minimum SLA requirements to support the Premium service.

It was further agreed to collect and make available vendor information on their Differential Services implementations (if not restricted by non-disclosure agreements).

Matt Zekauskas gave a presentation on measurement tools required to perform QBone Premium service monitoring, and their location in the network.

Sue Hares presented the results of the QBone Bandwidth Broker meeting the night before. Four Bandwidth Broker prototypes for intra-domain IP DiffServ management are planned to be available for the Internet2 demonstration in April 1999. Agreement was reached on the protocols to be used for the intra- and inter-domain interfaces of the BB. A stable BB requirements document is planned for mid-January 1999.

2. QIG Kickoff Meeting

2.1. The QBone Organization

The organizational structure of the QBone was presented by Ben Teitelbaum (PDF/ PPT). Participation in the different groups building the QBone was decided by the QFC. The QFC evaluated 36 proposals of 73 organizations (more stats: PDF / PPT). Out of these, 13 were felt to be qualified for participation in the QIG. The QIG will work on "nuts and bolts" issues regarding the interconnection of different DiffServ domains. Intra-domain DiffServ issues will be tackled by the QSG, which consists of today's QIG members and all QBone proposals of potential later QIG joiners.

The Internet2 QoS Working Group will continue to guide the process of introduction of DiffServ services in the QBone until the QIG establishes itself as a stable and well organized body. At that stage the role of the I2 QoS WG will be taken over by the QIG.

While the QFC will not play a role in the future of the QBone, both the QIG and the QSG are expected to be pretty active groups from now on.

2.2. The QBone Architecture

The short term aim of the QIG is to enable demonstrations of applications using the QBone Premium Service ("Virtual Leased Line") at the Internet2 spring member meeting in April 1999. To reach this aim, consensus has to be reached on the Draft QBone Architecture, on the bandwidth broker requirements, and on measurement tools for the Premium service validation. The eager timeline and the requirement to reach consensus require a broad access to information. Network capabilities, service requirements and equipment capabilities have to be known and understood by all QIG participants. The discussion results led to updates of the Draft QBone Architecture (version 2 was available before the end of 1998) and to issues to be solved before the next meeting.

2.2.1. QBone Architectural Guidelines and Discussion

Ben Teitelbaum presented the Internet2 QoS WG guidelines to introduce Differential Services. As those results seem to be well known and to a large extent accepted, the discussions didn't touch the basics of the presented contents.

Only a few QIG participants were able to comment on the first Draft QBone Architecture this time. The Draft QBone Architecture specifies the Premium service and defines network requirements to support it (minimum SLA contents, equipment and measurement requirements, Premium call handling). Still some constructive comments were given (formulation of the packet delay variation as an absolute figure in milliseconds). It was agreed to finalize the document before the next QIG meeting and have a phone conference if necessary. The latest draft of the Draft QBone Architecture may be found on the QBone home page under Architecture.

The discussion continued with the presentation of individual network DiffServ features by the participants representing networks. This quickly revealed that at the time of the meeting most network operators were not able to provide complete information on their ability to support DiffServ services. Instead of a summary of the individual presentations, here a list of identified issues:

2.2.2. Report from Internet2 Measurement Working Group

Matt Zekauskas informed about the measurement tools required to validate and monitor the QBone DiffServ service (presentation in PDF or PPT). The main issue is whether the hardware, software and MIBs required for the tools to support DiffServ codepoints are available.

As a result of this presentation, version 02 of the Draft QBone Architecture now contains the following information.

The following parameters are required for auditing and debugging QBone services:

Several tools offer the required measurement functionality. Any tool to be applied will have to support the relevant DiffServ parameters in one way or another. In order to measure One-way Packet Delay and Instantaneous Packet Delay Variation, sequence numbers of the packets to be measured have to be captured. The One-way Packet Delay measurement further requires synchronized clocks. The QBone Measurement Working Group produced the following list of tools to support Premium service measurements. We added some words on parameters to be measured and DiffServ-specific requirements.

Surveyor

The Surveyor may be used to measure performance parameters of a separate measurement flow as defined by the IETF IPPM Working Group. Surveyor DS measurement flows should be sent at least in parallel to all DS connections (i.e. aggregate ingress-egress flows).
Location: At all DS ingress/egress routers of a specific QBone DS domain.
Measured Parameters: One-way Packet Loss, One-way Delay of a dedicated measurement flow.
DS Requirements: DS Code Point for EF must be set in measurement packet flow.
Possible Improvements: Compare the Premium Flow to a BE flow. Study time-series data to understand one-way delay variation.

OCxmon (or RTFM)

The OCxmon may be used as a multi-purpose operational support tool. It could be used to measure the QBone Premium performance parameters of aggregates, if samples of separate OCxmons of one domain can be linked for the evaluation. The OCxmon currently is only available for OC3 and OC12 IP over ATM interfaces. A POS version is under development. OCxmon could further be used to build usage statistics (i.e. DS load and DS load vs. DiffServ reservation). Location: All interfaces of a DS Domain. Preferably at ingress/egress interfaces.
Measured Parameters: One-way Packet Loss, TCP ipdv, load measurements, usage statistics.
Possible Improvements: OCxmon without appropriate filters to evaluate the measured data is not useful for operational purposes. The ability to link separate measurements strongly depends on the clock accuracy (currently probably insufficient; improvement expected) and the amount of captured data.

MRTG

MRTG may be used for loss related performance statistics and DS load as well as DS load vs. DS reservation statistics. As MRTG evaluates data read from routers by SNMP, the router MIB must support all relevant DS objects.
Location: key routers.
Measured Parameters: One-way Packet Loss, load measurements, usage statistics.
Possible Improvements: Router MIB has to support relevant DS objects.

Traceroute

Should run in parallel to the Surveyor. Statistics in the changes of routes used by surveyor traffic may help to interpret measurement results. Traceroute statistics should be gathered at least from all DS connections (i.e. aggregate ingress-egress flows) of a domain.
Location: At all DS ingress/egress routers of a specific QBone DS domain.
Measured parameters: Route information.
DS Requirements: None.
Possible Improvements: N/A.

MRT

MRT is suggested to monitor and debug inter-domain routing problems. It further allows a real time view on installed routes and provides information on route stability. It could be used at DS ingress/egress routers to support troubleshooting and to help to interpret performance statistics.
Location: At all DS ingress/egress routers of a specific QBone DS domain.
Measured Parameters: Real-time route information.
DS Requirements: None.
Possible Improvements: N/A.

DS Ping

A DS ping is suggested as a future development. A DS ping may be linked with a Best Effort ping and the replies may directly indicate differentiated service.

2.2.3 Report from the QBone Bandwidth Broker Working Group

Sue Hares informed about the first meeting of the QBone Bandwidth Broker WG. The group agreed to use the COPS protocol for intra-domain BB interfaces and the DIAMETER protocol for inter-domain BB interfaces. No agreement was yet reached on the protocol for customer-BB communication. Four intra-domain BBs are expected to be available for demonstrations at the Internet2 spring member meeting in April 1999. In order to keep this timeline, BB requirements will have to be stable by mid-January 1999.

Inter-domain BB implementations may not be expected before the second half of 1999.

The BB WG further offered support in the creation of interim solutions to support the QBone DS service operation until BB implementations are available.

For more information check the QBone BB homepage.

2.2.4 Next Steps

The following actions were felt to be most important to proceed on the introduction of the QBone Premium service:

From the discussion on the Draft QBone Architecture it can be said that operational topics (e.g. Premium "call" definition) may be expected to become issues soon as well.

3. Next QIG meeting

QBone Interoperability Group (QIG) Planning Meeting
January 26th, 1999
MCNC, Research Triangle Park, NC