Subject: Default 802.1 user priority mappings

From: [email-masked]
Date: Wed, 17 Dec 1997 18:36:58 -0800

Bryan,

There is information in 802.1p/D8 that isn't in the is802 draft. While it
is true that few values are shown in the issll draft, there are actually 7
values/usages called out in .1p Annex H. [While there was strong demand for
the 7 we couldn't think of a good default use for the last one, and the
abruptness of our halt at that point convinced me, at least for the time
being, that 8 is enough but 4 too few to build into useful defaults].

Why 7 in .1p and only 3 in ISSLL? In large part because in the near future
(which I loosely take to be a couple of years), there is strong demand to
enhance the performance of existing applications over existing protocol
stacks (and new applications over existing protocol stacks) i.e. to deliver
benefit without assuming the existence of a deployed integrated services
framework/RSVP/differentiated services etc.

I got a measure of the feeling of the 802.1 group on this issue when I had
to modify an earlier proposal I had made concerning default mapping of user
priorities to queues (see 802.1p/D7) in order to resolve significant
negative votes. The earlier default mapping gave more emphasis to admission
controlled flows than the final version which is more "here and now".

So we don't have any reserved bits in .1p. [Quite separately I don't think
we would have designated reserved bits even if there had been space. The
devil makes work for idle bits - manufacturers and marketing guys get hold
of them and make standard solutions which interoperate into standards based
solutions which don't. The entire key to the success of LAN switching has
been simplicity, plug and play, and stable expectations which have allowed
significant engineering for cost].

This discussion may be unsatisfying to those who see the world mainly in
terms of a march to integrated services/RSVP/ISSLL or differentiated
services or whatever will be decided in the future. I know that if I was
carrying that banner I might want to have a word with persons with
blinkered vision acting in ignorance of the future etc.  [though of course
I don't believe that is actually the case, as argued in my other emails].
So that's a downer. However the great news is that by the end of next year
(CY98) we can expect to see the deployment of literally millions of LAN
switch ports offering LAN priority service. This deployment will enable the
use of new applications in a way that simply wouldn't be possible with
existing switches. It would not be possible to make this happen for a
future which has yet to be pinned down - it has to be here and now stuff
for the 70 odd .1 voters to agree to a standard which will set market
expectations that will have a fundamental effect on the products of the 25
odd companies they work for. Moreover to get these switches deployed next
year we had to have a fair idea of what would be standardized as least
common denominator a while ago.

We could snatch defeat from the jaws of victory by attempting to assign new
default sematics to the .1p user priority. In fact we could sufficiently
cloud the issue as to make the bits unusable on any multivendor network.
However it is highly likely that in '98 the only thing that you can be sure
of is that all the switches are capable of doing the default mappings - and
if IS802 is going to be as widely deployed as possible it would do well to
work with those defaults.

The reality is that the semantics of the .1p bits are not free for ISSLL to
define. But the service is there to be exploited.

Am I arguing passionately here because I believe .1p specifies the very
best way to do things? No. If I had a free hand I would have specified
something different. But so would someone else. And the differences
wouldn't have been the same and would change over time. I've watched QoS
discussions for the last 15 years while the reality is there hasn't been
anything  deployed on the majority of networks. It's time to get something
to work. The LAN environment with its marvellous availability of bandwidth
is very forgiving as to the fine details. So I see the glass as 90% full
and don't want to break it to get the last 10% [which I don't believe will
come from a drop priority bit anyway].

Mick

>6. I don't think we have a bit spare. There are valid distinct uses for at
>least 6 of the potential 8 values. If we did have a bit spare it would end
>up where the manufacturers of low cost switches would ignore it (see item
>5).
In the issll draft default mapping there are 3 reserved values, and one
already corresponds to marked packets for lowest priority traffic. Are
there
other uses defined for some of the reserved bits in 802.1 ?

[email-masked] on 12/16/97 06:19:47 PM

To:   [email-masked]
cc:   [email-masked], [email-masked],
      [email-masked] (Mick Seaman/HQ/3Com)
Subject:  Re:  FW: 802.1 user priority mapping

Mick,
thanks for the detailed reply - see comments below. I recognize
that the semantics of the 802.1 bits are in the domain of the 802.1
group, but some input from issll might be helpful there.
>Although I believe the concept of drop priority to be a very important one
>in the WAN, I do not believe it needs to be encoded in the 802.1p
>"user_priority" field. The following describes the thinking behind this
>evaluation and some of the discussion among members of 802.1.
>1. The 802.1p user priorities do not represent values to be carried end to
>end across arbitrary transmission media.
Right - that's the job of the IP TOS field, which will with diff-serv
have both delay priority and drop priority semantics. Having an 802
media underneath which understands the same semantics looks useful
and may well be something that the issll group should be promoting.
>2. There is little requirement for switches to drop packets in this
>programmed way (an argument could naturally be constructed just as
>arguments for most things can be constructed) since LANs run lightly
loaded
>and queuing at interfaces to links is a temporary affair due to temporary
>coincidence of bursts. It is too easy to imagine queues as having queued
>packets in them, but a LAN switching system with appropriate capacity
>planning will run with average queue lengths of significantly less than 1
>(average queue length of 1 occuring at 50 or 60% depending on your traffic
>model). Traffic peaks which temporarily exceed bounds are smoothed into
the
>unused space (time) with little impact on the network.
If there wasn't any problem then issll over 802 wouldn't be needed at all.
Congestion can occur in a LAN, particulary with high speed links feeding
into lower speed ones. Simple priority queueing by itself may not be able
to provide the range of services that int-serv / diff-serv will end up
defining.
>4. Experience with "network abusers" on LANs is not that they transmit a
>little too much traffic which should then be dropped, but they misbehave
>grossly. Switches which have the smarts to spot and police such abusers
>have to take more drastic action than marking packets for drop. Most often
>this abusive traffic is notable because there is something about it
>(broadacst for example) that makes its impact more than chewing up
>bandwidth.
Not all marked (failed policing) traffic is necessarily abusive. Truly
abusive traffic should be dropped straight away. Traffic which is just of
lower importance relative to other traffic should be dropped at a
congestion
point, which may be in a different place to that where the traffic was
marked.
If there isn't any congestion then the packets don't need to be dropped at
all.
>5. While it is possible to envisage an architecture where the switches at
>the LAN edge mark packets for drop (thus marking packets from just a few
>users) and switches at the core of the network do the dropping when there
>are bandwidth conflicts there are problems with this model which go beyond
>whether a packet will ever be dropped (point 2 above). The switches at the
>network edge are the most economically sensitive, probably implement 2
>queues only, and may take advantage of not having to modify the packet at
>all. Hence they probably won't set drop priority - and the last thing we
>need is a standard which no one follows. The switches which can play with
>the packets and mark them to be dropped are probably sufficiently close to
>the core that they will be the ones doing the dropping - and are probably
>smart enough to track individual flows and calculate whether flows are out
>of bounds or not - the cost of these switches is typically amortized
across
>many end stations and has modest effect on total network cost. Note here
>that the scale of the LAN means that we are attacking a very different
>problem from requiring ISPs to track individual flows.
I think there's quite a range of implementations possible. Simple policing
and marking policies are certainly possible at the edge. One of the
benefits
of such an approach is to avoid the need for the core switches to keep
track
of individual flows - one of the prime motivations for diff-serv. In the
real
world you can't rely on end systems to do their own policing - it is a
network
function that needs to be performed and has to be performed somewhere. The
cost of edge vs core policing will vary with the network equipment and
design.
There isn't one right answer.
>These I think are the major arguments, minor arguments include:
>
>7. I want to see more experience and conclusion on drop bits, particularly
>on the LAN before we decide that all the switches ought to implement
>additional queueing mechanisms  - no small consideration. We need hard
>numbers to make an argument.
Flipping it round I could say that I'd like to see more evidence that
more than 4 delay levels are needed in a LAN before we preclude the use
of a drop level. The flexibility of 4 delay levels and 2 drop levels
seems greater than 8 delay levels alone.
Bryan