Subject: Re: 802.1 user priority mapping

From: [email-masked]
Date: Tue, 16 Dec 1997 14:55:21 -0800

I concure with Scott here.   And to answer Scott, we've spent no time at
all in 802.1 on this issue.

/jsb

[email-masked] on 12/16/97 12:28:10 PM

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

Brian, while I agree, I think this should be taken up with the IEEE.  How
much discussion has drop priority been getting in their meetings?  We have
room for drop priorities (if we decide to use them) but I don't think we
get to change the semantics of the 802.1p bits.
...Scott

---

From: [email-masked]
Date: Tue, 16 Dec 1997 15:21:06 -0800

Bryan,

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: [email-masked]
Date: Tue, 16 Dec 1997 15:21:30 -0800

Bryan,

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

Mick

---

From: Bryan Gleeson <[email-masked]>
Date: Tue, 16 Dec 1997 18:19:47 -0800 (PST)

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.

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

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

>(broadacst for example) that makes its impact more than chewing up

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.

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

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

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 ?

>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

---

From: Ronald Brockmann <[email-masked]>
Date: Wed, 17 Dec 1997 15:34:13 +0100

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

Let me add to the discussion the fact that wireless LAN last hops
(like IEEE 802.11) typically have a lower bitrate (<10 Mbps), rapidly 
changing cell population and volatile channel conditions. Drop preference
seems to be a very exciting solution to bringing multimedia to these rough
environments in a very transparant way (gradually reducing multimedia
quality with worsening channel conditions). Carrying this additional
information may be less useful in the wired Ethernet infrastructure
that connects the wireless Access Points, but highly valuable in the
wireless last hop.

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

I too agree that reserving a bit would be a sound strategy for I think
it will be very useful once we figured out how this drop preference thing
really works.

Ronald

---

From: [email-masked]
Date: Wed, 17 Dec 1997 16:44:42 -0800

Bryan,

It is a mistake to infer that if there is not congestion that requires
dropping packets that there is no need for distinguishing packets through
the switches, or indeed no need for admission control.

New applications using switched LANs (including but not limited to voice)
benefit from low latency/jitter. If there is no prioritization of frames
sent by these applications they can get stuck behind the temporary queues
built up by file transfers and other such network uses. This is
particularly true of speed transitions from 100 Mb/s to 10 Mb/s in edge
switches (or from 1000 Mb/s to 100 Mb/s). It doesn't matter that the
average network loading is low, the temporary queue causes delay for the
urgent packet. With simple prioritization it works like a dream.

For these new applications, admission control (whether SBM or H.323
gatekeeper) may well be based on the ability of the network to meet
expected latency bounds rather than on total throughput. There is a body of
thought which says that it is not worth doing admission control because it
is so much less expensive (for the end user, based on total cost of
ownership including administrative costs) to put more bandwidth into the
switched LAN. Personally I neither buy "the you never need control, just
buy more" or the "you have to have admission control always" arguments, but
they are both points of view with real deployed networks to point at.

Delay is not just an issue with new applications. Network round trip time
is also important for some existing applications, for example those which
are RPC based and single threaded or where the human network user needs the
answer before proceeding. Further back in time there are also protocols
which operate on a window of one basis, perhaps not of concern to the IETF,
but still relevant to switch vendors. We have bench marked the performance
of LANs and switched LANs at the user application level for years for these
reasons.

While prioritization is useful to avoid network induced delays, the
temporary queuing and congestion may not even persist long enough on the
switch port in question to be there when the same application sends its
next packet. Signalling "back off" with something as dramatic as dropping a
packet is not appropriate here. In addition, protocols have been designed
to be sensitive to network conditions other than dropped packets -
increases and variance in round trip delay for example.

There is nothing so deadly as applying arguments which make eminent sense
in one context to another context. Orders of magnitude separate the
available LAN switching bandwidth in the products that are rolling out
today from the bandwidth available through the Internet.

---

From: Bryan Gleeson <[email-masked]>
Date: Wed, 17 Dec 1997 20:17:37 -0800 (PST)

Mick,

>However your argument as to the inevitability of congestion is a little at
>odds with my experience. I've seen very few LANs which are run at levels of
>sustained congestion (those that do tend to stick in my mind - like the
>company with a campus FDDI ring serving 30,000 users and running at 70%+
>loading). The majority run in single digit percentages.

>This is not to say that the Pointcast problems aren't real, but their
>practical solution lies elsewhere.

Clearly any network administrator that runs a network at a high level
of congestion doesn't have very much job security. However peak loads
and spikes occur, and I may want to give priority to my database query 
application rather than RealVideo. Over a long period of time you would 
expect the network to be provisioned so that congestion was rare, but 
it is always a race between applications using more and deploying 
equipment to provide more. Given that, there's quite a difference
between prohibiting the use of an application till the network gets
upgraded, and penalizing that application during peak loads.

>Again I don't want to declare myself against all forms of admission control
>and policy control. Not at all. I just want to know exactly why, with hard
>numbers and tough analysis, why we should not in ISSLL use default mappings
>which were approved in .1 just a month ago.

I would make a procedural point here. 802.1 should not be in the business
of "approving" mappings of internetwork layer services onto 802.1p mechanisms.
802.1 is traditionally internetwork layer protocol independent. Annex H is 
informative (shouldn't it be an Appendix ?) It is up to the bodies that 
define the various internetworking protocols to define in a normative way 
how they wish to use the mechanisms provided by an 802.1p LAN. For example 
ISSLL gets to say which user_priority corresponds to Controlled Load, 
not 802.1. 802.1 gets to say that user_priority 0 gets serviced before 
user_priority 2, for example, but not which traffic classes get assigned
to which user_priority.

Bryan

---

From: [email-masked]
Date: Wed, 17 Dec 1997 18:54:51 -0800

Bryan,

Below I was referring to the potential argument that studies on the use of
drop priority in the Internet and large WANs carry over automatically to
the switched LAN. Not to any other argument.

We are putting a real bandwidth kicker in the network with switches now.
Over the space of less than 2 years we're going from 10 Mb/s shared between
many users to 100 Mb/s dedicated and from backbones of 100 Mb/s to 24 Gb/s
plus. That's a factor of 240. Networks that having been working for the
last few years should be kept going very happily for some time. In a couple
of years we can reassess.

Mick

>High bandwidth doesn't make congestion go away, since congestion is
>a function of traffic density rather than bandwidth. No matter how
>big the bandwidth pipe is, there will always be some apps that want
>to use it all, not immediately perhaps, but sooner or later. For
>example, today Pointcast causes problems on some (poorer) networks.
>I'm sure there'll be an equivalent to Pointcast to give network
>administrators headaches in the year 2000 if they operate a network
>that doesn't handle congestion well.

---

From: Bryan Gleeson <[email-masked]>
Date: Wed, 17 Dec 1997 18:16:59 -0800 (PST)

Mick,

>urgent packet. With simple prioritization it works like a dream.

It would indeed be a mistake to think that prioritization of frames
wasn't needed, but I haven't seen anyone make that argument. I am not 
arguing for the elmination of delay priorities. I am saying that
for a LAN, 4 delay priorities and 2 drop levels provides a better
basis for providing various services than a LAN which provides
8 levels of delay priorites. In fact such a scenario would not
be incompatible with 802.1p, as far as I understand it. It would
just be different from the currently defined default, which is 
more of a lowest common denominator. Perhaps issll can build on this 
and provide a default mapping which is compatible with the existing 
801.2p behaviour, but reserves a set of values for services which 
we know are on the way (i.e. diff-serv).

>they are both points of view with real deployed networks to point at.

I definitely think that you always need policing. The framework
document says that it is "reasonable" to assume that end stations can 
be trusted to police themselves, but I haven't found many network 
administrators that would agree with this assertion. 

Bryan

---

From: Andrew Smith <[email-masked]>
Date: Thu, 18 Dec 1997 10:58:05 -0800

Bryan,

> Sent:	Wednesday, December 17, 1997 6:17 PM
> To:	[email-masked]; [email-masked]
> Cc:	[email-masked]; [email-masked]
> Subject:	Re: FW: 802.1 user priority mapping
> 
[Andrew Smith] I don't buy that argument: LAN administrators have been
living with that assumption since the day Ethernet and Token-Ring were
invented. But that is an issue that economics will decide: if your
switch that does per-flow policing and diff-serv marking/dropping is as
cheap as mine that doesn't then I am sure you will sell a lot more of
them. 

And the whole justification for the ISSLL 802 approach is an economic
one: RSVP and routers can do a much better job than ISSLL does, without
any new standards but they *are* a little pricey.

Andrew

***********************************************************************
Andrew Smith                            tel: +1 (408) 863-2821
Extreme Networks                        fax: +1 (408) 342-0990
10460 Bandley Drive                     http://www.extremenetworks.com
Cupertino CA 95014                      em:  [email-masked]
***********************************************************************

---

From: Andrew Smith <[email-masked]>
Date: Thu, 18 Dec 1997 11:14:00 -0800

A set of "defaults" does not rule anything out.

Andrew

> From:	Paul Ferguson [SMTP:[email-masked]]
> Sent:	Thursday, December 18, 1997 11:10 AM
> To:	Andrew Smith
> Cc:	[email-masked]; [email-masked]
> Subject:	RE: FW: 802.1 user priority mapping
> 
> At 11:03 AM 12/18/97 -0800, Andrew Smith wrote:
> 
> >
> >That is an interesting point, but I have not heard any assertion in
> the
> >diff-serv arena that the approaches being discussed are
> >appropriate/suitable for use in a private LAN environment: most of
> the
> >arguments seem to be about "inter-ISP service contracts" based on IP
> ToS
> >bits so far. Is there really a need to duplicate these mechanisms at
> all
> >possible layers?
> >
> 
> Perhaps not, but I certainly wouldn't rule it out.
> 
> - paul

---

From: [email-masked]
Date: Fri, 19 Dec 1997 08:56:35 -0800

Andrew's question was "Is there really a need to duplicate these mechanisms
at all possible layers", not "should there be devices in the LAN capable of
implementing these mechanisms".

Further, there is a significant difference between having all devices
perform a function and some devices doing so. Moreover the path between end
stations is not the same at all points, therefore it is not a strict
logical consequence that because it is assumed that the application or
operating system can set ToS bits (my assumption too by the way), that the
natrure of mechanisms at any particular point on the path is defined.

Looked at another way, if this were a requirement it would not be possible
to operating differential services on a LAN-WAN-LAN path without upgrading
all the switches in the LAN to be ToS/CoS aware. I don't think that anyone
believes this to be the case.

Mick

Juha Heinanen <[email-masked]> on 12/18/97 10:38:19 PM

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

   That is an interesting point, but I have not heard any assertion in the
   diff-serv arena that the approaches being discussed are
   appropriate/suitable for use in a private LAN environment: most of the
   arguments seem to be about "inter-ISP service contracts" based on IP ToS
   bits so far. Is there really a need to duplicate these mechanisms at all
   possible layers?
we have always assumed in diff-serv discussions that also the
application or the operating system can set the delay and drop
preference bits and if that is the case, then the lan would need to
support them too.
-- juha