Subject: FW: 802.1 user priority mapping

From: [email-masked]
Date: Tue, 16 Dec 1997 15:07:20 -0800

Bryan,

Andrew Smith passsed on your comments with regard to drop priority and
802.1p in the LAN.

The default mappings described in draft-ietf-issll-is802-svc-mapping-01.txt
directly reflect what is in IEEE Draft Standard 802.1p/D8 (see Section 3
and Annex H) which is the version that has recently passed its IEEE 802
working group ballot with no negative comments  (the further steps towards
a standard are usually smooth).

I do not believe we should attempt to rewrite these defaults in ISSLL. They
have been carefully considered and to rework them could introduce enough
confusion as to make the meaning of the 802.1p "user_priority" and traffic
classes on any given LAN unclear - effectively wrecking the bits and the
capability they represent. In addition there has been cross representation
between the ISSLL IS802 group and 802.1 during the development of 802.1p,
so this is not a case of one group acting in ignorance of the efforts or
assumptions of another.

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. The values are determined for
transmission across the switched LAN portion of the data path - the
particular values being chosen by RSVP, or by a LAN attached end station,
or by some other policy means for the LAN portion of the transmission.
Therefore the 802.1p values can be dedicated to the characteristics of the
LAN hop, just as different mechanisms are dedicated to the characteristics
of different links.

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.

3. 802.1 has taken considerable care to keep switches (bridges) as simple
as possible. This involves keeping a close eye on the reality requirements
to do fancier things in the main data path and accepting only the most
important that have any economic impact on the switch. If basic (layer 2)
switches  became more elaborate they would become more like routers (layer
3 switches): in fact they are built as layer 3 switches and can then use IP
packet characteristics to make decisions if necessary.

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.

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.

These I think are the major arguments, minor arguments include:

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).

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.

8. I am very unclear as to the requirement for drop priority on loads
subject to admission control - particularly Controlled Load and Guaranteed
Service - be that admission control by an SBM or by an H.323 gatekeeper. If
there is a CL/GS requirement for drop priority in support of traffic class
aggregation can that not be met in systems which see Layer 3 information at
the aggregation and subsequent points in the network.

Mick

> -----Original Message-----
> From:   Bryan Gleeson [SMTP:[email-masked]]
> Sent:   Tuesday, December 16, 1997 11:42 AM
> To:     [email-masked]; [email-masked]
> Subject:     802.1 user priority mapping
>
>
> I think the default mapping to IEEE 802 user_priority described
> in draft-ietf-issll-is802-svc-mapping-01.txt should make provision
> for the concept of "drop priority" as distinct from "delay
> priority" to take account of the ongoing diff-serv work.
>
> The diff-serv proposals use drop priority to tag packets that
> fail policing or that are marked as such by applications. If
> there is no congestion then you still want the marked packets
> to be delivered in order, rather than bumped down to a
> lowest possible delay priority level which would then result
> in out of order delivery. This problem is mentioned in the
> above draft, however it is assumed there that such flows are
> abusing the network and don't deserve any better. For an
> application like multilayered video, marking some packets
> as more important than others is not network abuse, but
> a reasonable thing to do.
>
> At the diff-serv meeting it was emphasized that it was
> very important to distinguish between the traffic type
> (e.g degree of delay sensitivity) and its importance.
> One person's email could be more important than another's
> internet telephony. A split of the user_priority bits into
> 1 bit of drop priority and 2 bits of delay priority would
> probably more closely reflect the diff-serv approaches than
> using 3 bits of delay priority. Other approaches which reserve
> a set of values for drop priority may also be possible. At
> this point I think the default mapping should not use up all
> the bits for delay priority levels, precluding further
> extensions when diff-serv is nailed down, or possible
> use by 802.1 of some form of drop priority semantics.
>
> Bryan Gleeson
> Cisco.
>

---

From: Paul Ferguson <[email-masked]>
Date: Tue, 16 Dec 1997 19:06:16 -0500

>packet characteristics to make decisions if necessary.

Well, there's this whole can of worms called 'legacy'
LAN switches already deployed which don't support 802.1p.  ;-)

As an aside, draft-ietf-issll-is802-bm-05.txt suggests that
SBM, when combined with per-flow policing on the end-systems,
and traffic control and priority queuing at the link-layer,
will provide a close approximation of the controlled-load
and guaranteed services. However, in the absence of any
link-layer traffic controls or priority-queuing mechanisms
in the LAN switch infrastructure (for example, on a shared
media LAN), the SBM mechanism only limits the total amount
of traffic load imposed by RSVP-associated flows. In
environments of this nature, there is no available mechanism
to separate RSVP flows from best-effort traffic, per se. This
brings into question the usefulness of using the SBM model
in a LAN infrastructure which does not support the capability
to forward packets tagged with an IEEE 802.1p priority level.

Enough said about how 802.1p relates to SBM/RSVP.

In any event, I personally think that 802.1p user_priority
certainly has a place in diffserv implementations, especially
in implementations where "delay indication" (whatever we
might decide that might be) could be used in conjunction
with a forwarding and preferential queue servicing mechanism.

- paul

---

From: Keith McCloghrie <[email-masked]>
Date: Wed, 17 Dec 1997 01:36:15 -0800 (PST)

Hi Mick,

> LAN hop, just as different mechanisms are dedicated to the characteristics

I suggest this applies equally to drop priority and delay priority.

> unused space (time) with little impact on the network.
 
With higher bandwidth applications on higher bandwidth links, I think the
potential for concurrent bursts from multiple sources to overload the
switches is increased.  Whereas delay priority is appropriate for
delay-sensitive traffic, it seems to me that drop priority is more
appropriate for delay-insensitive (i.e., Best Effort) traffic.  This is
as true in the LAN as in the WAN.

> packet characteristics to make decisions if necessary.

I suggest that implementing drop priorities is just as simple as
implementing delay priorities.

> While it is possible to envisage an architecture where the switches at

Switches, which can't modify a packet, can't do the remapping of 802.1p
user-priority.  If despite this, the remapping of priority is simple
enough to be included in the framework document, then I suggest that
setting drop priority is also simple enough.

> up where the manufacturers of low cost switches would ignore it (see item 

The mapping document lists only 5 used values.  One of these is for BE
traffic, and one is for "less than BE".  Less than BE is already
acknowledged in the framework document to be of dubious value because
it results in out-of-order traffic; drop priority is a way to
accomplish the same purpose without the re-ordering problem.  Another
value is used to distinguish between 10ms delay and 100ms delay; I've
commented on previous drafts of the framework document that it's not
clear to me that the distinction between 10ms and 100ms is really
implementable.  So, it would seem to me that there are values to spare.

[I acknowledge that it is late in the 802.1p process.  However, it is only
recently that the idea of Differentiated Service has arisen in the IETF.]

> numbers to make an argument.

Bryan asked for the default mappings to make provision for drop priority.
One possibility would be to reserve some of the values (e.g., one of the
bits) in the default mapping until the "more experience and conclusion
on drop bits" is available.  Indeed, there are already some values
which are reserved.  While the default mapping is only a default, and
can be changed, it would be much better for a future transition from
one default to another default to only need to add some extra meanings,
rather than having to redefine some of the values.

Keith.