From: "Norman W. Finn" Subject: Re: ["Robin Tasker": Priority in 802.1p] To: Peter_Wang@3mail.3Com.COM (Peter Wang/HQ/3Com) Date: Fri, 12 Apr 1996 12:17:52 -0700 (PDT) Cc: nfinn@cisco.com, P8021@nic.hep.net Peter Wang/HQ/3Com writes: > > > 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. > > Yes, one can imaging a lot of things! If you think through how GARP is > specified (at least the intention of the current design), you should see > that it is not a whole lot different than the combination of IGMP and > DVMRP/PIM/MOSPF. From our discussions with Prof. Cheriton, it's > apparently that if one implements it correctly, the GARP overhead should > actually be slightly less (since it allows for multiple addresses to be > registered within a single packet as opposed to the 1 address per message > for IGMP). Hence, if everyone thought IP multicast control > traffic was acceptable for routers (which are slower in general than > switches), I don't see why there should be any objection to doing similar > things at the MAC level. Thank you for clearing up one point, Peter. Because GARP allows ganging a number of MAC addresses into one DLSDU (how many? 180 or so?), there is some hope, here. My multiplier of "8" is really a "1". On the other hand, I'm not talking about multicast. I'm talking about unicast. There are a couple of orders of magnitude difference in the number of registrations in the two situations, I claim. The IP multicast model is largely irrelevant; IGMP control traffic is two packets per subnet == bridged LAN per multicast address. Simply stretching that model to support switches, with one station per twisted pair, is significant. The thing that make this feasible is the tremendous potential for reduction in data traffic that the multicast overhead buys us. Without the multiple registrations per packet, Using GARP for unicast traffic raises the bar another order of magnitude or more, with no resultant reduction in traffic. With the coalescing of addresses into fewer packets, the situation is at best comparable to the multicast case in overhead. But, it's comparable to the switch case, which is already an order worse than the router/subnet model. Now, increase the size of the installation by a factor of the number of VLANs, and we're still in trouble. ("Absurd" is no longer a relevant term. "Dangerous" is.) > > 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. > > The VLAN management and database distribution schemes are yet to be > worked out. GARP may actually work out to be as effective a mechanism > for these as well. A hope I share, but a wish that needs to be substantiated before we approve a standard. > > 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. > > If priority flag can be kept separate from MAC addresses without incurring > any control overhead and is still backwards compatible, I don't think there > will be any objections. > > -Peter I agree. That's not what many people see when reading 802.1p, though. As they stand, neither IPv4 nor IPX can deal with multiple MAC addresses as a means of achieving CoS/QoS. RSVP is the principle means, at this date, of dealing with QoS issues, but it doesn't handle multiple MAC addresses. Unless someone can address the issues I've raised, I can't vote to standardize a mechanism that can't be used by IPv4 or IPX, and doesn't scale well, even if you changed those protocols to use it. -- Norm