*Internet2 QoS Working Group Meeting* Fall 2000 Internet2 Member Meeting, Atlanta November 1, 2000 *Attendees* Shoichiro Asano - NII asano@nii.ac.jp Michael Bucheit - AIV mbucheit@aivllc.com Lynn Cannon - WSU cannon@wsu.edu Doug Carlson - Cornell U. dc21@cornell.edu Valentino Cavalli - TERENA cavalli@terena.nl William Chimiak - ECU w.chimiak@ieee.org Ben Chinowsky (scribe) - Internet2 chinowsky@internet2.edu Gerry Creager - TAMU gerry@cs.tamu.edu Claudia de Luna - JPL claudia.de.luna@jpl.nasa.gov Dick desJardins - NASA NREN rdesjardins@arc.nasa.gov Wilson Dillaway - Tufts U. wilson.dillaway@tufts.edu Larry Dunn - Cisco ldunn@cisco.com Jeff Eschbach - Motorola jeffrey.eschbach@motorola.com Marshall Eubanks - Multicast Tech tme@multicasttech.com Philippe Galvez - Caltech philippe.galvez@cern.ch Andy Germain - NASA GSFC andy.germain@gsfc.nasa.gov Terry Gray - U. of Washington gray@washington.edu Thierry Labbe - Alcatel thierry.labbe@usa.alcatel.com Olivier Martin - CERN olivier.martin@cern.ch Toru Maruta - KDDI to-maruta@kddi.com Aziz Mohammed - Alcatel aziz.mohammed@usa.alcatel.com John H. Moore - NCSU jhm@ncstate.net Mark Pullen - GMU mpullen@gmu.edu Victor Reijs - HEAnet/SURFnet victor.reijs@heanet.ie George Sadowsky - NYU george.sadowsky@nyu.edu Fay Sheu - NCHC, Taiwan c00yzs00@nchc.gov.tw Corkey Smith - Boeing Phantomworks corkey.smith@boeing.com Jeff Smith - NASA GSFC jeff.smith@gsfc.nasa.gov Thom Stone - NASA ARC tstone@mail.arc.nasa.gov José A. Survagy - RNP2 survagy@unifacs.br Ben Teitelbaum (Chair) - Internet2 ben@internet2.edu George Uhl - NASA GSFC uhl@rattler.gsfc.nasa.gov Shigeo Urushidani - NII urushidani.shigeo@lab.ntt.co.jp Ken White - NASA MSFC ken.white@msfc.nasa.gov Matt Zekauskas - Internet2 matt@internet2.edu *Discussion* Ben: How many have read the draft charter? (only about one in four) QoS WG was originally closed -- Ben & Guy wanted it that way to get work done -- Russ Hobby's new IETF-based guidelines -- IETF-style open working groups -- given these guidelines, "not going to decide anything too official" today -- mailing lists will be central. Lists: qos-wg was closed, qbone was open -- agreed that Ben will move qbone to qos-wg and open it -- add yourself to qos-wg. Slashified QBone site: not really a forum, but a place to post information -- response to calls for an experience database -- Ben Chinowsky is new webzine editor; expect arm-twisting from him. Feb. 14 is milestones day for WGs. Membership for design teams should be identified by then. Recognition of importance of metrics. Plan for today's meeting is charter, then 15 min. for Victor on apps-level measurement, then more charter; aiming to be done by 3:30. Basic structure of charter: high-level objectives, background about WG history, things to do, things to not do... Intro restates original goals and adds traffic-engineering goals. Xxx: Needs to specify that these are QoS WG goals rather than just Internet2 project goals. Ben: Not really, just fitting QoS WG goals into the big picture. Xxx: Name of WG should be in the first paragraph and fitting-in should be more explicit. Ben: OK. St. Sauver's main point is studying economics and finding out where QoS might be needed. It's not obvious that work set out in paragraph 1 is needed at all -- thoughts? Larry: End-to-end/campus infrastructure issues are counterexamples to the "everything's cool" view...even in a well-provisioned environment like Abilene there are congestion problems. Xxx: I'm in the telemedicine world -- bandwidth is still expensive, and certainty is required. Our H.323 experience was not favorable. Ben: Remember, QoS doesn't create bandwidth -- someone has to lose. Larry: Right, I'm willing to pay for bandwidth. Terry: Need to look at all the things besides queuing and switches that hurt performance -- understand what we can control. E.g. my experience of listening to a seminar online -- bad on wire on desktop, great on wireless on laptop. A "personal hot button" is that after years of beating on Cisco etc. to help understand transient net problems, we still don't. Lots of finger-pointing, little knowledge. Ben: Measurement infrastructure work helpful? Terry: I hope so -- transient net problem requires persistent multi-site monitoring, or "magic bullet" to take same path taking snapshots along the way. George U.: Requires router internals as well -- extra metrics that you might consider. Michael: Have to find a common language in QoS community -- start the process with defining the problem, then agree on measures that make sense, then analyze, verify, control. Let's not reinvent what's already known about process management. In particular, we should start with the application. Speeds things up a lot. Ben: Part of the problem is that we are trying to enable apps that don't yet exist -- one idea is to build basic service primitives. Michael: But every industry does that -- let's identify the top 3 requirements for the network, then agree on measurement. Xxx: Networks are stochastic -- the only way to tell if DiffServ is the right thing is to try it -- no one has done this on a large scale yet, and yes, we need objective criteria for how to test. We're a research organization; even if we find out that it can't be done, that's OK. Ben: But we are an *applied* research organization, so we need to be sure there is a real problem. Xxx: I don't think we need to worry about that. Xxx: Throwing bandwidth at the problem is a limited solution. Larry: Required reading is the current version of Terry's document on the cost of bandwidth at http://staff.washington.edu/gray/papers/; see also http://www.internet2.edu/qos/wg/papers/papers.html. Aziz: Seems like question is already settled: DiffServ, BB, measurement. Ben: Focused on supporting hard real-time apps, coming together but it's a long road. Point is that there are things we can do on the routers now. I don't want to throw out what we've already done. Recap history -- fat pipes and smart pipes, architecture document frozen since August 1999 (though with placeholders and entirely missing signaling section, it's basically sound). Held workshops. Phil Chimento is now with Torrent Networks. Charter: 1. Empirical collective wisdom 2. Theoretical collective wisdom Xxx: Yes, these should be separate, though they can reference each other. 3. Promoting QoS in Internet2 infrastructure Xxx: "growth" makes it sounds like it will just happen -- "deployment" is better because more active. Xxx: But not whole picture. Xxx: Testing and deployment then. Xxx: Make it clearer that experimentation and applied research are what we are doing? Ben: Just capture what's been done, or initiate inter-domain QoS testing? Xxx: The latter. George U.: End-to-end QoS -- looking at other mechanisms besides DiffServ? Ben: Good drafts exist on MPLS/DiffServ interactions. Xxx: Isn't MPLS out of the question in the current infrastructure? Ben: Yes, if we restrict to what happens in inter-domain peerings, but still useful for accounting and route pinning. 4. Where does bandwidth glut make QoS unnecessary? Xxx: Take it out. Xxx: Where it's relevant... Ben: Only temporary conditions... Xxx: How about a cookbook? Xxx: Telemedicine goes to rural areas where bandwidth is expensive -- I like the idea of a cookbook. Xxx: How do we test? Xxx: Testing the inter-domain interoperability of various QoS implementations, one of which could be overprovisioning plus measurement. (general agreement) 5. QBone Xxx: Keep clear that QBone and QoS WG are separate; rewording of previous bullet helps here...specify per-domain SLA and behavior, and domain can implement. Xxx: Better to specify QoS as goal and DiffServ as important implementation detail. Xxx: I like the idea that a domain can do QoS just by doing things at its edges. 6. LBE Ben: In particular, voluntary marking of packets for LBE service -- could enable interesting apps -- parallel SETI@home using idle time of net instead of idle time of machines. Plus, can be done easily. George U.: Already shot down in IETF. Ben: No, what was shot down was a new PHB for this purpose; in fact, Brian Carpenter said yesterday that he is about to publish a bulk handling PDB draft that describes how to do the LBE idea with existing PHBs. Xxx: Lots of real-world apps, e.g. backups. Ben: Enables Napster, not prohibits it...all the WG really needs to do is write a paper recommending it and pick a DSCP. Stas: also question of whether you want to configure minimum departure rate or allow it to be completely starveable. 7. Partnering with Internet2 apps initiative for candidate killer apps Ben: Should at least schedule next QoS meeting in conjunction with killer-app meetings. Roch Guerin wants to broaden this to document application needs more generally. ===== Victor Reijs presentation: Megaconference II testing, apps behavior on impaired nets, TERENA/DANTE. Most usual tools are end-to-end testing, not edge-to-edge -- want to do app-layer net testing. Worked with 320 Kbps H.323 video stream. Tool is new and still proprietary but has potential. Want to simulate impaired networks and determine app quality for e.g. H.323. PERT: Performance Emergency Response Team. See http://www.heanet.ie/heanet/projects/nat_infrastruct/cosmega.html. NISTnet has Linux tool to generate impairment. ===== Ben: Notes from this meeting will go to list, then we can start talking about milestones. 8. Filling in QBArch gaps (no comments) 9. Communicating and sharing for tech transfer Xxx: Why not group with first two items to produce a communication meta-item? Ben: OK. 10. Partnering with Measurement WG Ben: Will the measurement points you use for fault isolation be the same as ours for QoS? Matt: Ours are a subset of yours. Measurement architecture is coming -- I want to make sure there is enough there for what the QoS WG wants to do. Ben: So we should co-schedule meetings? Matt: Yes. 11. Partnering with Multicast WG Ben: Per Brian Carpenter, QoS-needy apps are often also multicast-needy apps -- is anyone aware of anyone working on this? Xxx: Work four years ago on an experimental protocol on this -- "incredibly complex...cross product of two hard problems"...only way to do it is IntServ style. Larry: Hard, yes, but for best current thoughts, 1) look at capabilities for doing them together, as they are often orthogonal, and 2) layer 4-7 multicast or unicast replication is becoming an important market force -- need to see how that plays together. Xxx: If tree in a QoS domain... Ben: Even within QBone need to ask about level of service... Xxx: Uniform QoS spec throughout domain... Ben: Have been prodding Kevin Almeroth to work on this, as the multicast working group is ready for the next problem -- he has some thoughts. Xxx: We have a multicast app you can test with. 12. Partnering with Economics WG Xxx: Yes, if people are interested.