Transcripción

1 MMTP - Multimedia Multiplexing Transport Protocol Luiz Magalhaes and Robin Kravets Department of Computer Science University of Illinois, Urbana-Champaign 1304 W Springfield Avenue Urbana, IL {magalhae,rhk}@cs.uiuc.edu ABSTRACT Multimedia data has special requirements that are hard to be met on mobile hosts due to potentially low bandwidth and disruptions due to host mobility. Such limited communication capabilities of mobile hosts can be offset by the simultaneous use of multiple link layer technologies. MMTP is a member of a suite of protocols that share the novel characteristic of aggregating bandwidth from multiple linklayer channels. The use of multiple channels to transport user data provides five key benefits: (1) a fatter pipe,(2) a fast feedback path, (3) the retransmission of selected lost messages, without delaying the playout of the data stream, (4) less sensitivity to minor bandwidth fluctuations on any one individual channel, and (5) smooth vertical handoffs for active data streams. MMTP is a rate-based protocol designed for transferring multimedia data on mobile systems, and makes simultaneous use of every communication channel available to send data at the required rate. Transmission in MMTP is governed by two mechanisms. The first is a set of rate control protocols associated with each outgoing channel. The second is a scheduling algorithm that places incoming packets on the appropriate channel. MMTP is link-layer aware protocol that uses bandwidth estimation for congestion control, and relays to the application information needed for rate adaptation. In this paper, we show that the quality of data transmission can be improved through the use of MMTP through experimental comparisons with data transmitted via UDP. We also demonstrate the economy of bandwidth: MMTP only sends packets that it estimates will arrive within the packet deadline, thus decreasing the number of late packets that will be discarded at the receiver. Keywords Wireless communication, multimedia transport protocols, low bandwidth link. Permission to make digital or hard copies of all or part of this work for personal or classroom use is granted without fee provided that copies are not made or distributed for profit or commercial advantage and that copies bear this notice and the full citation on the first page. To copy otherwise, to rcpubliah, to past on servers or to redistribute to lists, requires prior specific permission and/or a fee. SIGCOMM - Latin Amedce & Catfbbean,4/01 San Jose, Costs Rica 2001 ACM ISBN /01/0004,..$5o00 1. INTRODUCTION As mobile devices become more prevalent, the demand for anytime/anywhere connectivity for those devices increases, and the requirements on that connectivity become more stringent. Connectivity for mobile devices is governed by the communication technology on the device and the coverage area of that technology. To add versatility to the mobile devices, they are normally built with multiple communication technologies and the capacity for expansion. Laptops commonly come with built in infrared and with multiple PCMCIA slots, allowing for multiple communication cards. With the growing demand for mobility support, coverage areas for wireless connectivity are growing and overlapping. Due to different administrative authorities and different underlying link layer technologies, the current infrastructures only support coordination and cooperation between homogenous support stations ("horizontal handofffs"). In order to support better handoffs, communication quality and cost optimization, the mobile node's operating system can coordinate the simultaneous use of multiple diverse communication channels, providing seamless connectivity as the mobile node migrates between coverage areas ("vertical handoffs") [1]: If the mobile node has access to multiple communication channels, the application can be guided as to which channel is currently the most appropriate [2]. Such support is limited to the use of one communication channel per application data stream. The goal of our research is to aggregate the bandwidth available from multiple channels to create a virtual channel with more bandwidth than each channel alone. Given that the bottleneck for most wireless communication is the last hop to the base station, the addition of bandwidth at this last hop will alleviate some of the resources constraints on the mobile node. Our approach exposes link-layer connectivity and resource information to the transport layer, allowing the transport protocol to adapt to both changes in available bandwidth on each channel and changes in availability of channels. Our solution preserves end-to-end semantics, transparently providing the application with the simultaneous use of multiple channels. We are currently designing a framework for the aggregation of multiple communication channels, enabling transparent use for multiple and individual data streams. A main component of this framework is a protocol suite that provides diverse transport layer protocols able to operate in the context of multiple communication channels. In this paper, we present a protocol from this suite, MMTP, Multimedia Multiplexing Transport Protocol, which supports the transmission of time 220

2 MMTP - Protoeolo de Transporte Multimedia Multiplexado Luiz Magalhaes and Robin Kravets Department of Computer Science University of Illinois, Urbana-Champaign 1304 W Springfield Avenue Urbana, IL {magalhae,rhk}@cs.uiuc.edu Resumen Los datos multimedia poseen requisitos dificiles de cumplir para sistemas anfitriones (host) m6viles, debido al ancho de banda potencialmente bajo y alas interferencias habitualmente asociados a dichos anfitriones. Estas capacidades limitadas de comunieaci6n de los sistemas anfitriones m6viles pueden mejorarse mediante la utilizaci6n simult~nea de tecnologias de capas de enlace mfltiple. MMTP es uno entre varios protocolos que comparten la novedosa caracteristica de poder agregar ancho de banda a partir de canales mfltiples de capas de enlace. La utilizaci6n de canales mdltiples para transmitir datos de usuario proporciona cinco beneficios clave: (1) un tubo m~s grande, (2) una via de retroalimentaci6n m~s r~tpida, (3) la retransmisi6n de mensajes perdidos seleccionados, sin que esto demore la presentaci6n del flujo de datos, (4) sensibilidad reducida ante fluctuaciones menores del ancho de banda en cualquier canal individual dado, y (5) transferencias verticales uniformes para flujos de datos activos. MMTP es un protocolo basado en velocidad y disefiado para transferir datos multimedia en sistemas m6viles, el cual utiliza en forma simult~fnea cualquier canal de comunieaci6n disponible para enviar datos ala velocidad requerida. En MMTP, la transmisi6n es controlada por dos mecanismos. El primero es una serie de protocolos de control de velocidad asociados a cada canal saliente. E1 segundo es un algoritmo de planificaci6n que coloca paquetes entrantes en el canal apropiado. MMTP es un protocolo orientado a capas de enlace que utiliza el c,~lculo del ancho de banda para control de congesti6n, y transmite a la aplicaci6n la informaci6n necesaria para adaptar la velocidad. En Permission to make digital or herd copies of all or part of this work for personal or classroom use is granted without fee provided that copies are not made or distributed for profit or commercial advantags and that copies bear this notice and the full citation on the first page. To copy otherwise, to republish, to post on servers or to redistribute to lists, requires prior specific permission and/or a fee. SIGCOMM - Latin Amedce & Cadbbeen 4/01 San Jose, Costa Rice 2001 ACM ISBN /01/ $5.00 este documento, a trav6s de comparaciones experimentales de datos transmitidos por UDP, se demuestra que la calidad de la transmisi6n de datos puede mejorarse mediante la utilizaci6n de MMTP. Tambi6n se demuestra el ahorro de ancho de banda: MMTP s61o envia aquellos paquetes que estima llegar~n a destino dentro del plazo limits del paquete, reduciendo de este modola cantidad de paquetes demorados a ser desechados por el receptor. 1 Introducci6n A medida que los dispositivos m6viles se hacen m~s predominantes, aumenta la demanda para que dichos dispositivos posean conectividad en cualquier momento yen cualquier lugar, y los requisitos para dicha conectividad se hacen mils estrictos. La conectividad para dispositivos m6viles depende por una parte de la tecnologia de comunicaci6n de dicho dispositivo y por otra del ~irea de cobertura de dicha tecnologia. Para agregar versatilidad a los dispositivos m6viles, generalmente se los fabrica incluyendo mfltiples tecnologias de comunieaci6n y posibilidades de expansi6n. Las computadoras port~ftiles traen comdnmente incorporados puertos infrarrojos y mfltiples ranuras PCMCIA, lo cual permite utilizar diversas tarjetas de comunicaci6n. A causa de la creciente demanda de soporte para movilidad, las ~reas de cobertura para conectividad inavtmbrica est~n aumentando y superponi6ndose las unas alas otras. Debido a las diferentes autoridades administrativas y alas distintas tecnologias de capas de enlace, las actuales infraestructuras s61o soportan la coordinaci6n y cooperaci6n entre estaciones de soporte homog6neo ("transferencias horizontales"). Con el objeto de soportar mejores transferencias, calidad de comunicaci6n y optimizaci6n de costos, el sistema operativo del nodo m6vil puede coordinar el uso simultaneo de mfiltiples y diversos canales de comunicaci6n, proporcionando asi conectividad sin barreras a medida que el nodo m6vil migra entre 221

3 sensitive rate-based data streams (e.g. audio, video) that may be generated live or from stored data. MMTP is a rate-based protocol that uses bandwidth and delay estimation for both determining the available bandwidth and for congestion control. Maintenance of these estimations provides natural support for adaptive multimedia applications. Given the characteristics of the multimedia data stream in terms of frame rate and bandwidth requirements, MMTP uses any available communication channels to transmit the data. As the available channel resources change, MMTP adapts, changing the fraction of flow that is being sent on each channel and adding or removing channels as necessary. MMTP provides a best effort service. If the aggregation of available channels does not provide enough bandwidth for the application stream, MMTP will drop packets that it estimates cannot arrive on time and inform the application of the lack of necessary resources. The use of MMTP provides five key benefits. First and foremost, there is the benefit of a fatter pipe, which enables better quality multimedia traffic. Second, MMTP provides a fast feedback path. Although the delay for data transmission will depend on the channel with the longest propagation delay, control feedback can be returned on the channel with the shortest propagation delay. Third, extra bandwidth on any of the channels may enable the retransmission of select lost messages, without delaying the playout of the data stream. Forth, due to the use of multiple channels, MMTP is less sensitive to minor bandwidth fluctuations on any one individual channel. Finally, smooth vertical handoffs for active data streams are a natural benefit of using multiple channels and of hiding link-layer connectivity. This paper is organized into five additional sections. Section 2 presents relevant research associated with the current work in communication support for mobile computing. A real life scenario of multimedia in mobile environments is investigated in Section 3. MMTP is presented on Section 4, where we explore its startup behavior, flow and congestion control. In Section 5, the experimental results are presented, and Section 6 contains conclusions and future research directions. 2. BACKGROUND AND RELATED RESEARCH The current Internet infrastructure was not designed with the needs of multimedia traffic in mind. The pervading best effort delivery protocol that forms the base of all Internet traffic, IP, has no built in mechanism for reservation of bandwidth or for periodic traffic. The protocols that were developed later to allow the use of the IP infrastructure for multimedia traffic do not consider mobility. Adapting the solutions used on wired hosts to mobile systems is not straightforward, because the characteristics of wireless communication channels are even less agreeable to multimedia traffic. In addition, normal reservation schemes [3] used for wired hosts will not work or may become very expensive due to changes in the location of a mobile host. However, varying the quality of the source stream to match the available bandwidth and loss rate has been successfully adapted to the mobile environment, although it falls to the application to keep track of the available bandwidth and other parameters necessary for the adaptation. Due the periodic nature of multimedia traffic, it is commonly accepted that the best protocols for such data streams use ratebased mechanisms. Moreover, the lossy nature of wireless communication channels makes channel losses a poor congestion indicator. In response, bandwidth estimation in conjunction with congestion avoidance has been suggested for use with wireless rate-based protocols. One of the earliest examples of a reliable rate-based protocol is NErBLT [4], which was designed for the transport of bulk data and is not suitable for multimedia traffic. Recent examples of other reliable rate-based protocols are WTCP and RAP. WTCP [5] is a reliable split connection protocol that has good performance over lossy low bandwidth links that have high latency. RAP [6] is a TCP-friendly rate-based protocol for realtime streams. The aggregation of the bandwidth from two modems has been implemented in both Linux and Windows, In both systems, the characteristics of both channels must be the same and only a simple load-balancing algorithm is used for scheduling transmission. The aggregation of many lower bandwidth channels in a larger pipe is called "reverse multiplexing" in ATM [7], and is now part of the ATM specification, as it allows a multiplicity of rates and flexibility in allocating bandwidth for commercial services. Some work has also been done in the aggregation of bandwidth [8] in wireless links by using the facilities of PPP (multi header extensions [9]. The mechanisms in MMTP are more general, working with heterogeneous interfaces. By uncoupling the transport protocol from the network protocol, transitions from one network to another are very natural in MMTP, and require no switching. The Barwan project presented the concept of "vertical handoffs"[1], transitions from one link layer to another. WTCP uses a similar model, when the mobile transitions from one area of coverage to another, there is'a handoff and the older connection is relinquished. In MMTP, if an area is connectivity rich and multiple ways to access the infrastructure are available, the activation of a new interface does not cause another to be dropped. The new interface is added to the existing pool. Adapting the bandwidth requirements of a multimedia stream to the available bandwidth of the channel has been proposed in [10]. Because this requires a close interaction between the transport protocol and the coding application, there are many proposals for integrating source coding and the transport protocol. [11] proposes a transcoding the source into a nonprioritized packet stream to ensure graceful degradation in the presence of packet loss, and describes a TCP-friendly rate based protocol and the framework for the interaction of the protocol and transcoder. [12] proposes modifications to the TPC protocol, a resilient encoder and a rate control algorithm for the same objective. While we do not delve into source coding, MMTP exposes rate changes to the application, enabling adaptation. MMTP can be viewed as two one-way protocols, one from sender to receiver carrying data, and another from the receiver to the sender, carrying control information. RTP [13] uses different streams for data and control information, while MMTP carries control information inside the data packets, allowing for changes in the rate for presentation be communicated to the application simultaneously with the receipt of data. Because MMTP does not back-off on lost packets, mechanisms such as RED [14] will not affect the sending rate. Although we believe that our congestion control method results in fair resource utilization, the work presented on [15] on the differentiating multimedia traffic on router to avoid congestion can be used to police MMTP traffic. 222

4 ireas de cobertura ("transferencias horizontales") [1]. En caso que el nodo m6vil tenga acceso a mfiltiples canales de comunicaci6n, se puede orientar a la aplicaci6n acerca de cufil de los canales es actualmente el mils apropiado [2]. Dicho soporte se limita al uso de un solo canal de comunicaci6n por flujo de datos de la aplicaci6n. Nuestra investigaci6n tiene como objetivo agregar ancho de banda disponible a partir de canales mfiltiples para crear un canal virtual con un ancho de banda mayor al de cada canal por si solo. Dado que para la mayoria de las comunicaciones inalfimbricas el cuello de botella lo constituye el filtimo salto a la estaci6n base, el agregar ancho de banda a este filtimo salto aliviarfi algunas de las restricciones de recursos en el nodo m6vil. Nuestro m6todo expone conectividad de capas de enlace e informaci6n de recursos ante la capa de transporte, haciendo posible que el protocolo de transporte se adapte tanto a cambios en el ancho de banda disponible para cada canal como a cambios en la disponibilidad de canales. Nuestra soluci6n preserva la semfintica de extremo-a-extremo, y en forma transparente permite a la aplicaci6n el uso simultaneo de mfiltiples canales. En la actualidad estamos disefiando un marco para el agregad0 de mfiltiples canales de comunicaci6n, 1o cual permitir~ el uso transparente de flujos de datos mfiltiples e individuales. Uno de los principales componentes de este marco es un conjunto de protocolos que proporciona diversos protocolos de capas de transporte capaces de operar en el contexto de mfiltiples canales de comunicaci6n. En este documento, presentamos uno de los protocolos de este conjunto, MMTP, Protocolo de Transporte Multimedia Multiplexado, el cual soporta la transmisi6n de flujos de datos basados en velocidad y sensibles al tiempo (por ej.: audio, video) generados en vivo o a partir de datos almacenados. MMTP es un protocolo basado en velocidad que utiliza estimaciones de ancho de banda y de demora tanto para determinar el ancho de banda disponible como para control de congesti6n. El mantenimiento de dichas estimaciones proporciona el soporte natural para aplicaciones multimedia adaptables. Dadas las caraeteristicas del flujo de datos multimedia en t~rminos de velocidad de cuadro y de requisitos de aneho de banda, MMTP utiliza cualquier canal de comunicaci6n disponible para transmitir los datos. Cuando los recursos del canal disponible cambian, MMTP se adapta mediante la modificaci6n de la fracci6n de flujo que estfi siendo enviado en cada canal y el agregado o eliminaci6n de canales segfin sea necesario. MMTP proporciona el mejor servicio disponible. Si el agregado de canales disponibles no proporciona el suficiente ancho de banda para el flujo de la aplicaci6n, MMTP desecharfi paquetes que segfn sus estimaciones no pueden llegar a tiempo, e informarfi a la aplicaci6n acerca de la falta de recursos necesarios. La utilizaci6n de MMTP proporciona cinco beneficios clave. Ante todo, el beneficio de un tubo mils ancho, el cual permite una mejor calidad de trfifico multimedia. En segundo lugar, MMTP proporciona una via rfipida de retroalimentaci6n. A pesar de que la demora en la transmisi6n de datos dependerfi del canal con la mayor demora de propagaci6n, se puede reenviar retroalimentaci6n de control por el canal con la menor demora de propagaci6n. En tercer lugar, el ancho de banda extra en cualquiera de los canales puede permitir la retransmisi6n de mensajes perdidos seleccionados, sin demorar la presentaci6n del flujo de datos. En cuarto lugar, y debido a la utilizaci6n de mfiltiples canales, MMTP es menos sensible ante fluctuaciones menores del ancho de banda en cualquier canal individual dado. Por filtimo, las transferencias verticales uniformes para flujos de datos activos constituyen un beneficio natural derivado de la utilizaci6n de mfiltiples canales y del encubrimiento de la conectividad de capas de enlace. Este documento estfi organizado en cinco secciones adicionales. La secci6n 2 presenta investigaciones pertinentes relacionadas con el presente trabajo acerca de soporte de comunicaciones para computaci6n m6vil. En la secci6n 3 se investiga un escenario real de multimedia en ambientes m6viles. MMTP es presentado en la secci6n 4, donde se hace un reconocimiento de su comportamiento de inicio, flujo y control de congesti6n. En la secci6n 5 se presentan los resultados de los experimentos, y la secci6n 6 contiene cor/clusiones e indicaciones para futuras investigaciones. 2 Precedentes e investigaciones relacionadas La infraestructura actual de Internet no fue disefiada teniendo en cuenta las necesidades del trilfico multimedia. IP, hasta ahora el mejor y mils difundido protocolo de entrega que forma la base de todo el trfifico de Internet, no posee ningfin mecanismo incorporado para la reserva de ancho de banda o para trfifico peri6dico. Los protocolos disefiados con 223

5 A new approach to mobility is to make mobility visible to the endpoint. While Mobile IP tries to hide host mobility by using proxies, mobility can also be achieved by letting transport protocols take care of the switch. This requires the uncoupling of the network address from the connection identifier, and a scheme for location. TCP and DNS were modified to accomplish that in [16]. The same end-to-end arguments apply to MMTP, but MMTP relies on a proxy for location. MMTP has the additional advantage in the case of multimedia traffic because it generally does not need nor accepts the added overhead of TCP reliability. Sh rt Range Vh.~ Radi In-Building Infrared Cellular Network NC:llt~olar~ 3. MULTIMEDIA IN MOBILE ENVIRONMENTS Multimedia traffic is very sensitive to delay, jitter and bandwidth restrictions. Introducing wireless links into the path of a multimedia data stream not only increases the potential for such problems, but also brings with it problems from handoffs. In an effort to offset these negative effects, a mobile host may have access to multiple communication technologies. With the growing pervasiveness of the wireless infrastructure, in many places there will be an overlap of coverage. This presents an opportunity to tap additional resources to help the transmission of multimedia traffic. At the same time, mobility-aware protocols may account for communication artifacts created by movement, such as variations in bandwidth and changes in channel availability. Consider the following scenario: a user is waiting for a train and wants to watch the news. The train station terminal has both short-range radio and infrared connectivity. The user has a cellular modem in addition to the infrared and short-range ratio interfaces on the palmtop. Currently, the user would have to choose which interface to use to access his/her favorite news source. Even if the user chose the interface with the best qualities, any fluctuations in service characteristics would directly impact reception. When the user boards the train, the local connectivity (short-range radio and infrared) becomes unavailable. If the user had chosen any of the local connections, there would be a gap in the transmission as the connection was being handed off to the cellular modem. The solutions presented in this paper improve this scenario in two ways: better channel quality and seamless handoffs. The improvement of quality comes with the use of all available channels. This not only aggregates bandwidth, permitting a better quality in the multimedia data stream, but also smoothes out variations in a single channel that would impact data presentation by spreading consecutive packets in different media. We enable the simultaneous use of multiple channels by exposing the underlying link layer to the transport protocol. By creating a transport protocol that is mobility-aware, and knows the existence of multiple interfaces, we can offer the illusion of a single "fatter" pipe with better transmission qualities to the multimedia application. This aggregated channel has interesting qualities. Although the individual channel with longest propagation delay dominates the propagation delay for data, as will be shown in the next section, the control data may take advantage of the channel with lowest propagation delay, helping adaptation. Figure 1. Wireless Mobility The use of overlapping communication channels allows for smooth handoffs as the mobile node migrates between coverage areas. If the user moves slowly out from an area covered by a certain communication means, the degradation in quality is perceived by the protocol, and the channel is slowly phased out, with no interruptions. When entering an area covered by a new link layer, the protocol adds the new channel to its processing, with the entailing gains in quality. 4. MMTP MMTP supports the transmission of time sensitive rate-based data streams that may be generated live or from stored data. Given the characteristics of the data streams in terms of frame rate and bandwidth requirements, MMTP uses any available communication channels to transmit the data. As the available channel resources change, MMTP adapts, adding or removing channels as necessary. MMTP provides a best effort service. If the aggregation of available channels does not provide enough bandwidth for the application stream, MMTP will drop packets that it estimates cannot arrive on time and inform the application of the lack of necessary resources. MMTP is a rate-based protocol that multiplexes data packets across multiple communication channels. The main task of MMTP is the decision as to which channel to use for transmitting the current packet. This decision is based on estimations of the bandwidth and delay characteristics of each channel. After startup, two control mechanisms arc used to adapt the sending rate to the channel bandwidth: rate decrease messages and channel probe. In this section, we present the protocol parameters and describe the operation of MMTP. 4.1 Communication Framework MMTP was designed in the context of a communication framework that provides support for the simultaneous use of multiple link-layer communication technologies. Relevant to this protocol, the framework provides the following functionality. First, the framework monitors for the availability of communication channels for each communication interface on the mobile computer. Dynamic probing techniques are used to find new channels and maintain information about existing channels. Second, the framework probes idle available channels for information about channel parameters such as available bandwidth and propagation delay. Information about active channels is 224

6 posterioridad para permitir que la infraestructura IP sea utilizada para trifico multimedia no tienen en cuenta la movilidad. Adaptar las soluciones utilizadas en sistemas anfitfiones fijos para aplicarlas a sistemas m6viles no es sencillo, debido a que las caracteristicas de los canales de comunicaci6n inalimbrica son incluso menos adecuados para el trifico multimedia. Ademis, los esquemas de reserva normales [3] utilizados para sistemas anfitriones fijos no funcionarin o serfin demasiado costosos a causa de los cambios de ubicaci6n del anfitri6n m6vil. Sin embargo, la variaei6n en la calidad del flujo de origen para obtener el ancho de banda y la tasa de p6rdida disponibles ha sido adaptada con 6xito al ambiente m6vil, a pesar de que es la aplicaci6n la que debe controlar el ancho de banda disponible y otros parimetros necesarios para la adaptaci6n. Debido a la naturaleza basada en velocidad (ratebased) del trifico nmltimedia, generalmente se acepta que los mejores protocolos para dichos flujos de datos utilicen mecanismos basados en velocidad. Debido a la inestable naturaleza de los canales de comunicaci6n inahimbrica, las p6rdidas no siempre indican congesti6n. Como respuesta, se ha sugerido utilizar estimaci6n de ancho de banda en conjunto con evitaci6n de congesti6n para protocolos inalimbricos basados en velocidad. Uno de los primeros ejemplos de protocolo confiable basado en velocidad es NETBLT [4], el cual rue diseflado para el transporte de datos en masa y no resulta adecuado para el tr,~fico multimedia. Algunos ejemplos m~is recientes de otros protocolos confiables basados en velocidad son WCTP y RAP. WCTP [5] es un protocolo confiable de conexi6n dividida con muy buen rendimiento en enlaees inestables de bajo ancho de banda con alta latencia. RAP [6] es un protocolo basado en velocidad y de ficil utilizaci6n con TCP, para flujos en tiempo real. El agregado del ancho de banda de dos m6dems ha sido implementado tanto en Linux como en Windows. En ambos sistemas, las caracteristicas de ambos canales deben ser las mismas, y s61o se utiliza un algoritmo simple de equilibrio de carga para programar la transmisi6n. Los mecanismos en MMTP son mils generales y trabajan con interfaces heterog6neas. AI separar el protocolo de transporte del protocolo de red, las transiciones de una red a otra son muy naturales en MMTP, y no requieren conmutaci6n. E1 proyecto Barwan present6 el concepto de "transferencias verticales" [1], transiciones desde una capa de enlace a otra. WTCP utiliza un modelo similar, cuando la unidad m6vil pasa de un firea de cobertura a otra, se produce una transferencia y se abandona la conexi6n anterior. En MMTP, si un irea posee alta conectividad y se encuentran disponibles diversas maneras de acceder a la infraestructura, la activaci6n de una nueva interfaz no produce el descarte de otras. La nueva interfaz se agrega a los recursos existentes. En [7] se propone adaptar los requisitos de ancho de banda del flujo multimedia al ancho de banda disponible del canal. Debido a que esto requiere una estrecha interacci6n entre el protocolo de transporte y la aplicaci6n de codificaci6n, existen varias propuestas para integrar la codificaci6n de origen y el protocolo de transporte. [8] propone transcodificar el origen, transformfindolo en un flujo de paquetes no prioritario de manera de asegurar una degradaci6n agraeiada en presencia de p6rdida de paquetes, y describe un protocolo basado en velocidad y de ficil utilizaci6n con TCP, y el marco para la interacci6n del protocolo y del transcodificador. Con el mismo objetivo en mente, [9] propone modificaciones para el protocolo TCP, un codificador adaptante y un algoritmo de control de velocidad. Sin ahondar en la codificaci6n de origen, MMTP propone cambios de velocidad en la aplicaci6n y posibilita la adaptaci6n. MMTP puede ser visto como dos protocolos de una sola via, una que transporta datos desde el emisor al receptor, y otra que transporta informaci6n de.control desde el receptor al emisor. RTP [10] utiliza diferentes flujos para informaci6n de datos y de control, mientras que MMTP transporta informaci6n de control dentro de los paquetes de datos, permitiendo que los cambios en la velocidad de presentaci6n sean comunicados a la aplicaci6n en forma simultanea a la recepci6n de datos. Debido a que MMTP no desiste en caso de paquetes perdidos, los mecanismos tales como RED [11] no afectarin la velocidad de transmisi6n. Aunque consideramos que nuestro m6todo de control de congesti6n tiene como resultado una utilizaci6n justa de recursos, el trabajo de [12] acerca de la diferenciaci6n de trifico multimedia en el router para evitar congestiones se puede utilizar para monitorear el trfifico de MMTP. Un nuevo enfoque ante la movilidad es el de hacer que esta sea visible para el extremo. Mientras que el IP M6vil intenta ocultar la movilidad del sistema anfitri6n mediante el uso de proxies, la movilidad tambi6n se puede obtener permitiendo que sean los protocolos de transporte los que se encarguen de la central. Esto requiere separar la direcci6n de red del identificador de conexi6n, asi como un esquema para ubicaci6n. Para conseguir esto, en [13] se 225

7 collected from the protocols using them. The framework continues monitoring dynamically, providing information about available and active interfaces to interested protocol such as MMTP. This communication framework is currently being designed in conjunction with the protocols that will be using it. The details of the framework are beyond the scope of this paper. 4.2 Data Characteristics Multimedia data streams can be generated on the fly at the rate at which they need to be played out or retrieved for storage. Applications using on-the-fly streams often have very little tolerance for delay, while applications using stored media may be more tolerant. In addition, for the former, frames are only accessible for transmission as they are generated, while in the later, all frame are accessible at the same time. Frames from multimedia data streams often exceed the maximum transmission size and must be fragmented into multiple packets. Intelligent fragmentation can be done that enables the reception and processing of pieces of the frame, even if the entire frame does not arrive, supporting the concept of application level framing [17]. In the rest of this paper, we discuss MMTP in the context of on-the-fly data with one packet per frame. 4.3 Startup Behavior On startup, the application defines the requested frame rate. The protoeol queries the communication framework to learn the number of available channels, and an estimate of the propagation delay and packet rate for each. To see if the required frame rate can be met, the protocol calculates the available aggregated channel rate. There are two cases: 1. Frame rate > Z packet rate(i) o the application is notified that packets will be dropped. The application may decide to abort the transmission, to change the frame rate or just continue. 2. Frame rate < ~ packet rate(i) the estimation indicate that there is enough bandwidth for the transmission. Initial delay is a playout parameter that tells the receiving application how long to wait before playing the first frame. Initial delay can be chosen between the maximum initial delay given by the application and the minimum initial delay calculated by the protocol given the propagation delays of active channels. The larger the initial delay, the more slack the protocol has to compensate for jitter, because it adds time to the deadline of each frame. The receiving application will buffer a number of frames proportional to the ratio between initial delay and frame period (the inverse of frame delay) before initiating playout. Initial delay is always greater or equal the longest propagation delay for the channels being used and is not dependent on which channel is used to send the first packet. The examples in Figure 1 depict the startup behavior assuming two channels and one packet per frame. Figure la shows initial delay when the first packet is sent on the channel with longest propagation delay, and Figure Ib shows initial delay when the first packet is sent on the other channel. In the both examples, the sender receives frame 0 at time t and frame 1 at time t + 1/frameRate. In Figure la the first frame was sent on the channel with longest propagation delay, So playout can start as soon as frame 0 is received, since we know that frame 1 will have arrived at the end of frame 0 play period. If propagation delays of the two channels are very different, it is possible that frame 1 will arrive before frame 0. In this situation, we buffer frame 1 and still begin playout upon receipt of frame 0. In Figure lb, frame 0 arrives first, but playout must be delayed until we are within one play period of the receipt of frame 1, or else there may be a gap at the end of the playout of frame 0. Because MMTP uses estimation for both available bandwidth and propagation delay, it is difficult to implement option 2, since initial delay depends directly on the estimated value for propagation delay in both channels. Sending the first packet on the channel with longest propagation delay allows the playout to be self-eloeked to [ Frame Time I I sender = r_i.._.._.._.~ ~ g! ~ e [ ~ i'ql-"pr P i delay _Prop ~_4~ I [ delay 1. [" = Pl~yout Play~ut frame 1 frame 2 to [ Frame Time I I i sender i~r il -,.- : PlaTyout Play~ut frame 1 frame 2 Figure 2. Startup Behavior for MMTP with Two Channels 4.4 Flow Control Flow control for MMTP can be modeled as a set of rate control protocols, one for each channel, all servicing a single queue. 226

8 modificaron tanto TCP como DNS. Los mismos argumentos extremo-a-extremo son aplicables en MMTP, a diferencia que este 61timo utiliza un proxy para ubicaci6n. En el caso de tr~fico multimedia, MMTP tiene una ventaja adicional ya que generalmente no necesita ni acepta el gasto fijo agregado de depender de TCP. 3 Multimedia en ambientes m6viles Imcwt RJuqla nadla In-lilulldlng InW'MqKI ~l, Uuklr Netwm'k Cdular Netwn El trfifico multimedia es muy sensible ante demoras, jitter y restricciones de ancho de banda. La introducci6n de enlaces celulares en la ruta de un flujo de datos multimedia no s61o incrementa el potential para que se produzcan dichos inconvenientes, sino que tambi~n conlleva problemas con las transferencias. En un esfuerzo por contrarrestar estos efectos negativos, el anfitri6n m6vil puede tener acceso a diversas tecnologias de comunicaci6n. Debido a la creciente penetrabilidad de la infraestructura inalfimbrica, en muchos lugares se producir~ una superposici6n de coberturas. Esto presenta la oportunidad de interceptar recursos adicionales para facilitar la transmisi6n de trfifico multimedia. AI mismo tiempo, los protocolos orientados a movilidad pueden dar cuenta de artefactos de comunicaci6n creados por movimiento, tales como variaciones en el ancho de banda y cambios en la disponibilidad de canales. Considere el siguiente caso: un usuario estfi esperando un tren, y quiere ver las noticias. La terminal de la estaci6n de trenes posee tanto conectividad de radio de corta distancia como infrarroja. E1 usuario posee en su computadora de mano un m6dem celular ademfis de las interfaces infrarroja y de radio de corta distancia. En la actualidad, el usuario deberia seleccionar qu6 interfaz desea utilizar para acceder a su servicio de noticias favorito. Incluso si el usuario selecciona la interfaz con las mejores cualidades, cualquier fluctuaci6n en las caracteristicas del servicio afectarfi directamente la recepci6n. Cuando el usuario sube al tren, la conectividad local (radio de corta distancia e infrarroja) deja de estar disponible. Si el usuario ha seleccionado cualquiera de las conexiones locales, se producirfi una interrupci6n en la transmisi6n debido a que la conexi6n estfi siendo transferida al m6dem celular. Las soluciones presentadas en este documento mejoran este escenario de dos maneras: mejor calidad de canal y transferencias sin barreras. Figura 1: Movilidad eelular La mejora de calidad surge a partir de ia utilizaci6n de todos los canales disponibles. Esto no s61o agrega ancho de banda, 1o cual permite una mejor calidad en el flujo de datos multimedia, sino que tambi6n mediante la difusi6n de paquetes consecutivos en diferentes medios suaviza en un canal individual aquellas variaciones que podrian afectar la presentaci6n de datos. AI exponer la capa de enlace subyacente ante el protocolo de transporte, posibilitamos la utilizaci6n simuttanea de mfiltiples canales. Mediante la creaci6n de un protocolo de transporte orientado a movilidad que conoce la existencia de mfiltiples interfaces, es posible ofrecer la ilusi6n de un tubo finico mils ancho con eualidades de transmisi6n mejor preparadas para la aplicaci6n multimedia. Este canal agregado posee cualidades interesantes. A pesar de que el canal individual con mayor demora de propagaci6n domina la demora de propagaci6n de datos, como se demuestra en la secci6n siguiente, los datos de control pueden sacar ventaja del canal con menor demora de propagaci6n de datos, lo cual facilita la adaptaci6n. La utilizaci6n de eanales de comunicaci6n superpuestos permite transferencias uniformes a medida que el nodo m6vil se desplaza entre fireas de cobertura. Si el usuario se aleja lentamente de un ~irea cubierta por un cierto tipo de medio de comunicaci6n, el protocolo percibe la degradaci6n de calidad y el canal se desfasa lentamente, sin interrupciones. AI entrar en un firea cubierta por una nueva capa de enlace, el protocolo agrega el nuevo canal a su procesamiento, con las mejoras correspondientes en la calidad. 4 MMTP MMTP soporta la transmisi6n de flujos de datos basados en velocidad y sensibles al tiempo, que pueden ser generados en vivo o a partir de datos almacenados. Dadas las caraeteristieas de los flujos de datos en t6rminos de veloeidad de euadro y de 227

9 Tokens are generated for each channel based on estimates of available bandwidth and tagged with estimates of propagation delay. Packets are inserted into the queue at the frame rate of the source and need to be transmitted on one of the available channels. This type of resource management problem closely models the scheduling of processes in realtime multiprocessor operating systems [18], where processing time is mapped to transmission time for each channel. Packets are transmitted on a channel if there is a token and if the propagation delay ensures that the frame will arrive on time. Tokens are used for each transmission on a channel and new tokens are not generated until old tokens are used. When a frame arrives, there are three possibilities: 1. No tokens are available: the frame has to wait until a token is generated on a channel that will deliver it on time. If no token is generated before the frame's deadline expires, the frame is discarded. 2. Exactly one token is available: if the corresponding channel can deliver the frame on time, the frame is sent. Otherwise, this case reduces to case Multiple tokens are available: if more than one channel can deliver the frame, the channel with longest propagation delay is chosen. Maintaining the channel with longest propagation delay filled helps creating a fast response path. If no channels can satisfy the frame's deadline, the frame waits as in case 1. Even if none of the available channels can currently send a frame, queued frames may still be transmitted if a new channel with smaller propagation delay is added or a large decrease in the expected propagation delay of one of the current channels enables successful packet transmission. 4.5 Congestion Control In MMTP, congestion control is implemented as a reactive technique based on bandwidth estimation. Both the propagation delay and available bandwidth in a channel will vary due to routing changes and due to interference caused by other traffic. The available bandwidth is equal to the diffference between the maximum bandwidth of each link and the usage of each link. Propagation delay is composed of two parts: the actual propagation delay of the bits in the transmission lines and plus the time spent during processing in each router on the path. The first part is fixed in the absence of route changes, but the second will grow according to the size of the queues in the intervening routers. To avoid congestion, the protocol tries to keep the requested bandwidth below available bandwidth in a channel. This is done by measuring available bandwidth and changing the rate packets are sent to a compatible value. Available bandwidth is inferred by measuring the inter-arrival times of packets at the receiver, and feeding the measurements back to the sender. Because packets are being sent at regular intervals in each channel, the inter-arrival time should converge to the period frames are being sent on that channel if sufficient bandwidth is available. If the inter-arrival times start to grow, somewhere in the path a router is running above capacity, and queuing packets Parameter Estimation To estimate the basic parameters, available bandwidth and propagation delay, the inter-arrival time of packets is traeked at the receiver for each channel. Inter-arrival time is compared to the period frames are being sent on that channel (present on each packet header). With stable queueing delays, inter-arrival time should converge to this period. As queueing delays change, jitter is introduced and inter-arrival time will vary. A running total for jitter should be zero if there are no changes in channel characteristics, stabilizing the average inter-arrival time. A packet that arrives late causes the next packet to appear to arrive earlier, so the sum of the jitters should cancel. The accumulated jitter is a moving average of the last n packets, where n is an implementation parameter. The size of n should be such that it has the same temporal granularity of the keepalive messages, so those can carry meaningful data back to the sender. There are two special cases when running total for jitter will not be zero: When there is incipient congestion, the queue sizes on the routers grow, and this is seen at the receiver as a positive increase in the accumulated jitter. In this case, the receiver sends back a message asking for a decrease in the sending rate, so the transmission will not cause congestion. This is actually a better mechanism than decreasing bandwidth usage upon dropped packets. Using dropped packets as a measure of congestion is a reactive technique, used when congestion is already present. By using the accumulated jitter to signal approaching congestion, the protocol can try to prevent packets from being dropped. Moreover, dropped packets are not a good measure of congestion for mobile hosts, where wireless links have much higher loss rates than normal wired lines. When propagation delay drops, there will be a drop in the inter-arrival time in one time-slot. Alter that, the perceived rate will again converge to the sending rate. To detect that this drop is not an artifact cause by a previous packet that was very late, the jitter history is analyzed. If the pattern shows a large positive value followed by a large negative value (which would cancel out), then this event is ignored. If the trend is stable, and the early packet is not an artifact, then the next keep alive message will carry an indication that extra bandwidth may be available on that channel. The measurement of inter-arrival times works well to prevent congestion, but it does not work to measure excess or idle bandwidth in a channel. The problem is that at every sending rate, the maximum bandwidth measured by the application is equal to the bandwidth being pumped at the sender. Therefore, we can decrease the sending rate, but not increase it with this method. Another mechanism is needed to measure available bandwidth above what is being used Probing The mechanism MMTP uses to measure an increase in available bandwidth is probing. There are two easy ways to implement probing. The first one is additive increase: to continually increase the send rate by small amounts in the absence of rate decrease requests, and keep normal inter-arrival time measurements. If the inter-arrival times start to grow, that means we overshot or we are experiencing congestion, and the protocol has to throttle back the rate. The problem with this approach is that the virtual bandwidth gains are not tested until needed, as the packet rate is bound by the frame rate of the multimedia stream. In addition, when needed the virtual bandwidth measured by the rate increases may not be there. 228

10 requisitos de ancho de banda, MMTP utiliza cualquier canal de comunicaci6n disponible para transmitir los datos. A medida que los recursos del canal disponible cambian, MMTP se adapta, agregando o eliminando canales segdn sea necesario. MMTP proporciona un servicio de mejor esfuerzo. Si el agregado de canales disponibles no proporciona el suficiente ancho de banda para el flujo de la aplicaci6n, MMTP desecharfi paquetes que segfin sus estimaciones no pueden llegar a tiempo, e informar~i a la aplicaci6n acerca de la falta de recursos necesarios. MMTP es un protocolo basado en velocidad que distribuye en forma mfiltiple paquetes de datos a lo largo de mfiltiples canales de comunicaci6n. La principal tarea de MMTP consiste en decidir qu6 canal usar para transmitir el paquete actual. Esta decisi6n se basa en estimaciones del ancho de banda yen las caracteristicas de demora de cada canal. Luego del inieio, se utilizan dos mecanismos de control para adaptar la velocidad de transmisi6n al ancho de banda del canal: mensajes de disminuci6n de velocidad y sondeo de canal. En esta secci6n, presentamos los parfimetros del protocolo y describimos la operaci6n de MMTP. 4.1 Marco de Comunicaci6n MMTP rue disefiado dentro del contexto de un marco de comunicaci6n que proporciona soporte para el uso simultaneo de mfiltiples teenologias de enlace de capa. En 1o que respecta a este protocolo, el marco provee la siguiente funcionalidad. En primer lugar, el marco monitorea la disponibilidad de eanales de comunicaci6n para cada interfaz de comunicaci6n de la computadora m6vil. Se utilizan t6cnicas din~micas de sondeo para encontrar nuevos canales y mantener la informaci6n acerca de canales existentes. En segundo lugar, el marco sondea canales disponibles ociosos para obtener informaci6n acerca de parfimetros de canal tales como ancho de banda disponible y demora de propagaci6n. La informaci6n acerca de, los canales activos se obtiene a travcs de los protocolos que los est~tn utilizando. El marco continua monitoreando din~tmicamente, proporcionando informaci6n acerca de interfaces disponibles y activas a aquellos protocolos interesados, tales eomo MMTP. En la actualidad, se est~ disefiando este marco de comunicaci6n en conjunto con los protocolos que lo utilizarfin. Los detalles acerca del marco no esutn incluidos en el presente documento. 4.2 Caracterlsticas de los datos Los flujos de datos multimedia se pueden generar al vuelo a la velocidad a la cual necesitan ser reproducidos o recuperados para almacenamiento. Las aplicaciones que utilizan flujos al vuelo poseen generalmente baja tolerancia ante demoras, mientras que las aplicaciones que utilizan medios almacenados pueden ser mils tolerantes. Adem,qs, en el primer caso, s61o se puede acceder a los cuadros para transmisi6n a medida que son generados, mientras queen el segundo caso, se puede acceder a todos los cuadros al mismo tiempo. Los'cuadros de flujos de datos multimedia exceden a menudo el tamaflo m/tximo de transmisi6n y deben ser fragmentados en paquetes mfltiples. Se puede realizar una fragmentaci6n inteligente que posibilite la recepci6n y procesamiento de partes del cuadro, incluso si la totalidad del mismo no llega a destino, lo cual soporta el concepto de encuadre a nivel de aplicaci6n [14]. En el resto de este documento, consideraremos a MMTP dentro del contexto de datos al vuelo con un paquete por cuadro. 4.3 Comportamiento de inicio A1 iniciarse, la aplicaci6n define la velocidad de cuadro requerida. El protocolo consulta al marco de comunicaci6n para obtener la cantidad de canales disponibles, asf como una estimaci6n de la demora de propagaci6n y velocidad de paquete para cada uno de los mismos. Para determinar si se puede obtener la velocidad de cuadro requerida, el protoeolo calcula la velocidad agregada del canal disponible. Hay dos casos: * Velocidad de cuadro > ~ velocidad de paquete (i)- se notifica a la aplicaci6n que se descartarfin paquetes. La aplicaci6n puede decidir abortar la transmisi6n, modificar la velocidad de cuadro o simplemente continuar. Velocidad de cuadro < ~ veloeidad de paquete (i)- la estimaei6n indica que existe ancho de banda suficiente para la transmisi6n. La demora inicial es un parfimetro de reproducci6n que le indica a la aplicaci6n receptora cufinto tiempo debe esperar antes de reproducir el primer cuadro. La demora inicial puede seleceionarse entre ia demora inicial m6xima establecida por la aplicaci6n y la demora inicial minima calculada por el protocolo en base a la demora de propagaci6n de los canales 229

11 The second is to use probe-packets. A probe packet is sent back to back with a normal packet. The inter-arrival time of the packet and the probe should be zero, as they were sent back-toback. However, normally this value will not be zero, but instead measure the queuing delay inserted by the reuters. Probe packets should carry useful payload, as they will take place of a normal packet. The problem is that there may not be data available to send two packets back-to-back. In this case, an empty packet can be sent. This type of probing can be harmful if the system is working at the limit: the bandwidth lost to the probe packet may cause a useful packet to be dropped. 4.6 Adding and Removing Channels The initial list of available channels is received from the communication framework when the protocol starts. As time goes by, new channels may become available, and old channels may be lost. The communication framework notifies MMTP of those events, and gives ancillary information as estimates of available bandwidth. When a new channel is added to protocol processing, the available bandwidth has to be measured if this data is not present. To do the initial probing, the protocol used the packet pair method [19], the same mechanism as the normal protocol probing: two messages are sent back to back and their interarrival time is measured at the receiver. This is used as the estimation of maximum bandwidth on that link, and fed back to the sender. When a channel is lost, a de-registration message is sent to the peer using the channel with lowest delay. This takes out that interface from the protocol processing. The message also contains the last packet received on that channel. Outstanding packets are put on the queue for retransmission, with the same constraints of the other packets (they will not be sent if they cannot meet the deadline.) Every active channel sends keep-alive messages periodically. Besides notifying the peer that the channel is still open, these messages carry updates of the measures performed at the receiver, the inter-arrival times of the messages, the estimated available bandwidth, the number of packets late and lost. If a keep-alive is not received, the sender sends a query message to assure that the channel is still open or if a control message was lost. A channel may be present in processing but not carry any data if the channel delay is greater than the slack on the channel. This may happen if transmission started before the channel was added to the processing. If the delay on the new line is greater than DO (the initial delay), the channel can never be used to carry data for that transmission. It can still carry control messages, but it will only be used if no other channels are available. Normal keep-alive messages and probing are done in the channel, in ease the delay drops to a usable level. A channel may also be phased out if the delay or bandwidth drops to very low levels. This may happen as the user moves out of the coverage area and the link layer conditions deteriorate, or by congestion. While no de-registration message arrives, keep-alive and probing will continue. If only one channel is available and keep-alive messages are not being received, the protocol will signal that the link may be broken. 5. EXPERIMENTAL RESULTS We built our experiments to show two important aspects of MMTP. The first is bandwidth aggregation: we show that we can send better quality streams if we use more than one channel. This was accomplished by measuring the number of packets that arrived on time. The second aspect of MMTP is the economy of bandwidth. MMTP will only :send packets that it estimates will arrive within the packet deadline. This way no resource is wasted. This is shown by the goodput, or ratio of packets that arrived on time by the total number of packets sent. This was shown indirectly by measuring the number of packets that arrived late. 5.1 Experimental Testbed Our test setup consists of two Sony laptops, a PCG-505TR and a PCG-F450, both running RedHat 6.2 linux with kernels, patched for infrared, and with PCMCIA package version The first is connected to the network using a 3Cam 574 PCMCIA adapter at 10Mbps. The second has two connections, an IRLan connection to an HP NetBeamlR using an Actisys dongle on the serial port, and a Rangelan2 PCMCIA adapter, as shown on Figure 3. The first laptop is running the proxy software and the mobile the client side. Proxy Infrared o,] mobile I B u Rangelan Figure 3. Test Setup Infrared and Rangelan have very different characteristics. Infrared offers a point-to-point reliable link layer, with link speeds up to 4Mb/s. The use of a serial dongle limited the speed to 115Kbps, and the protocol overhead further limited throughput to 9KBps. Rangelan is an old radio technology, the radio link is subject to burst errors, and throughput varies with medium usage. The best throughput measured was on the order of 36KBps. The major characteristics are given in Table 1. Table 1. Characteristics of the Wireless Networks Delay for packets Minimum Average Throughput of 1400 bytes (msec) (msec) (KB/sec) Infrared Rangelan i We assume that there is a source generating frames of 1400 bytes with a certain periodicity. We tested our protocol against a nxfve program that sends frames using UDP as they are being generated. The results for the test program follow. 5.2 Rangelan These are typical results since there are small fluctuations due to traffic and errors on different runs. For each run, the source 230

12 activos. Cuanto mayor sea la demora inicial, el protocolo deber~ compensar mayores periodos de baja actividad por jitter, ya que agrega tiempo al plazo limite de cada cuadro. La aplicaci6n receptora almacendni una cantidad de cuadros proportional a la relaci6n entre la demora inicial y el periodo de cuadro (1o opuesto a demora de cuadro) antes de iniciar la reproducci6n. to ~ to ~me--~... i i L i It Figura 2: Compor~amiento de inicio de MMTP con dos eanales La demora inicial siempre es mayor o igual a la demora m~ts larga de propagaci6n para los canales que est~n siendo utilizados, independientemente de cual de los canales se utilice para enviar el primer paquete. Los ejemplos de la figura 1 describen el comportamiento de inicio teniendo en consideraci6n dos canales y un paquete por cuadro. La figura l a muestra la demora inicial en casos en que el primer paquete es enviado por el canal con la mayor demora de propagaci6n, y la figura lb muestra la demora inicial en casos en que el primer paquete es enviado por el otro canal. En ambos ejemplos, el emisor recibe el cuadro 0 en el momento t y el cuadro 1 en el momento t + 1/fi'ameRate. En la figura la el primer cuadro fue enviado por el canal con la mayor demora de propagaci6n, de modo que la reproducci6n comienza tan pronto como se recibe el cuadro 0, debido a que sabemos que el cuadro 1 habr~ llegado a destino al completarse el periodo de reproducci6n del cuadro 0. Si las demoras de propagaci6n de ambos canales son muy diferentes, es posible que el cuadro 1 llegue antes que el cuadro 0. En este caso, almacenamos el cuadro 1 y comenzamos de todas maneras la reproducci6n al recibir el cuadro 0. En la figura lb, el cuadro 0 llega primero, pero la reproducci6n debe demorarse hasta que nos encontremos a un periodo de reproducci6n de la recepci6n del cuadro 1, porque de otro modo se produciria una interrupci6n al finalizar la reproducci6n del cuadro 0. Debido a que MMTP utiliza estimaci6n tanto para el ancho de banda como para la demora de propagaci6n, es dificil implementar la opci6n 2, ya que la demora inicial depende directamente del valor estimado para la demora de propagaci6n en ambos canales. El enviar el primer paquete por el canal con la mayor demora de propagaci6n permite que la reproducci6n se autocronometre. 4.4 Control de flujo El control de flujo de MMTP se puede modelar como un conjunto de protocolos de control, uno para cada canal, y todos al servicio de una cola individual. Se generan sefiales para cada canal segfn estimaciones de ancho de banda disponible y se las marca con estimaciones de demora de propagaci6n. Los paquetes se insertan en la cola a la velocidad de cuadro del origen, y deben ser transmitidos a trav6s de uno de los canales disponibles. Este tipo de problema de administraci6n de recurso modela la organizaci6n de procesos en sistemas operativos con multiprocesador en tiempo real [15], en los cuales el tiempo de procesamiento se asigna al tiempo de transmisi6n para cada canal. Los paquetes se transmiten por un canal siempre y cuando haya una serial y si la demora de propagaci6n asegura que el cuadro llegar~ a tiempo. Las seriales se utilizan para cada transmisi6n en un canal, y no se generan nuevas seriales hasta que las anteriores no han sido utilizadas. En el momento en que un cuadro llega a destino, se presentan tres posibilidades: 1. No hay seriales disponibles: el cuadro debe esperar hasta que se genere una serial en un canal que 1o pueda entregar a tiempo. Si no se generan sefiales antes que expire el plazo limite del cuadro, el cuadro se descarta. 2. Hay exactamente una sola serial disponible: si el canal correspondiente puede entregar el cuadro a tiempo, el mismo es enviado. De otro modo, este caso se reduce al caso Hay m61tiples sefiales disponibles: si m~s de un canal puede entregar el cuadro, se selecciona el canal con la demora de propagaci6n m~s larga. El mantener ocupado el canal con mayor demora de propagaci6n facilita la creaci6n de una via de respuesta r~pida. Si ningfin canal puede satisfacer el plazo limite del cuadro, 6ste espera del mismo modo queen el caso 1. Incluso cuando ninguno de los canales disponible puede enviar un cuadro en ese preciso momento, los cuadros en cola podr~in ser transmitidos siempre y cuando se agregue un nuevo canal con menor demora de propagaci6n o si una gran disminuci6n en la demora de propagaci6n esperada de uno de los canales actuales posibilita la transmisi6n con 6xito del paquete. 231

13 program generated 1000 frames of 1400 bytes each. A frame was generated every x microseconds, as shown on the table. Frames were deemed late if they arrived more than one second after they were generated. As an example, if our cutoff value was 6 seconds, all frames on the run with period equals microseconds would have arrived on time, as this is the largest value for the delay, and no frames were lost. Of course, this is a limited run, and for unbounded media if there is not enough bandwidth the delay would keep on growing, making frames late. Frames are normally lost in bursts - the program recorded both the numbers of bursts (blocks of lost frames) and the total number of frames that were lost. (delayed more than one second) blocks /64 I / / / /0 I arrived within one second I I000 that arrived Periodicit y (in msec) Table 2. UDP Flooding on Rangelan Late frames (delayed more than one second) Lost frames/ blocks Frames that arrived within one second Total frames that arrived / / / / / / / / / It is interesting to note that the number of "good" frames seesaws as the periodicity varies (as seen on chart 1). For a multimedia flow, late frames are useless, so the important number is given on the fourth column - even though more frames may have arrived, if they are late they are wasted. A frame that arrived late also used bandwidth and time - making other frames that follow it late. Ideally, dropping frames should happen at the source. Another way of using more frames is changing the allowed delay, by buffering frames so the deadline of each frame is postponed. In some runs, the UDP frames flooded the wireless link, and these frames were dropped, allowing more frames to arrive in time. 5.3 Infrared Because infrared offers a reliable link, all dropped frames are the result of UDP flooding. The maximum delay on infrared is smaller than on Rangelan, due probably to a smaller buffer on the base-station. If the cutoff were 3.5 seconds, all frames that arrived would be on time. The arrival of the frames was a monotonous increasing function, the first frames arriving on time until the 1-second cutoff was exceeded, and all subsequent frames were late. Table 3. UDP Flooding on Infrared Iperiodicityl Late Lost FrameslTotal ] in (in reset) frames frames/ that frames As soon as there is enough bandwidth to carry the traffic, both losses and late flames drop to zero. The intervals are shown are not the same as Rangelan due to the differences in bandwidth and delay. 5.4 MMTP The test setup for MMTP has a source process that creates frames at the given periodicity and sends them to the proxy. The proxy sends these frames to the receiver on the mobile. The client process does not record the same information on lost flames, so the third columns of the tables are not comparable. Most of the frames shown on the third column were discarded at the source and not lost in the network. Changing the cutoff time would change the number of sent frames, as the protocol would assume that more frames could meet their deadline. Periodicity in (in msec) Table 2. MMTP on Infrared and Rangelan Late frames (delayed more than one second) Lost/ discarded frames/ blocks* Frames that arrived within one second / i / i / / / /5 986 Total frames that arrived The current version of MMTP is still in the development stage, so the performance is below the theoretical maximum. It is too conservative on the low range, dropping too many packets, and seems to perform worse than the naive protocol at certain periodicities. However, when comparing the performance of MMTP and simple UDP flooding, it must be pointed out that flooding is actually wasting resources both on the landline and on the wireless link. The high-speed links of the University infrastructure mask this effect, and allow flooding to course through the network until packets are dropped on the wireless base-stations. This would not happen on the Internet at large. MMTP drops the packets at the source, so only packets that are expected to arrive on time are actually sent. Chart 2 below shows the number of wasted frames. Those frames were received after their deadline had expired. 232

14 4.5 Control de congesti6n En MMTP, el control de congesti6n se implementa como t6cnica reactiva bas/mdose en la estimaci6n del ancho de banda. Tanto la demora de propagaci6n como el ancho de banda disponible en un canal variaran en base a cambios de enrutamiento y a interferencias causadas por otros trfificos. El ancho de banda disponible es igual a la diferencia entre el ancho de banda mfiximo de cada enlace y el uso de cada enlace. La demora de propagaci6n est~i compuesta por dos partes: la demora real de propagaci6n de los bits en las lineas de transmisi6n y la suma del tiempo utilizado durante el procesamiento en cada router de la via. La primera parte se fija en la ausencia de cambios de ruta, pero la segunda aumentarfi de acuerdo con el tamafio de las colas en los routers involucrados. Para evitar la congesti6n, el protocolo intenta mantener el ancho de banda requerido por debajo del ancho de banda disponible del canal. Esto se logra midiendo el ancho de banda disponible y modificando la velocidad a la cual se envian los paquetes para que tenga un valor compatible. El ancho de banda disponible se deduce midiendo los tiempos internos de llegada de paquetes al receptor, y reenviando estas rnediciones al emisor. Debido a que los paquetes se envian a intervalos regulares en cada canal, el tiempo interno de llegada deberia converger en el periodo en el cual se estfin enviando cuadros por dicho canal, siempre y euando haya suficiente ancho de banda. Si el tiempo interno de llegada comienza a aumentar, esto quiere decir que en algfn lugar de la via uno de los routers est~ funcionando por encima de sus capacidades y poniendo paquetes en cola Estimaci6n de parfimetros Para estimar los par,~etros bfisicos, ancho de banda disponible y demora de propagaci6n, se monitorea en cada uno de los canales el tiempo interno de llegada de paquetes al receptor. El tiempo interno de llegada se compara con el pedodo durante el cual se envian cuadros por cada canal (presente en cada encabezado de paquete). Con demoras de cola estables, los tiempos internos de llegada debertan converger en este periodo. A medida que las demoras de cola se modifican, se introducen jitters y los tiempos internos de llegada varian. El total ininterrumpido del jitter deberia ser igual a cero si no se producen cambios en las caracteristicas del canal, 1o cual estabiliza el tiempo interno de llegada. Un paquete que llega tarde a destino provoca que el pr6ximo paquete parezca haber llegado antes, de modo que el total de los jitters deberia cancelarse. El jitter acumulado es un porcentaje en movimiento de los filtimos paquetes n, en donde n es un parfimetro de implementaci6n. El tamafio de n deberia tener la misma granularidad temporal que los mensajes que mantienen viva la conexi6n, de manera de poder reenviar datos significativos al emisor. Hay dos casos especiales en los cuales la cantidad ininterrumpida del jitter no es igual a cero: Cuando se produce una congesti6n incipiente, los tamafios de las colas en los routers aumentan, y el receptor percibe esto como un aumento positivo del jitter acumulado. En este caso, el receptor reenvia un mensaje solicitando una disminuci6n en la velocidad de emisi6n, de modo que la transmisi6n no provoque congestiones. Este es realmente un mecanismo mejor que la reducci6n del uso de ancho de banda en caso de paquetes descartados. La utilizaci6n de paquetes descartados como medida de congesti6n es una t6cnica reactiva que se utiliza una vez producida la congesti6n. Mediante la utilizaci6n del jitter acumulado para sefializar una congesti6n inminente, el protocolo puede intentar evitar que los paquetes scan descartados. Por otra parte, los paquetes descartados no constituyen un buen medidor de congesti6n para anfitriones m6viles, ya que los enlaces inal~tmbricos poseen tasas de p6rdida mayores que las lineas fijas normales. Cuando la demora de propagaci6n disminuye, se produce una disminuci6n en el tiempo interno de llegada de un intervalo de tiempo. A continuaci6n, la velocidad percibida convergir~ nuevamente con la velocidad de emisi6n. Para definir siesta disminuci6n no se trata de una ilusi6n provocada por un paquete previo que lleg6 muy tarde, se analiza la historia del jitter. Si el patr6n muestra un gran valor positivo seguido de un gran valor negativo (que cancelaria al anterior), se ignora este evento. Si la tendencia es estable y el primer paquete no es una ilusi6n, el pr6ximo mensaje para mantener viva la conexi6n indicara que podr/t haber ancho de banda extra disponible en dicho canal. La medici6n de tiempos internos de llegada funciona bien para prevenir congestiones, pero no sirve para medir ancho de banda excesivo u ocioso en un canal. El problema es que para cada velocidad de emisi6n, el ancho de banda mfiximo medido por la aplicaci6n 233

15 Q m =E ~~"',,., ".,.,f :: ", "d periodicity * mmlp... I... rangelan - udp,a maximum Figure 4. Comparison of UDP, MMTP and Theoretical Maximum for Packets versus Periodicity.F, O, ^. 73~ 010 ~ 06 l~ 100 0! B pedodicity 1Late flames MMTP # Late flames UDP Figure 5. Packets Received after their Deadline Other than losses caused by errors on media, when the periodicity hits microseconds the joint channel created by MMTP has enough bandwidth to carry all traffic. This is not true to any of the channels taken singly. That means that even in the current form MMTP allows a better quality stream with more reliability than any one of the channels used alone 6. CONCLUSIONS AND FUTURE WORK In this paper, we have shown that by exposing information about link-layer connectivity to the transport layer it is possible to use multiple channels concurrently, and adapt both intra-ehannel by varying the rate in which data is transmitted and extra-channel by adding and deleting channels from the pool of available channels. The resulting virtual channel has many characteristics that are more amenable to multimedia traffic than each of the channels taken alone. The virtual channel has more bandwidth, less overall variability and more resilience. Added bonus is the built-in mechanism for vertical handoffs. The simultaneous use of multiple interfaces brings many opportunities and challenges. MMTP was designed for multimedia traffic, and reflects the constraints of this type of data stream. We are currently exploring the design of other transport protocols that can use multiple link-layer channels suitable to various types of data. It is clear that a complementary communication framework is necessary to take advantage of the benefits of such a protocol. The communication framework can help the :mobile locate the available communication services and offer a uniform API for MMTP and other protocols. The path for future work lies in the integration of such a communication framework with MMTP and other protocols able to take advantage of knowledge of multiple link-layer channels. In our current research, we are exploring the possibilities opened by the excess of bandwidth on multiple channels, enabling retransmission of select packets without adversely affect the playout of the data stream. 7. ACKNOWLEDGMENTS This work was sponsored in part by NSF ITR grant ANI and by Conselho Nacional de Desenvolvimento Cientifico e Tecnologico, CNPq, Brazil, grant / REFERENCES [1] M. Stemm and R. H. Katz, Vertical Handoffs in Wireless Overlay Networks. ACMMobile Networking (MONET), Special lssue on Mobile Networking in the lnternet, [2] X. Zhao, C. Castelluccia, and M. Baker, Flexible Network Support for Mobility. presented at Fourth ACM International Conference on Mobile Computing and Networking (MOBICOM'98), [3] L. Zhang, S. Deefing, D. Estrin, S. Shenker, and D. Zappala, RSVP: A New Resource Reservation Protocol. IEEE Network Magazine, pp. 8-18, [4] D.D. Clark, M. Lambert, and L. Zhang, NETBLT: A High Throughput Transport Protocol.,, [5] P. Sinha, N. Venkitaraman, R. Sivakumar, and V. Bharghavan, WTCP: A Reliable Transport Protocol for Wireless Wide-Area Networks. presented at ACM Mobieom '99, [6] R. Rejaie, M. Handley, and D. Estrin, RAP: An End-to-end Rate-based Congestion Control Mechanism for Realtime Streams in the Internet. presented at IEEE Infocom 99,

16 es igual al ancho de banda establecido por el emisor. Por 1o tanto, con este m6todo podemos disminuir la velocidad de emisi6n pero no ast aumentarla. Hace falta otro mecanismo para medir al ancho de banda disponible por encima del que se es~ utilizando Sondeo El mecanismo utilizado por MMTP para medir incrementos en el ancho de banda disponible es el sondeo. Existen dos maneras sencillas de implementar el sondeo. La primera es el incremento aditivo: incrementar eontinuamente la velocidad de emisi6n en pequefias cantidades cuando no haya solicitudes de disminuci6n de velocidad, y mantener mediciones normales de tiempos internos de llegada. Si los tiempos internos de llegada comienzan a aumentar, eso significa que se superaron los limites o que estamos experimentando congesti6n, en cuyo caso el protocolo tiene que disminuir la velocidad. El problema de este enfoque es que las ganancias de aneho de banda virtual no se miden hasta que no son necesarios, ya que la velocidad de paquete est~i vineulada con la velocidad de euadros del flujo multimedia. Adem~is, es posible que el ancho de banda virtual medido por los aumentos de velocidad no est6 presente cuando se lo necesite. La segunda es la utilizaci6n de paquetes de sondeo. E1 paquete de sondeo se reenvia junto con un paquete normal. El tiempo interno de llegada del paquete y de la sonda deberia ser igual a cero, ya que fueron enviados en forma adosada. Sin embargo, por 1o general este valor no ser~i igual a cero sino que medir~ la demora de cola introducida por los routers. Los paquetes de sondeo deberian transportar carga 6til, ya que utilizan parte de un paquete normal. El problema es que puede que no haya datos disponibles para enviar dos paquetes adosados. En este easo, se puede enviar un paquete vacio. Este tipo de sondeo puede resultar dafiino si el sistema ester funcionando al limite: el ancho de banda sacrificado para el paquete de sondeo puede ocasionar que se descarte un paquete 6til. 4.5 Agregado y eliminaci6n de canales Cuando se inicia el protocolo, el marco de comunicaci6n envia la lista initial de eanales disponibles. A medida que pasa el tiempo, puede que nuevos canales queden disponibles, y que se pierdan canales en uso. El marco de comunicaci6n notifica dichos eventos a MMTP y proporciona informaci6n auxiliar como estimaciones del ancho de banda disponible. disponible en caso que dicho dato no est~ presente. Para realizar este sondeo initial, el protocolo utilizaba el m6todo de par de paquetes [16], el mismo mecanismo que el protocolo normal de sondeo: se envian dos mensajes adosados yen el receptor se mide su tiempo interno de llegada. Esto se utiliza a modo de estimaci6n del ancho de banda mfiximo de dicho enlace, y se informa de esto al emisor. Cuando se pierde un canal, se envia un mensaje de renuncia al par a trav6s del canal con menor demora. Los paquetes excepcionales son puestos en cola para retransmisi6n, con las mismas restricciones de otros paquetes (si no pueden cumplir con el plazo limite, no serfin enviados). Cada canal activo envia peri6dicamente mensajes para mantener viva la conexi6n. Ademfis de notificar al par que el canal afn se encuentra abierto, estos mensajes contienen actualizaciones de las mediciones realizadas en el receptor, el tiempo interno de llegada de los mensajes, el ancho de banda disponible estimado, la cantidad de paquetes demorados y perdidos. Si uno de estos mensajes no es recibido, el emisor envia un mensaje de consulta para averiguar si el canal afin est~i abierto o si se perdi6 un mensaje de control. Cuando la demora de un canal es mayor a su periodo de baja actividad, el mismo puede estar presente en el procesamiento pero no transportar ningfn dato. Esto puede suceder si la transmisi6n comenz6 antes de que el canal fuera agregado al procesamiento. Si la demora de la nueva llnea es mayor a DO (la demora initial), el canal nunca podrfi ser utilizado para transportar datos en dicha transmisi6n. Puede transportar mensajes de control, pero s61o ser~t utilizado cuando no haya otros canales disponibles. En caso que la demora disminuya hasta un nivel utilizable, en este canal se podr6n realizar sondeos y enviar mensajes normales para mantener viva la conexi6n. Tambi~n se puede descartar progresivamente un canal si la demora o el aneho de banda disminuyen a niveles extremadamente bajos. Esto puede suceder a medida que el usuario abandona un firea de cobertura y las condiciones de la capa de enlace se deterioran, o por congesti6n. Mientras no se reciban mensajes de renuncia, se continuar~i con los sondeos y mensajes para mantener viva la conexi6n. Si solamente un canal estfi disponible y no se est~n recibiendo mensajes para mantener viva la conexi6n, el protocolo sefialar~ que el enlace puede estar interrumpido. Cuando se agrega un nuevo canal al procesamiento del protocolo, se debe medir el ancho de banda 235

17 [7] F.M. Chiussi, D. A. Khotimsky, and S. Krishnan, Generalized inverse multiplexing of switched ATM connections, presented at Proceedings of the IEEE Conference on Global Communications (GlobeCom '98), [8] A.C. Snoeren, Inverse Multiplexing for Wide- Area Wireless Networks. presented at Proceedings of the IEEE Conference on Global Communications (GlobeCom '99), Global Internet Symposium, [9] K. Sklower, B. Lloyd, G. McGregor, D. Carr, and T. Coradetti, The PPP Multilink Protocol, RFC1990., [10] J. Bolot and T. Turletti, Experience with Rate Control Mechanisms for Packet Video in the Intemet. A CM Computer Communications Review, vol. 28, pp. 4-15, [11] K.-W. Lee, R. Puri, T. Kim, K. Ramchandran, and V. Bharghavan, An Integrated Source Coding and Congestion Control Framework for Video Streaming in the Internet. presented at IEEE Infocom 2000, [12] S. Servetto and K. Nahrstedt, Broadcast Quality Video over IP. IEEE Journal on Selected Areas in Communications, Special issue on QoS in the Internet, [13] [14] [151 [16] [17] [18] [19] H. Schulzrinne, S. Casner, R. Frederick, and V. Jacobson, RTP: A Transport PrOtocol for Real- Time Applications. Internet Engineering Task Force Internet Draft, July S. Floyd and V. Jacobson, Random Early Detection Gateways for Congestion Avoidance. 1EEE/A CM Transactions on Networking, K. Jeffay, Towards a Better-Than-Best-Effort Forwarding Service for Multimedia Flows. IEEE Multimedia, vol. 1999, A. Snoren and H. Balakrishnan, An End-to-End Approach to Host Mobility. presented at ACM Mobieom '99, D. D. Clark and D. L. Tennenh0use, Architectural Considerations for a New Generation of Protocols. in Proceedings of the SIGCOMM '90 Symposium, 1990, pp E. D. Jensen, C. D. Locke, and H. Tokuda, A Time-Driven Scheduling Model for Real-Time Operating Systems. in IEEE Real-Time Systems Symposium, S. Keshav, A Control-Theoretic Approach to Flow Control. presented at Proceedings of the SIGCOMM '92 Symposium,

18 5. Resultados experimentales Nuestros experimentos tienen eomo objeto mostrar dos aspeetos importantes de MMTP. El primero es el agregado de aneho de banda: demostramos que podemos enviar flujos de mejor calidad al utilizar m~is de un solo canal. Esto se logr6 mediante la mediei6n de la eantidad de paquetes reeibidos a tiempo. El segundo aspeeto de MMTP es el ahorro de aneho de banda. MMTP s61o enviar~t aquellos paquetes que estime llegar~tn a destino dentro del plazo limite del paquete. De este modo no se desperdieian reeursos. Esto se demuestra graeias al caudal fitil, o poreentaje de paquetes llegados a tiempo dentro del total de paquetes enviados. Esto se demostr6 indireetamente al medir la cantidad de paquetes que llegaron demorados. 5.1 Banco de pruebas de experimentos Nuestra eonfiguraei6n de pruebas eonsisti6 en dos eomputadoras port,stiles Sony, una PCG-505TR y una PCG-F450, arnbas operando RedlIat 6.2 linux con kernels , con conexi6n infrarroja y con paquete PCMCIA versi6n La primera se eoneeta a la red utilizando un adaptador PCMCIA 3Com 574 a 10Mbps. La segunda posee dos eonexiones, una eonexi6n IRLan a un NetBeamlR HP que utiliza un dongle Aetisys en el puerto serial, y un adaptador PCMCIA Rangelan2, eomo se muestra en la figura 3. La primera eomputadora port~ttil ejeeuta el software proxy y la m6vil opera eomo eliente. Figura 3: Configuraci6n de prueba El infrarrojo y Rangelan poseen earacteristieas muy diferentes. El infrarrojo ofrece una eapa de enlaee punto a punto eonfiable, con veloeidades de enlaee de hasta 4Mb/s. La utilizaei6n de un dongle serial limit6 la veloeidad a l l5kbps, y el protocolo superior limit6 atln rods el rendimiento a 9Kbps. Rangelan es una vieja tecnologia de radio, el enlaee de radio est/t sujeto a errores de r~ifagas, y el rendimiento varia con el uso medio. El mejor rendimiento registrado fue del orden de los 36KBps. Las principales caracteristicas se presentan en la tabla 1. Demora para paquetes de 1400 bytes (mseg.) Minima Promedio (mseg.) Rendimient o (KB/seg) Infrarrojo 315 Rangelan 176 Tabla 1: Caraeteristieas de las redes inahtmbrieas Asumimos que hay un origen que genera euadros de 1400 bytes con una eierta periodieidad. Probamos nuestro protocolo en conjunto con un programa sencillo que envia euadros utilizando UDP a medida que son generados. A eontinuaei6n se presentan los resultados eorrespondientes al programa de prueba. 5.2 Rangelan: Estos son resultados tipicos ya que hay pequefias fluetuaeiones oeasionadas por tr~ifieo y errores en diferentes ejeeueiones. Para eada ejeeuei6n, el programa de origen gener euadros de 1400 bytes eada uno. Se gener6 un euadro eada x mierosegundos, eomo se muestra en la tabla. Se consideraron demorados aquellos cuadros que llegaron mrs de un segundo despu6s de haber sido generados. Como ejemplo, si nuestro valor de eorte fue de 6 segundos, todos los euadros en la ejeeuei6n con un periodo igual a mierosegundos habnin llegado a tiempo, ya que este es el valor mils grande de la demora, y no habrfa perdida de cuadros. Por supuesto, esta en una ejecuei6n limitada, yen el easo de medios sin limites de no haber aneho de banda sufieiente la demora seguirh ereeiendo, haeiendo que los euadros se retrasen. Los euadros se pierden normalmente en rfifagas y el programa registr6 tanto la eantidad de r~ifagas (bloques de euadros perdidos) eomo el nfimero total de euadros perdidos. Periodicidad en microsegundos: 10000, 15000, 20000, 25000, 30000, 35000, 40000, 50000, Cuadros demorados (retrasados m~is de un segundo): 10, 582, 6, 753, 0, 818, 18, 1, 0 Cuadros/bloques perdidos: 684/35, 352/37, 350/38, 68/10, 101/15, 0/0, 20/3, 21/3, 17/1 Cuadros que Uegaron en el plazo de un segundo: 306, 66, 644, 179, 899, 184, 962, 978, 983 Cantidad de cuadros que llegaron: 316, 648, 650, 932, 899, 1000, 980, 979, 983 Tabla 2: Saturaei6n UDP en Rangelan Es interesante notar que la cantidad de cuadros "buenos" oscila a medida que varia la periodicidad (como puede verse en la tabla 1). Para el flujo multimedia, los cuadros retrasados resultan in6tiles, de modo que el n6rnero importante es el que figura en la cuarta columna - aunque hallan llegado m,~s l 237

19 SIGCOMM A m ~ r i ca Lati n a 238

20 cuadros, si est~n demorados no sirven. Un cuadro demorado tambi6n utiliz6 ancho de banda y tiempo - y de este modo demor6 a otros cuadros posteriores. Lo mejor seria que el descarte de cuadros se produzca en el origen. Otro m6todo para utilizar m~s cuadros es modificar la demora permitida, almacenando cuadros en el buffer de manera que el plazo limite de cada cuadro se posponga. En algunas ejecuciones, los cuadros UDP saturaron el enlace inal~imbrico, por 1o cual fueron descartados, permitiendo que mls cuadros llegaran a tiempo. 5.3 Infrarrojo Debido a que el infrarrojo ofrece un enlace confiable, todos los cuadros descartados son el resultado de saturaci6n UDP. La demora m~ixima en el infrarrojo es menor que la de Rangelan, probablemente a eausa de un buffer mrs pequefio en la estaci6n base. Si el corte fuera de 3,5 segundos, todos los cuadros que llegaron Io hubiesen hecho a tiempo. La llegada de cuadros fue una funci6n mon6tona y en aumento, los primeros cuadros llegaron a tiempo hasta que se excedi6 el torte de un segundo, y todos los cuadros subsiguientes llegaron demorados. Periodicidad en microsegundos: 10000, 50000, , , Cuadros demorados (retrasados m~is de un segundo): 84, 346, 671,309, 0 Cuadros/bloques perdidos: 909/64, 646/322, 312/309, 0/0, 0/0 Cuadros que llegaron en el plazo de un segundo: 7, 8, 17, 691, 1000 Cantidad de cuadros que llegaron: 91, 354, 688, 1000, 1000 Tabla 3: Saturaci6n UDP en infrarrojo En cuanto hay ancho de banda suficiente para transportar el tr,~fico, tanto las perdidas como los cuadros demorados se reducen a cero. Los intervalos que se muestran no son iguales a los de Ragelan debido alas diferencias en el ancho de banda y la demora. 5.4 MMTP La configuraci6n de prueba para MMTP posee un proeeso de origen que crea cuadros a una periodicidad dada y los envia al proxy. E1 proxy envia estos cuadros al receptor en el m6vil. El proceso del cliente no registra la misma informaci6n acerca de cuadros perdidos, de modo que no es posible comparar las terceras columnas de las tablas. La mayoria de los cuadros que se muestran en la tercera columna rue descartada en origen en lugar de perderse en la red. Si se modifica el tiempo de corte se modificani la cantidad de cuadros enviados, ya que el protocolo asumir~ que otros cuadros pueden cumplir con su plazo limite. Periodicidad en microsegundos: 10000, 15000, 20000, 25000, 30000, Cuadros demorados (retrasados m~ de un segundo): 0, 25, 0, 73, 10, 0 Cuadros/bloques perdidos: 761/21, 562/17, 548/27, 269/3, 86/10, 14/5 Cuadros que llegaron en el plazo de un segundo: 178, 413, 452, 648, 904, 986 Cantidad de euadros que llegaron: 178, 438, 452, 731,914, 986 Tabla 4: MMTP en infrarrojo yen Rangelan La versi6n actual de MMTP todavja se encuentra en la fase de desarrollo, de modo que el rendimiento se encuentra por debajo del m,~ximo en teoria. Resulta demasiado conservador en el rango bajo, descarta demasiados paquetes yen apariencia tiene un rendimiento peor que el del protocolo simple en ciertas periodicidades. Sin embargo, cuando se compara el rendimiento de MMTP y de la saturaci6n simple UDP, se debe seflalar que la saturaci6n desperdicia en realidad recursos tanto en la linea fija como en el enlace inal~imbrico. Los enlaces de alta velocidad de la Universidad disfrazan este efecto, y permiten que la saturaci6n circule por la red hasta que los paquetes son descartados por las estaeiones base inal~mbricas. Esto no ocurre en la totalidad de Interact. MMTP descarta los paquetes en el origen, de modo que s61o se envien aquellos paquetes que se supone llegar,~n a tiempo. El cuadro 2 a continuaci6n muestra la cantidad de cuadros perdidos. Dichos cuadros fueron recibidos luego de que se venciera su plazo limite. Packets versus Periodicity ol."o"., pedodiolty Cuadro 1: Comparaei6n de UDP, MMTP y m~ximo en teoria t ~ t : mmtp - - mnllelen - udp A milodmum 239