The Multiplexing Transport Protocol Suite

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.


, , , , , , , , , , , ,

  1. #1 by Kevin on October 19, 2012 - 11:34 pm

    Is there a reliable way to (on the fly) separate discrete multicast channels via open source or free software?

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: