Servicio de sistema de transporte (página 2)

La multiplexión también puede ser útil en la capa de transporte por otra razón. Por ejemplo, suponiendo que una subred utiliza circuitos virtuales de manera interna y que impone una tasa máxima de datos a cada uno. Si un usuario necesita más ancho de banda del que le puede proporcionar un circuito virtual, una alternativa es abrir múltiples conexiones de red y distribuir el tráfico entre ellas en round robin (de manera circular). Esto se denomina multiplexión hacia abajo. Un ejemplo común de multiplexión hacia abajo se da en los usuarios caseros que poseen una línea ISDN. Esta línea proporciona dos conexiones separadas de 64 kbps cada una. Al usar ambas para llamar a un proveedor de Internet y dividir el tráfico en las dos líneas se consigue un ancho de banda efectivo de 128 kbps.

Recuperación de caídas

Si los hosts y los ruteadores están sujetos a caídas, la recuperación de éstas se vuelve un tema importante. Si la entidad de transporte está por entero dentro de los hosts, la recuperación de caídas de la red y de ruteadores es sencilla. Si la capa de red proporciona servicio de datagramas, las entidades de transporte esperan la pérdida de algunas TPDU"s todo el tiempo, y saben cómo manejarla. Si la capa de red proporciona servicio orientado a la conexión, entonces la pérdida de un circuito virtual se maneja estableciendo uno nuevo y sondeando la entidad de transporte remota para saber cuáles TPDU"s ha recibido y cuáles no. Estas últimas pueden retransmitiese.

Un problema más complicado es la manera de recuperarse de caídas del host. En particular, podría ser deseable que los clientes sean capaces de continuar trabajando cuando los servidores caen y se reinician rápidamente.

Sin importar cómo se programen el emisor y el receptor, siempre habrá situaciones en las que el protocolo no podrá recuperarse correctamente. El servidor puede programarse de una de dos maneras: mandar confirmación de recepción primero o escribir primero. El cliente puede programarse de cuatro maneras: siempre retransmitir la última TPDU, nunca retransmitir la última TPDU, retransmitir sólo en el estado S0(ninguna TPDU pendiente) o retransmitir sólo en el estado S1(una TPDU pendiente). Esto da ocho combinaciones pero, para cada combinación existe algún grupo de eventos que hacen fallar al protocolo.

Son posibles tres eventos en el servidor: el envío de una confirmación de recepción (A), la escritura al proceso de salida (W) y una caída (C). Los tres eventos pueden ocurrir en seis órdenes diferentes: AC(W). AWC, C(AW), C(WA), WAC y WC(A), donde los paréntesis se usan para indicar que ni A ni W pueden seguir a C (es decir, una vez que el servidor se cae, se cayó). Para cada estrategia hay alguna secuencia de eventos que causa la falla del protocolo.

Hacer más elaborado el protocolo no sirve de nada. Aunque el cliente y el servidor intercambien varias TPDU"s antes de que el servidor intente escribir, para que el cliente sepa exactamente lo que está a punto de ocurrir, el cliente no tiene manera de saber si ha ocurrido una caída justo antes o justo después de la escritura. La conclusión es inevitable: según nuestra regla básica de que no debe haber eventos simultáneos, la caída de un host y su recuperación no pueden hacerse transparentes a las capas superiores.

En términos más generales, la capa de transporte puede recuperarse de fallas de la capa de red, siempre y cuando cada extremo de una conexión lleve el registro de dónde está.

Un protocolo de transporte sencillo

Para hacer más concretas las ideas estudiadas hasta ahora, en esta sección estudiaremos detalladamente una capa de transporte de ejemplo. Las primitivas de servicio abstractas que usaremos son las primitivas orientadas a la conexión. La elección de estas primitivas hace que el ejemplo sea similar al popular protocolo TCP.

LAS PRIMITIVAS DE SERVICIO DE EJEMPLO

Nuestro primer problema es cómo expresar de manera concreta estas primitivas de transporte. CONNECT es fácil: sencillamente tenemos un procedimiento de biblioteca connect que puede llamarse con los parámetros adecuados necesarios para establecer una conexión. Los parámetros son los TSAP"s locales y remotos. Durante la llamada, el invocador se bloquea mientras la entidad de transporte intenta establecer la conexión. Si ésta tiene éxito, se desbloqueo el invocador y puede comenzar la transmisión de datos.

Cuando un proceso requiere la capacidad de aceptar llamadas entrantes, llama a listen, especificando un TSAP en particular en el que quiere escuchar. El proceso entonces se bloquea hasta que algún proceso remoto intenta establecer una conexión con su TSAP.

Observe que este modelo es altamente asimétrico. Un lado es pasivo, pues ejecuta un listen y espera hasta que ocurre algo. El otro lado es activo e inicia la conexión. Una pregunta interesante es qué debe hacerse si el lado activo comienza primero. Una estrategia es hacer que falle el intento de conexión si no hay un escuchador en el TSAP remoto. Otra estrategia es hacer que el iniciador se bloquee (posiblemente para siempre) hasta que aparezca un escuchador.

Una alternativa, es mantener la solicitud de conexión del lado receptor durante cierto intervalo de tiempo. Si un proceso de ese host llama a listen antes de que expire el temporizador, se establece la conexión; de otro modo se rechaza y se desbloqueo al invocador devolviéndole un error.

Para liberar una conexión, se utiliza un procedimiento disconnect. Cuando ambos lados se han desconectado, se libera la conexión. En otras palabras, estamos usando un modelo de desconexión simétrico.

La transmisión de datos tiene precisamente el mismo problema que el establecimiento de una conexión: el envío es activo, pero la recepción es pasiva. Usaremos la misma solución para la transmisión de datos que para el establecimiento de la conexión: una llamada activa send que transmite datos, y una llamada pasiva receive que bloquea hasta que llega una TPDU.

Nuestra definición concreta del servicio consiste, por tanto, en cinco primitivas: CONNECT, LISTEN, DISCONNECT, SEND Y RECEIVE. Cada primitiva corresponde exactamente a un procedimiento de biblioteca que ejecuta la primitiva.

La primitiva LISTEN anuncia la disposición del invocador a aceptar solicitudes de conexión dirigidas al TSAP indicado. El usuario de la primitiva se bloquea hasta que se hace un intento de conexión a él. No hay expiración del temporizador.

La primitiva CONNECT toma dos parámetros, un TSAP local (es decir, dirección de transporte), local, y un TSAP remoto, remote, e intenta establecer una conexión de transporte entre los dos.

La primitiva SEND transmite el contenido del búfer como mensaje por la conexión de transporte indicada, posiblemente en varias unidades si es demasiado grande. Los errores posibles, devueltos son falta de conexión, dirección de búfer ilegal y cuenta negativa.

La primitiva RECEIVE indica el deseo del invocador de aceptar datos. El tamaño del mensaje de entrada se pone en bytes. Si el proceso remoto ha liberado la conexión o la dirección de búfer es ilegal (por ejemplo, fuera del programa del usuario), se establece a un código de error que indica la naturaleza del problema. La primitiva DISCONNECT termina una conexión de transporte.

Los protocolos de transporte de internet: UDP

Internet tiene dos protocolos principales en la capa de transporte, uno orientado y otro no orientado a la conexión. El protocolo no orientado a la conexión es UDP. El protocolo orientado a la conexión es TCP.

INTRODUCCIÓN A UDP

El conjunto de protocolos de Internet soporta un protocolo de transporte no orientado a la conexión, UDP (Protocolo de Datagramas de Usuario). Este protocolo proporciona una forma para que las aplicaciones envíen datagramas IP encapsulados sin tener que establecer una conexión.

UDP transmite segmentos que consisten en un encabezado de 8 bytes seguido por la carga útil. Los dos puertos sirven para identificar los puntos terminales dentro de las máquinas de origen y destino. Cuando llega un paquete UDP, su carga útil se entrega al proceso que está enlazado al puerto de destino. Este enlace ocurre cuando se utiliza la primitiva BIND o algo similar, para TCP (el proceso de enlace es el mismo para UDP). El puerto de origen se necesita principalmente cuando debe enviarse una respuesta al origen.

Al copiar el campo Puerto de origen del segmento que llega en el campo Puerto de destino del segmento que sale, el proceso que envía la respuesta puede especificar cuál proceso de la máquina emisora va a obtenerlo.

El campo Longitud UDP incluye el encabezado de 8 bytes y los datos. El campo Suma de verificación UDP es opcional. Su desactivación no tiene sentido a menos que la calidad del servicio de los datos no importe.

UDP No realiza control de flujo, control de errores o retransmisión cuando se recibe un segmento erróneo. Todo lo anterior le corresponde a los procesos de usuario. Lo que sí realiza es proporcionar una interfaz al protocolo IP con la característica agregada de desmultiplexar varios procesos utilizando los puertos. Para aplicaciones que necesitan tener control preciso sobre el flujo de paquetes, control de errores o temporización, UDP es lo ideal.

Un área en la que UDP es especialmente útil es en las situaciones cliente-servidor. Con frecuencia, el cliente envía una solicitud corta al servidor y espera una respuesta corta. Si se pierde la solicitud o la respuesta, el cliente simplemente puede terminar y probar nuevamente. El código no sólo es simple, sino que se necesitan muy pocos mensajes (uno en cada dirección) en comparación con un protocolo que requiere una configuración inicial.

Una aplicación que utiliza de esta manera a UDP es DNS (Sistema de Nombres de Dominio). En resumen, un programa que necesita buscar la dirección IP de algún host, puede enviar al servidor DNS un paquete UDP que contenga el nombre de dicho host. El servidor responde con un paquete UDP que contiene la dirección IP del host. No se necesita configuración por adelantado ni tampoco liberación posterior. Sólo dos mensajes viajan a través de la red.

LLAMADA A PROCEDIMIENTO REMOTO

En cierto sentido, enviar un mensaje a un host remoto y obtener una respuesta es muy parecido a hacer una llamada a función en un lenguaje de programación. En ambos casos, se inicia con uno o más parámetros y obtiene un resultado. Esta observación ha llevado a la gente a tratar de que las interacciones de solicitud-respuesta en redes se asignen en forma de llamadas a procedimiento. Esto hace que las aplicaciones de red sean mucho más fáciles de programar y de manejan.

Por ejemplo, imagine un procedimiento llamado obt_dirección_IP (nombre-de-host) que envía un paquete UDP a un servidor DNS y espera una respuesta, y en caso de que no llegue ninguna con rapidez, termina y lo intenta nuevamente. De esta forma, todos los detalles de la conectividad pueden ocultarse al programador.

Cuando un proceso en la máquina 1 llama a uno en la máquina 2, el proceso invocador de la primera se suspende y la ejecución del procedimiento se lleva a cabo en la 2. La información se puede transportar desde el invocador al proceso invocado en los parámetros, y se puede regresar en el resultado del procedimiento. El paso de mensajes es transparente para el programador. Esta técnica se conoce como RPC (Llamada a Procedimiento Remoto) y se ha vuelto la base de muchas aplicaciones de redes. Tradicionalmente, el procedimiento invocador se conoce como cliente y el proceso invocado, como servidor.

El propósito esencial de RPC es hacer que una llamada a procedimiento remoto sea lo más parecida posible a una local. En la forma más simple, para llamar a un procedimiento remoto, el programa cliente debe enlazarse con un pequeño procedimiento de biblioteca, llamado stub del cliente, que representa al procedimiento servidor en el espacio de direcciones del cliente. De forma similar, el servidor se enlaza con una llamada a procedimiento denominada stub del servidor. Estos procedimientos ocultan el hecho de que la llamada a procedimiento desde el cliente al servidor no es local.

Los pasos para realizar una RPC son:

• 1. El cliente llame al stub del cliente. Ésta es una llamada a procedimiento local, y los parámetros se colocan en la pila de la forma tradicional.

• 2. El stub del cliente empaca los parámetros en un mensaje y realiza una llamada de sistema para enviar dicho mensaje. El empaquetamiento de los parámetros se conoce como marshaling.

• 3. El kernel envía el mensaje desde la máquina cliente a la máquina servidor.

• 4. El kernel pasa el paquete entrante al stub del servidor.

• 5. El stub del servidor llame al procedimiento servidor con parámetros sin marshaling. La respuesta sigue la misma ruta en la dirección opuesta.

El elemento clave es que el procedimiento cliente, escrito por el usuario, simplemente realiza una llamada a procedimiento normal (es decir, local) al stub del cliente. Puesto que el procedimiento cliente y el stub del cliente están en el mismo espacio de direcciones, los parámetros se pasan de la forma usual. De manera similar, el procedimiento servidor es llamado por un procedimiento en su espacio de direcciones con los parámetros que esperaba. Para el procedimiento servidor, nada es inusual. De esta forma, en lugar de que la E/S se realice en sockets, la comunicación de red se realiza simulando una llamada a procedimiento normal.

A pesar de la elegancia conceptual de RPC, hay algunas desventajas ocultas. La más grande es el uso de parámetros de apuntador. Por lo general, pasar un apuntador a un procedimiento no es un problema. El procedimiento invocado puede utilizar el apuntador de la misma manera que el invocador, porque ambos procedimientos habitan el mismo espacio de direcciones virtual. Con RPC, el paso de apuntadores es imposible porque el cliente y el servidor están en diferentes espacios de direcciones. En algunos casos, se pueden utilizar trucos para hacer que el paso de apuntadores sea posible.

Un segundo problema es que en los lenguajes de tipos flexibles, como C, es perfectamente legal escribir un procedimiento que calcule el producto interno de dos vectores (arreglos), sin especificar la longitud de cada uno. Éstos pueden terminarse mediante un valor especial conocido sólo por los procedimientos invocador e invocado. Bajo estas circunstancias, es esencialmente imposible que el stub del cliente aplique marshaling a los parámetros debido a que no tiene forma de determinar su longitud.

Un tercer problema es que no siempre es posible deducir los tipos de parámetros, ni siquiera de una especificación formal o el código mismo.

Un cuarto problema se relaciona con el uso de las variables globales. Por lo general, los procedimientos invocador e invocado pueden comunicarse utilizando variables globales y parámetros. Si el procedimiento invocado se mueve a una máquina remota, el código fallará porque las variables globales ya no se pueden compartir.

Estos problemas no significan que RPC no tiene mucho futuro. De hecho, se utiliza ampliamente, pero se necesitan algunas restricciones para hacerlo funcionar bien en la práctica.

Por supuesto, RPC no necesita utilizar paquetes UDP, pero RPC y UDP son una buena combinación y UDP se utiliza comúnmente con RPC. No obstante, cuando los parámetros o resultados son más grandes que el tamaño máximo del paquete UDP o cuando la operación solicitada no tiene la misma potencia (es decir, no se puede repetir de forma segura, como cuando se incrementa un contador), tal vez sea necesario establecer una conexión TCP y enviar una solicitud a través de ella en lugar de utilizar UDP.

El protocolo de transporte en tiempo real

El RPC cliente-servidor es un área en la que se utiliza ampliamente UDP. Otra son las aplicaciones multimedia en tiempo real. En particular, conforme el radio en Internet, la telefonía en Internet, la música bajo demanda, la videoconferencia, el vídeo bajo demanda y otras aplicaciones multimedia se volvían más comunes, las personas que descubrieron cada una de esas aplicaciones estaba reinventando más o menos el mismo protocolo de transporte de tiempo-real. Gradualmente se volvió más claro que tener un protocolo de transporte genérico para múltiples aplicaciones sería una excelente idea. Y fue por esto que nació el RTP (Protocolo de Transporte en Tiempo Real).

La posición del RTP en la pila de protocolos es algo extraña. Se decidió colocarlo en el espacio de usuario y ejecutarlo (por lo general) sobre UDP. La aplicación multimedia consiste en múltiples flujos de audio, vídeo, texto, entre otros. Éstos se colocan en la biblioteca RTP, la cual está en el espacio de usuario junto con la aplicación. Esta biblioteca multiplexa los flujos y los codifica en paquetes RTP, que después coloca en un socket. En el otro extremo del socket (en el kernel del sistema operativo), los paquetes UDP se generan e incrustan en paquetes IP. Si la computadora está en una Ethernet, los paquetes IP se colocan a continuación en tramas Ethernet para su transmisión.

Como consecuencia de este diseño, es un poco difícil decir en cuál capa está RTP. Debido a que se ejecuta en el espacio de usuario ya que está enlazado al programa de aplicación, ciertamente luce como un protocolo de aplicación. Por otro lado, es un protocolo genérico, independiente de la aplicación que simplemente proporciona características de transporte, por lo que se parece a un protocolo de transporte. Probablemente la mejor descripción es que es un protocolo de transporte que está implementado en la capa de aplicación.

La función básica de RTP es multiplexar varios flujos de datos en tiempo real en un solo flujo de paquetes UDP. El flujo UDP se puede enviar a un solo destino (unidifusión) o a múltiples destinos (multidifusión). Debido a que RTP sólo utiliza UDP normal, sus paquetes no son tratados de manera especial por los ruteadores, a menos que se habiliten algunas características de calidad de servicio IP normales.

A cada paquete enviado en un flujo RTP se le da un número más grande que a su predecesora. Esta numeración permite al destino determinar si falta algún paquete. Si falta alguno, la mejor acción que el destino puede realizar es aproximar el valor faltante mediante la interpelación. La retransmisión no es una opción práctica debido a que el paquete retransmitido probablemente llegará muy tarde como para ser útil. En consecuencia, RTP no tiene control de flujo, control de errores, confirmaciones de recepción ni ningún mecanismo para solicitar retransmisiones.

Cada carga útil RTP podría contener múltiples muestras, y éstas podrían codificarse de la forma en la que la aplicación desee. Para permitir la interconectividad, RTP define diversos perfiles (por ejemplo, un solo flujo de audio), y para cada perfil se podrían permitir múltiples formatos de codificación.

Otra característica que muchas de las aplicaciones en tiempo real necesitan es la marcación del tiempo (timestamping). La idea aquí es permitir que el origen asocie una marca de tiempo con la primera muestra de cada paquete. Las marcas de tiempo son relativas al inicio del flujo, por lo que sólo son importantes las diferencias entre dichas marcas de tiempo. Los valores absolutos no tienen significado. Este mecanismo permite que el destino realice una pequeña cantidad de almacenamiento en búfer y reproduzca cada muestra el número exacto de milisegundos después del inicio del flujo, independientemente de cuándo llegó el paquete que contiene la muestra. La marcación del tiempo no sólo reduce los efectos de la fluctuación. sino que también permite que múltiples flujos estén sincronizados entre sí.

RTP tiene un hermano pequeño llamado RTCP (Protocolo de Control de Transporte en Tiempo Real). Maneja la retroalimentación, sincronización y la interfaz de usuario, pero no transporta ningún tipo de datos. La primera función se puede utilizar para proporcionar a los orígenes retroalimentación en caso de retardo, fluctuación, ancho de banda, congestión y otras propiedades de red. El proceso de codificación puede utilizar esta información para incrementar la tasa de datos (y para proporcionar mejor calidad) cuando la red está funcionando bien y para disminuir la tasa de datos cuando hay problemas en la red. Al proporcionar retroalimentación continua, los algoritmos de codificación se pueden adaptar continuamente para proporcionar la mejor calidad posible bajo las circunstancias actuales.

RTCP también maneja sincronización entre flujos. El problema es que flujos diferentes pueden utilizar relojes diferentes. con distintas tasas de derivación. RTCP puede utilizarse para mantenerlos sincronizados.

Por último, RTCP proporciona una forma para nombrar los diversos orígenes (por ejemplo, en texto ASCII). Esta información puede desplegarse en la pantalla del receptor para indicar quién está hablando en ese momento.

Los protocolos de transporte de internet: TCP

UDP es un protocolo simple y tiene algunos aspectos específicos; pero para la mayoría de aplicaciones de Internet se necesita una entrega en secuencia confiable.

INTRODUCCION A TCP

TCP (PROTOCOLO DE CONTROL DE TRANSMISION) se diseño para proporcionar un flujo de bytes confiable de extremo a extremo. Cada maquina que soporta TCP tiene una entidad de transporte TCP. Una entidad TCP acepta flujo de datos de usuario de procesos locales, lo divide en fragmentos y envía cada fragmento como un datagrama IP independiente. Cuando los datagramas que contienen datos TCP llegan a una maquina, se pasan a la entidad TCP, la cual reconstruye los flujos de bytes originales.

La capa de red no proporciona ninguna garantía de que los datagramas se entregarán de manera apropiada, por lo que corresponde a TCP retransmitir los datagramas que fueran necesarios.

EL MODELO DEL SERVICIO TCP

El servicio TCP se obtiene al hacer que tanto el servidor como el cliente creen sockets, cada socket tiene una dirección que esta formada por la dirección IP del host y de un número que identifica al puerto. Para obtener el servicio de TCP, se debe establecer de manera explicita una conexión entre un socket en la maquina emisora y uno en la receptora. Un socket puede utilizarse para múltiples conexiones al mismo tiempo.

Los números de puertos menores a 1024 se llaman puertos conocidos y se reservan para servicios estándar. Por ejemplo para transferir un archivo FTP se utiliza el puerto 21.

Los puertos conocidos son:

Para evitar que todos los procesos que llaman a los puertos conocidos estén activados todo el tiempo (lo que representa un desperdicio de memoria) en Unix por ejemplo se utiliza el proceso inetd (demonio de Internet) el cual se conecta a sí mismo a múltiples puertos y espera la primera conexión entrante, después separa un nuevo proceso y ejecuta el demonio apropiado para él, dejando que ese demonio maneje la solicitud. De esta forma, los demonios distintos de inetd solo están activos solo cuando hay trabajo para ellos.

Todas las conexiones son de duplex total y de punto a punto. Una conexión TCP es un flujo de bytes, no de mensajes. Los límites de los mensajes no se preservan de extremo a extremo. Los archivos de Unix también tienen esa propiedad, el lector de archivos no puede indicar si éste escribió un bloque, un byte o todo a la vez. Al igual que con un archivo de Unix, el software de TCP no tiene idea de lo que significan los bytes y no le interesa averiguarlo. Un byte es solo un byte.

Cuando una aplicación pasa datos a TCP, este decide si los envía inmediatamente o los almacena en el búfer.

EL PROTOCOLO TCP

Una característica clave de TCP es que cada byte de una conexión TCP tiene su propio número de secuencia de 32 bits.

La entidad TCP emisora y la receptora intercambian datos en forma de segmentos. Un segmento consiste en un encabezado TCP fijo seguido de bytes de datos.

El protocolo básico usado para las entidades TCP es aquel en el que un transmisor envía un segmento. Cuando llega el segmento al destino, la entidad TCP receptora devuelve un segmento que contiene una confirmación de recepción.

Para establecer una conexión en TCP el servidor espera pasivamente una conexión entrante ejecutando las operaciones LISTEN y ACCEPT y especificando un origen o no especificando nada. El cliente ejecuta una operación de CONNECT especificando la dirección IP y el puerto con el que se desea conectar. Al llegar el segmento al destino revisa si hay un proceso que haya ejecutado un LISTEN en el puerto indicado.

Si algún proceso esta escuchando en el puerto, ese proceso recibe el segmento TCP entrante y puede entonces aceptar o rechazar una conexión.

Para liberar una conexión cualquiera de las dos partes puede enviar un segmento TCP indicando que no tiene mas datos por transmitir. Al confirmarse la recepción ese sentido se apaga. Sin embargo puede seguir puede continuar un flujo de datos indefinidos en el otro sentido. Cuando ambos sentidos se han apagado se libera la conexión.

CONTROL DE CONGESTION EN TCP

Cuando la carga ofrecida a cualquier red es mayor que la que puede manejar, se genera la congestión. Aunque la capa de red también intenta manejarlos, gran parte del trabajo recae sobre TCP ya que la solución real a la congestión es la disminución de las tasas de datos.

En teoría puede manejarse la congestión aprovechando un principio de física: la ley de conservación de los paquetes. La idea es no inyectar un nuevo paquete a la red hasta que salga un viejo. TCP intenta lograr esta meta manipulando dinámicamente el tamaño de los paquetes.

En Internet existen dos problemas importantes la capacidad de la red y la capacidad del receptor. Cada emisor mantiene dos ventanas: la ventana que ha otorgado el receptor y la ventana de congestión. Cada una refleja la cantidad de bytes que puede enviar el receptor.

Al establecer una conexión, el emisor asigna a la ventana de congestión el tamaño de segmento máximo usado por la conexión, entonces envía un segmento máximo. Si se recibe la confirmación de recepción antes de que expire el paquete el emisor agrega el equivalente en bytes de un segmento en la ventana de congestión, y envía dos segmentos. A medida que se confirma cada uno de estos segmentos se aumenta el tamaño de la ventana de congestión a un tamaño mayor.

La ventana de congestión sigue creciendo hasta ocurrir una expiración del paquete o alcanzar el tamaño máximo de la ventana receptora. A este algoritmo se le conoce como arranque lento.

El algoritmo de control de congestión utilizado para Internet se conoce como el umbral en el cual al ocurrir una expiración del paquete, se establece el umbral en la mitad de la ventana de congestión actual y la ventana de congestión se reestablece a un segmento máximo. Luego se usa el arranque lento para determinar lo que puede manejar la red, excepto que el crecimiento exponencial termina al llegar al umbral. A partir de este punto las transmisiones exitosas aumentan linealmente la ventana de congestión.

TCP Y UDP INALÁMBRICOS

En teoría, los protocolos de transporte deben ser independientes de la tecnología de la capa de red subyacente. En particular el TCP no debería preocuparse si el IP está operando fibra o por radio. En la práctica si importa ya que la mayoría de las implementaciones de TCP han sido optimizadas cuidadosamente con base en supuestos que se cumplen en las redes inalámbricas. Ignorar las propiedades de la transmisión inalámbrica puede conducir a implementaciones del TCP correctas desde el punto de vista lógico pero con un desempeño equivocado.

El problema principal es el algoritmo de control de congestión. TCP supone que las expiraciones de los paquetes ocurrían por la congestión y no por paquetes perdidos. En consecuencia, al expirar un paquete TCP disminuye su velocidad v envía con menor ímpetu. Lo que se pretende con este enfoque es reducir la carga de red y aliviar así la congestión.

Desgraciadamente, los enlaces de transmisión inalámbrica son muy poco confiable. Pierden paquetes todo el tiempo. El enfoque adecuado para el manejo de paquetes perdidos es enviarlos nuevamente, tan pronto como sea posible. La reducción de la velocidad simplemente empeora las cosas. Una solución es el TCP indirecto, el cual es la división de la conexión TCP en dos conexiones distintas. La primera va del emisor a la estación base al receptor. La estación base simplemente copia paquetes entre las conexiones en ambas direcciones.

La desventaja es que se viola por completo la semántica de TCP. Dado que cada conexión es una conexión TCP completa, la estación base confirma la recepción de cada fragmento TCP de la manera normal, solo que ahora la recepción de una confirmación el emisor no significa que el receptor recibió el segmento, sino que la estación base lo recibió.

Aspectos del desempeño

El entendimiento del desempeño de las redes es más un arte que una ciencia. Muy poca de la practica tiene que ver con la teoría.

PROBLEMAS DE DESEMPEÑO EN LAS REDES DE CÓMPUTO

Algunos problemas de desempeño, como la congestión, son causados por sobrecargas temporales de los recursos. Si repentinamente llega más tráfico a un ruteador que el que puede manejar, surgirá la congestión y el desempeño bajará. El desempeño se degrada cuando hay un equilibrio estructural de los recursos.

Las sobrecargas también pueden generarse sincrónicamente. Por ejemplo, si una TPDU contiene un parámetro erróneo. Un segundo ejemplo de sobrecarga síncrona es lo que ocurre tras una falla del suministro eléctrico. Al regresar la energía, todas las máquinas saltan simultáneamente a sus ROM"s para reiniciarse. Una secuencia de arranque común podría requerir acudir primero a algún servidor (DHCP) para conocer la identidad verdadera de la máquina, y luego a un servidor de archivos para obtener una copia del sistema operativo.

Aun en ausencia de sobrecargas síncronas y con suficientes recursos disponibles, puede haber un bajo desempeño debido a la falta de afinación del sistema.

Una cantidad que conviene recordar durante el análisis del desempeño de redes es el producto ancho de banda-retardo que se obtiene al multiplicar el ancho de banda (en bits/seg) por el tiempo de retardo de ida y vuelta (en seg). El producto es la capacidad del canal desde el emisor al receptor y de regreso (en bits).

Otro problema de desempeño que ocurre con las aplicaciones de tiempo crítico como audio y vídeo es la fluctuación. Un tiempo medio de transmisión corto no es suficiente. También se requiere una desviación estándar pequeña. El logro de un tiempo medio de transmisión corto con una desviación estándar pequeña requiere esfuerzos serios de ingeniería.

Enviado por:

Ing.+Lic. Yunior Andrés Castillo S.

"NO A LA CULTURA DEL SECRETO, SI A LA LIBERTAD DE INFORMACION"®

www.monografias.com/usuario/perfiles/ing_lic_yunior_andra_s_castillo_s/monografias

Santiago de los Caballeros,

República Dominicana,

2015.

"DIOS, JUAN PABLO DUARTE Y JUAN BOSCH – POR SIEMPRE"®