The chair introduced the first of four problems he hoped to resolve in the meeting: "Problem #1: The QIG is a farce" (as an organizational construct). This provoked immediate discussion. There was general agreement that the QIG meetings had resulted in many fruitful discussions and had produced two very good draft documents, but that there really was no good reason to keep these meetings closed. It was further agreed that, although the backbones are somewhat lagging in their QBone implementations, the previous non-readiness of the backbones was more of an excuse than a real reason for slow progress in interoperability testing. For example, why aren't there more interoperability tests between universities connected to the same gigaPoP? It was also pointed out that, with the backbones as lightly-loaded as they are, there would be value to starting wide-area testing, even without EF forwarding in the middle.
There was also general agreement that the original process by which the working group would oversee the QIG was too heavyweight. This led to a discussion about what to do with the QIG and how to explain the decision to current QIG participants and non-participants. A consensus was reached on opening up the QIG to broader participation, which, since the original purpose of that group had been to serve as a tightly focused organization with carefully controlled membership, amounts to more or less dissolving it.
Discussion then moved on to "Problem #2: "The QSG is a Vacuum". The group agreed that opening/dissolving the QIG would also help spark more QSG activity (since it would no longer be perceived as second class). A comment was made that it will be difficult to find 10 more Sue Hares' (!), but that it would be valuable to find 2 or 3 to lead interest groups on topologically specific areas ("gigaPoP QBone engineering", "campus QBone engineering", etc). Other suggestions were: that we more actively "champion" the Premium service, the centerpiece of the proposed QBone architecture; that a test plan - a way to prove that the proposed architecture does in fact work - be created, and, especially, that instrumentation and measurement tools be brought online as quickly as possible.
The chair then introduced the closely-related Problems #3 and #4: respectively, "QBone ETA Slippage", and "Will they come?". Teitelbaum noted that senior UCAID management is very eager to see the QBone succeed and that there is a management/PR perception that we may be slipping a bit in our promise to be actively testing interdomain DiffServ services by Summer 1999. John Wroclawski nicely framed the relationship between Problems #3 and #4, by asking if the first time a customer (as vs. management) asks for QoS services, will we be able to say yes? While the point of this comment (no real current demand from QoS-needy applications) was not lost on the chair, Ben pointed out that we already have customers of a sort already: QIG gigaPoP participants and their associated application teams that think they are ready to do wide-area testing. There was general agreement that it would be best to keep our noses to the grindstone and stick to the original plan, rather than rushing to declare a premature victory.
It was also agreed that it is crucial we be able to measure QoS performance. This led to discussion on how hard it is to measure QoS on a lightly-loaded network. It was pointed out that it is easy to create artificial congestion, and that therefore we don't have to wait for real congestion in order to test QoS and the tools to be used to measure it. It was further observed that with the one-way delay variance tests in the architecture, it would be possible to measure queuing effects in lightly-loaded non-conforming networks. The planned "QCon" event will also create a more controlled testing environment in the short term.
The chair then brought the discussion back to the four problems as originally presented, and restated the group's conclusions. In general, there was strong sentiment for a more activist, "nudging" role for the QoSWG, and for the need to "build a virtual community and remind people they're in it."
Discussion then moved on to a review of the draft QBone Architecture. Again the discussion was dominated by the problem of measurement. Matt Zekauskas, chair of the Internet2 Measurement Working Group, brought the group up to date on the relevant portion of the architecture document, emphasizing that the architecture specifies only metrics to be obtained, not how to obtain them. Some issues raised were: The value of measuring routing effects (a suggested metric area), even though the QBone Premium Service exempts routing effects; "How do you know if your QoS is working when everything's fine?"; We must be clearer about whether we are doing specification or verification; Are we starting from scratch or "writing down what vendors are doing"?; Why not require passive measurement (A: it's expensive); In light of the complexity of the problem of measuring QoS, there was discussion of the possibility of splitting off the measurement portion of the draft QBone Architecture into a separate document, but eventually it was agreed to keep it where it is -- central to the QBone architecture.
Terry Grey suggested that a kind of application-specific measurement tool might be an infrastructure of remotely-configured video reflectors (i.e. to test your own video streams).
The second half of the architecture discussion concerned the the QBone Premium Service definition and issues of how one would actually engineer it. John Wroclawski called the group's attention to three problems: first, the architecture says nothing about how to engineer a QPS service; second, the document needs to manage expectations better about what a Premium service can actually deliver; and third, that the service-MTU concept was problematic in a subtle way that he didn't have time to explain fully (!). It was pointed out that traffic engineering wasn't supposed to be part of the spec, but was rather a concern of the participating QBone domains. It was agreed, however, that providing more network engineering support to QBone participants would be a good idea and that we should draft a supplementary advisory document on traffic engineering. With respect to John's un-uttered nit, Ruediger Geib, Larry Dunn, Scott Brim, John Sikora, Ben Teitelbaum, and Jim Grisham all agreed to circle later with John W. to understand it better; Ben also volunteered Kathie Nichols and Roch Guerin to scrutinize the service definition with this group.
Finally, the chair called for reports from five MoU partners present at the meeting. Konishi Kazunori from APAN reported that Toshiba and others have DiffServ working in their routers and that a demo is being planned between Japan and the San Diego Supercomputing Center, using VideoCharger and MPEG. Work on bandwidth brokers, including IPv6 versions, is also underway at Osaka University and Hitachi. This work is based on FreeBSD. John Dyer of TERENA stated his openness to communication with the QoSWG and TERENA's wish to let the QoSWG lead and to avoid duplication of effort. Klaus Lindberg of FUNET gave an update on Finnish supercomputing and the situation in Finland more generally. FUNET wants to be able to test the routers required for QoS. Lindberg reported that "we have a countrywide multicast network" which needs QoS already, but that work on QoS is only just getting started. He also said that "we can use real network load" from NORDUnet to test the routers. It was pointed out that edge country links in Europe are expensive, and that this is also a place where QoS is already needed. John Coulter from CANARIE/BellCanada gave an update on CA*Net2/3. Three Canadian universities are completing gigaPoP testing; eight more gigaPoPs are in the works. This will be followed by WAN testing, then implementation of the backbones. Finally, Arni Raghu from Rutgers expressed his organization's desire to engage with the QBone. They have done QoS research making use of RSVP at the edges and DiffServ in the middle. They have also tested a mini-BB in a small network, and have "generic PHB identifiers" in the works.
The meeting was closed with an exhortation to join Net'99 upstairs and
hear Reed Hundt's speech, which had just begun.