SUBJECT G1)

A recurring theme in 1993 concerned the suitability of ATM to transport TCP/IP based traffic. The arguments generally centered around the possible need for ATM WAN switches to support very large buffers such that TCP's reactive congestion control mechanism will work. Points of contention include: are big buffers needed, if so then where, and what exactly is the TCP congestion control mechanism.

Undoubtedly, many of these discussions have been fueled by some 1993 studies which reported that TCP works poorly over ATM because of the cell-discard phenomenon coupled with TCP's congestion control scheme.

The longest thread on this subject started in the October 1993 timeframe and ended in December under the subject of "Fairness on ATM Networks".

Generally folks expressed opinions in one of the following postures:

Big buffers are not needed at all....

A few argued that if ATM VC's are provisioned and treated as fixed leased lines then ATM will be able to support TCP/IP just fine. This means that you would need to subscribe to the maximum possible burst rate which would be very inefficient use of bandwidth since TCP is usually very bursty.

Put big buffers in routers and not ATM switches....

If you are using wide-area links over ATM, then use a router smart enough not to violate the Call-Acceptance contract. The call acceptance function should be such that it doesn't let you negotiate a contract that causes congestion. Congestion should only occur when there is a fault in the network. A router is quite capable of smoothing out bursts. That is what they do right now when they operate over leased lines. The advantage of an ATM connection replacing a leased line is that the connection parameters can be able to be renegotiated on the fly, so if your IP network (as opposed to the ATM network) is experiencing congestion, then it can request more bandwidth.

Supporting this thinking is the notion that for most data networks using ATM as their wide-area medium, a router would likely be the access point with many TCP connections being concentrated on a given ATM connection.

Still others suggest that ATM switches should implement priorities and that there should be different buffer sizes allocated per priority.

The different priorities and associated buffer sizes would support traffic separation, trading off cell loss for delay. So for example, "voice" traffic could have small buffer sizes and "data" traffic could have big buffer sizes. The switches would then provide the buffering necessary to support TCP's reactive congestion control algorithms.

Some folks argued that this would be "expensive" to implement. Regardless, many new switches being anounced in 1993/4 claim to have such priorities and buffer size capabilities.

In the original algorithm, the TCP goes into slow-start when a packet loss is detected. In slow-start, the window is set to one packet and increased by one for every acknowledgement received until the window size is half what it was before the packet is dropped. You get a series of larger and larger bursts but the largest causes half the number of packets to be buffered as there were before the packet drop occurred. Hence there is no burst until the window size is half what it was before the packet is dropped and is then increased at a much lower rate, 1/(window size) for each acknowledgement. This window control algorithm ensures that the only bursts generated are probably small enough to be no problem.

In the Reno algorithm, the window is halved so that packets start being sent in response to acknowledgements again after half the old window's of acknowledgements have been received. Hence there is no "burst" of packets generated. The only packess generated are in response to acknowledgements, and only after half an old window of acknowledgements are received.

For more information check out Van Jacoboson's algorithms published in ACM SIGCOMM 1988.

[ Back to Index | FAQ Index | Cell Relay Retreat ]

Maintained by Cell Relay Retreat
Last Changed 25 August 1996