Posts Tagged ‘multiplexing
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.
One aspect that has been overlooked in mobile research is link layer access. Most mobility solutions assume that the link layer configuration will be automatic and base trigger mechanisms in the presence of network layer connectivity.We believe that there is the need for a framework for link layer access, to standardize the operating system interface, creating an unified API to report the presence of access point in the vicinity of the mobile, and to do AAA(Authentication, Authorization and Accounting). A multiplexing transport protocol has to be aware of new link layers that become available, and of link layers that can no longer be used, to add and remove these interfaces from protocol processing. To this end, a link-layer aware transport protocol needs the following support:
Link layer management: a management entity can usedirect information (by probing or listening to the link layer for the presence of access points) or indirect information(by using an existing connection to query the infrastructure for the existence of additional access points) to find new access points. This is called link layer discovery. Management also encompasses measuring signal strength and possibly location hints to rule that a link layer is nolonger usable. This is called link layer disconnection.
Network layer management: before using a link layer,the mobile has to acquire an IP address for that interface. The most common protocol for acquiring a network addressin broadcast media is DHCP (Dynamic Host Configuration Protocol). For point-to-point links, such as infrared, acquiring a network address also entails creatinga point-to-point link. In this case, the link will only be created on demand, as creating the link precludes other mobiles from using the same access point.
Transport layer notification: the transport layer has to benotified of new access points (in the form of a new IP address it can use) and of the loss of an active access point(an IP that can no longer be used). The transport protocols can also notify a management entity about the available bandwidth of each link. Because this bandwidth is closely tied with the available bandwidth of the last hop, by controlling the maximum bandwidth each protocol instance can use the management entity to enforce usage policies for cooperating protocols.