Discussion Overview

The following points were raised in the class discussion for this paper:

• The question of why a multiplicative decrease of ½ is used in TCP was raised. While no definitive explanation was arrived at, it was suggested that this use of ½ may be due to the fact that division by two is computationally cheap. When TCP’s AIMD mechanism was first developed, this simplicity of computing a factor of ½, relative to the computation of alternative factors such as ⁷/₈, may have provided a significant enough advantage to justify its use.

• TCP’s slow start mechanism was further elaborated on (see the presentation slides for an in-depth discussion of this mechanism). It was pointed out that because slow start allows a TCP connection to claim available bandwidth very quickly, the low initial send rate is maintained only very briefly and so, is of little practical significance to a streaming media application. It was further pointed out that the name “slow start” is an obvious misnomer for the exponentially growing process that it describes. The name was used, however, as even this exponential process is slower than the original scheme used in TCP – which was to simply send packets as quickly as possible without any regard for network congestion.

• The concern was raised that the complexity of the computational requirements placed on the sender and receiver in an equation-based congestion control scheme may be too heavy was raised. In response to this, it was noted that the protocol presented in the paper was intended for use in such computationally intensive applications as streaming multimedia. Clearly, the computation of equation-based congestion control parameters is not too much to expect from communication end-points capable of encoding and decoding video frames, for instance.

• The question of why TCP compatibility is such an important property of any transport protocol to be deployed over the general Internet was raised. In response, it was pointed out that TCP is responsible for moving nearly 90% of all Internet traffic, addresses the very serious issue of congestion collapse and is a key reason for the Internet’s remarkable ability to scale and grow. For these reasons, widespread use of a transport protocol that starved TCP traffic would probably not be acceptable to ISP’s. It was also noted that few other transport protocols have been deployed in any serious way since TCP, with the Stream Control Transmission Protocol (SCTP) being a notable exception.

• It was noted that studies published after the paper presented have shown that TCP, on average, achieve higher throughput that TFRC. This disparity, however, is not extreme.

• The question was raised as to whether or not most streaming applications make use of UDP instead of TCP. It was noted that the most streaming applications make use of TCP. As a side note, it was also noted that one advantage of using TCP is that it lets you get around firewalls.

• A concern raised was that the TFRC protocol does not provide for reliable transmission. In response to this, it was mentioned that according to the designers of TFRC, reliability is not necessary and by requiring retransmissions, may in fact be detrimental to a broad range of streaming applications (e.g. streaming video).

• It was suggested that rather than replacing TCP with TFRC, an alternative approach may be to appropriately modify TCP’s AIMD mechanism so as to achieve a smoother sending rate. It was pointed out that this alternative has been explored extensively. Generalized AIMD was introduced as a framework for such modifications to TCP.

• The Datagram Congestion Control Protocol (DCCP) was briefly discussed as a follow-up of the work presented in this paper. (See the material for Paper 10, “Designing DCCP: Congestion Control Without Reliability”, for a detailed presentation of DCCP).

• The validity of the two major concerns with TCP’s suitability for streaming media applications was brought into question. It was first noted that the two traditional criticisms of TCP for streaming video are (1) its unstable sending rate and (2) its use of retransmissions. A discussion of the argument presented in class against these two criticisms can be found in “The Case for Streaming Multimedia with TCP” (see the Additional References page for a link to this paper).