Módulo 03 La Capa de Transporte (Pt. 2)

Presentación del tema: "Módulo 03 La Capa de Transporte (Pt. 2)"— Transcripción de la presentación:

1 Módulo 03 La Capa de Transporte (Pt. 2)

2 Copyright Copyright © 2010-2017 A. G. Stankevicius
Se asegura la libertad para copiar, distribuir y modificar este documento de acuerdo a los términos de la GNU Free Documentation License, versión 1.2 o cualquiera posterior publicada por la Free Software Foundation, sin secciones invariantes ni textos de cubierta delantera o trasera. Una copia de esta licencia está siempre disponible en la página La versión transparente de este documento puede ser obtenida de la siguiente dirección: Redes de Computadoras - Mg. A. G. Stankevicius

3 Contenidos Servicios y protocolos de la capa de transporte.
Multiplexado y demultiplexado de segmentos. Transporte no orientado a la conexión (UDP). Teoría de transporte confiable de datos. Transporte orientado a la conexión (TCP). Establecimiento y cierre de conexiones. Teoría de control de congestión. Control de congestión en TCP. Redes de Computadoras - Mg. A. G. Stankevicius

4 Transmission Control Protocol
Es un protocolo punto a punto. Permite intercambiar un flujo de bytes. No requiere delimitadores de mensajes. Implementa una operatoria en pipeline. Los mecanismos de control de flujo y de congestión determinan el tamaño de la ventana deslizante. Puede requerir hacer uso de almacenamiento intermedio ya sea al enviar o al recibir. Redes de Computadoras - Mg. A. G. Stankevicius

5 Transmission Control Protocol
Posibilita la transferencia bidireccional de datos. Una misma conexión permite enviar y recibir datos. El parámetro MSS denota el tamaño máximo de segmento aceptado por una dada implementación. Es orientado a la conexión. Requiere una fase previa de inicialización antes de comenzar con el intercambio de información. Implementa control de flujo. El emisor nunca satura de datos al receptor. Redes de Computadoras - Mg. A. G. Stankevicius

6 Estructura de un segmento
ACK denota que el nro. de reconocimiento es válido se cuenta a nivel de bytes, no a nivel de paquetes 32 bits puerto origen puerto dest. URG permite marcar a los datos como urgentes número de secuencia número de reconocimiento PSH solicita se procesen los datos del buffer lon. - u a p r s f ven. de recep. checksum punt. urgente RST, SYN, FIN se utilizan para establecer y finalizar conexiones. opciones (tam. variable) campo para publicitar el tamaño de la ventana de recepción datos de la aplicación (tam. variable) checksum (análogo a UDP) formato de un segmento TCP Redes de Computadoras - Mg. A. G. Stankevicius

7 Secuencia y reconocimiento
puerto origen puerto dest. número de secuencia número de reconocimiento f ven. de recep. s r p a u lon. - ventana deslizante de tamaño N ACK ya recibido a ser enviados todavía no usables puerto origen puerto dest. número de reconocimiento f ven. de recep. s r p a u lon. - número de secuencia enviados esperando ACK Redes de Computadoras - Mg. A. G. Stankevicius

8 Secuencia y reconocimiento
El número de secuencia de un segmento indica la posición del byte transferido dentro del flujo de bytes de la conexión. El número de reconocimiento indica el próximo número de secuencia esperado del otro lado. TCP hace uso de reconocimientos acumulativos, esto es, al reconocer un cierto número de secuencia se reconocen implícitamente todos los anteriores. La especificación formal nada dice acerca de qué hacer con los segmentos fuera de orden. Redes de Computadoras - Mg. A. G. Stankevicius

10 Tiempo de espera razonable
¿Qué valor resulta conveniente adoptar como tiempo de espera razonable (TCP timeout)? Al menos tiene que ser mayor que el RTT. Pero el RTT es un valor dinámico, el cual cambia en el tiempo. Un valor excesivamente bajo va a causar reenvíos prematuros absolutamente innecesarios. Pero un valor demasiado alto hace que sea muy costoso recuperarse ante una pérdida. Redes de Computadoras - Mg. A. G. Stankevicius

11 Estimación del RTT ¿Cómo se puede estimar el valor del RTT?
Cada vez que se recibe un ACK como respuesta a un mensaje enviado previamente se puede obtener una nueva estimación del RTT. Es conveniente no hacer uso de las retransmisiones a la hora de estimar el RTT. ¿Por qué será? La estimaciones obtenidas posiblemente oscilarán a lo largo del tiempo, por lo que hace falta concebir algún mecanismo que permita sopesar múltiples estimaciones. Redes de Computadoras - Mg. A. G. Stankevicius

12 TCP RTT Para obtener una estimación adecuada del RTT se hace uso del alisado exponencial EMA (Exponentially- weighed Moving Average). EMA prioriza la última medición del RTT y penaliza cada vez mas a las mediciones anteriores de forma exponencial. Un valor usual para α es RTT-estimado = (1 - α) × RTT-estimado + α × RTT-observado Redes de Computadoras - Mg. A. G. Stankevicius

13 RTT observado vs. estimado
Redes de Computadoras - Mg. A. G. Stankevicius

14 TCP timeout Una vez obtenida la estimación del RTT es posible elegir un valor adecuado de timeout. Al valor estimado de RTT se le debe incorporar un margen de seguridad adicional. Ante grandes cambios en el valor estimado, el margen de seguridad debería incrementarse. Un valor usual para β es 0.25. desvmed-RTT = (1 - b) × desvmed-RTT + b × | RTT-observado – RTT-estimado | TCP-timeout = RTT-estimado + 4 × desvmed-RTT Redes de Computadoras - Mg. A. G. Stankevicius

15 Transmisión confiable
TCP implementa un canal de comunicación confiable por encima del canal no confiable provisto por la capa de red. Hace uso de las técnicas exploradas en la familia de protocolos RDT y de los protocolos GBN y SR. Usa un único temporizador para controlar las retransmisiones producto de las pérdidas. También se disparan retransmisiones al recibir mensajes de ACK duplicados. Redes de Computadoras - Mg. A. G. Stankevicius

16 Emisor TCP (simplificado)
Al recibir nuevos datos de la aplicación: Crea un segmento con el número de secuencia que corresponda (esto es, el desplazamiento del primer byte a ser transmitido a través del flujo de bytes). Programar el temporizador, en caso de no estar ya corriendo, usando el TCP-timeout antes calculado. Al dispararse la alarma de temporizado: Retransmitir el segmento que expiró. Reprogramar el temporizador. Redes de Computadoras - Mg. A. G. Stankevicius

17 Emisor TCP (simplificado)
Al recibir un mensaje de ACK: Si se trata de un mensaje de ACK asociado a un segmento para el cual se estaba esperado confirmación, marcar el segmento como confirmado y reiniciar el temporizador sólo en caso de contar con otros segmentos para los cuales se está aún esperando confirmación. Por el momento asumiremos como simplificación que no se reciben mensajes de ACK por duplicado. También ignoraremos el control de flujo y la gestión de las congestiones (por ahora). Redes de Computadoras - Mg. A. G. Stankevicius

18 Emisor TCP (simplificado)
“datos” recibidos de la aplicación “segmento TCP” = empaq(proxnumsec, “datos”, checksum); enviar(“segmento TCP”); proxnumsec = proxnumsec + largo(“datos”); if (!“alarma puesta”) poner(alarma);  proxnumsec = primernumsec base = primernumsec a la espera de un evento disparo(alarma) reenviar el segmento aún- no reconocido con menor- nro. de sec.; poner(alarma); mensaje de ACK recibido con nro. de ACK x if (x > base) base = x; if (“quedan segmentos- no reconocidos”) poner(alarma); Redes de Computadoras - Mg. A. G. Stankevicius

22 Ajuste fino del temporizador
La pérdida de segmentos se debe usualmente a la congestión en alguno de los routers del núcleo de la red. Al producirse la retransmisión de un segmento a consecuencia del disparo del temporizador debemos tener esto en consideración: Al volver a programar el temporizador a consecuencia de la retransmisión se debe duplicar su duración. Es decir, se dejará momentáneamente de lado el mecanismo de estimación basado en el RTT. Redes de Computadoras - Mg. A. G. Stankevicius

23 Generación de confirmaciones
Al llegar un segmento en orden, esto es, con el número de secuencia esperado, y además si ya se han confirmado todos los bytes anteriores del flujo de bytes: Este caso se conoce como “confirmación demorada” (delayed ACK), pues se debe esperar hasta 500ms para ver si se reciben más segmentos. De no aparecer segmento alguno, se envía la confirmación al acabarse el tiempo de espera. Redes de Computadoras - Mg. A. G. Stankevicius

24 Generación de confirmaciones
Al llegar un segmento en orden, esto es, con el número de secuencia esperado, pero con la salvedad de que el último segmento aún no fue confirmado: Enviar inmediatamente un único mensaje confirmando cumulativamente ambos segmentos. Este caso se produce al llegar un segundo segmento mientras que con un segmento anterior se estaba ensayando una confirmación demorada. Redes de Computadoras - Mg. A. G. Stankevicius

25 Generación de confirmaciones
Al llegar un segmento fuera de orden el cual genera un hueco (faltan bytes en el medio): Enviar inmediatamente un mensaje de confirmación duplicado indicando el número de secuencia del primer byte faltante. Al llegar un segmento fuera de orden el cual completa parcial o totalmente el comienzo de un hueco anterior: Enviar inmediatamente un mensaje de confirmación para la parte cubierta del hueco. Redes de Computadoras - Mg. A. G. Stankevicius

26 Retransmisión anticipada
Esperar hasta que se dispare la alarma asociada a un segmento implica tener que esperar una gran cantidad de tiempo. El emisor podría darse cuenta de que se produjo algún inconveniente al detectar la recepción de confirmaciones duplicadas. El emisor suele enviar múltiples segmentos uno tras otro (mientras la ventana lo permita). Al perderse un segmento llegarán múltiples mensajes de confirmación para el último segmento recibido. Redes de Computadoras - Mg. A. G. Stankevicius

27 Retransmisión anticipada
El emisor al observar tres mensajes de confirmación repetidos puede asumir que el segmento con ese número de secuencia se malogró. La técnica de retransmisión anticipada (fast retransmit) consiste en retransmitir un cierto segmento antes de que se dispare la alarma del temporizador. Redes de Computadoras - Mg. A. G. Stankevicius

29 Control de flujo en TCP El protocolo TCP estipula que el receptor cuente con un almacenamiento intermedio para alojar los segmentos que van llegando. La aplicación puede tomarse su tiempo en consumir los segmentos que van llegando. El control de flujo consiste en asegurar que el emisor no sature el almacenamiento intermedio del receptor. bufrecep buffer libre buffer ocupado datos de abajo datos hacia arriba ventrecep Redes de Computadoras - Mg. A. G. Stankevicius

30 Control de flujo en TCP El receptor publicita el valor actual de la ventana de recepción ventrecep. En una implementación que descarte los segmentos recibidos fuera de orden el buffer libre se estima como bufrecep – [ultbyterecep – ultbyteent]. El emisor limita la cantidad de paquetes enviados aún no reconocidos a ese valor. De esta forma se asegura que nunca saturará al buffer del receptor. Redes de Computadoras - Mg. A. G. Stankevicius

31 Gestión de conexiones en TCP
Recordemos que TCP previo al comienzo del intercambio de segmentos debe establecer la conexión entre las partes involucradas. Durante esta fase las partes acuerdan de forma mutua conectarse y deben inicializar las distintas variables TCP tales como: Número de secuencia inicial (base, proxnumsec). Almacenamientos intermedios (bufrecep). Tamaño de la ventana de recepción (ventrecep). Redes de Computadoras - Mg. A. G. Stankevicius

37 Saludo de tres fases closed listen estab. SYN rcvd SYN sent
ServerSocket = socket(AF_INET,SOCK_STREAM) serverSocket.bind((ip,port)) serverSocket.listen(1) l ClientSocket = socket(AF_INET,SOCK_STREAM) clientSocket.connect((ip,port)) SYN(n.sec=x) SYN(x) SYNACK(n.sec=y,n.ack=x+1) se crea un nuevo socket para comunicarse con ese cliente ACK(n.ack=y+1) l SYNACK(n.sec=y,n.ack=x+1) ACK(n.ack=y+1) Redes de Computadoras - Mg. A. G. Stankevicius

40 el cliente inicia una conexión
Síntesis (cliente) el cliente inicia una conexión TCP con el envío del SYN espera de 30 segundos closed SYN sent established time wait FIN wait 2 FIN wait 1 recep. del FIN y envío del ACK recep. del SYN/ACK y envío del ACK recep. del ACK (no contesta nada) el cliente comienza a cerrar la conexión TCP con el envío del FIN Redes de Computadoras - Mg. A. G. Stankevicius

41 Síntesis (servidor) recep. del ACK (no contesta nada)
el servidor crea un socket en modalidad de escucha closed listen SYN received last ACK close wait established recep. del SYN y envío del SYN/ACK envío del FIN recep. del FIN y envío del ACK recep. del ACK (no contesta nada) Redes de Computadoras - Mg. A. G. Stankevicius

42 Control de congestión La congestión se produce cuando los nodos envían tal cantidad de información que el núcleo de la red no alcanza a procesar. No confundir con el control de flujo. ¿Cómo se manifiesta la congestión en la red? Por la pérdida de paquetes producto de la saturación del almacenamiento intermedio de los routers. Por el incremento en los retardos producto del aumento del tiempo de encolado en los routers. Redes de Computadoras - Mg. A. G. Stankevicius

43 Control de congestión Se trata de un problema igual de desafiante que el trasporte confiable de información. En la década de '80, antes de que sea tenido en cuenta, el núcleo de internet colapsó. Los administradores reseteaban el HW y la red volvía a funcionar sólo por un par de horas. ¿Se entiende la magnitud del problema? ¡¡¡Reseteaban internet!!! Redes de Computadoras - Mg. A. G. Stankevicius

44 Control de congestión Antes de abordar cómo evitar la congestión nos concentraremos en entender cuáles son las causas de la congestión y cuáles son sus consecuencias. La idea es partir de un escenario simplificado, más directo de analizar, para luego ir considerando situaciones más realistas. Esto es, seguiremos un acercamiento análogo al adoptado para presentar los desafíos asociados a la transmisión confiable de datos. Redes de Computadoras - Mg. A. G. Stankevicius

45 Congestión con buffer infinito
Como primer escenario consideremos la siguiente situación: Dos emisores y dos receptores. Un único router que los comunica. El router cuenta con un almacenamiento intermedio infinito. Al contar con un buffer infinito, los paquetes no se pierden, por lo que tampoco se debe retransmitir paquete alguno. Redes de Computadoras - Mg. A. G. Stankevicius

47 Congestión con buffer finito
Consideremos ahora un escenario análogo al anterior, pero con el router contando con una cantidad finita de almacenamiento intermedio. La eventual pérdida de paquetes ahora causa la retransmisión de los mismo. Idealmente queremos que in = out. Una retransmisión “perfecta” es producto únicamente de las pérdidas de paquetes. Por otra parte, las retransmisiones de paquetes demorados incrementan la tasa real 'in. Redes de Computadoras - Mg. A. G. Stankevicius

49 Costos de la congestión
Primer escenario: el emisor sólo envía al tener la certeza de que hay lugar en el buffer. No se producirán pérdidas de paquetes. Por ende, in = 'in. in = 'in out R/2 Redes de Computadoras - Mg. A. G. Stankevicius

50 Costos de la congestión
Segundo escenario: el emisor sólo reenvía al tener la certeza de que se produjo una pérdida. Ocasionalmente se puede producir una pérdida al saturarse el buffer del router. El emisor sólo reenvía los paquetes que conoce que se han perdido (esto es algo imposible de determinar a ciencia cierta). 'in out incluso al producirse retransmisiones logra aproximarse asintóticamente a R/2 R/2 R/2 Redes de Computadoras - Mg. A. G. Stankevicius

51 Costos de la congestión
Tercer escenario: al igual que antes, pero ahora se contempla que el emisor envíe duplicados. Ocasionalmente se puede producir una pérdida al saturarse el buffer del router. El disparo anticipado de un temporizador provoca la retransmisión innecesaria de paquetes. 'in out parte del ancho de banda disponible es desperdiciado en las retransmisiones R/2 R/2 Redes de Computadoras - Mg. A. G. Stankevicius

52 Costos de la congestión
La congestión genera dos costos ocultos: Para un mismo nivel de datos recibidos se debe enviar un nivel mayor de datos debido a las retransmisiones. Las retransmisiones producto de los retrasos malgastan ancho de banda en los enlaces. 'in out R/2 Redes de Computadoras - Mg. A. G. Stankevicius

54 Situación más realista
Consideremos ahora un escenario con múltiples emisores y receptores y con múltiples enlaces con almacenamiento intermedio finito. Al producirse una pérdida todo el ancho de banda invertido en mover ese paquete a través de los routers previos termina siendo malgastado. 'in out R/n Redes de Computadoras - Mg. A. G. Stankevicius

55 Detección de la congestión
Control de congestión punta-a-punta (TCP). La red no brinda información acerca de que sucede en el núcleo de la red. La congestión se detecta al observar pérdidas de paquetes en el origen o el destino. Control de congestión asistida por la red (ATM). Los routers informan a las computadoras en la frontera de la red acerca de las congestiones. Usando banderas (por caso, el campo ECN de IP), o imponiendo la cadencia de envío a ser usada. Redes de Computadoras - Mg. A. G. Stankevicius

56 Control de congestión en ATM
ATM introduce los conceptos de ancho de banda disponible y de ancho de banda garantizado para gestionar congestiones. Si en una cierta conexión se detecta que queda capacidad para ser utilizada, el emisor es invitado a hacer uso de ella. En contraste, al detectarse una congestión el emisor se debe limitar a enviar datos sin superar el ancho de banda garantizado. Redes de Computadoras - Mg. A. G. Stankevicius

57 Control de congestión en ATM
Para implementar este comportamiento se entremezclan celdas especiales llamadas RM (Resource Management) con celdas de datos. Los bits de las celdas RM son modificados por los routers. El bit NI indica que se debe mantener la cadencia de envío, pues se detectó una congestión leve. El bit CI indica la detección de una congestión. El receptor rebota hacia el emisor las celdas RM que vaya recibiendo. Redes de Computadoras - Mg. A. G. Stankevicius

59 Control de congestión en TCP
A diferencia de ATM, TCP adopta un esquema de control de congestión punta-a-punta. Por ende no recibe asistencia del núcleo de la red. El emisor limita su tasa de transmisión respetando la siguiente relación: [ultbyterec - ultbyteent] < ventcong. El tamaño de la ventana es dinámico, depende del nivel de congestión en la red percibido por el emisor. ult. byte reconocido enviados pero no reconocidos ult. byte enviado ventana de congestión Redes de Computadoras - Mg. A. G. Stankevicius

60 Control de congestión en TCP
¿Cómo hace el emisor para percibir el nivel de congestión en la red? Tomando nota de los eventos de pérdida. Se produce un evento de pérdida toda vez se vence el tiempo de espera TCP o bien cuando se reciben cuatro ACK para el mismo segmento TCP. El emisor responde ante un evento de pérdida reduciendo su ventana de congestión. Se han implementado diversas políticas que mejoran la respuesta de este mecanismo. Redes de Computadoras - Mg. A. G. Stankevicius

61 TCP AIMD TCP adopta la política AIMD (Additive Increase Multiplicative Decrease) para controlar el tamaño de la ventana de congestión. El emisor incrementa de manera lineal su ventana de congestión a cada RTT, pero ante un evento de pérdida se reduce exponencialmente a la mitad. R por prueba y error se intenta determinar el ancho de banda a disposición Redes de Computadoras - Mg. A. G. Stankevicius

62 TCP slow start Al comenzar, la política AIMD puede tomar un tiempo excesivo en alcanzar el régimen óptimo. Consideremos el siguiente ejemplo: RTT = 200ms y MSS = 500 bytes. Inicialmente ventcong = 1, pero MSS/RTT = 20 Kbps. Si se dispone de un mayor ancho de banda, TCP va a tardar bastante tiempo hasta hacer uso del mismo. La política slow start indica que al comenzar se debe agrandar exponencialmente la ventana de congestión hasta que se detecte el primer evento de pérdida. Redes de Computadoras - Mg. A. G. Stankevicius

64 Ajuste fino TCP implementa un ajuste sutil en función de cómo es que se detectó la congestión. Si se vence el tiempo de espera TCP: ventcong se reduce a 1. de ahí crece exponencialmente hasta alcanzar un determinado umbral para luego crecer linealmente. Ante tres ACK duplicados para un segmento: ventcong se reduce a la mitad. de ahí crece linealmente como siempre. Redes de Computadoras - Mg. A. G. Stankevicius

65 Ajuste del umbral ¿Cómo determinar el valor más apropiado para el umbral que altera el ritmo de crecimiento de la ventana de congestión? El umbral tiene que depender del nivel de congestión actual. Un posibilidad es usar el valor de ventcong antes del evento de pérdida como guía. A tal efecto, cuando la nueva ventana de congestión alcance la mitad del valor que tenía antes se deberá cambiar de un crecimiento exponencial a uno lineal. Redes de Computadoras - Mg. A. G. Stankevicius

66 TCP Reno vs. TCP Tahoe Los distintos ajustes finos al mecanismo de gestión de la congestión dieron a lugar a diferentes implementaciones. TCP Reno implementa el ajuste fino antes visto. En contraste, TCP Tahoe dictamina que en los dos casos la ventana de congestión debe reducirse a 1. Estos llamativos nombres de las versiones de TCP se corresponden con las versiones BSD en las que se implementaron por primera vez. Redes de Computadoras - Mg. A. G. Stankevicius

67 TCP Reno vs. TCP Tahoe Redes de Computadoras - Mg. A. G. Stankevicius

68 En síntesis Mientras ventcong <= umbral, el emisor está en la fase “slow start”, por lo que la ventana debe crecer exponencialmente. Cuando ventcong > umbral, el emisor entra en la fase de “evasión de congestión”, por lo que ahora la ventana crece linealmente. Si se reciben tres ACK repetidos, tanto umbral como ventcong se ajustan a ventcong/2. Al vencerse el tiempo de espera TCP, se hace umbral = ventcong/2 y luego ventcong = 1. Redes de Computadoras - Mg. A. G. Stankevicius

69 Control de congestión en TCP
umbral = 64KB ventcong = 1 MSS dupACKcont = 0 ACK duplicado dupACKcont++ ACK nuevo ventcong += MSS*(MSS/ventcong) dupACKcont = 0 transmito nuevos segmentos (mientras se pueda) ACK duplicado dupACKcont++ disparo umbral = ventcong/2 ventcong = 1 dupACKcont = 0 retransmito el segmento slow start congest. avoid. fast recovery ACK nuevo ventcong += MSS dupACKcont = 0 transmito nuevos segmentos (mientras se pueda) ventcong ≥ umbral l dupACKcont == 3 umbral = ventcong/2 ventcong = umbral + 3 retransmito el segmento disparo umbral = ventcong/2 ventcong = 1 dupACKcont = 0 retransmito el segmento ACK nuevo ventcong = umbral dupACKcont = 0 disparo umbral = ventcong/2 ventcong = 1 dupACKcont = 0 retransmito el segmento ACK duplicado ventcong += MSS transmito nuevos segmentos (mientras se pueda) Redes de Computadoras - Mg. A. G. Stankevicius

70 Desempeño de TCP ¿Cuál será el desempeño de TCP en función de ventcong y del RTT actual? Sea W el tamaño de la ventana en el momento que se produce una pérdida. Cuando ventcong es W el desempeño es W / RTT. Acto seguido, el tamaño de ventana se restringe a W / 2, por lo que el desempeño cae W / 2RTT. Por lo tanto, el desempeño promedio es ¾W / RTT. ¡El RTT está fuertemente vinculado al desempeño! Redes de Computadoras - Mg. A. G. Stankevicius

71 Futuro de TCP El comportamiento de TCP sobre enlaces de alto desempeño no es del todo satisfactorio. Un enlace de alto desempeño obliga a contar con una ventana de transmisión más grande a fin de mantener ocupado el enlace. Con las tecnologías actuales es posible alcanzar el máximo tamaño de ventana permitido. Algo análogo sucede en los enlaces con altos RTTs. Otro inconveniente hoy en día es que es posible agotar los números de secuencia disponibles. Redes de Computadoras - Mg. A. G. Stankevicius

72 Futuro de TCP La RFC 1323 postula dos mecanismos para atender estos cuestionamientos: La ventana de congestión pasa a representarse con un entero de 32 bits, codificando este valor en los 16 disponibles a través de un factor de escalamiento. Para evitar que nuevo segmentos se consideren retransmisiones de segmentos anteriores, el tamaño práctico de la ventana se acota a 1 GB. El agotamiento de los números de secuencia se soluciona permitiendo que se repitan. Redes de Computadoras - Mg. A. G. Stankevicius

74 Equidad TCP Imaginemos que dos sesiones TCP compiten por hacer uso de la totalidad del ancho de banda de un determinado enlace. El incremento lineal de la ventana de congestión hace que ambas sesiones vayan consumiendo partes equitativas de ese ancho de banda. El retroceso exponencial que se produce ante los eventos de pérdida también se dispara en ambas sesiones. Por ende, se converge hacia un uso equitativo del enlace entre las sesiones. Redes de Computadoras - Mg. A. G. Stankevicius

75 Equidad TCP vs. UDP Las aplicaciones multimediales suelen no hacer uso de TCP. Precisamente, el control de congestión lejos de ser una virtud sería un inconveniente. No es deseable que la ventana de transmisión ni la de congestión detengan el flujo de datos. Por esta razón, las aplicaciones multimediales suelen hacer uso de UDP. Envían datos a un ritmo constante, tolerando la eventual pérdida de algún paquete. Redes de Computadoras - Mg. A. G. Stankevicius

76 Conexiones TCP paraleralas
¿Cómo interactúa la equidad TCP con el establecimiento de conexiones en paralelo? Nada impide que una misma aplicación abra una cantidad de conexiones en paralelo. Por caso, supongamos que un enlace de capacidad R está soportando 9 conexiones. Si una cierta aplicación abre una nueva conexión, recibirá apenas R / 10 del canal. Si más tarde otra aplicación abre 10 nuevas conexiones, recibirá en cambio R / 2 del canal. Redes de Computadoras - Mg. A. G. Stankevicius

77 ¿Preguntas? Redes de Computadoras - Mg. A. G. Stankevicius