teo 07: L4: Performance en TCP

Question 1

¿Cuál es el objetivo de SS? (slow start)

Answer 1

+ Alcanzar el punto de funcionamiento lo antes posible

+ Antes: La menor cantidad de rounds (RTT) posibles

Question 2

• ¿Cuál es el valor máximo de IW? ¿Puede ser infinito?
• ¿Cuál es el problema si IW muy grande? ¿y si es muy chica?
• ¿Cuál es el valor usado en las implementaciones de TCP?

Answer 2

+ El valor de IW depende de la capacidad de los enlaces
+ moda(MSS) ~ 1500B
+ moda(BW_enlaces)&raquo_space; 1 MSS / RTT

Limite superior
+ Si IW muy grande induce congestión (en la primera ráfaga)

Question 3

Que IW se usa ahora? Se uso siempre el mismo?

Answer 3

Evolución histórica

• RFC2001 (1988) —> IW=1
• RFC2414 (1998) —> IW=2
• RFC3390 (2002) —> IW=4
• RFC6928 (2010) —> IW=10

¿Por qué IW=10?
+ Tamaño colas en routers (se verá más adelante)
+ Más de 10 puede congestionar y perderse en la primer ráfaga
+ IW > 3 —> Fast Recovery si hay pérdidas en la primera ráfaga

Question 4

Que conclusion se puede sacar a partir de lo publicado por Mathis et al?

Answer 4

En CA + Fast recovery (RENO) el throughput depende unicamente de la latencia (los otros parametros son fijos).

Entonces, la latencia sera siempre un parametro a minimizar.

Question 5

Delayed ack. Para que sirve?

Answer 5

Delayed ACK (RFC1122)
\+ ACK (cuando corresponde) no se envía inmediatamente
\+ ¿Cuánto se espera?
  - En la RFC1122: máx = 500ms
  - En la práctica: máx = 200ms
  - Hasta el arribo del segundo segmento de tamaño MSS

Question 6

Pros, contras y neutros de delayed ack.

Answer 6

Pros
• Menor cantidad de ACKs generados por dst
• Menor cantidad de ACKs enviados a la red

Neutro
• Como ACK acumulativo no afecta confiabilidad

Contras
• Si tiempo para enviar ACK muy prolongando, afectará estimación de RTT en src
• Disminución de señales de pérdida de segmentos fast reTx (RFC5827)

Question 7

Selective ack (SACK).

• para que se usa (pros)
• contras
• implementacion

Answer 7

Problema
> Con delayed ack, no tenemos tantos acks duplicados, por lo que es mas probable que haya que esperar a rto para darse cuenta que algo anda mal.

Solución
> Añadir Selective Repeat (SR) usando Opciones de TCP (RFC2018)

Implementación
> Permitir el uso de SACK el momento del SYN
> Enviar en las opciones los segmentos faltantes

Problemas de SACK TCP
> Vulnerabilidad SACK PANIC

Question 8

A que se les llama Elefantes? (Long fat pipes)

Answer 8

LFN son aquellas conexiones de alto BW · RT T

Ejemplo de LFN (RFC3649)
RTT = 100ms
M SS = 1500B
BW = 10Gbps
BW · RT T = 83.333 segmentos = 12.500.000B

Question 9

Limitaciones de TCP en LFN

Answer 9

1. Máxima cantidad de bytes en vuelo por rwnd

2. Bajo throughput de Reno en LFT

Question 10

Limitaciones de TCP en LFN: Máxima cantidad de bytes en vuelo por rwnd

Answer 10

+ rwnd 16 bits —> máximo en vuelo: 65536 bytes
+ Notar que en ejemplo anterior ~12MB

Solución: Window scaling
> Junto al SYN se envía el factor de escalamiento (potencias de 2)

Question 11

Conclusiones de TCP en LFN

Answer 11

\+ Reno con baja perfomance
\+ Es necesario usar otros algoritmos, ejemplo
  -> CUBIC,
  -> TCP SACK
  -> etc

Question 12

Google QUIC: ¿Por qué necesitamos un nuevo protocolo de L4?

Answer 12

1. Osificación
   • TCP sumamente desplegado
   • Conservadurismo: No se pueden hacer cambios en TCP
   • Por ejemplo, ¿Podríamos pasar de ACK a NAK? NO!
2. Aceleración del proceso de innovación
   • TCP manejado por el kernel del SO
   • Demora hasta publicación de upgrades del OS kernels
   • Mayor demora aún que los usuarios migren al nuevo kernel

Question 13

Que soluciones trae QUIC?

Answer 13

Solución

• > QUIC a nivel de App (sobre UDP)
• > Updates de por fuera del kernel del SO
• > Update QUIC = Update de Apps con QUIC
• > Mayor velocidad de innovación

Question 14

Que “side fx” trae QUIC?

Answer 14

Otras mejoras de QUIC
1. Lidiar con NATs
> No existían cuando TCP fue ideado!

2. Minimizar tiempo de establecimiento de conexión
   > Agregar autenticación que tampoco existían cuando TCP fue ideado!
3. Reducir HOL Blocking

Question 15

Que propone Google QUIC?

Answer 15

1. Reducción del establecimiento de conexión
2. Cambios en control de congestión
3. Multiplexación
4. Identificador de conexión
5. Loss Recovery

Question 16

Que propone Google QUIC?

Answer 16

1. Reducción del establecimiento de conexión
2. Cambios en control de congestión
3. Multiplexación
4. Identificador de conexión
5. Loss Recovery

Question 17

Que propone Google QUIC?

2. Cambios en control de congestión

Answer 17

TCP
+ Definido en SO
+ Uno solo para todas las App

QUIC
+ Modularizable
+ Cada App puede tener el suyo de acuerdo a sus necesidades

-> Ejemplo:
YouTube usa distintos algs en los stream de video y audio

Question 18

Que propone Google QUIC?

3. Multiplexación

Answer 18

Escenario
• Apps y multiples elementos dentro de una misma conexión
• Por ejemplo, HTTPv1.1 persistente

Problema
• HOL blocking

Solución
• MUX en QUIC: permite que cada elemento tenga su ID

Question 19

Que propone Google QUIC?

3. Multiplexación

Answer 19

Escenario
• Apps y multiples elementos dentro de una misma conexión
• Por ejemplo, HTTPv1.1 persistente

Problema
• HOL blocking

Solución
• MUX en QUIC: permite que cada elemento tenga su ID

Question 20

Que propone Google QUIC?

4. Identificador de conexión

Answer 20

TCP
+ Identificados por la 4-tupla: (src_ip,dst_ip,src_port,dst_port)

QUIC
+ A través de un ID
+ Seleccionado al azar por el cliente
+ Dimensión: 64 bits

Ventaja
> Mitiga reescrituras de NATs

Question 21

Que propone Google QUIC?

5. Loss Recovery

Answer 21

TCP
+ Ambigüedad si segmento nuevo o reTx

QUIC
+ Paquetes llevan dos números de secuencia
- Seq Numb: Ubicación de la data
- Packet Number: Número único de paquete

Ventaja
> Estimación de RTT