From: "Norman W. Finn" Subject: Re: ["Robin Tasker": Priority in 802.1p] To: Peter_Wang@3mail.3Com.COM Date: Thu, 11 Apr 1996 11:27:51 -0700 (PDT) Cc: P8021@nic.hep.net Peter Wang/HQ/3Com writes: > > >>There is another problem, of course, with registering priorities with > >>unicast MAC addresses -- the registration of those addresses. The > >>thought of propagating 8 * (the number of endstations) worth of unicast > >>MAC address registrations in order to establish the infrastructure > >>required for QoS packet delivery is obviously absurd. > > I believe the current draft recommended using two priority levels as default. > Also, putting the priority in GARP was originally intended for multicast > addresses, as the name GARP suggests. The fact the GARP happens to support > registration of unicast addresses was strongly advocated by David Cheriton, > the author of EGMP, which GARP evolved from. 1 * (the number of endstations) packets propagated throughout the switches and backbone is an absurd amount of traffic for (I would claim) most any installation. Look at the effort that went into 802.1D to ensure that there is only one BPDU per LAN segment per hello time. That's not to say that the notion would be entirely useless; a few switches on a Gbit backbone using 2-level tagging comes to mind. But the potential for drowning a bridged network in end-station registrations seems very real. How much control traffic? We are seeing installations with 10,000 endstations distributed among 100 VLANs. (10,000 endstations) * (8 priority levels) / LeaveAllPeriod is a heck of a lot of packets to be distributed to all switches. Reduce 8 to 2 and it's still way too many. GARP for multicast addresses does not break down so badly, because you have at most two replies per LAN segment. Also, there is only one group address per flow, with fewer flows than endstations. And, of course, balanced against the cost of GARP for group addresses, you have the reduction in the amount of traffic obtained by limiting the multicast distrubution. But registering unicast MAC addresses means multiple MAC addresses per endstation, with no benefit of reduced data flow. It's the difference between many endstations per flow and up to 8 flows per endstation. But, perhaps I'm a little confused, here. In the meetings, we have talked about unicast address registration. When I read 802.1p/D2 more carefully, last night, I found it difficult to tell whether, in fact, unicast registration is really allowed. The terminology seems to imply that it is only for group addresses without explicitly stating that it is limited to registering group addresses. Perhaps a paragraph or two that states explicitly that unicast addresses may or may not be registered by the GARP protocol is in order. (Or did I miss it? It wouldn't be the first time I mis-read a spec.) > >>So, if defining priorities in the 802.1p manner for unicast addresses > >>is not a good idea, and if a method such as the I/G bit would work for > >>both unicast and multicast, why does 802.1p have priorities at all? > > The reason 802.1p incorporates priority is to specify the behavior of > bridges when expedited forwarding is to be implemented in the bridge to > take advantage of the priority mechanisms supported by the underlying > MAC. Token Ring and FDDI both include priority field in their MAC > headers. Ethernet doesn't (yet). Even if 802.3 standardizes on using > the source MAC address's I/G bit as priority flag, the need still remains > for 802.1p to describe the bridge behavior in term of mapping priorities > to internal queues to dissimilar MAC. There is no question that the need still remains to describe the bridge behavior. The question is whether 802.1p is the place, and GARP the mechanism, for associating unicast MAC addresses with CoS. The reasoning seems to be: 1. Priorities are needed, perhaps more than 2 levels. 2. MAC addresses could reasonably be used to determine priorities for group addresses, and the group registration protocol used to make the association. 3. Endstations could use the same mechanism to associate their unicast MAC addresses with priorities. 4. Actual use of this registration mechanism by endstations for unicast messages will generate far too much control traffic. Somewhere between step 2 and step 4, something went wrong. We seem to be standardizing one mechanism (802.1p) that cannot scale to large installations, and another (802.1q) able to increase dramatically the practical size of a bridged installation. I see a disconnect that needs to be repaired. We need a CoS mechanism that will work in a large VLAN-bridged installation. I want to be clear -- I have no particular objection to having a multicast MAC destination address determine the priority of the data stream. Group addresses seem, in effect, to have a 1:1 correspondence with data flows. But unicast MAC addresses are another matter, entirely. Compare the 802.1p plan to priorities kept separate from MAC addresses, (e.g. in the VLAN tag or the I/G bit) which requires no control overhead. -- Norm