To: mjs@NSD.3Com.COM, P8021@nic.hep.net
Cc: rt@dla1.dl.ac.uk
Subject: Re: ["Robin Tasker": Priority in 802.1p]
Date: Wed, 10 Apr 96 12:04:41 +0100
From: "Robin Tasker" <R.Tasker@dl.ac.uk>

Mick

You wrote on the issue of not carving bandwidth out of an oversubscribed
service in bridges but to ensure that temporary execursions of bridge queuing
due to undifferentiated data background did not blow away the timeliness of
multimedia traffic. Of course I entirely agree if you are trying to provide
multimedia capability.

However the two items are intimately linked - timely flows must get through.
My point is that the mechanism of priority ordered queues simply does not scale
and by relying solely on that mechanism the control of the network resource is
moved from the network infrastructure to the end users.

I have no doubt that the "low level" techniques work in a nicely controlled
environment and certainly the nice simple solution is to be encouraged. However
introducing such capability scares me somewhat because most "real" networks
are anything but nicely controlled environments. Whether it is MBONE traffic
(and that maybe isn't too good an example) or other multimedia application
run between PCs or workstation on the bridged local area, the summation of
the "low level" techniques jeapordise the delivery of service across the entire
resource.

RSVP is undoubtedly heavyweight and inappropriate throughout the bridged
local area network but network topology is increasingly focused on centralised
switches with dedicated media to the end users. It is at the centre that a
sophisticated means of dealing with QoS would be of considerable benefit. As
you said a small number of priority flows is workable but towards the centre
of the network I imagine the summation of all such flows will likely be
disasterous for all the reasons previously discussed.

Of course I entirely agree that proprietary means are to be avoided but
sticking with pure and simple priority will actively encourage manufacturers
to introduce sophistication to ensure a well engineered solution, i.e. 
proprietary solutions. I would just like to minimise that risk. [incidently
RSVP is being worked by the IETF so I guess that qualifies as a standard...]

As you say, there is a role for the "low level" stuff in the provision of
multimedia capability in a bridge loacal area network and I agree. But only
as a part of a well engineered solution. I am certain it is not the entire
picture and I believe spending time to get it right first will be time well
spent. That is my motivation for separating the two threads of 802.1p since
the pruning capability is merited by itself.

It's the complexity of the subject which concerns me. If 802.1p is completed
with a well worked solution for pruning but only a half-done job for QoS no
one wins. The pruning part of 802.1p is vital and is becoming well engineered;
it would be a pity if the other half of the work doesn't match.

Pure and simple I believe this is a discussion that needs to take place.


Robin