Cap. 3 – O nível de transporte

Nota prévia A estrutura da apresentação é semelhante e utiliza algumas das figuras, textos e outros materiais do livro de base do curso James F. Kurose and Keith W. Ross, "Computer Networking - A Top-Down Approach Featuring the Internet,“ Addison Wesley Longman, Inc., 3rd Edition, 2005

Organização do capítulo Serviços do nível transporte Multiplexing / Demultiplexing Estudo do transporte: UDP Como implementar a transferência fiável de dados Transporte orientado conexão: TCP Transferência fiável de dados Controlo de fluxo Gestão da conexão Controlo da saturação Controlo da saturação no protocolo TCP

Papel do nível de transporte É o nível geralmente visível pelas aplicações pelo que é central em toda a arquitectura de protocolos Pode providenciar dois tipos de serviços: orientado à conexão e não orientado conexão ou modo datagrama ou connectionless razões de ser: melhorar a qualidade de serviço oferecida pelo nível rede e mascarar as suas deficiências (erros, perdas, etc.) multiplexing / demultiplexing endereçamento extremo a extremo (end-to-end); exemplo: endereço IP + porta oferecer uma interface adequada às aplicações (exemplo: accept, connect, send, receive, read, write, close, …)

Como se desenrola um protocolo de transporte aplicação transporte rede host aplicação transporte rede host

Mensagem de nível transporte - Segmentos (dados da aplicação) Aplicação (Segmento) Transporte Cabeçalho transporte trans Dados (Pacote) Rede Cabeçalho rede trans Dados Cabeçalho frame (Frame) Data link rede trans Dados

Communication End Points em TCP/IP Um endereço IP identifica um host. Para identificar o ponto de acesso a um serviço ao nível transporte é necessária alguma forma de “desdobramento” dentro do host. Em TCP/IP esse desdobramento faz-se através da noção de porta. Um ponto de terminação da comunicação é designado em TCP/IP por socket. Host processos Endereço IP portas e filas de espera Cada fila de espera corresponde a um socket distinto.

Portas TCP/IP As portas usados em UDP e TCP estão normalizadas em gamas de utilização. Existe uma gama reservada, e outra que pode ser usada para escrever novas aplicações Dentro das gamas reservadas, existem portas fixas associadas a aplicações normalizadas. Exemplos: HTTP funciona em TCP com o servidor httpd associado à porta 80, o smtpd (sendmail por exemplo) na porta 25, etc. Cada servidor que realiza um serviço normalizado tem uma porta fixa associada As portas em UDP e TCP correspondem a filas de mensagens independentes mesmo que usem o mesmo número de porta. Ex: a porta 45 em UDP é diferente da porta 45 em TCP A afectação de números de portas normalizadas está a cargo do IANA (Internet Addressing and Naming Authority) A respectiva tabela está no ficheiro /etc/services

Multiplexing / Demultiplexing Multiplexing and Demultiplexing: determinar qual a fila de espera (e indirectamente o processo) a quem os dados se destinam. Multiplexing and Demultiplexing poderia ser traduzido por agregar / desagregar. receiver P3 P4 application-layer data M M application transport network P1 P2 header M M application transport network application transport network Segmento ou tpdu H t M H n segment Tpdu - Transport Protocolo Data Unit é outra designação de Segmento

Multiplexing / Demultiplexing (continuação) 32 bits Os dados são marcados com a porta origem e destino Os dois pares (porta, endereço IP) identificam inequivocamente a origem e o destino dos dados Também se utilizam os termos segmento TCP, datagrama UDP ou pacote UDP para designar os TPDU TCP e UDP source port # dest port # other header fields application data (message) Formato do segmento

Exemplos com portas TCP Web client host C source port: x dest. port: 23 host A server B source port:23 dest. port: x Source IP: C Dest IP: B source port: y dest. port: 80 Source IP: C Dest IP: B source port: x dest. port: 80 Exemplo: Telnet Source IP: A Dest IP: B source port: x dest. port: 80 Web server B Web client host A Exemplo: Web server

Identificação dos sockets O Socket UDP de um processo, e a respectiva fila de espera, são identificados univocamente pelo endereço IP do processo e pela porta associada ao socket. UDP Socket ID = ( local IP address, local port number) Nota: é possível fazer a associação de um socket UDP local a um socket UPD remoto. O Socket TCP de um processo, e a respectiva fila de espera, são identificados univocamente pelo endereço IP do processo e pela porta associada ao socket, assim como pelo endereço IP remoto e a porta remota. TCP Socket ID = ( local IP address, local port number, remote IP address, remote port number)

O protocolo UDP Nível de serviço do protocolo UDP Serviço “best effort” que só acrescenta multiplexagem e desmultiplexagem ao nível rede. As mensagens UDP (Datagramas UDP) podem ser perdidos ou entregues fora de ordem Ausência de conexão (“connectionless”): não é necessário nenhum estabelecimento de conexão (“handshaking”) entre o emissor e o receptor e cada datagrama é processado independentemente dos outros Vantagens do protocolo UDP Sem necessidade de conexão (o que evita um RTT suplementar e vários pacotes extra) Simples - sem estado do lado do emissor ou do receptor Cabeçalho mais pequeno que o TCP (8 bytes ao invés de 20 bytes) Sem controlo de saturação - os dados podem ser enviados à velocidade que o emissor desejar

Utilizações do protocolo UDP Geralmente utilizado pelas aplicações de “streaming multimedia” Tolerantes à perca de pacotes Sensíveis à velocidade de transmissão Outras utilizações do UDP (pela simplicidade e ausência de necessidade de conexão): DNS SNMP, ... Se for necessária fiabilidade é sempre possível introduzi-la ao nível aplicação

Formato do datagrama UDP Os datagramas UDP 32 bits source port # dest port # Tamanho, em Bytes, do segmento UDP incluindo o cabeçalho length checksum Dados aplicação (mensagem) Formato do datagrama UDP

UDP checksum Objectivo: detectar “erros” (e.g., bits invertidos) nos segmentos transmitidos Emissor: trata o conteúdo do segmento como uma sequência de inteiros de 16 bits checksum: soma (complemento a 1’s) do conteúdo do segmento O valor calculado é colocado no campo respectivo antes da emissão Receptor: calcula o valor do checksum Compara o valor calculado com o valor do campo do datagrama recebido: ≠ — o datagrama tem pelo menos um erro = — não foram detectados erros. O que não quer dizer que estes não possam existir.

Exemplo Nota Quando se somam números em complemento a 1’s, o carryout do bit mais significativo tem de ser adicionado ao resultado Exemplo: com dois inteiros de 16 bits 1 1 1 1 0 0 1 1 0 0 1 1 0 0 1 1 0 1 1 1 0 1 0 1 0 1 0 1 0 1 0 1 0 1 1 1 0 1 1 1 0 1 1 1 0 1 1 1 0 1 1 1 1 0 1 1 1 0 1 1 1 0 1 1 1 1 0 0 1 0 1 0 0 0 1 0 0 0 1 0 0 0 0 1 1 carryout Kurose and Ross forgot to say anything about wrapping the carry and adding it to low order bit soma checksum

Recepção dos datagramas UDP portas udp dados do datagrama ou tpdu udp desmultiplexagem pelas portas Datagrama ou tpdu udp desmultiplexagem udp, tcp, ... datagrama ip desmultiplexagem ip, icmp, arp, ... frame cabeçalho frame cabeçalho ip cabeçalho udp dados utilizador

Compensação dos erros Os níveis inferiores ao nível de transporte podem introduzir erros, sobretudo perca de pacotes e frames Os frames com erros são em geral recusados ao nível data-link pelo que podem ser assimilados a pacotes perdidos Os protocolos de transporte que introduzem fiabilidade têm de mascarar os erros sob pena de violarem a sua especificação Quando um circuito tem uma taxa de erros elevada no nível data-link, também se usam protocolos para mascarar os erros a esse nível para evitar que os mesmos se propaguem para os níveis superiores e que sejam estes que os têm de recuperar Uma aplicação que use UDP pode também ter de realizar, ao nível aplicação, mecanismos de compensação dos erros

Protocolo simplista e irrealista Emissor Receptor Exemplo de um protocolo que pressupõe que não há erros, nem perca de segmentos e que o receptor tem uma capacidade ilimitada de receber segmentos (isto é, que o receptor tem buffers disponíveis ou que a aplicação consome os dados em tempo útil) 1 2 3 4 tempo 5

Introdução de confirmações de recepção Emissor Receptor ack s2 O protocolo pressupõe que os segmentos não se perdem ack s3 ACK = Acknowledgement ou confirmação de recepção (aviso de recepção). Receptor saturado ack tempo s4

Perca de um segmento s1 ack s2 Receptor Emissor ack s3 Quando um ACK se perde há uma situação de bloqueio eterno (deadlock) ack tempo

Introdução de temporizadores (Timeouts) Emissor Receptor ack s2 s3 duplicado timeout tempo

Problemas ainda mal resolvidos A solução anterior não resolve ainda o problema da perca de um ACK que poderá conduzir à aceitação de um segmento duplicado O mesmo problema poderá ser introduzido por um receptor lento (face ao timeout) a enviar o ACK Um timeout mal regulado, muito curto por exemplo, poderá conduzir ao mesmo problema Na verdade as velocidades relativas do emissor e receptor podem não ser constantes nem conhecidas a priori Note-se que um timeout muito elevado conduz a uma recuperação demasiado lenta de uma perda

Situações patológicas Emissor Receptor ack s3 s1 duplicado s2 perdeu-se timeout s2 tempo Timeout demasiado curto

Números de sequência A solução consiste em introduzir números de sequência únicos para cada segmento. Estes números permitem ao receptor distingir dados esperados, dados repetidos, etc. Para se poupar espaço nos cabeçalhos interessa minimizar o número de bits a usar. O número pode então ser reutilizado ciclicamente desde que não se introduza confusão Se um protocolo pressupõe que o nível de baixo não troca a ordem dos segmentos e que o emissor só avança quando tem a certeza que o receptor recebeu os últimos dados enviados, então um número de sequência representado num só bit é suficiente

Protocolo stop & wait Emissor s0(0) Receptor a(0) timeout s0(0) ignora duplicado mas envia ack s1(1) a(0) timeout s1(1) ignora ack duplicado a(1) s2(2) tempo a(2)

Funcionamento Quando tem um segmento para transmitir, o emissor transmite-o e activa um temporizador. Depois podem suceder os seguintes eventos: O temporizador dispara – reenvia o segmento Chega um ACK com o número de sequência esperado - passa adiante Chega um ACK com outro número de sequência - ignora-o Quando recebe um segmento, o receptor emite sempre um ACK com o número de sequência igual ao do último segmento recebido correctamente. Se o segmento é novo, guarda-o e dá-o ao nível de cima, senão ignora-o pois é um duplicado.

Tempo de transmissão e RTT Num canal de 10.000 Km com a velocidade de transmissão de 1 Mpbs quantos segmentos de 1000 bytes se poderiam transmitir antes que chegue o ack do primeiro ? Tt = nº de bits a transmitir / velocidade de transmissão = 8000 / 1000000 = 0,008 = 8 ms Tp = dimensão do canal / velocidade de propagação = 10000 / 200000 = 0,05 = 50 ms, logo RTT = 100 ms Tt Tp O ack do segmento chegará 108 ms depois do início da transmissão do mesmo, se se admitir que o tempo de processamento do receptor é nulo e que o tempo de transmissão do ack também é nulo. Resposta: 108/8 = 13,5

Desempenho do protocolo stop & wait Circuito a 1 Mbps, RTT de 100 ms, frames de 1KB 8000 b/frame T = = 8 ms Transm. 10**6 bps Fracção de tempo em que o emissor está a transmitir Taxa de utilização = U = 8 ms 108 ms = = 0,074 = 7,4 % Conclusão: o protocolo não permite aproveitar completamente a capacidade do circuito !

Desempenho do protocolo (continuação) emissor receptor transmissão do 1º bit, t = 0 transmissão do último bit, t = Tt recepção do 1º bit RTT recepção do último bit, enviar ACK ACK chega, enviar o próximo segmento, t = RTT + Tt Tt RTT + Tt 8 ms 108 ms Taxa de utilização = U = (sem erros) = = 0,074 = 7,4 %

Protocolos com pipelining Pipelining: o emissor pode avançar e enviar segmentos mesmo que de alguns dos anteriores não esteja ainda confirmada a recepção. Duas formas genéricas destes protocolos: go-Back-N selective repeat

Protocolos com pipelining emissor receptor transmissão do 1º bit, t = 0 transmissão do último bit, t = Tt 1º bit chega do 1º segmento RTT último bit do 1º seg. chega, enviar ACK último bit do 2º seg. chega, enviar ACK último bit do 3º seg. chega, enviar ACK ACK chega, enviar o próximo, t = RTT + Tt A taxa de utilização subiu 3 vezes ! 3 x Tt RTT + Tt 3 x 8 ms 108 ms Taxa de utilização = U = (sem erros) = = 22,2 %

Pipelining com go-back-N O emissor vai transmitindo segmentos para a frente, usando um buffer dito “janela” do emissor. nºs de sequência Janela de emissão Emissor buffer de emissão segmentos esquecidos pois já foram acknowledged futuro segmentos no buffer de emissão à espera de serem acknowledged nºs de sequência Receptor segmentos esquecidos pois já foram consumidos pelo nível superior futuro

Funcionamento no emissor Dispõe de uma janela de até N segmentos consecutivos não acknowledged que pode ir transmitindo Coloca um nº de sequência no cabeçalho dos segmentos que emite Activa um timeout para cada segmento transmitido timeout(n): retransmite o segmento emitido há mais tempo e todos os outros até ao fim da janela (“go back N”) ACK(n): confirma todos os segmentos para trás incluindo o do nº de sequência (“cumulative ACK” – pode evitar repetições se possível)

Máquina de estados do emissor Nota: a gestão dos “timeouts” indicada está simplificada.

Funcionamento do receptor Recebe segmento com o número de sequência esperado: Entregar os dados ao nível superior Enviar ACK correspondente Recebe segmento fora de ordem (atrasado ou adiantado): Ignorar -> não há buffering suplementar no receptor ! Enviar ACK com o nº de sequência do último segmento aceite, isto é, o último que foi retirado do buffer para entregar ao nível superior

GBN

Generalização nºs de sequência Notas: a janela do emissor ser > 1 permite pipelining a janela do receptor ser > 1 permite memorizar frames “do futuro” (selective repeat”) Um protocolo com as duas janelas iguais a 1 diz-se stop and wait Janela de emissão Emissor buffer de emissão segmentos esquecidos pois já foram acknowledged futuro segmentos no buffer de emissão à espera de serem Acknowledged ou com “buracos” tempo Janela de recepção nºs de sequência Receptor buffer de recepção segmentos esquecidos pois já foram consumidos pela aplicação futuro segmentos no buffer de recepção à espera de serem consumidos pela aplicação ou à espera de serem contíguos

A janela do receptor ser superior a 1 permite optimizar GBN timeout 1 2 3 4 5 6 7 8 9 10 11 12 13 14 ack2 1 2 3 4 5 6 7 8 9 10 11 12 13 14 não chegou ignorados timeout 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 ack8 ack9 1 2 11 12 13 14 15 16 3 4 5 6 7 8 9 10 não chegou buffered ignorados

Selective repeat O receptor envia um ACK de todos os segmentos correctamente recebidos e que conseguiu bufferizar, mesmo recebidos fora de ordem O emissor activa logicamente um timeout para cada segmento enviado e desactiva o respectivo timeout quando recebe um ACK Quando dispara um timeout, o emissor só volta a enviar os segmentos para os quais ainda não tenha recebido um ACK O emissor continua limitado pela dimensão da sua janela

Visão das janelas

Funcionamento do Selective Repeat Emissor: Receptor: Dados do nível superior : Se está disponível um nº de sequência na janela, enviar segmento Timeout(n): reenviar segmento n, activar timeout(n) ACK(n) in [sendbase,sendbase+N]: Marcar o segmento n como recebido Se n é o menor segmento unACKed, avançar a base da janela para o próximo unACKed nº de sequência Segmento n in [rcvbase, rcvbase+N-1] Send ACK(n) Out-of-order: bufferizar In-order: entregar (entregar também os outros segmentos contíguos já recebidos), avançar a base da janela para o próximo segmento não recebido Segmento n in [rcvbase-N,rcvbase-1] senão: ignorar

Piggybacking Na prática os canais são quase sempre full-duplex. A implementação dos 2 canais de dados exigiria 4 canais lógicos por causa dos ACKs. Usa-se então uma técnica chamada “piggybacking” que consiste em introduzir os ACKs nos segmentos do canal do sentido contrário. Tem no entanto que se tomar em consideração o caso em que o tráfego é assimétrico. dados nº de sequência no sentido do envio nº de sequência do ack do tráfego do sentido contrário

Outros mecanismos Uma outra alternativa ao envio de ACK de todos os segmentos recebidos, mesmo fora de ordem, é não enviar senão ACKS cumulativos dos dados recebidos na ordem. Mas, o receptor, se receber vários ACKs seguidos com o mesmo número de sequência, pode concluir que houve um segmento que se perdeu mesmo que não tenha havido um timeout. Enviar NACKs (Negative Acknowledgement) sobre os segmentos em falta para que o emissor retransmita o mais cedo que possível, mesmo antes que o timeout seja desencadeado.

Números de sequência Os números de sequência são necessariamente cíclicos (“andam à roda”). Para diminuir o tamanho do cabeçalho, tenta-se usar o menor número possível de bits. Coloca-se então o problema de saber exactamente qual o menor número de valores distintos do número de sequência que são necessários : Emissor com janela de dimensão K, receptor com janela de dimensão 1, isto é, “Go back N” e nível inferior que mantém a ordem dos segmentos e não memoriza os atrasados : K + 1 Emissor e receptor com janela de dimensão K, nível inferior mantém a ordem dos segmentos e não memoriza os atrasados: 2 K Nível inferior é uma rede que não mantém a ordem dos pacotes e que pode memorizar os atrasados : então os nºs de sequência têm de acomodar o tráfego à velocidade máxima durante o máximo tempo de vida de um pacote (por convenção 3 minutos na Internet).

Valor dos timeouts O valor dos timeouts deve ser superior ao RTT. Um timeout demasiado curto ou demasiado longo diminui o rendimento do protocolo. Um protocolo do nível transporte deve avaliar dinamicamente o RTT para afinar o valor do time-out. O tamanho da janela de emissão depende da relação Tt / RTT. Quando a janela de emissão é maior do que 1, uma janela de recepção maior que 1 permite sempre aumentar o rendimento. O tamanho dos segmentos é variável (de algumas dezenas de bytes a vários milhares de bytes).

Taxa de utilização de uma canal com janela de emissão igual a 1 Tu = Tt / (Tt + RTT) = Tt / TA Tu - taxa de utilização Tt - tempo de transmissão de um frame TA - tempo que medeia entre o início da transmissão e a recepção do respectivo ack Tp - tempo de propagação de extremo a extremo TA = Tt + 2 * Tp Tu = Tt / (Tt + 2 * Tp ) = 1 / ( 1 + 2 Tp / Tt ) = 1 / ( 1 + 2 A ) A = Tp / Tt = Tempo de propagação / tempo de transmissão O quociente A é tanto maior quanto maior for o tempo de propagação e menor for o tempo de transmissão. Em todos os casos está-se a desprezar o tempo de processamento (pelo receptor) e o tempo de transmissão do ACK.

Exemplo num canal de 1 Km Funcionando a 1 Kbps (frame médio de 1000 bits) Tempo de transmissão = Tt = 1000 / 1000 = 1 s Tempo de propagação = Tp = 1 / 200000 = 5 . 10-6 s = 5 micro segundos A = 5 . 10-6 / 1 = 5 . 10-6 => 1 + 2A aprox. = 1 => Tu = 1 Funcionando a 1 Mbps (frame médio de 1000 bits) Tempo de transmissão = Tt = 1000 / 1.000.000 = 10-3 = 1 ms Tempo de propagação = Tp = 1 / 200.000 = 5 . 10-6 s = 5 micro s A = 5 . 10-6 / 10-3 = 5 . 10-3 => 1 + 2A aprox. = 1 => Tu = 1 Num canal de pequena dimensão a taxa de utilização é sempre igual a 100% seja qual for a velocidade de transmissão pois o tempo de propagação é muito reduzido.

Exemplo num canal de 200 Km Funcionando a 1 Kbps (frame médio de 1000 bits) Tempo de transmissão = Tt = 1000 / 1000 = 1 s Tempo de propagação = Tp = 200 / 200.000 = 1 . 10-3 s = 1 ms A = 10-3 / 1 = 10-3 => 1 + 2A aprox. = 1 => Tu = 100 % Funcionando a 1 Mbps (frame médio de 1000 bits) Tempo de transmissão = Tt = 1000 / 1.000.000 = 10-3 s = 1 ms Tempo de propagação = Tp = 200 / 200.000 = 10-3 s = 1 ms A = 10-3 / 10-3 = 1 => 1 + 2A = 3 => Tu = 33,33 % Num canal de média dimensão a taxa de utilização é 1 se o canal for de baixa velocidade mas começa a diminuir conforme a velocidade de transmissão vai aumentado, ou seja, a velocidade de transmissão é significativa.

Exemplo num canal de 50000 Km Funcionando a 1 Kbps (frame médio de 1000 bits) Tempo de transmissão = Tt = 1000 / 1000 = 1 s Tempo de propagação = Tp = 50.000 / 200.000 = 0,250 s = 250 ms A = 0,250 / 1 = 0,250 => 1 + 2A = 1,5 => Tu = 66,66 % Funcionando a 1 Mbps (frame médio de 1000 bits) Tempo de transmissão = Tt = 1000 / 1.000.000 = 10-3 s = 1 ms A = 250 / 1 = 250 => 1 + 2A = 501 => Tu = 0,2 % Num canal de grande dimensão a velocidade de propagação é sempre significativa.

Conclusões Se a relação 1 + 2*Tp / Tt = 1 + 2A é próxima de 1, ou seja, quando o tempo de propagação é muito pequeno, uma janela de emissão de dimensão 1 pode ser adequada. Caso esta relação seja > 1, ou seja, quando o tempo de propagação começa a ser significativo face ao tempo de transmissão, é sempre necessário aumentar a janela de emissão para aumentar a taxa de utilização. A janela de recepção maior que 1 destina-se a recuperar melhor dos erros e a acomodar melhor as variações de velocidade do receptor. Na ausência de erros, não garante aumento de rendimento. Quando a janela de emissão é maior que 1, a taxa de utilização é aumentada proporcionalmente, mas não pode ultrapassar 100 % como é óbvio. Numa conexão de transporte, a rede pode introduzir um tempo de propagação significativo (como num canal de grande dimensão) pelo que uma janela de emissão igual a 1 é quase sempre uma má ideia.

O Protocolo TCP

O protocolo TCP Connection oriented, reliable, full-duplex, end-to-end transport Stream oriented byte flow (unstructured) Um processo pode trabalhar simultaneamente com várias conexões Trabalha com "segmentos TCP" de comprimento variável e acomoda-se a canais com diferentes MTUs (Maximum Transfer Units) Implementa controlo de fluxos e fiabilidade através de técnicas de sliding window Utiliza temporizadores ajustados dinamicamente à situação da rede Implementa controlo da saturação da rede A terminação da conexão é ordenada e simétrica, isto é, espera até todos os dados serem recebidos de ambos os extremos

Conexões TCP socket = endereço IP + porta socket 1 socket 2 reliable, serial, full-duplex byte stream Uma conexão é inequivocamente identificada pelo par (socket 1, socket 2)

TCP: o protocolo Ponto a ponto: Byte stream ordenado e fiável: Um emissor e um receptor Byte stream ordenado e fiável: Não há “delimitadores de mensagens” pipelined: A janela do emissor é ajustada dinamicamente buffers de emissão e recepção full duplex: Cada conexão é bi-direccional MSS: maximum segment size Orientado conexão: Um hand shaking (troca de mensagens de controlo) tem de ter lugar antes de qualquer troca de dados flow controlled: O emissor não “afoga” o receptor

Fiabilidade ao nível transporte e data-link Os protocolos de transporte orientados conexão são em alguma medida semelhantes aos protocolos orientados conexão do nível data-link. No entanto, dado que o ambiente de execução desses protocolos é muito diferente, os protocolos de transporte são substancialmente mais complexos pois a rede pode “memorizar” pacotes e trocar-lhes a ordem router router canal físico de dados host router router host rede

Transporte versus Data-link Endereçamento e eventual necessidade de multiplexagem é mais complexa ao nível transporte A rede tem capacidade de bufferização e pode trocar a ordem dos segmentos O estabelecimento da conexão é mais complexo devido aos dois factores anteriores O dinamismo da rede tem implicações delicadas sobre a performance do nível transporte tendo que se introduzir mecanismos não só de controlo de fluxos, como também de controlo da saturação

acknowledgement number O segmento TCP source port dest port 32 bits Dados (variável) sequence number acknowledgement number rcvr window size ptr urgent data checksum F S R P A U head len not used Opções (variável) Contadores em bytes (não em segmentos!) Flags: URG: urgent data ACK: o campo de ACK é válido PSH: push data now Nº de bytes que o receptor pode aceitar RST, SYN, FIN: (Comandos de controlo da conexão) Internet checksum

Alguns dados sobre o cabeçalho Um segmento TCP tem no máximo 65535 - 20 - 20 bytes de dados Os números de sequência são dos bytes transmitidos; o ack number denota o próximo byte esperado e não o último correctamente recebido THL - TCP Header Length, indica o número de palavras de 32 bits do cabeçalho e é necessário devido às opções O campo Flags permite passar informação de controlo Window size permite indicar à outra extremidade quanto espaço há livre no buffer de recepção do emissor; o valor 0 é legal e permite indicar que o emissor está saturado O campo das opções permite negociar o MTU a usar na conexão, assim como outras opções como por exemplo “window scale option” e a utilização de “negative acknowledgements”; também é usado para “echo e echo reply probings”

Flags e segmentos de controlo Cada segmento pode ou não ter flags posicionadas. Um segmento com flags posicionadas e sem dados é só de controlo. As flags são: ACK - Acknowledgement field is valid RST - Reset the connection (idem reject) SYN - Synchronyze sequence numbers (abertura da conexão com SYN = 1 e ACK = 0) FIN - Sender has reached the end of its byte stream (fecho da conexão) URG - Urgent pointer field is valid PSH - This segment requests a PUSH (o receptor não deve “buferizar” estes dados à espera de mais e deve entregá-los imediatamente à aplicação) Os segmentos com SYN e FIN têm números de sequência para poderem ser repetidos em caso de perca e para ambas as partes se colocarem de acordo sobre os valores iniciais.

A gestão dos timeouts em TCP P: Como determinar o valor do timeout ? Maior que o RTT mas o RTT é variável ! Demasiado curto: timeout prematuro Retransmissões desnecessárias Demasiado longo: reacção lenta à perca de segmentos P: Como determinar o RTT? RTTmedido: medir o tempo que medeia entre a transmissão e a recepção do ACK Ignorar as retransmissões e os segmentos cumulativamente ACKed O valor medido irá variar, pretende-se um RTT estimado menos sujeito a picos (smoother ou “alisado”) Usar várias medidas e fazer médias, não usar apenas o último valor lido

Distribuição do valor do RTT probabilidade probabilidade 0.3 0.3 0.2 0.2 0.1 0.1 RTT (ms) RTT (ms) Distribuição da probabilidade do valor do RTT (round trip time) num canal físico (à esquerda) e na Internet (à direita) Verifica-se que em função da carga da rede, existe uma grande variância do RTT. Para uma rede carregada a 50% o RTT pode variar num factor de 4, mas para uma rede carregada a 90% o RTT pode variar num factor de 16 !

Exemplo da situação

Round Trip Time e Timeout Cálculo do RTT: Trata-se de uma amostragem pesada A influência da última amostra decresce exponencialmente Valor típico de  : 0.125 EstimatedRTT = (1- )*EstimatedRTT + *SampleRTT Valor do timeout a usar: RTTestimado mais “margem de segurança” Grande variação do RTTestimado -> maior margem de segurança DevRTT = (1-)*DevRTT + *|SampleRTT-EstimatedRTT| (tipicamente,  = 0.25) TimeoutInterval = EstimatedRTT + 4*DevRTT

Outros aspectos da gestão do timeout O RTT dos segmentos retransmitidos não é usado para a estimativa do valor do timeout Sempre que se perde um segmento o valor do timeout usado é duplicado momentaneamente

Gestão dos números de sequência Host A Host B Nºs de sequência: Nº do primeiro byte presente no segmento ACKs: Nº de sequência do próximo byte esperado pelo receptor ACK cumulativo P: como são geridos os segmentos recebidos fora de ordem ? R: não faz parte da especificação de base O utilizador escreve ‘C’ Seq=42, ACK=79, data = ‘C’ host B recebe ‘C’, ecoa ‘C’ Seq=79, ACK=43, data = ‘C’ host A recebe o ‘C’ ecoado Seq=43, ACK=80 tempo Cenário com telnet

Gestão de ACKS [RFC 1122, RFC 2581] Evento Segmentos recebidos sem buracos, todos os segmentos anteriores já ACKed anteriores já ACKed menos um Segmento fora de ordem gerando um buraco Chegada de um segmento que preenche parcial ou totalmente um buraco Acção do receptor delayed ACK. Esperar até 500ms por outro segmento. Se este não chegar enviar ACK Enviar imediatamente um ACK cumulativo Enviar ACK duplicado, indicando o nº de sequência do próximo byte esperado (o 1º do 1º buraco) Envio imediato de um ACK cumulativo

Cenários de retransmissão Host A Host B Host A Host B Seq=92, 8 bytes data Seq=92 timeout Seq=92, 8 bytes data Seq=100, 20 bytes data ACK=100 timeout X ACK=100 ACK=120 loss Seq=92, 8 bytes data Sendbase = 100 Seq=92, 8 bytes data SendBase = 120 Seq=92 timeout ACK=120 ACK=100 SendBase = 100 SendBase = 120 Timeout prematuro, ACKs cumulativos Perca de um ACK time time

Cenário com ACK cumulativo Host A Seq=92, 8 bytes data ACK=100 loss timeout Host B X Seq=100, 20 bytes data ACK=120 time SendBase = 120

Retransmissão rápida O time-out é em geral muito longo: Assim a recuperação de um segmento perdido é lenta A recepção de ACKs duplicados pode ser interpretada como um NACK O emissor envia muitos segmentos seguidos Se um se perder, aprecerão muitos ACKs repetidos. Se o emissor receber 3 ACKs com o mesmo número de sequência: fast retransmit: reenviar os segmentos antes de o time-out expirar

Controlo de fluxos Controlo de fluxo Receptor: informa explicitamente o emissor do espaço livre no buffer de recepção Campo RcvWindow no segmento Emissor: evita que a dimensão dos dados ainda não confirmados (unACKed) ultrapasse o valor de RcvWindow O emissor não satura os buffers do receptor por transmitir muito ou muito depressa RcvBuffer = tamanho do Buffer de recepção RcvWindow = espaço livre no Buffer Buffer do receptor

Estabelecimento da conexão Three way handshake: 1: o cliente envia um segmento de controlo com a flag SYN posicionada para o servidor Com o nº de sequência inicial do cliente 2: o servidor recebe o SYN, responde com um segmento de controlo com as flags SYN e ACK, isto é: ACK do SYN Inicia o buffer Especifica o nº de sequência inicial do servidor 3: o cliente responde com um segmento de ACK

Funcionamento Host A Host B SYN (seq = x ) Tempo SYN, ACK (seq=y, ack=x+1 ) Data, ACK (seq=x+1, ack=y+1 )

Números de sequência inicial É essencial que, dadas as características da rede, os pacotes atrasados de uma conexão fechada não sejam interpretados como pacotes válidos de uma nova conexão entre os mesmos sockets. As técnicas usadas para lidar com este tipo de problema são uma ou mais das várias apresentadas a seguir: Ao fechar-se normalmente uma conexão espera-se o “Maximum Network Packet Life Time” ( MNPLT) antes de libertar as portas e os números de sequência (“estado TIME-WAIT” no fecho de um socket que dura 30 segundos). Após o “boot” espera-se o MNPLT Determinar o MNPLT adequado é delicado, o que conduz a valores muito elevados deste parâmetro, e portanto desinteressantes (actualmente vale 3 minutos) Usa-se um relógio monotonicamente crescente para gerar os números de sequência iniciais o que exige números de sequência com muitos bits se os canais admitem grandes velocidades de transmissão Usam-se números pseudo-aleatórios (usando o relógio da máquina como ponto de partida)

Fecho da conexão com um protocolo assimétrico Host A Host B data Tempo disconnect request data Este protocolo conduziria à quebra abrupta de conexões com perca de dados

Fecho da conexão TCP Host B Host A disconnect request (FIN, seq = x ) Tempo ack ( ACK, ack = x+1 ) timeout disconnect request (FIN, seq = y, ack = x+1 ) ack ( ACK, ack = y+1 ) fim

Evolução do estado de uma conexão TCP server lifecycle TCP client lifecycle

Princípios do controlo da saturação informalmente: demasiados pacotes estão a ser injectados na rede para a capacidade que esta tem de os encaminhar diferente de controlo de fluxos! sintomas: Perca de pacotes (buffers com overflows) Tempos de trânsito elevados (filas de espera de dimensão elevada – queueing) Tempos de trânsito com uma grande instabilidade (a rede está em “rotura” e tem comportamentos limite)

Origens/custos da saturação A saturação da rede implica um aumento significativo do tempo de trânsito dentro da rede Este aumento do tempo de trânsito conduz ao aumento das retransmissões Muitas dessas retransmissões revelam-se inúteis, pelo que conduzem a um desperdício da capacidade da rede Devido também ao aumento das filas de espera, muitos pacotes são suprimidos. Cada pacote suprimido no interior da rede implica o desperdício da capacidade da mesma até aí consumida Em condições de saturação da rede, o rendimento desta começa a decair e a percentagem da sua capacidade que é aproveitada de forma útil decai também

Conclusões A saturação: conduz a um comportamento em que o rendimento da rede decresce rapidamente tem por sintomas: perca de pacotes, tempos de trânsito elevados, tempos de trânsito com uma grande instabilidade

Como lidar com a saturação ? O equipamento de rede lida com a saturação suprimindo os pacotes que não consegue encaminhar No entanto, tal medida não permite maximizar o rendimento da rede Uma supressão indiscriminada e inadequada pode até contribuir para o agravamento da situação É necessário encontrar formas de adaptar a procura à oferta e tal passa necessariamente por os hosts abrandarem o ritmo de geração de novo tráfego Os hosts têm pois de ser notificados ou pelo menos reagirem à saturação

Aproximações ao controlo da saturação Existem duas classes de aproximações (e também utilizações conjuntas das mesmas): End-end: Os routers não dão feedback explícito da saturação O host final é que se apercebe da saturação pelo aumento do tempo de trânsito e pela perca de pacotes Aproximação usada pelo protocolo TCP Network-assisted: Os routers dão feedback explícito sobre a saturação aos hosts: Um bit assinala a saturação (SNA, DECbit, TCP/IP ECN, ATM) É eventualmente explicitado o ritmo a que o emissor deve transmitir

Controlo da saturação do protocolo TCP Controlo extremo a extremo (“end-end” - sem suporte explícito da rede) Ritmo de transmissão dos segmentos condicionado pelo “congestion window size”, Congwin: Congwin Janela com W segmentos, cada um com MSS bytes, transmitidos em cada RTT, conduzem ao seguinte ritmo de transmissão: throughput = w * MSS RTT Bytes/sec

Filosofia do controlo da saturação em TCP “Probing” da banda passante disponível: Transmitir tão rápido quanto possível sem perca de segmentos Ir incrementando a janela até à perca de segmentos (saturação) Perante a perca, decrementar a janela e depois recomeçar a fazer “probing” Duas fases Slow start Congestion avoidance Variáveis importantes: Congwin (janela de saturação) Threshold (limite)

Gestão da janela do emissor do ponto de vista da saturação – Slow start Maximum allowed window = minimum ( Receiver window, Congwin ) A congestion window é gerida da seguinte forma durante esta fase: 1) No início ou após um período de saturação, o valor é igual a um segmento (equivalente ao MSS – “Maximum Segment Size”) 2) Por cada ACK chegado ao receptor (acked), Congwin é incrementada de 1 MSS (logo, duplica em cada RTT) Esta estratégia conduz a uma subida exponencial do valor de Congwin. Quando surge um timeout, anota-se o valor na variável Treshold e inicializa-se Congwin ao valor do MSS de novo.

TCP “Slowstart” Slowstart algorithm Host A one segment RTT Host B time two segments four segments Slowstart algorithm início: Congwin = 1 para (cada segmento ACKed) Congwin = Congwin+1 MSS até (loss event OR CongWin > Threshold) Aumento exponencial (por RTT) da dimensão da janela

Segunda fase – subida linear Congestion avoidance /* slowstart acabou pois */ /* Congwin > threshold */ Até (loss event) { por cada w segments ACKed: Congwin++ } threshold = Congwin/2 Congwin = 1 Recomeçar a fase slowstart

Variantes O Algoritmo descrito tem a designação de TCP Tahoe. A variante corrente, designada por Reno, trata a perca de um pacote isolado (assinalada por aparecerem 3 ACKs seguidos da mesma sequência) de forma diferente. Com TCP Reno, quando a perca isolada de um pacote é detectada, a Congwin é reduzida a metade mas a fase “slow start” é evitada entrando-se logo na fase de subida linear (“congestion avoidance”). Existem outras variantes mais modernas deste algoritmo (Vegas, etc.)

Tahoe e Reno

Visão sintética Se a CongWin está abaixo de Threshold, o emissor está na fase slow-start, a janela cresce exponencialmente. Quando a CongWin está acima de Threshold, o emissor está na fase congestion-avoidance, a janela cresce linearmente. Se ocorre um triple duplicate ACK, Threshold = CongWin/2 e CongWin = Threshold. Se ocore um timeout, Threshold = CongWin/2 e CongWin = 1 MSS.

Acções Event State TCP Sender Action Commentary ACK receipt for previously unacked data Slow Start (SS) CongWin = CongWin + MSS, If (CongWin > Threshold) set state to “Congestion Avoidance” Resulting in a doubling of CongWin every RTT Congestion Avoidance (CA) CongWin = CongWin+MSS * (MSS/CongWin) Additive increase, resulting in increase of CongWin by 1 MSS every RTT Loss event detected by triple duplicate ACK SS or CA Threshold = CongWin/2, CongWin = Threshold, Set state to “Congestion Avoidance” Fast recovery, implementing multiplicative decrease. CongWin will not drop below 1 MSS. Timeout CongWin = 1 MSS, Set state to “Slow Start” Enter slow start Duplicate ACK Increment duplicate ACK count for segment being acked CongWin and Threshold not changed

Filosofia do TCP perante a saturação real O protocolo TCP procura encontrar um ponto de equilíbrio que permita extrair o máximo de rendimento da rede sem provocar saturação Quando a rede está saturada, o desvio padrão do RTT começa a aumentar significativamente, pelo que o valor do timeout usado também aumenta significativamente Ao mesmo tempo perdem-se pacotes pelo que Congwin tem frequentemente o valor de um MSS e o valor do time-out é duplicado Este conjunto de factores conduz a que o desempenho das ligações TCP nestas circunstância seja muito afectado

Variação da janela Long-lived TCP connection

Desempenho do TCP Quando a janela tem a dimensão W (em bytes) e está estável, a taxa ou velocidade de transmissão ou capacidade, da conexão TCP, é: W / RTT No entanto, a conexão nunca tem o mesmo valor de janela pois o TCP tentaria aumentar a mesma. Admitindo que o valor máximo que não provocaria saturação fosse W, quando a janela tiver W+MSS aparece um timeout e a mesma é reduzida a W/2, pelo que, desprezando a fase de slow start, a taxa de transmissão da conexão fica reduzida a: W / 2 . RTT Assim, dado o valor da janela variar constantemente entre W / 2 e W, pode-se considerar que em velocidade de cruzeiro a taxa de transmissão da conexão TCP será: 0,75 . W / RTT W / RTT é a fracção máxima da capacidade da rede que a conexão poderia usar.

Equidade (“Fairness”) do protocolo TCP Se o protocolo TCP for equitativo, então se N conexões TCP partilham um link, cada uma deveria obter 1/N da capacidade do link TCP connection 1 bottleneck router capacity R TCP connection 2

Ilustração intuitiva R R Duas conexões: equal bandwidth share Consideremos que cada uma está já na fase “congestion avoidance” Sempre que há perca de pacotes o valor de Treshold é dividido por 2 R equal bandwidth share loss: decrease window by factor of 2 congestion avoidance: additive increase Connection 2 throughput loss: decrease window by factor of 2 congestion avoidance: additive increase Connection 1 throughput R

Conclusão Se a rede só tivesse tráfego TCP, os canais seriam partilhados com bastante equidade (“fairness” ou justiça) Tal não é verdade pois existem outros tipos de tráfego (UDP) A saturação penaliza o tráfego TCP mais do que outros tipos de tráfego Uma aplicação que use várias conexões TCP em paralelo obtêm uma fracção mais significativa da banda do que uma que só utilize uma conexão Este aspecto é tanto mais verdade quanto mais saturada estiver a rede