TCP para alta velocidade

Desempenho do TCP
Necessita de rwnd (janela de recepção) = PDB, para manter a rota
cheia
Janela ideal de transmissão (cwnd) = 2 PDB, para permitir recuperar
de erros e manter a taxa máxima
– Recuperação em TCP leva pelo menos um RTT
Taxa = min(cwnd,rwnd)/RTT
Buffer default em TCP = 216 Bytes = 64 kB
– 64 kB, RTT = 200ms => 2,5 Mbps Baixo!
Negociar fator de escala para estender os valores da janela rwnd
para a mesma ordem de grandeza do PDB usando 32 bits
RFC 7323 - TCP Extensions for High-Performance (set/2014)
Long fat pipe (LFN) – PDB > 105 bits
Cabeçalho TCP
Options
Opções do TCP
Negociadas na abertura da conexão
Fator de escala da janela previamente determinado e
negociado durante a abertura da conexão
– No máximo, shift de 14 posições permitido, levando a janela
de 1 Gbytes (230) (2 x janela tem que ser menor que 231,
para que segmentos não sejam descartados por idade)
Opção de uso de timestamp no SYN
– Interpretado como uma extensão superior dos 32 bits de
sequenciamento de pacote
– Usado tanto em dado como em ACK, nas duas direções
Ajuste do TCP para desempenho
TCP tunning guide
– http://fasterdata.es.net/TCP-tuning/
Tamanho de buffers nos sockets de tx e rx
– Kernel força um tamanho máximo de buffer
– Se buffer de recepção é grande demais e controle de fluxo
se perde, transmissor pode inundar o receptor, causando
rwnd = 0 e interrupção da transmisssão
– Janelas grandes em excesso no transmissor não causam
problemas, desde que haja memória para suprir alocação
Linux, FreeBSD, Windows, e OSX todos suportam
auto ajuste do TCP
Ferramentas de Medição
http://fasterdata.es.net/TCP-tuning/tools.html
Iperf : nice tool for measuring end-to-end TCP/UDP
performance
pathrate/pathload : tools to measure available bandwidth and
capacity
pipechar: hop-by-hop bottleneck analysis tool
UDPmon: Network performance measurement tool
synack: ping replacement for sites that block ping
Some useful Network Testing Tools
NDT: Web100 based Network Configuration Tester
tcpdump: dump all TCP header information for a specified
source/destination
tcptrace: format tcpdump output for analysis using xplot
TCP em redes de PDB alto
Múltiplas perdas em janelas longas -> perda de desempenho
Número de sequência do TCP de 32 bits pode estourar
enquanto pacotes ainda estão na rede, causando recebimento
errôneo de duplicatas
MSL (maximum segment life) = TTL do pacote IP pode não ser
suficiente para garantir vida “curta” na rede
– 2**31 / C (bytes/s) > MSL (segundos), para operação sem
erro
1,5 Mbps
→ 104 s (~ 3h)
10 Mbps
100 Mbps
1 Gbps
→ 1700 s (~ 30 min)
→ 170 s (~ 2 min)
→ 17 s
– Alta velocidade é o problema neste caso
Estimativa de RTT ruim, amostrando apenas um pacote por
janela em janelas grandes, necessita de novos métodos
– RTTM (Round-Trip Time Measurement) – usa timestamp no campo de
opções
Estouro de sequenciamento
PAWS (PROTECT AGAINST WRAPPED
SEQUENCE NUMBERS)
Idéia geral: Descartar pacote como duplicata se
timestamp é inferior a algum valor recebido
recentemente na conexão
– Com timestamp incrementado a cada 1 ms, 32 bits
estouram em 24,8 dias, detetando duplicatas com tempo de
vida inferior a este valor
– Pode ser aplicado a outros segmentos TCP como SYN e
SYNACK para detetar duplicatas
Futuro do TCP: TCP sobre
pipes “longos, gordos”
Cenário
– Segmentos de 1500 bytes, RTT = 100 ms
– Vazão desejada de 10 Gbps
– PDB = 1 Gbps, exigindo janela W = 83.333 segmentos no
transmissor (na realidade no TCP maior para se obter a taxa
média desejada)
Para obter 10 Gbps médio implica em ter uma taxa
de perda de L = 2 · 10-10 Uau!
– Perda de apenas 1 pacote a cada 5 x 109 pacotes ou
equivalente, uma perda a cada 1h 40min! IRREAL!
Novas versões do TCP para alta velocidade, pois
simplesmente aumentar as janelas não é suficiente
TCP para alta velocidade
Problema central: TCP incrementa sua taxa
devagar (linear) e decrementa rápido
(exponencial) frente a perdas
Uma solução: subir mais rápido e descer
mais lento
TCP para alta velocidade
HS-TCP (Sally Floyd)
– RFC 3649: HighSpeed TCP for Large Congestion Windows.
Experimental,2003.
– RFC 3742: Limited Slow-Start for TCP with Large
Congestion Windows. Experimental, 2004.
Scalable TCP (cambridge)
Fast TCP (caltech)
BIC/CUBIC (NCSU)
Layered TCP (LTC)
Hamilton TCP (HTCP)
...
A maioria altera o envio do TCP
O que é HS-TCP (High Speed TCP)
Semelhante a TCP padrão quando cwnd é baixo
Mais agressivo que TCP padrão quando cwnd é alto
– Usa uma ação de resposta modificada
Consegue trabalhar com janelas grandes, mas com
taxa de perda menor que TCP normal
High Speed TCP se comporta em janelas maiores
como um agregado de N conexões TCP
HS-TCP (atinge W com menor L)
L (perda)
W
RTTs entre perdas
10-2
12
8
10-3
38
25
10-4
263
38
10-5
1795
57
10-6
12279
83
10-7
83291
123
10-8
574356
180
10-9
3928088
264
10-10
268646653
388
HS-TCP emulando N conexões TCP
Em janelas grandes, HS-TCP se comporta como um agregado
de N conexões TCP
N conexões paralelas têm uma vazão agregada de
N .1,22 ⋅ MSS /( RTT L )
Número de conexões equivalentes em função de W
N (W ) = 0, 23W 0,4
W
N(W)
1
1
10
1
100
1,4
1.000
3,6
10.000
9,2
100.000
23
HS-TCP (vermelho) versus TCP
(verde)
Fonte: artigo de sally floyd
HS-TCP em ambiente de descarte no
fim da fila (drop-tail)
Drop-tail (FIFO)
– Pacote descartado quando o buffer fixo se esgota
Gerência ativa de fila
– Pacote descartado antes do buffer esgotar
E.g. RED, onde tamanho médio da fila é monitorado
Em ambiente FIFO
– Assuma que TCP aumenta sua taxa para (P pacotes)/RTT
– Então P pacotes irão possivelmente ser descartados
durante evento de congestionamento grave na conexão
Equidade com TCP: RED
Eixo vertical: % de utilização do enlace
– Vermelho (5 sessões HS-TCP); verde (5 sessões TCP)
Equidade com TCP: FIFO
Eixo vertical: % de utilização do enlace
– Vermelho (N/2 sessões HS-TCP); verde (N/2 sessões TCP)
HS-TCP requer Slow-Start Limitado
Slow-start até atingir uma janela de 83.000 pacotes
não funciona bem
– Dezenas de milhares de pacotes descartados de uma única
janela de dados força timeout e retorno a slow start com
valor baixo de threshold
– Recuperação lenta da conexão TCP
Alteração do mecanismo de Slow-Start
– Limita a rajada durante o aumento exponencial da janela
– Crescimento da janela limitado a no máximo N (parâmetro)
pacotes por RTT
Slow-Start Limitado
Outras alterações
Precaução contra reordenamento de pacotes
– Esperar mais de 3 ACKs duplicados antes de
retransmitir
Recuperar de forma mais suave quando um
pacote retransmitido é perdido
Outras questões
Iniciar com janelas CWND já grandes?
Fazer uso de banda imediatamente
disponível?
Quick-Start
Especifica no campo de opção IP do pacote SYN a
taxa desejada de transmissão
– Roteadores intermediários decrementam contador TTL e
podem decrementar o valor da taxa inicial desejada se
necessário
O receptor da conexão retorna informação no
ACKSYN
–
–
–
–
Emissor sabe se todos os roteadores participaram
Emissor tem uma medida do RTT
Emissor pode ajustar a janela inicial cwnd
TCP do emissor continua com operação padrão (incremento
linear e decremento multiplicativo)
Opção Quick-Start
Retorno necessário de todos os roteadores ao longo
da rota
Opção apenas aprovada pelos roteadores que estão
subutilizados
Nenhum estado por fluxo mantido no roteador
Questões
Vale a pena a complexidade?
Mecanismo suficiente em diferentes
topologias e diferentes condições de tráfego?
Necessidade premente?
Na realidade não
– Abrir N conexões simultâneas
– Usar MulTCP (agregado de N conexões virtuais)
Contudo, pode-se fazer melhor com um TCP
apropriado para alta velocidade
– Melhor flexibilidade (sem ter que configurar N)
– Melhor escalabilidade (com variedade de banda e de fluxos)
– Competir mais equitativamente com TCP existente (para
cenários onde TCP pode obter a banda disponível)
Internet2 Land Speed Record
http://www.internet2.edu/lsr/
IPv4
– 264,147 terabit-meters per second by a team consisting of
members from the University of Tokyo, the WIDE project, and
Chelsio Communication and other organizations by sending 2.98
terabytes of data across 30,000 kilometers of network over 45
minutes at an average rate of 8.80 gigabits per second.
IPv6
– 272,400 terabit-meters per second by a team consisting of
members from the University of Tokyo, the WIDE Project, NTT
Communications, and others accomplished by transferring 20.42
terabytes of data across 30,000 kilometers of network in about 300
minutes at an average rate of 9.08 gigabits per second.
Referências para TCP
Stevens, W. Richard, TCP/IP Illustrated, Volume 1 The Protocols, AddisonWesley, 1994
RFC-793, Transmission Control Protocol, 1981
RFC-1323, RCP Extensions for High Performance, 1992
RFC-2001, TCP Slow Start, Congestion Avoidance, Fast Retransmit, and Fast
Recovery Algorithms, 1997
RFC-2018, TCP Selective Acknowledgement Options,1996
RFC-2581, TCP Congestion Control, 1999
RFC-3168, The Addition of Explicit Congestion Notification (ECN) to IP, 2001
RFC-3360, Inappropriate TCP Resets Considered Harmful, 2002
RFC-3390, Increasing TCP's Initial Window, 2002
RFC-3449, TCP Performance Implications of Network Path Asymmetry, 2002
RFC-3481, TCP over Second (2.5G) and Third (3G) Generation Wireless
Networks, 2003
RFC-3649, High Speed TCP for Large Congestion Windows, 2003
RFC-3782, The NewReno Modification to TCP’s Fast Recovery Algorithm, 2004
Alto Desempenho
Ter um backbone de alta velocidade apenas não é garantia de
desempenho
Internet se tornou a rede global e convergência de tráfego para
IP vai demandar mais capacitação dos gerentes de rede e
melhoria em resposta a falhas e atualizações
Nos enlaces de menor velocidade, que são os que realmente
serão restritivos da vazão, QoS pode ser necessário
Sincronização de fluxos multimídia pode causar perdas e
atrasos em picos de demanda, mesmo em enlaces de maior
velocidade (instantâneo versus média)
Como disponibilizar rede de alto
desempenho?
Melhorar a taxa de acesso ao ISP
– Frame Relay, ATM, SDH/SONET
– Ethernet Metropolitano
– Redes sem fio de alta performance
Melhorar a performance do backbone
– ATM, SDH/SONET
– Multiplexação em fibra ótica (CWDM, DWDM)
Melhorar a performance do backbone IP
– MPLS
– Integração MPLS e Ethernet Metropolitano
Como transportar IP?