To: "Norman W. Finn" Cc: P8021@nic.hep.net Subject: Priority, 8 levels or 2 Date: Sat, 13 Apr 1996 19:29:07 -0700 From: Mick Seaman Norm, In response to your request: >> Mick, >> Can you comment on the relationship between the 8 levels of destination >> MAC priority in 802.1p and the two levels of priority suggested by 802.3 >> in the source I/G bit? This seems like one priority mechanism too many. >> -- Norm I have set down a number of thoughts. Some at least, I hope, will prove pertinent to your concern. Much is background and I have included it since we have such a wide cc: list on this discussion. 1. This is the first I have heard that 802.3 is specifying the source I/G bit as priority. I'll refrain from saying more until I know more about the proposal. 2. In the superset MAC Service (ISO/IEC 10039) and in .1D a distinction is made between the user priority of a frame and the access priority. The user priority is (ideally) communicated end to end (at least at the MAC layer - see further on). The access priority is a hop-by-hop or segment by segment concept. The access priority reflects what the frame needs to compete with other frames on a particular segment. It reflects the importance attached to the user priority in the local context and is in general not known to the originating user. In some respects .1p and the I/G bit scheme differ in this analysis though both are nominally user priority schemes. .1p is allowing the recipient of the frame to determine the priority and in the scope where .1p is likely to be most used (near the edge of the network) this is likely to relate more to the resources contended for in the local environment. (see comment 5.). Of course the user priority of the MAC is what the network layer thinks of as its access priority for this hop. 3. Personally I believe that 8 levels of priority far exceeds the requirements at the MAC layer and that 2 should be quite sufficient. Here I agree with 802.12. I note that two levels of priority for frames which may be simply forwarded through a bridge equates to 3 levels in practice. The extra level is direct bridge to bridge signalling which may be demultiplexed, acted on, and consequent frames forwarded without their addition to the bridge forwarding queues. See the architectural model of a bridge in .1D. The main reason for my belief (that 2 is the right number of classes of service through a bridge) is that bridged networks do not operate at all well at consistently high levels of loading. A major congestion avoidance strategy in bridged networks is appropriate network sizing. In point of fact a major congestion avoidance strategy in all networks including telephone networks, terminal networks into transaction systems, etc. is network sizing. Major system vendors put a lot of effort into sizing models and estimation. All too often this seems (to me), to be forgotten in protocol centric discussions. Bridged networks should be sized so as to function below the loading point at which the average queue length at a port is 1. This means average throughputs less than 50-66% of link capacity depending on your traffic model. The reason for the 2 queues/classes is that traffic can be highly bursty and packets at lower priority - more strictly packets for traffic at lower classes of service or `disadvantaged classes' as we have called them - can arrive in crowds. These lower class crowds temporarily swell queue lengths and makes priviliged traffic comprising higher priority packets very jittery. The solution, then, is to provide separate queuing for the priviliged classes. At low average queue occupancies there would appear to be little benefit is further segregating the priviliged classes. On the whole they appear to be well behaved as a group, and less likely to crowd than unpriviliged data classes. This is because, today, they often represent more regular traffic streams. Furthermore while it is possible to support more of these traffic streams by being much more careful in the bridges, you cannot achieve average link utilizations in excess of 100% whatever you do. The consistent model to date in .1p has been to allow the job of choking down of the privileged traffic to be handled in other more resource constrained parts of the system (say the wide area links and the routers attached to them). Providing further levels of priority might allow the network to operate at higher average queue lengths but unfortunately the average queue length rises fairly rapidly for further average throughput gains for most traffic models. To put this another way - to get a little more throughput you lose a lot in response time and jitter. Alan Chambers has coined the acronym CAPEK - Congestion Avoidance by Purchasing Extra Kit - to describe the historical and effective behavior of bridged LAN providers. Alan, can you remind me what the Czech poet Capek did which makes this so apt? The relevant metric would seem to be CAPD - Congestion Avoidance Per Dollar. In bridged LANs (or to be more accurate in regions of bridged LANs particularly including those where there are 10:100 floor switches) the highest CAPD would seem to be realized by low loadings, short average queue lengths, and two simple classes. In the wide area, in complete contrast, expensive links make CAPEK inappropriate and higher CAPDs can be achieved through much sifting of traffic. A practical consideration which makes me so extremely sceptical of the claims for multiple MAC priorities is that many of the chipsets provided for such MACs have had such poor system interfaces that it is necessary to hand many packets at a time over the interface to obtain high levels of throughput. These packets then sit in a single undifferentiated queue awaiting initial transmission. The resultant head-of-line blocking means that the supposed benefit of the priority may be lost even before the packet leaves the source endstation. I reason that if actuality rather than future possibility was important to many advocates of multiple priority schemes, they would take more pains over the chipsets and the implementations, and less over the simulations. 4. However there are a number of powerful arguments, technical, pragmatic, and human, for keeping the number of priority levels at 8 in the production of .1p as a standard. We have managed to reach consensus, at least in task group discussion, as of a couple of meetings ago, that we could all live with 8 priorities and an option to have upto 8 traffic classes. While it is possible that putting this to a vote might cause the number of classes to be reduced, it would also cause the number of people who are happy with .1p to be reduced. Having reached consensus I believe (as task group chair) that it is important to move on to more important issues. The points I have made above have been aired and heard, other points have been aired and heard. The time has come to enforce the rule that we will give agenda time only to new data, not to new opinions (and certainly not to restating old opinions). The exception to this rule would be if there was a significant change of opinion and a request by those who'd changed to revisit the issue and make a decision against their former stated position. Those of us who believe 2 is enough are not obliged to implement more queues. This is crucially important to vendors and users who believe that switches should rival repeaters for low cost. Those of us who believe that a bridge standard should not restrict the capabilities inherent in a particular MAC - meaning Token Ring most particularly but also potentially FDDI can choose to implement 8 classes of service. This is clearly important to those who believe that control-based rather than extra-bandwidth-based approaches are a viable approach to CAPD in the LAN. As with VLANs a standard with broad economic appeal to facilitate interoperability is preferable to separate standards. The technical argument for more classes is that we cannot predict, for the anticipated life of a standard such as .1p, what traffic profiles will look like. There may come a time when it is useful to further segregate the priviliged classes, or indeed find packets amongst the disadvantaged classes that should aspire to distinctive treatment. Experience with the complex flow specifications in use at higher layers might allow their reduction to a brief ennumeration possibly with trivial parameterization. In part .1p as it stands is a product of the failure of much (18 months) inconclusive discussion about how to get things "right" - which in the current context means searching for a definitive answer with very little experience and data. Against that background we look to capture 90% of the benefit with a simple approach, rather than wait for the philosophers stone for an indeterminate period. The provision for upto 8 priorities and 8 classes provides for flexibility and improvment without discarding basic interoperability. The pragmatic argument for 8 levels of destination priority is that 8 has been the common management number for all MACs to date. In .1D we even allowed 8 priorities for interfacing with 802.3 - so that management across all MAC types could take a simple view. At the time we did have in mind that there might be differential queuing in bridges. 5. I hadn't realised until a few days ago that the priority richness implied by 8 priorities had very significantly skewed the way that newcomers to 802.1p viewed the standard. At least one person told me that he viewed .1p as setting out to be primarily a QoS standard - and was considerably enlightened when I advanced my personal opinion that GARP's major role was that of a pruning protocol. As a pruning protocol of course it can have a massive impact on QoS by getting multicast traffic off links and segments where it has no need to be in the first place. One of the topologies in which .1p is very effective is that of a network with a 100 Mb/s core and 10 Mb/s edges, and the 100:10 transition queuing can cause a lot of jitter to high class traffic by accumulating low class data traffic packet crowds. The effect of .1p would be incomplete in this (and other) important but simple scenarios if there were no provision for differential queuing. While there is some dispute about large a switched network and how far across it such a simple approach will prove useful, I feel we are on very solid ground concerning the broad economic appeal and effect of the approach. In a switch intensive network where many repeaters have been replaced by switches there are many more switches at the network periphery - 95%+ of the switch ports are here. A simple scheme which works well for the first one, two, or three layers of switches into the network and allows low cost dedicated silicon based approaches makes an enormous contribution to lowering network costs (or allowing the money to be spent to further improve network jitter, response, and throughput. 6. Since the advocates for 2 levels of priority tend to have 802.3 and 802.12 backgrounds, and the advocates for 8 (or some number such as 4 or 5 more typically) have 802.5 backgrounds, I am not surprised that .3 advocates would propose a single bit distinction. It has been suggested that there is another pragmatic single bit distinction - the U/L bit in the destination address. With the IPv6 mapping of multicast to MAC addresses this would give priviliged status to IP multicast - which in turn is likely to carry time sensitive traffic. Of course that would mean that certain other protocols would run fast too - if present on the LANs under discussion. On the other hand people may not care. 7. And finally you may well be right. If 802.3/Ethernet had priority intrinsically I doubt whether there would have been sufficient demand to put it in .1p. And that would make our job easier. The devil makes work for idle bits.