Date: Tue, 30 Sep 1997 16:17:58 -0800 From: "John A. Dundas III" To: Elise Marie Meyer Cc: cenic-tpg@ucdavis.edu Subject: Re: CalREN-2 Query As I described back on April 25 at the MREN/NSF Forum on HPDN/vBNS, I believe there are three (within the first three layers) possible, somewhat competing, solution spaces to properly answer the questions raised by QoS. The solution spaces within layers 1-3 include: (1) ATM, (2) IEEE standards (e.g., 802.1p, 802.1Q, 802.1D - the update, not the current standard), and (3) IETF standards (i.e., RSVP). I believe the only satisfying solution exists at the intersection of these spaces. IP represents the common bearer service between disparate campuses. If follows then that a corresponding network layer solution is needed to augment IP to carry QoS information meaningfully. Of course the TOS bits exist today, and v6 has the CoS bits. However RSVP is really needed to properly coordinate all of the end and intermediate systems in an interoperable, standards-based, media independent fashion. ATM already has a rich QoS feature set. However unless it is implemented from end-to-end, ATM QoS is meaningless. The implication here is that the wide area needs to be ATM, each campus backbone needs to be ATM, and the network to the desktop needs to be ATM. It is my assertion that this won't happen. I can guarantee it won't happen at Caltech. We are NOT putting in a large ATM infrastructure. We are using Ethernet, FastEthernet, and Gigabit Ethernet. This leads to the next solution space... The IEEE has long recognized that frame-based networks need to be augmented to support at least priority queueing, if not a richer set of QoS capabilities. The standards committees are working on these as we speak. At Caltech we have gone with a Cisco solution from end-to-end (on campus). One of the prerequisites to do this was assurance from Cisco that they would fully support 802.1p, Q, and D, when they were available. This is all well and fine within itself, but it gets us back to the ATM problem. Unless 802.1p, et al, is implemented from end-to-end, it doesn't do any good. RSVP is needed to coordinate the various link and physical layers in order to support end-to-end QoS. We haven't even begun to touch on the other important layers of the stack and the support they need to implement QoS. How many QoS APIs are available for the machines you are interested in supporting? What sort of tools are there to monitor QoS usage? Can the applications and underlying operating systems support QoS if it were available? Do you want to make QoS "guarantees" or "probabilistic warranties"? How will you control the economics of differentiated services? Do any of these solutions scale to support the entire campus? I think Russ has some of the answers. CalREN-2 can help push progress in development of the applicable standards. Priority queueing is available now and is independent of network media. We can start learning with this. >1. Do you agree with our conclusions regarding the state of the >technology? Yes and no. I agree that no vendor supports all the standards needed to make this work today. Do I need ATM? No. >2. If you have Quality of Service requirements for your applications, >how are you planning to solve them? WFQ, RED, etc. >3. How are you planning to provide CalREN-2 functionality on your >campus? (what options are you considering?) See above. John Dundas