To: 100271.522@compuserve.com, P8021@nic.hep.net
Cc: rt@dla1.dl.ac.uk
Subject: Priority in 802.1p
Date: Tue, 09 Apr 96 14:43:03 +0100
From: "Robin Tasker" <R.Tasker@dl.ac.uk>

Tony

Within the Internet community the use of the MBONE for multimedia 
applications is growing to support distributed multimedia applications.
These activities are based on multicast datagrams and multicast routing
to distribute information from single source to many recipients. As a 
part of this operation multicast pruning is introduced to ensure that
datagrams travel only where required on the Internet. However the quality
of the service provided is strictly limited as the multicast datagrams have
to compete with other Internet users and the service seen by the end user
is variable.

To complement this work, RSVP is being developed to provide a mechanism to
manage the QoS across the network. It can be used to reserve bandwidth and
acts to augment existing multicast (and unicast) protocols. Software is
beginning to be comercially available to support RSVP and as it becomes
deployed a well engineered solution will be available across the Internet
to run "well behaved" multimedia applications.

Whilst many local area networks are routed and will benefit from the MBONE/
RSVP developments, bridged local area networks are not so fortunate. The
work in 802.1p will provide the mechanism to introduce pruning through the
bridged local area network and as such will be of great benefit. It does
not however address the second issue of QoS which is an essential element
to provide the well engineered solution for bridged local area networks.
Certainly it acknowledges the need for such a development insofar as it
discusses the use of priority to manage traffic flows across segments of the
network. This is however simplistic and almost certainly useless.

For example, a typical bridged local area network will run TCP/IP based
applications and will almost certaily use NFS to provide file access. NFS is
an excellent mechanism on a lightly loaded, error free network, but it suffers
when loads and errors increase. It can very rapidly become unuseable.

The proposed use of priority classes is potentially disasterous. It will allow
end users to control network resources and could easily render networks
unmanageable. It enables a user sets up a high priority "flow" across the
network which will take precedence over other traffic. One needs to question
how many such flows can be supported simultaneously, and also the effect of
these flows on the other "low" priority traffic. Almost certainly NFS traffic
will stop working which will effectively stop very many network users working.

The way out will be to ensure that all such traffic travels at the higher 
priority which rather negates the purpose of introducing priority management
in 802.1p in the first place. The result is a poorly engineered solution which
will satisfy some but cause phenomenal aggravation to many.

It is vital that the second element of multimedia support is provided in a
robust and useful manner. For that reason I would welcome the decoupling of the
two items from the 802.1p document to allow the (multicast) pruning technique
to progress as rapidly as possible and for the management of QoS to be more
carefully considered.

Clearly any solution cannot be too onerous on bridges and end stations. It 
could be that the best solution will operate between switches given that the
final connection to end stations is increasingly over dedicated media. 

Just as 802.1p is loosely based on IGMP/IGMP2 so it might be sensible to
look at the emerging RSVP work but operating between switches to provide the
two elements necessary for a useful solution for multimedia applications.

Comments?


Robin

+++++

Robin Tasker				telephone:	+44 1925 603226
CCLRC, Daresbury Laboratory		fax:		+44 1925 603230
Warrington				email:		r.tasker@dl.ac.uk
Cheshire
UK