In this paper the authors talk about a switch-based technique for obtaining higher bandwidth compared to processor based routers of the day. They do so by discarding ATMs connection-based state and maintaining IP’s connectionless state, thus preserving IPs flexibility and simplicity. They utilize existing switch-based ATM hardware, thus achieving higher bandwidth than IP routers of the day. Several important points of the paper are:
- The concept of flows helps preserve the connection-less notion of IP in the connection oriented ATM hardware. Upon detecting a flow, there will be a connection established on the ATM switch, thus giving the flow a higher bandwidth by using the efficient hardware. Short bursts of traffic would use IP forwarding, thus avoiding the cost of establishing the ATM connections. In the case of a link failure, the switch can go back to using IP forwarding, without requiring to go through the cost of re-establishing all lost connections.
- The concept of flows makes it easier to offer QoS. The authors discuss two types of QoS, contract based and policy based. In contract based service, the switch trusts the application and allows it to choose its own QoS requirements. In policy based service, an administrator configures the switch for QoS. In both cases, the existence of flows makes it easier to apply a policy to specific flows. Furthermore, flows are given lifetimes after which if there is no activity on the flow
- The paper tends to favor the end-to-end argument by allowing each switch to make local decisions regarding the creation of connections. By placing this responsibility on the end points (the switches), the IP switches can choose what’s best for them, without the need to accept the creation of a flow as dictated by the network.
One glaring problem is that there is not enough data for the simulations described in the paper. Most of the experiments are based on short samples of data, representing the network for only a few short minutes. Also when dealing with multicast, the implementation requires establishment of point-to-multipoint connections for each sender. This might cause the creation of too many connections when dealing with multicast messages. There is not enough analysis provided whether the creation of so many connections hinders multicast performance or not.
The authors choose to use the existing ATM hardware switches because it is an already existing solution that is relatively cheap. Further research could be investigating a new hardware for the IP switch without reusing existing ATM hardware. If the IP switch is designed on its own dedicated hardware, it could be more efficient. More research needs to be done to determine the best flow detection algorithms. Another possibility would be addition of a protocol where the application can explicitly tell the switch if it requires the creation of a flow.
