Subject: RE: draft-iab-qos-00.txt

From: "Yoram Bernet" <[email-masked]>
Date: Tue, 16 May 2000 15:41:34 -0700

I do think that the draft serves a useful purpose in highlighting some
areas in which work remains to be done. However, I think that it paints
a pessimistic picture of the state of the art and negelcts important
prior work and developments. I would like to see it refined to account
for these. I think that it should not be issued as an RFC at this time.
I'll delve a little deeper in the following paragraphs. I would be happy
to write paragraph by paragraph comments on the draft, if the iab is
receptive/interested in this. 

The concluding paragraphs call for "integrating the various elements of
the (QoS) architecture into a cohesive whole" (section 6). The major
elements discussed in the draft are intergated services and
differentiated services. Oddly enough, the integration of these into a
cohesive whole is precisely the work that has been underway for over a
year, in the issll working group (see
http://www.ietf.org/internet-drafts/draft-ietf-issll-diffserv-rsvp-04.tx
t). Yet this document is not even cited in the references. Geoff - are
you aware of the work that has been going on in this realm?

Section 4.12 cites the "chicken and egg" problem of applications waiting
for infrastructure and infrastructure waiting for applications. I think
that the missing yet relevant pieces here are network devices and host
operating systems. Network devices had support for a primitive form of
diffserv for years (they are now becoming available with more
sophisticated forms of diffserv support). Similarly, major equipment
vendors have had RSVP available for several years. An operating system
with a relatively simple and cohesive API has just become broadly
available. Sure - there have been RSVP APIs for some time, as well as
traffic control APIs, yet these did not combine the different elements
into a cohesive whole in a manner that simpifies the task for
applications. Following the availability of an operating system with a
cohesive API, QoS enabled applications are emerging. Applications that
use the QoS API include SAP/R3, Netmeeting, and TAPI-3 enabled apps.
Applications that are currently porting to these APIs include Windows
Media Technology and IP/TV. I think that given this landscape and the
dramatic recent changes, the assessment of the state of the art in the
text is quite pessimistic.

Which brings me to the third point - section 7, although it starts by
stating charitably that "there is no reason to condemn the QoS
architectures as completely impractical" and goes on to mention that the
missing sections need to be filled in with something "more substantial
than pixie dust and wishful thinking" - scares the hell out of me. While
I actually agree that there are missing pieces and I agree that a great
service can be done by filling these in (I happen to believe that they
lie primarily in the area of policy based provisioning and configuration
as well as traffic engineering), I am afraid that this doc, in its
current form will have a chilling effecrt on the creativity that we are
seeing in the industry. It stands to chill both potential customers as
well as equipment vendors from further experimentation, development and
deployment, much in the same way that the RSVP Applicability Statement
did some time ago.   
  
I have been working for some time now on the integration of the existing
QoS components into a cohesive whole. I have been working with leaders
in the industry as well as with IT folks and with customers. I think
that Geoff's assessment of the weaknesses of the various architectures
is pretty much correct. I also think that the work that has been
happenning in the ISSLL group has been combining the architectures in a
manner that addresses many of the deficiencies. I agree with Geoff on
many of the individual issues raised. For example, I agree that the
converged architecture must address QoS deployment diversity (as
discussed in section 4.10). I think that the current converged approach
is heading in this direction. I have considered issuing a draft
describing how it does so, but simply have not had the time. Briefly
put, the current converged approach suggests that applications signal to
indicate what they would like and to provide the network information
about themselves. This signaling is generally alolowed to flow
end-to-end through the network. It is listened to by those devices that
can benefit from listening to it. It is ignored by those that cannot.
Certain devices will respond by installing per-flow state. Others will
simply apply aggregate diffserv style traffic handling. The quality of
services that a specific subnetwork can offer and the efficiency with
which it can do so will depend on the functionality of the network
devices within that subnetwork. The network manager is able to configure
network elements in his or her subnetwork, to dial-in the desired
tradeoff of QE product (bieng able to simultaneously support high
quality services and to operate the network efficiently in terms of
resource consumption) and processing overhead. This can be done in a
seamless manner - all the information is available to the network
manager to choose the point at which he/she wishes to operate his/her
network. His/her choices are compatible with the choicesof network
managers upstream or downstream. This idea is developed in a number of
papers including one published recently in IEEE Communications, February
issue.    

Yoram 
> -----Original Message-----
> From: Wijnen, Bert (Bert) [mailto:[email-masked]]
> Sent: Tuesday, May 16, 2000 12:03 AM
> To: [email-masked]
> Subject: draft-iab-qos-00.txt
> 
> 
> This document is about to go out as Informational RFC.
> If anyone has comments, pls let me know asap.
> 
> Bert Wijnen
> 
>