In accordance with statements of direction from several vendors, TransPAC plans to implement four service classes. We are testing weighted fair queuing (WFQ) to implement this priority scheme. WFQ examines the priority bits in the IP header to route packets into several queues. These queues are then serviced in a round-robin fashion, with higher-priority queues receiving a longer service interval. Depending on the implementation, fair-queuing may be in effect within each of these queues. So, for example, if three 10-Mbps streams traverse the high-priority queue, they would each receive 33 percent of the bandwidth that's available to that queue.

All this is well and good, and sounds like it's exactly what the doctor ordered. But while several vendors offer WFQ on campus routers with 100BASE-X interfaces, no vendors that we have talked with as of this writing offer it on routers that support both BGP and ATM interfaces. This is somewhat of a paradox since a popular model within the IETF uses differentiated service in the core of wide-area networks (where BGP and ATM are currently mainstays) and RSVP at the end points. Regardless, all the vendors we have spoken with assured us that this feature is on their product road maps. Our sense is that this functionality should be available sometime this quarter.

While not immediately applicable to TransPAC, we tested one 100BASE-X WFQ implementation (Cisco's Catalyst 8510 Layer 3 switch) to determine if there are some generalizations that we could make to characterize WFQ's behavior. Using a Netcom Systems Smartbits SMB-2000 traffic generator/analyzer, we determined empirically that the worst-case bandwidth available to a given stream can be determined by the following generalized equality: BWS=(WS*L)/(WT*MS)--where, BWS equals worst-case stream bandwidth; WS equals weighted round-robin weight for stream; L equals line bandwidth; WT equals total weighted round-robin weight; and MS equals stream multiplier.

So, for example, the 8510 uses four queues per interface, which, by default, receive weights of 1, 2, 4 and 8, respectively. Queue weights are adjustable, but they must add up to 15. Packets are mapped to queues based on their IP precedence bits according to the following table:

· PrecedenceQueue Weight0-112-324-546-78

· For two packet streams with an IP precedence of 5: WS=4, L=107, WT=15, and MS=2. This gives a worst-case bandwidth for each stream of: (4*107)/(15*2)=~13.3 Mbps.

It is very important that researchers who use the TransPAC link are aware of the resources available for their applications, so such a generalized equality will come in handy in the future.

In lieu of per-VC WFQ, we are left with another mechanism that was really designed as a tool to help avoid congestion. WRED (Weighted Random Early Detection) provides a means through which traffic can be selectively dropped. This is helpful if your environment consists of traffic, like TCP, that responds when packets are dropped.

The "weighted random" part of WRED indicates that packets are discarded from random flows based on IP precedence bits. "Early detection" means that this selection is done well in advance of buffer exhaustion. The idea is that rather than allowing buffers to fill completely and then be forced to drop all traffic non-selectively, you begin to drop selectively before buffers are full. The advantage is that many traffic flows are not simultaneously affected and, in the case of TCP, do not all enter their slow start phases and begin to ramp up at the same time--an effect called "global synchronization." In environments where RED is not implemented, it is common to see waves of congestion as end systems slow down and speed up their transmissions in unison. WRED is not a substitute for WFQ, however; indeed, the two should complement each other. But given our current options, we feel WRED is better than nothing.