Figura 1. Relación entre la probabilidad de llegada de los datagramas y los parámetros de QoS

Figura 2. Problema de escalabilidad de RSVP

El diseño original de Internet contemplaba un servicio best effort, es decir sin ninguna garantía de calidad de servicio. Con la proliferación, a partir de 1994 aproximadamente, de aplicaciones de videoconferencia y multimedia en tiempo real en Internet, muy sensibles a situaciones de congestión, creció el interés de adaptar los protocolos de Internet para ofrecer algún tipo de Calidad de Servicio.

En realidad ya había algo de Calidad de Servicio desde el principio en IPv4, pues en la cabecera del datagrama se encontraba como luego comentaremos el campo denominado TOS (Type Of Service) de ocho bits de los cuales los tres primeros representaban una prioridad (allí denominada precedencia) que permitía marcar los datagramas según su importancia, marcado que permitía establecer en principio políticas o prioridades en la transmisión de los datagramas por la red.

Aunque la prioridad representa una cierta calidad de servicio, por cuanto que permite clasificar los datagramas en categorías, no es capaz en general de ofrecer una garantía estricta, al estilo de la ofrecida por ATM, donde es posible reservar un caudal determinado para un circuito, aplicación o flujo determinado, asignándole un circuito virtual CBR, por ejemplo. Aunque un flujo concreto marque sus datagramas con máxima prioridad no es posible, en general, garantizarle un caudal mínimo o un retardo máximo ya que podría sufrir congestión debido a un caudal excesivo de datagramas de esa prioridad producido por el tráfico agregado de otros flujos.

Al parecer la única forma de ofrecer una calidad de servicio garantizada es realizando una reserva previa de capacidad en todo el trayecto, al estilo de los circuitos ATM; para ello es preciso que cada router intermedio tenga conocimiento de la existencia de dicho flujo. Esto supone pasar del modelo no orientado a conexión, utilizado en Internet, al orientado a conexión. Hacia 1995 había una tendencia en Internet a desarrollar ese modelo y fruto de esta filosofía es la denominada Arquitectura de Servicios Integrados o IntServ (de Integrated Services). El elemento más conocido y representativo de la arquitectura IntServ es el protocolo RSVP que describiremos a continuación. Curiosamente a pesar del interés que el modelo IntServ suscitó entre la comunidad Internet su uso no se ha difundido, ni entre los fabricantes que han sido reacios a implementarlo en los equipos, ni entre los ISPs, que tampoco lo han desarrollado en sus redes. Según los expertos el fracaso del modelo IntServ se debe a su no escalabilidad, es decir a que el costo de su implementación crece cuando menos linealmente con la complejidad de la red. El problema está en que, al ser RSVP un protocolo orientado a conexión los routers han de mantener una información de estado de todos los flujos activos que pasan por ellos. Esta información de estado puede ser aceptable en los routers de la periferia, pero resulta inmanejable en los routers del core de la red que han de soportar miles de conexiones activas (véase la Figura 2).

Dado que la arquitectura IntServ seguía sin resolver el problema de la calidad de servicio en Internet hacia 1997 apareció un modelo alternativo denominado Arquitectura de Servicios Diferenciados o DiffServ (de Differentiated Services). La idea básica de DiffServ consiste en que cada paquete lleva escrito un código que indica a que clase pertenece; se supone que los routers saben el tratamiento que han de dar a cada una de las clases posibles, por lo que no han de mantener ninguna información sobre conexiones o flujos concretos; el número de clases posibles es limitado e independiente del número de hosts o de flujos que pasan por los routers, por lo que la arquitectura DiffServ es escalable. En realidad el modelo DiffServ reinventó hasta cierto punto el olvidado y denostado campo TOS de IPv4, que incluía entre otras cosas el subcampo precedencia que ya hemos comentado.