To: mjs@NSD.3Com.COM
Cc: P8021@nic.hep.net, rt@dla1.dl.ac.uk
Subject: .1p priority and scaling
Date: Fri, 12 Apr 96 11:50:56 +0100
From: "Robin Tasker" <R.Tasker@dl.ac.uk>


Mick

Thanks for your detailed analysis supporting the use of .1p for multimedia
applications. I'm pleased we both agree that it doesn't scale (at least in
the most relevant direction); what you described is the start point for a
clear definition of the Scope. It begins to tell us what it can do, but more
importantly what it can't do. You are quite correct to deal with realities
and to avoid the hand-waving clouds and arbitary correction of everyone's
favorite kit. Like you I see it to be vital that 802.1 deals with soluble
problems.

What you described was a well structured, well configured and resourced 
network. As you say the key is to reduce the jitter on the multimedia flow
when normal data is also in transit to the end station. I have no doubt that
within the constraints you mention, the situation is rescued by the use of
priority. That is why I too consider priority to be a valuable tool.

Its the constraints that bother me - both the quality (and the cost) of the
topology and the responsible behaviour of the user community. What you describe
is approaching the best case and even then rigid limits (i.e. 1) are imposed
on the number of multimedia flows available to an end users with the 
cumulative number of flows no more than a couple of handfulls. 

Unfortunately the reality I know and have to work with is some distance behind.
And I am certain that this is true for most research and academic organisations
(at least in the UK) which taken together is a very large installed base. My
experience also says that these institutes are often considerably ahead of
most commercial organisations.

I can easily imagine a (large) set of PCs capable of using these techniques
(well they will be delivered pre-installed) and wham! the network gets blown
away. What this means is that not only must the Scope be carefully written
but also there must be some vigorous words on Performance which spells out
the realities as an essential part of .1p.

But of course priority remains just one mechanism to provide the multimedia
flows and certainly other standards organisations are working in this area.
I too would hate 802.1 to be involved in the complete study of end-to-end QoS,
maybe we could also discuss the colour of the bikesheds at the same time.

Equally I am also bothered by the general handwaving associated with the
higher level protocols sorting things out. Unfortunately the link level (i.e.
MAC bridges and switches) is where all these efforts concentrate and we
certainly must take into account the rest of the world. I rather think that
.1p needs to provide the synthesis of these developments to ensure that the
punter (i.e. me!) knows what he's getting into when he provides these network
services to a set of eager users.
 
I think Peter suggested that if we're looking for a comprehensive solution at
the link layer we should just take up ATM's work. Now there is more than one
grain of truth here but what I think it means is that the Scope/Performance
discussion had better come clean so that the end user buying .1p kit doesn't
find himself with a pup. He needs be able to include the variety of multimedia
provisions in such a way that it does all hang together. Consideration of
what else can be done at the link layer must be of value; a high function
switch that is indistinguishable from a router isn't necessarily useful.
Not many organisations really want the extra cost of administering different
IP nets or subnets. But they may well want their high function switch to do,
for example, RSVP type things.

Robin