The two transport protocols most commonly used in the Internet are TCP, which offers a reliable stream, and UDP, which offers a connectionless datagram service. We do not offer a connectionless protocol, because the mechanisms of a rate-based protocol need a longer-lived connection to work, as they use feedback from the receiver. The interarrival time of packets is measured at the receiver and is crucial for estimating the available bandwidth and for discriminating congestion and transmission losses. On the other hand, a multiplexing unreliable protocol that offers congestion control can be used as a basis of other protocols. The regularity of a rate-based protocol lends itself naturally to multimedia applications. Sound and video need bounds on arrival time so that the playback can be done smoothly. A multimedia protocol is the natural offshoot. Most multimedia applications need timely data. Data received after the playback time is useless. Moreover, for a system with bandwidth constraints, late data is adverse to the quality of playback, as it robs bandwidth from the flow. There are many strategies to deal with losses, from forgiving applications to forward error correction (FEC) schemes. Retransmissions are rarely used, because they take the place of new data, and the time to send a request and receive the retransmission may exceed the timing constraints.
When multiple channels are available, and the aggregated bandwidth is greater than the bandwidth necessary to transmit the multimedia stream, retransmissions can be done successfully without harming the quality of playback. The simultaneous use of multiple link layers generates extra bandwidth. The best-case scenario is the coupling of a low bandwidth, low delay interface with a
high bandwidth, high delay interface. The high bandwidth interface allows for a good quality stream, while the low delay interface makes retransmissions possible by creating a good feedback channel to request (and transmit) lost frames.
When the aggregated bandwidth is not enough to transmit packets at the rate required by the application, packets have to be dropped or the application has to change the characteristics of its stream. Adapting applications can change the quality of the stream on the fly to deal with bandwidth variations, but for non-adapting applications, the best policy is to drop packets at the sender. Sending packets that will arrive late will cause further problems by making other packets late, which can have a snowball effect.
In contrast to a multimedia protocol, a reliable protocol has to deliver intact every packet that the application sent. In this case, time is not the most important factor. Lost or damaged frames will have to be retransmitted until they are successfully received. If the application expects the data to be received in the same order it was sent, the protocol will have to buffer packets received after a loss until the lost packet retransmission is received. Using the channel abstraction to multiplex the data increases the occurrence of out-of-order deliver, increasing the burden in the receiving end.