by Chuck Kalmanek, AT&T Labs
Panel Session on Quality of Service Extensions to GSMP at Opensig '97
Session Chair: Simon Crosby,
University of Cambridge
Panelists: Peter Newman, Ipsilon
Joe Evans, University of Kansas
Aurel Lazar, Columbia University
Chuck Kalmanek, AT&T Labs
I wanted to start by explaining the title of my presentation today: The Devil's Advocate. To understand this, you have to understand that the Devil is a clever fellow with a silver tongue who seduces us by exploiting our insecurities and appealing to our baser instincts.
That brings us to GSMP. Now, we all realize that the idea behind GSMP was to replace the ATM control plane with the Ipsilon control plane. This is a nice goal if you work for Ipsilon, but it is not a noble goal.
But then into the world came others, with motives more pure (some of whom are my colleagues on this panel), who realized that the ATM control plane did not meet their lofty dreams. They decided that "the enemy of my enemy is my friend" and made a pact with the Devil.
Their pact was to unbundle switch control from switch hardware, separating the spirit from the flesh. These souls felt that, if only they could try out their own control architectures, they would receive generous grants, the world would be better off for having sponsored their work, and we would ALL be uplifted.
And then there are those who, perverting a good idea, have sunk deep into the depths of depravity. Of course, I am referring to the group from Cambridge, otherwise known as Babel. This group, in its delirium, jabbers on about using multiple control architectures on a single switch. We must be wary of this path, for along this path lies chaos, as the world descends into a cacophony of control architectures and we all long for PNNI.
Now for a few serious remarks on each of the three proposals. The main question, from the perspective of open signaling, is to what extent each of these proposals solves the problem of opening up the control of ATM switches.
As Devil's Advocate, I have to say that I like Peter's proposal. Peter attempts to express the resources of a switch in an abstract model. That way, if I want to design a control architecture to manage a switch, I can directly control the switch resources. The real test of Peter's proposal is: to what extent does it express real switches? I know that I can design a scheduler that Peter's model does not express. However, maybe the proposal is adequate to describe all the switches of interest.
Joe's proposal implements call admission for ATM Forum traffic management directly in the switch. This is both an advantage and a disadvantage of their proposal, depending on the extent to which one believes that the ATM Forum has adequately expressed the service classes that you would like to support. The proposal does not seem to allow a control architecture to support a different model of QoS easily.
Aurel's proposal, qGSMP, expresses switch resources in terms of a schedulable region in an elegant way. One concern about this is that it is not obvious to me that a switch vendors would be willing to make the schedulable region for their switch available to control architecture developers (let alone even knowing what the schedulable region is). A second concern is that computing the schedulable region seems to require prior knowledge of all the traffic classes that will exist in the network. If you expect to have MPEG2, motion JPEG, and CD quality audio, you can compute a schedulable region for MPEG2, JPEG, and CD quality audio. When new traffic types emerge, how easy is it to support them in this framework?