Hi Eric,
Tolly Group, via Current Analysis, has four articles on this
topic, and I am clipping from the summary:
Bandwidth Starvation Results Report Data
Report ID: 190707-0028-01.NV
Analyst: E. Hold
Issue Overview:
Although only a relatively small number of products have been tested, it is clear that session starvation is emerging as a critical issue associated with delivering QoS capabilities. The fact that HP and at least one major vendor within our current sample fail to prevent session starvation points to the importance of the issue. Based on preliminary testing results as well as research into product specifications of other switches, it would appear that session starvation is an issue with some 30% to 60% of the LAN switch vendors.
Furthermore, the current testing provides only a very basic look at QoS traffic management. Given the failure of devices to address such a basic concern, it is likely that significant implementation differences will emerge as more sophisticated QoS evaluations are done.
CurrentPerspective:
The ability to set a low priority bandwidth threshold is of key importance to the successful implementation of a policy networking solution. As such, we must take a negative position on any vendor that allows unmanaged bandwidth starvation of less important traffic. We feel that it is highly unlikely, in most circumstances at least, that users will be satisfied with any policy networking solution that causes this problem. After all, one of the key justifications for implementing a policy networking solution in the first place is the need to make more efficient use of the existing bandwidth.
It is important to note that there are some justifications for bandwidth starvation, although this should still be the user's decision, not the switch vendor's. If the policy networking solution is implemented as a strategic component of a back-up solution (such as an ISDN connection), then the ability to starve certain traffic types becomes more important. However, the key point here is that bandwidth starvation must be the user's decision, not the vendor's; a "controlled starvation" solution. As a result neither the 3Com solution (which does not allow starvation) nor the HP solution (which does starve bandwidth) are truly ideal solutions. But, while both solutions are less than perfect, it is certainly preferable to ensure that that traffic is not starved in the switch.
The results of the bandwidth starvation tests show that there are three broad categories of solution for the queue implementation scheme:
No Cap: Bandwidth starvation is expected in times of congestion (for example, HP's ProCurve 4000M).
Cap: Bandwidth starvation is avoided by setting a "cap" on the amount of bandwidth used by the high priority traffic. This is typically a 75/25% split (25% left for low priority traffic). A good example of this is the 3Com SuperStack switch
Variable Cap: Bandwidth starvation is avoided by setting a "cap" on the amount of bandwidth used by the high priority traffic. This Cap is user-definable to allow for improved networks performance. Extreme Networks implements this solution with the Summit24.
The nirvana for vendors is the variable cap solution, which provides the option of bandwidth starvation for backup situations, but in more usual circumstances ensures that the lower priority traffic is not starved out. Users should, however, look closely at the default implementation of this solution. Many vendors within this variable cap category set a default of 0% allocation to the low priority traffic - effectively providing a default of No Cap. Vendors need to address this issue, providing a default of 75/25.
|
