# TPT Distribuidos

- Se considera la interacción de HTTP con varios protocolos de transporte:
- TCP
- Transaction TCP
- un protocolo de petición-respuesta basado en UDP
- HTTP con conexiones TCP persistentes.

# **Objetivo**

Crear modelo para evaluar la sobrecarga de la red que transporta tráfico HTTP a través de una variedad de características de red.

Este modelo incluye un análisis de los efectos transitorios del arranque lento de TCP.

Presentamos modelos analíticos del tráfico HTTP en varios protocolos de transporte. Estos modelos nos permiten comparar los protocolos actuales y futuros en un marco común.

Validamos nuestros modelos comparándolos con mediciones de un sistema real.

# **Falencias**

Demostramos que el modelo es preciso dentro del 5% del rendimiento medido para redes de área extensa, pero puede subestimar la latencia cuando el ancho de banda es alto y el retardo bajo.

# Sobrecarga (overhead)

La sobrecarga de la red se refiere a los datos adicionales y al procesamiento necesarios para transmitir y recibir datos a través de una red. Estos datos y procesamiento adicionales pueden incluir datos redundantes, encabezados de protocolo de red, detección y corrección de errores y congestión de la red.

# **TCP**

- Posee algoritmos de control de flujo y evitación de congestión cuidadosamente ajustados. Es un protocolo excelente para el transporte masivo de datos en redes congestionadas.
- El tráfico web no es ideal para TCP. En la práctica, el acceso a la web está orientado a la petición- respuesta, con ráfagas de numerosas peticiones y pequeñas respuestas unidireccionales. La recuperación de una página web completa requiere peticiones separadas para el texto y cada imagen incrustada, lo que hace que el tráfico sea inherentemente de ráfagas.
- TCP no se adapta bien al tráfico frecuente, corto y de tipo petición-respuesta.
- Los frecuentes costes de establecimiento y desconexión de conexiones sobrecargan los servidores con **muchas conexiones en estado de espera TIME WAIT.**
- Las conexiones cortas pueden **interactuar mal con el algoritmo de slow start de TCP** para evitar la congestión
- El **handshake inicial añade latencia a cada transacción**
- TCP está optimizado para el transporte masivo de datos a gran escala, mientras que HTTP suele necesitar un protocolo ligero de solicitud-respuesta

# **Contribuciones**

- El comportamiento de inicio del algoritmo de **slow start** de TCP depende de la política de *acuse de recibo* del receptor, el cual, a su vez a menudo hace que la ventana de congestión se abra mucho más despacio de lo que se ha descrito.

Estos efectos son especialmente importantes para HTTP (y otros protocolos similares cortos de solicitud-respuesta), donde los **efectos transitorios suelen dominar el rendimiento**.

- Proporcionamos un modelo analítico para el transporte web a través de varios protocolos y lo utilizamos para comparar estos protocolos y validar los resultados experimentales de investigadores anteriores
- Aplicamos nuestro modelo para predecir el rendimiento de los protocolos en una amplia gama de características de red, incluidas las características de las redes futuras.
- Aplicamos estas predicciones para evaluar el rendimiento de las recientes mejoras de HTTP. Descubrimos que, aunque mejoras recientes como el HTTP persistente son eficaces con redes de gran ancho de banda, ofrecen beneficios mucho más modestos en redes de ancho de banda medio y bajo que son las mas comunes para el usuario promedio.

# 2. **Trabajos relacionados**

## **Conexión persistente HTTP**

- Su examen de una petición-respuesta HTTP típica demostró **rendimientos para respuestas cortas tan pequeños como el 10% del rendimiento obtenible por transferencias de datos masivas** en condiciones de red similares. Atribuyen estos costes a los mecanismos de establecimiento de conexión e inicio lento de TCP.
- Validamos sus resultados para hosts bien conectados; en tales casos, P-HTTP mejorará el rendimiento. **También demostramos que cuando el ancho de banda o el retardo se degradan** (quizás debido a la congestión de la red, a enlaces con cuellos de botella como un módem o RDSI, o a la colocación de hosts), **las mejoras de rendimiento de P-HTTP son mucho más modestas.**
- Una nota técnica reciente ha sugerido que el uso de pipelining es importante para obtener un buen rendimiento de la implementación HTTP/1.1 de P-HTTP. El **pipelining reduce el número de paquetes transmitidos y soporta la independencia de las peticiones.**

## **T/TCP (Transaction TCP)**

- Popone como **eludir el handshake** de tres vías de TCP y **evitar el arranque lento**
- **Acorta el periodo TIME WAIT** de TCP de 240 a 12 s, reduciendo la duración de retención del estado por conexión
- **Respecto a los costes de establecimiento de conexión**, **el tráfico HTTP sobre T/TCP y el TCP de conexión persistente** (P-HTTP sobre TCP) **se comportan de forma idéntica**.

## **Protocolos de solicitud-respuesta basados en UDP**

- El Protocolo de Entrega Fiable Asíncrono (ARDP) es un ejemplo de protocolo fiable de paso de mensajes **construido sobre UDP** para interacciones de tipo petición-respuesta entre un cliente y un servidor.
- Proporcionar un **mecanismo de comunicación fiable y ligero para transportar peticiones y respuestas entre clientes y servidores**
- La versión actual de ARDP (en desarrollo) **toma prestados los algoritmos de control de flujo, prevención de la congestión y retransmisión de TCP**.
- ARDP evita el **handshake** de TCP y selecciona aleatoriamente identificadores de conexión.

# 3. Modelos de red y tráfico

## Modelo de red


- Los tres primeros parámetros enumerados en la Tabla I - tiempo de ida y vuelta, ancho de banda y tamaño máximo del segmento 5 - son propiedades de una ruta de red determinada
- Los dos parámetros restantes pueden derivarse de los demás.
- El **tiempo de transmisión del segmento** (el tiempo que se tarda en enviar el paquete más grande posible) está directamente relacionado con el ancho de banda y el tamaño del segmento


- El tamaño máximo de ventana útil es el producto de bandwidth-delay expresado en un número integral de paquetes. Este parámetro final **representa el número de segmentos que deben estar en vuelo para mantener llena la "tubería" de la red.**
- **producto bandwidth-delay: rtt x bw**

Bandwidth delay product is a measurement of how many bits can fill up a network link. It gives the maximum amount of data that can be transmitted by the sender at a given time before waiting for acknowledgment.

- **Cuando el tamaño actual de la ventana es inferior a muws, se producirá un retraso en el retorno del acuse de recibo al remitente; cuando el tamaño de la ventana es al menos segmentos muws, habrá un flujo continuo de datos.**


- Una última característica de la red que n**o se tiene en cuenta aquí es la tasa de error en la transmisión**. El objetivo principal de este documento es examinar los efectos
de arranque de los protocolos de transporte.

Redes


- Para Ethernet, utilizamos el ancho de banda y la latencia observados y medidos entre dos hosts Sun SPARC 20/71 conectados por una Ethernet dedicada de 10 Mb/s
- Para Internet, empleamos dos valores distintos - "rápido" y "lento"- que corresponden a las velocidades de comunicación medidas entre hosts bien conectados en el mismo continente y en continentes distintos, respectivamente.
- Por último, sólo las cifras de Internet lenta y rápida tienen en cuenta las limitaciones de latencia y ancho de banda en áreas extensas; en los demás casos se supone que el cliente está directamente conectado al servidor mediante la tecnología de red dada
- Ya podemos observar que *MUWS* es bastante bajo en muchas redes actuales, con la excepción del caso de Internet rápida. **Una vez que la ventana de transmisión se ha abierto más allá de este valor, los acuses de recibo de los paquetes pendientes se devuelven tan rápido como se transmiten los paquetes**. ***MUWS* está directamente relacionada con la sobrecarga del protocolo; más adelante demostraremos que cuando es pequeña, las optimizaciones de la configuración de la conexión tienen poco que optimizar y, por tanto, proporcionan un rendimiento similar al de HTTP sobre TCP.**

## Modelo de tráfico

El rendimiento de los protocolos de transporte también depende de las características del tráfico HTTP. Consideramos varias cargas de trabajo HTTP potenciales.

- **Página pequeña**: Página única de 5 kB.
- **Página mediana**: Página única de 25 kB.
- **Página grande**: Página única de 100 kB.
- **Cluster pequeño**: Página única de 6651 B con imágenes incrustadas de 3883 B y 1866 B.
- **Cluster mediano**: Página única de 3220 B con tres imágenes incrustadas, de tamaños 57 613 B, 2344 B y 14 190 B
- **Cluster grande**: Una sola página de 100 kB con 10 imágenes incrustadas de 25 kB.

Cada una de las cargas de trabajo del clúster requiere múltiples HTTP solicitudes, una por página o imagen

**Suposiciones**:

- Suponemos que todas las peticiones son independientes. Las peticiones A y B son independientes si la petición B puede iniciarse antes de que la petición A haya finalizado.
- Para simplificar nuestro modelo, suponemos un tamaño de solicitud constante de 256 B
- Suponemos un tiempo de procesamiento de la peticion en el servidor igual a cero.

Un modelo más complejo del tamaño de la solicitud no está justificado, ya que las solicitudes casi siempre caben en un segmento y, por tanto, **el rendimiento está dominado por el tamaño de la respuesta**

# 4. Análisis de protocolos

## Tiempos mínimos de transmisión

El tiempo minimo de una transmisión es:


En caso de una serie de solicitudes independientes (ya sea mediante pipelining o multithreading), habrá en una sola latencia de ida y vuelta porque son enviadas a modo de ráfaga. Por lo tanto, el tiempo total necesario será


Debido a nuestras suposiciones sobre el tamaño de las solicitudes y el tiempo de procesamiento, el principal factor que influye en los tiempos mínimos de transmisión será *reply_min*

**Tiempos Teóricos Mínimos para enviar diferentes workloads a través de distintas redes**


## Modelo simple

- Podemos hacer una estimación muy sencilla de **cuándo será significativa la sobrecarga del protocolo de transporte comparando la relación entre el producto ancho de banda-retardo y el tamaño de la transacción**
- En cualquier protocolo de transporte de flujo continuo, se necesitan varios intercambios de ida y vuelta para alcanzar un rendimiento estable
- Cuando la transacción ofrecida es demasiado pequeña, no se alcanza la estabilidad y se amplifican los efectos transitorios. En cualquier protocolo de transporte de flujo continuo, se necesitan varios intercambios de ida y vuelta para alcanzar un rendimiento estable
- Para una transaccion HTTP, asumiendo el *req size* igual a cero, el ratio es:


- **Cuando esta relación es pequeña, se espera que los costes de setup del protocolo dominen el rendimiento; cuando es grande, los costes de configuración se amortizarían**
- Una visión alternativa del mismo concepto invierte esta relación para obtener el tamaño de la tubería en unidades de tamaño de respuesta.


- **Podemos utilizar esta ecuación para obtener una primera aproximación de los gastos generales de configuración**. Para estimar los gastos generales de las recuperaciones de una sola página, aplicamos directamente esta ecuación. Para grupos de recuperaciones utilizar la media armónica de relaciones para cada recuperación, si cada requiere una conexión independiente.
- **Estas sencillas ecuaciones ofrecen una buena predicción de los casos en los que los efectos transitorios serán elevados**, pero no captan con precisión estos efectos cuando aumenta el producto ancho de banda/retardo

## HTTP sobre TCP

### Fuentes de sobrecarga:

TCP añade varias fuentes de sobrecarga:

- Las cabeceras del protocolo *(implica paquetes mas grandes)*
- Three-way Handshake en el establecimiento de la conexión *(implica gasto de tiempo: 1 rtt extra y transferir mas paquetes)*
- El algoritmo de slow start

Tambien las retransmisiones y el retardo del control de congestión debido a la pérdida de paquetes, aunque esto no lo tenemos en cuenta porque las tasas de pérdida de paquetes dependen de una serie de factores que van más allá del alcance de este artículo.

### Efectos de Slow Start

- **El algoritmo de inicio lento de TCP limita la transmisión mediante una ventana de congestión (CWND) que se inicializa en un segmento y aumenta cada vez que se recibe un ACK.**
El tamaño del incremento cambia: inicialmente crece en incrementos de un segmento (fase de arranque lento) y, posteriormente, en 1/CWND (fase de evitación de la congestión).
- **Para rutas de gran BDP, el TCP inicialmente se alterna entre la transmisión de segmentos y las paradas (stalls) a la espera de que vuelvan los ACK de estos segmentos**. El número de segmentos enviados por parada aumenta exponencialmente durante el arranque lento hasta que hay suficientes segmentos en vuelo como para que los ACK vuelvan continuamente
- Para modelar el comportamiento del arranque lento, necesitamos saber cuántos segmentos se envían entre paradas, cuánto tiempo se pierde en cada parada y cuántas paradas se producen hasta que se alcanza el estado estacionario o finaliza la transmisión.
- Originalmente esperábamos que el número de paquetes entre cada parada siguiera un patrón exponencial simple: 1, 2, 4, 8, y así sucesivamente. Las **implementaciones modernas de TCP se desvían de este comportamiento por dos razones**:
- En las implementaciones TCP derivadas de BSD, el ACK del paquete SYN provoca incremento de CWND, por lo que para la respuesta comienza en 2.
- El algoritmo de ACK retardado de TCP normalmente hace que el cliente mande ACK cada dos segmentos, no cada segmento. Dado que la ventana de congestión se abre por cada ACK recibido en lugar de por cada segmento reconocido, la ventana de inicio lento se abre mucho más despacio de lo que se suele suponer.



- Redes como Fast-Ethernet, Fast-Internet, ADSL y DirecPC tienen sobrecargas sustancialmente mayores porque tienen tamaños de MUWS (BDP) mucho más altos.
- El elevado BDP de estas redes requiere de siete a 128 segmentos en tránsito para llenar la tubería de comunicaciones; en el caso de archivos pequeños, se pierde un tiempo considerable esperando los acuses de recibo de los paquetes. Estas sobrecargas son más pronunciadas cuando se procesan cargas de trabajo más pequeñas, ya que las cargas de trabajo más grandes pueden ampliar la ventana de congestión y amortizar el coste de establecimiento de la conexión a lo largo de la duración de la misma

la principal forma de overhead que agrega es debido a una apertura de la ventana lenta, lo cual hace que se envie muchos menos paquetes que la MUWS. La situacion empeora si encima se hacen ACK cada dos paquetes, provocndo que la apertura sea aun mas lenta

## HTTP sobre TCP con caché de conexión

- P- HTTP reutiliza una única conexión TCP para amortizar los costes de establecimiento de la conexión y evitar la congestión entre varias peticiones HTTP. Cuando se completa una transacción, la conexión TCP se deja abierta para transacciones posteriores. Se cerrará si la demanda del servidor o del cliente es alta, o cuando esté inactiva durante un periodo de tiempo determinado.
- T/TCP almacena en caché la información de establecimiento de la conexión TCP para que las conexiones TCP posteriores eviten el handshake de tres vías y reduzcan el coste del arranque lento. La información T/TCP almacenada en caché se eliminará mediante algoritmos similares a los utilizados para interrumpir las conexiones P- HTTP (por ejemplo, utilizando un tiempo de espera periódico o de uso menos reciente).
- Por lo tanto, modelamos estos protocolos conjuntamente como protocolos "HTTP sobre TCP con caché".


- En una serie de peticiones a un nuevo servidor, la primera siempre será un fallo y las siguientes normalmente serán aciertos.


## HTTP sobre protocolos basados en UDP

- ARDP evita el handshake de tres vías de T C P , al tiempo que mantiene el algoritmo de inicio lento de TCP para evitar la congestión.


- Por otro lado, la sobrecarga de ARDP se hace notable en los casos de mayor producto de ancho de banda-retardo (Fast-Ethernet, ambas Internets, ADSL y DirecPC).
- **ARDP también incurre en una sobrecarga mayor que TCP con caché de conexión para las cargas de trabajo de cluste**r. Esta sobrecarga se debe al hecho de que **ARDP siempre se inicia lentamente, mientras que el almacenamiento en caché** de los parámetros de establecimiento de conexión **permite evitar el inicio lento cada vez**.

# 5. Validación