As with nearly any congestion scheme, RBCC provides several advantages and also several drawbacks. Here are the deficiencies of RBCC that I know of, with some comments on each.
RBCC as outlined needs five extra fields in every packet to pass the needed congestion information. Three of these hold rates and two hold machine identifiers.
The rates need to be unsigned fixed or floating point numbers with a range of, say, 9 powers of 10 (1bps to 1Tbps), an accuracy of, say, 0.1%, and an ability to represent the value . This would require at least 16 bits per field. It probably would be better to use 32-bit IEEE 754 floating point numbers. The machine identifiers depend on the network layer used. The fields would be 32 bits in length for IPv6 and 128 bits in length for IPng. Overall, this gives an overhead of 20 octets for IPv4 and 44 octets for IPng, a header increase of 50% and 110 respectively.
As RBCC keeps a per-source per-interface rate table in every router, this may be a serious use of memory when a router has hundreds or more flows of traffic through it. Even worse, the cost of recalculating a rate table may be extremely high, as the algorithm given is not simple and is probably O(N) where N is the number of traffic flows through the router.
One way of reducing the cost of rate table recalculation is by performing the recalculation periodically and only when it needs to be recalculated. For example, the period between recalculations may be 100 or 1,000 milliseconds. This lessens the cost of recalculation but will cause more short-term congestion within the network. Also, a good value for the period between recalculations may be difficult to determine, and is likely to depend on the traffic load on the router.
One of the assumptions that RBCC makes is that the route taken by packets from the source to the destination is the same as the route in the reverse direction. In real networks, this is not necessarily so. A different route will prevent the reverse packets from affecting the rate table. Further work will examine the affect on RBCC if reverse packets are not seen by an RBCC router. If RBCC performs poorly with the events missing, this will severely limit its use in real networks.
Transport connections where traffic does not pass through a router (i.e where both source and destination are on the same subnet) cannot use RBCC for congestion control. This is a serious deficiency with RBCC.
RBCC currently does not have a mechanism for dealing with short-term congestion. It would be useful, for example, to return `Quench' packets to the source so as to quickly lower the source's rate, rather than waiting a round-trip for acknowledgment packets to return rate information to the source. This idea needs investigating.
RBCC can cope with the arrival of a new traffic flow through a router due to a route change, but not with the loss of a traffic flow through due to a route change. In the latter situation, the router will not detect the loss of the flow and will give less bandwidth to other flows than is available.
One possible solution to this inadequacy would be to use the information from any dynamic route protocol to infer when route changes have affected the list of traffic flows through the router.