Camada de Transporte. Serviços da camada de transportet. Multiplexagem / desmultiplexagem

Transcrição

1 Camada de Transporte Serviços da camada de transporte Multiplexagem / desmultiplexagem Serviço não orientado à ligação: UDP Transferência fiável de dados Serviço orientado à ligação: TCP transferência fiável controlo de fluxo gestão de ligações Controlo de congestionamento TCP 1º Semestre 2009/2010 Redes de Computadores 3.1 Serviços da camada de transportet Os protocolos da camada de pp transporte executam-se nos sistemas terminais e fornecem um serviço de comunicação ao nível lógico entre as aplicações Serviços de transporte vs. serviços de rede: Camada de rede: transferência de dados entre sistemas terminais Camada de transporte: transferência de dados entre processos; estes serviços são construídos com base nos serviços da camada de rede com o objectivo de os melhorar application transport network data link physical network data link physical network data link physical network data link physical network data link physical network data link physical application transport network data link physical 1º Semestre 2009/2010 Redes de Computadores 3.2

2 Protocolos da camada de transporte t - Internet t TCP (Transmission Control Protocol) - comunicação fiável, com garantia de entrega na ordem de extremo a extremo (unicast ou 1-para-1) controlo de fluxo application transport network data link physical network data link physical network data link physical network data link physical estabelecimento e gestão de ligações controlo de congestionamento network data link physical UDP ( User Datagram Protocol ) - comunicação não fiável, sem garantia de entrega na ordem ( best-effort ), de um para um ou mais extremos ( unicast ou multicast ) network data link physical application transport network data link physical 1º Semestre 2009/2010 Redes de Computadores 3.3 Multiplexagem l / Desmultiplexagem l As entidades da camada de transporte trocam entre si segmentos ou TPDU s ( Transport Protocol Data Unit ) Desmultiplexagem : mecanismo que permite entregar os segmentos recebidos ao processo da camada de aplicação a que pertencem segment header segment application-layer data Ht M Hn segment P1 M application transport network P3 receiver M M application transport network P4 M P2 application transport network 1º Semestre 2009/2010 Redes de Computadores 3.4

3 Multiplexagem l / Desmultiplexagem l Multiplexagem : mecanismo que permite recolher e enviar dados de vários processos da camada de aplicação 32 bits source port # dest port # other header fields Multiplexagem / desmultiplexagem: mecanismos baseados nos portos e nos endereços IP de origem e de destino application data (message) TCP/UDP segment format 1º Semestre 2009/2010 Redes de Computadores 3.5 Multiplexagem / Desmultiplexagem: exemplos host A Source IP: A Dest IP: B source port: x dest. port: 23 Web client server B host C Source IP: B Dest IP: A Source IP: C Source IP: C source port: 23 Dest IP: B Dest IP: B dest. port: x source port: y source port: x dest. port: 80 dest. port: 80 Multiplexagem l não orientada à ligação Web client host A Source IP: A Dest IP: B source port: x dest. port: 80 Web server B Multiplexagem orientada à ligação 1º Semestre 2009/2010 Redes de Computadores 3.6

4 UDP (User Datagram Protocol) Serviço de melhor esforço ( best effort ); os segmentos UDP podem ser: perdidos entregues à aplicação fora de ordem Serviço não orientado à ligação cada segmento UDP é tratado independentemente dos outros RFC 768 Porque existe o protocolo UDP não há necessidade de estabelecer uma ligação (eficiente i e.g. para mensagens curtas) não há necessidade de manter um estado (ao nível da camada de transporte t ) no emissor ou no receptor pequeno cabeçalho em cada segmento o emissor pode transmitir a qualquer ritmo - não se executam mecanismos de controlo de congestionamento (vantagens para a aplicação vs. desvantagens para a rede ) 1º Semestre 2009/2010 Redes de Computadores 3.7 UDP Usado em: aplicações multimédia tolerantes a perdas exigentes em ritmo de transmissão outras aplicações DNS SNMP (Simple Network Management Protocol) ) Uma aplicação pode incluir mecanismos de transferência de dados fiável, mesmo usando UDP ao nível de transporte Length, in bytes of UDP segment, including header 32 bits source port # dest port # length checksum Application data (message) UDP segment format 1º Semestre 2009/2010 Redes de Computadores 3.8

5 UDP - detecção de erros (mecanismo incluido no UDP) Procedimento abreviado: Receptor: calcula l o checksum do segmento Emissor: o resultado é igual ao inscrito no trata cada segmento como uma segmento? sequência de inteiros de 16 bits NÃO - erro detectado: deita fora o cálculo do controlo de erros: segmento informando, ou não, um complemento para 1 da soma do conteúdo do segmento processo da camada de aplicação SIM - segmento aceite (a existir o resultado é colocado no erro não foi detectado) campo checksum do segmento soma h checksum º Semestre 2009/2010 Redes de Computadores 3.9 Camada de Transporte Serviços da camada de transporte Multiplexagem/desmultiplexagem Serviço não orientado à ligação: UDP Transferência fiável de dados Serviço orientado à ligação: TCP transferência fiável controlo de fluxo gestão de ligações Controlo de congestionamento TCP 1º Semestre 2009/2010 Redes de Computadores 3.10

6 Transferência fiável de dados Função importante nas camadas de aplicação, transporte e ligação de dados As características do canal de comunicação subjacente determinam a complexidade do protocolo de transmissão fiável (que iremos designar por reliable data transfer -rdt) 1º Semestre 2009/2010 Redes de Computadores 3.11 Transferência fiável: implementação rdt_send(): called from above, (e.g., by app.). Passed data to deliver to receiver upper layer deliver_data(): data(): called by rdt to deliver data to upper send side receive side udt_send(): called by rdt, to transfer packet over unreliable channel to receiver rdt_rcv(): called when packet arrives on rcv-side of channel 1º Semestre 2009/2010 Redes de Computadores 3.12

7 Transferência fiável: metodologia Vamos desenvolver incrementalmente as partes emissora e receptora do protocolo de transferência fiável (rdt) Vamos considerar transferência de dados unidireccional (para simplificar a exposição) Embora a informação de controlo flua nos dois sentidos! Na especificação do emissor e do receptor, usam-se máquinas de estados finitos ( Finite State Machines - FSM) Uma vez num estado, o próximo é completamente determinado pelo acontecimento seguinte state 1 event causing state transition actions taken on state transition event actions state 2 1º Semestre 2009/2010 Redes de Computadores 3.13 rdt1.0 - transferência fiável sobre canal fiável Neste cenário inicial supomos que o canal subjacente é completamente fiável : sem erros sem perda de pacotes Receptor Wait for call from below rdt_rcv(packet) extract (packet,data) deliver_data(data) Wait for call from above rdt_send(data) packet = make_pkt(data) udt_send(packet) Emissor 1º Semestre 2009/2010 Redes de Computadores 3.14

8 rdt2.0 -canal com erros Agora, supomos que o canal subjacente pode introduzir erros Como recuperar dos erros? Confirmações positivas, acknowledgements (ACKs): o receptor informa explicitamente o emissor que recebeu bem um pacote Confirmações negativas, negative acknowledgements (NAKs): o receptor informa explicitamente o emissor que recebeu um pacote com erros o emissor retransmite um pacote sempre que recebe um NAK Mecanismos introduzidos: detecção de erros informação de controlo do receptor para o emissor (ACK s e NAK s) 1º Semestre 2009/2010 Redes de Computadores 3.15 rdt2.0 - especificação da máquina de estados rdt_send(data) sndpkt = make_pkt(data, checksum) udt_send(sndpkt) rdt_rcv(rcvpkt) && Wait for Wait for isnak(rcvpkt) call from ACK or udt_send(sndpkt) above NAK Receptor rdt_rcv(rcvpkt) && corrupt(rcvpkt) udt_send(nak) rdt_rcv(rcvpkt) && isack(rcvpkt) Λ Emissor Wait for call from below rdt_rcv(rcvpkt) && notcorrupt(rcvpkt) extract(rcvpkt,data) deliver_data(data) udt_ send(ack) 1º Semestre 2009/2010 Redes de Computadores 3.16

9 rdt2.0 exemplo de funcionamento sem erros rdt_send(data) sndpkt = make_pkt(data, checksum) udt_send(sndpkt) rdt_rcv(rcvpkt) && isnak(rcvpkt) Wait for Wait for call from ACK or udt_send(sndpkt) above NAK rdt_rcv(rcvpkt) && isack(rcvpkt) Λ Emissor Receptor rdt_rcv(rcvpkt) rcv(rcvpkt) && corrupt(rcvpkt) udt_send(nak) Wait for call from below rdt_rcv(rcvpkt) && notcorrupt(rcvpkt) t( extract(rcvpkt,data) deliver_data(data) udt_send(ack) 1º Semestre 2009/2010 Redes de Computadores 3.17 rdt2.0 exemplo de funcionamento com erros rdt_send(data) sndpkt = make_pkt(data, checksum) udt_send(sndpkt) rdt_rcv(rcvpkt) && isnak(rcvpkt) Wait for Wait for call from ACK or udt_send(sndpkt) above NAK Receptor rdt_rcv(rcvpkt) rcv(rcvpkt) && corrupt(rcvpkt) udt_send(nak) rdt_rcv(rcvpkt) && isack(rcvpkt) Λ Emissor Wait for call from below rdt_rcv(rcvpkt) && notcorrupt(rcvpkt) extract(rcvpkt,data) deliver_data(data) udt_send(ack) 1º Semestre 2009/2010 Redes de Computadores 3.18

10 rdt2.0 -mau funcionamento O que acontece se os ACK s/nak s têm erros? O emissor não sabe o que aconteceu no receptor se o emissor se limitar a retransmitir o pacote pode provocar um duplicado no receptor Tratamento de duplicados: o emissor junta um número de sequência a cada pacote o receptor pode detectar duplicados e deitá-los fora Pára e espera ( stop and wait ) O emissor envia um pacote e espera pela resposta do receptor 1º Semestre 2009/2010 Redes de Computadores 3.19 rdt2.1 - emissor (ACK/NAK com erros) rdt_rcv(rcvpkt) && notcorrupt(rcvpkt) && isack(rcvpkt) Λ rdt_rcv(rcvpkt) && ( corrupt(rcvpkt) p isnak(rcvpkt) ) udt_send(sndpkt) rdt_send(data) sndpkt = make_pkt(0, data, checksum) udt_send(sndpkt) rdt_rcv(rcvpkt) && ( corrupt(rcvpkt) Wait for Wait for isnak(rcvpkt) ) call 0 from ACK or above NAK 0 udt_send(sndpkt) Wait for ACK or NAK 1 rdt_send(data) d(d t Wait for call 1 from above rdt_ rcv(rcvpkt) && notcorrupt(rcvpkt) && isack(rcvpkt) Λ sndpkt = make_pkt(1, data, checksum) udt_send(sndpkt) 1º Semestre 2009/2010 Redes de Computadores 3.20

11 rdt2.1 - receptor (ACK/NAK com erros) rdt_rcv(rcvpkt) rcv(rcvpkt) && (corrupt(rcvpkt) sndpkt = make_pkt(nak, chksum) udt_send(sndpkt) rdt_rcv(rcvpkt) && not corrupt(rcvpkt) && has_seq1(rcvpkt) sndpkt = make_pkt(ack, chksum) udt_send(sndpkt) rdt_rcv(rcvpkt) && notcorrupt(rcvpkt) && has_seq0(rcvpkt) extract(rcvpkt,data) deliver_data(data) sndpkt = make_pkt(ack, chksum) udt_send(sndpkt) Wait for 0 from below Wait for 1 from below rdt_rcv(rcvpkt) && notcorrupt(rcvpkt) && has_seq1(rcvpkt) extract(rcvpkt,data) deliver_data(data) sndpkt = make_pkt(ack, chksum) udt_send(sndpkt) rdt_rcv(rcvpkt) && (corrupt(rcvpkt) sndpkt = make_pkt(nak, chksum) udt_send(sndpkt) rdt_rcv(rcvpkt) && not corrupt(rcvpkt) && has_seq0(rcvpkt) sndpkt = make_pkt(ack, chksum) udt_send(sndpkt) 1º Semestre 2009/2010 Redes de Computadores 3.21 rdt2.1 - discussão Emissor: Inclui um número de sequência em cada pacote (0,1); Verifica se o ACK/NAK tem erros; O número de estados duplica porque tem de ter em conta se espera confirmação do pacote número 0 ou 1. Receptor: tem de verificar se o pacote recebido é duplicado o estado indica se está à espera de um pacote número 0 ou 1 1º Semestre 2009/2010 Redes de Computadores 3.22

12 rdt protocolo sem NAK s Mesma funcionalidade d de rdt2.1 mas usando apenas ACK s o receptor manda um ACK por cada pacote bem recebido tem de incluir o número do pacote que está a confirmar a recepção, pelo emissor, de dois ACK s seguidos para o mesmo pacote tem o mesmo efeito que um NAK 1º Semestre 2009/2010 Redes de Computadores 3.23 rdt2.2 - protocolo sem NAK s rdt_send(data) sndpkt = make_pkt(0, data, checksum) udt_send(sndpkt) rdt_rcv(rcvpkt) && (corrupt(rcvpkt) has_seq1(rcvpkt)) udt_send(sndpkt) Wait for call 0 from above Wait for 0 from below Emissor (parcial) Wait for ACK 0 Receptor (parcial) udt_send(sndpkt) rdt_rcv(rcvpkt) && notcorrupt(rcvpkt) && isack(rcvpkt,0) Λ rdt_rcv(rcvpkt) && notcorrupt(rcvpkt) && has_ seq1(rcvpkt) extract(rcvpkt,data) deliver_data(data) sndpkt = make_pkt(ack1, chksum) udt_send(sndpkt) 1º Semestre 2009/2010 Redes de Computadores 3.24

13 rdt3.0 -canal com erros e perdas Nova hipótese: o canal subjacente pode perder pacotes (dados ou ACK s) usam-se checksum, nº de sequência, ACK s e retransmissões, mas é necessário incluir outros mecanismos. Abordagem: o emissor espera um intervalo de tempo razoável por um ACK retransmite se o ACK não for recebido durante esse intervalo se o pacote (ou o ACK) estiver apenas atrasado (e não perdido): a retransmissão provoca um pacote duplicado, mas o nº de sequência possibilita a detecção correcta no receptor Requisitos adicionais: o receptor tem de incluir em cada ACK o nº de sequência do pacote que está a confirmar temporizador timer. 1º Semestre 2009/2010 Redes de Computadores 3.25 rdt3.0 -emissor rdt_rcv(rcvpkt) Λ Wait for call 0from above rdt_rcv(rcvpkt) && notcorrupt(rcvpkt) t( && isack(rcvpkt,1) stop_timer timeout udt_send(sndpkt) start t_timer rdt_rcv(rcvpkt) && ( corrupt(rcvpkt) isack(rcvpkt,0) ) Λ Wait for ACK1 rdt_send(data) sndpkt = make_pkt(0, data, checksum) udt_send(sndpkt) start_timer rdt_send(data) Wait for ACK0 Wait for call 1 from above sndpkt = make_pkt(1, data, checksum) udt_send(sndpkt) start_timer t ti rdt_rcv(rcvpkt) && ( corrupt(rcvpkt) isack(rcvpkt,1) ) Λ timeout udt_send(sndpkt) start_timer rdt_rcv(rcvpkt) && notcorrupt(rcvpkt) && isack(rcvpkt,0) stop_ timer rdt_rcv(rcvpkt) Λ 1º Semestre 2009/2010 Redes de Computadores 3.26

14 rdt3.0 -exemplos 1º Semestre 2009/2010 Redes de Computadores 3.27 rdt3.0 -exemplos 1º Semestre 2009/2010 Redes de Computadores 3.28

15 rdt3.0 - desempenho Emissor Receptor Ritmo de transmissão - R bps (ex.: 1 Gbps ) Tempo de propagação extremo a extremo - A s (ex.: 15 ms) Tamanho dos pacotes de dados - L i bits (ex.: 1kB (8kbit) ) Tamanho dos pacotes ACK - L A bits (ex.: 125B (1kbit) ) Tempo de processamento de um pacote - T p s (ex.: 0 sec) Exemplo: T = transmissão 8kb/pkt 10 9 bps = 8 μs T T L i /R L A /R pck ACK T p Fracção do tempo em que Utilização = U = = se transmite dados = Em geral (T p =0): Utilização = U = L i /R 2A + (L i +L A )/R = L i 2AR + L i +L A 1º Semestre 2009/2010 Redes de Computadores 3.29 Protocolos de janela Técnica de janela: o emissor envia vários pacotes de seguida (tantos quantos o tamanho da janela) sem esperar pela confirmação de cada um. Aumento do nº de bits destinados à numeração dos pacotes armazenamento no emissor e/ou no receptor Dois tipos de protocolos de janela: voltar atrás ( go-back-n) e repetição selectiva ( selective repeat ) 1º Semestre 2009/2010 Redes de Computadores 3.30

16 Voltar Atrás - GBN ( Go-Back-N ) Emissor: números de sequência com k bits Janela de tamanho N, (são permitidos N pacotes consecutivos sem confirmação) ACK(n): confirma todos os pacotes até ao número n inclusivé Temporizador para o pacote (mais antigo) ainda não confirmado timeout: retransmite os pacotes que estão na janela de emissão 1º Semestre 2009/2010 Redes de Computadores 3.31 GBN - emissor Λ base=1 nextseqnum=1 rdt_send(data) if (nextseqnum < base+n) { sndpkt[nextseqnum] = make_pkt(nextseqnum,data,chksum) udt_send(sndpkt[nextseqnum]) if (base == nextseqnum) start_timer nextseqnum++ } else refuse_data(data) timeout start_timer Wait udt_send(sndpkt[base]) rdt_rcv(rcvpkt) rcv(rcvpkt) udt_send(sndpkt[base+1]) && corrupt(rcvpkt) udt_send(sndpkt[nextseqnum-1]) Λ rdt_rcv(rcvpkt) && notcorrupt(rcvpkt) t( base = getacknum(rcvpkt)+1 If (base == nextseqnum) stop_timer else 1º Semestre 2009/2010 start_timer Redes de Computadores 3.32

17 GBN - receptor default udt_send(sndpkt) Λ expectedseqnum=1 Wait sndpkt = make_pkt(expectedseqnum,ack,chksum) rdt_rcv(rcvpkt) && notcurrupt(rcvpkt) && hasseqnum(rcvpkt,expectedseqnum) extract(rcvpkt,data) deliver_data(data) data(data) sndpkt = make_pkt(expectedseqnum,ack,chksum) udt_send(sndpkt) expectedseqnum++ Confirmações: por cada pacote bem recebido envia o ACK(n) onde n é o maior número do último pacote que chegou na ordem podem ser gerados ACK s duplicados d precisa apenas de guardar em memória o número de sequência do pacote de que está à espera - expectedseqnum Pacotes fora de ordem: deita fora neste caso, não há necessidade de memória para pacotes no receptor! Envia confirmação do último pacote que chegou na ordem 1º Semestre 2009/2010 Redes de Computadores 3.33 GBN Exemplo de funcionamento 1º Semestre 2009/2010 Redes de Computadores 3.34

18 GBN - tamanho da janela Emissor Receptor Ritmo de transmissão - R bps (ex.: 1 Gbps ) Tempo de propagação extremo a extremo - A s (ex.: 15 ms) Tamanho dos pacotes de dados - L i bits (ex.: 1kB (8kbit) ) Tamanho dos pacotes ACK - L A bits (ex.: 1kB (8kbit) ) Tempo de processamento de um pacote - T p s (ex.: 0 s ) T i 1º pck 2º pck T T = 2A + 2T P + T i + T A T 1º i = L i /R ACK T A = L A /R Para que o emissor não pare (na ausência de perdas), o tamanho da janela N é: T T T A 1º pck T p N T T / T i Quantos bits se têm de usar para numerar os pacotes? 1º Semestre 2009/2010 Redes de Computadores 3.35 Repetição Selectiva - SR ( Selective Repeat ) O receptor confirma individualmente todos os pacotes recebidos tem de ter capacidade de armazenamento para entrega na ordem à camada superior o emissor apenas retransmite os pacotes que não foram confirmados é necessário um temporizador para cada pacote não confirmado janela do emissor contém N números consecutivos, dos quais o primeiro ainda não foi confirmado 1º Semestre 2009/2010 Redes de Computadores 3.36

19 SR - janelas do emissor e do receptor 1º Semestre 2009/2010 Redes de Computadores 3.37 SR - funcionamento emissor Dados da camada superior: se o próximo número de sequência cabe na janela envia um pacote timeout(n): retransmite o pacote n e reinicializa o temporizador ACK(n) [sendbase,sendbase+n]: marca o pacote n como confirmado se n era o menor número de sequência não confirmado avança a janela até ao próximo não confirmado receptor Pacote n [rcvbase, rcvbase+n-1] envia ACK(n) armazena o pacote, envia para a camada superior os pacotes na ordem e avança a janela Pacote n [rcvbase-n,rcvbase-1] envia ACK(n) Em qualquer outro caso: não faz nada 1º Semestre 2009/2010 Redes de Computadores 3.38

20 SR - exemplo 1º Semestre 2009/2010 Redes de Computadores 3.39 SR - numeração Exemplo: n os de sequência: 0, 1, 2, 3 tamanho da janela = 3 o receptor não pode distinguir entre as duas situações da figura! Qual a relação entre o tamanho da sequência e o tamanho da janela? 1º Semestre 2009/2010 Redes de Computadores 3.40

21 Camada de Transporte (cont.) t) Serviços da camada de transporte Multiplexagem/desmultiplexagem Serviço não orientado à ligação: UDP Transferência fiável de dados Serviço orientado à ligação: TCP transferência fiável controlo de fluxo gestão de ligações Controlo de congestionamento TCP 1º Semestre 2009/2010 Redes de Computadores 3.41 TCP - RFCs: 793, 1122, 1323, 2001, 2018, 2581, 2582,.. ligação ponto a ponto: ligação full duplex : um emissor e um receptor transferência fiável e por ordem de uma sequência de bytes: não há delimitação de mensagens transferência bidireccional de dados na mesma ligação os segmentos têm um tamanho máximo - MSS, Maximum Segment Size protocolo orientado à ligação: controlo por janela: estabelecimento de uma ligação tamanho da janela imposto pelos algoritmos de controlo de fluxo e de congestionamento memórias de emissão e de recepção socket door application writes data TCP send buffer segment application reads data TCP receive buffer (com inicialização do emissor e do receptor) antes do início da transferência de dados transferência de dados controlo de fluxo: socket door o emissor não ultrapassa a capacidade de memória do receptor 1º Semestre 2009/2010 Redes de Computadores 3.42

22 TCP - alguns mecanismos incluídos ou modificados desde a primeira implementação: 1981: Transmission Control Protocol 1990: TCP Reno (4.3BSD Reno) (TCP) [RFC793, J. Postel] Fast tretransmit (modificado) d / Fast Recovery 1986: observação de uma série de colapsos devidos a congestionamento 1988: TCP Tahoe Princípio da conservação do número de pacotes na rede,, como método de controlo de congestionamento; Novo mecanismo para cálculo de Timeout (RTO); mecanismo RTO Exponential Backoff (de Karn); inclusão das fases Slow Start e Congestion Avoidance; mecanismo Fast Retransmit. 1993: 4.4BSD TCP - Extensions for high hperformance Window Scale Option RTT measurements with timestamps and protection against wrapped sequences 1996: TCP Sack (TCP with Selective Acknowledgements) 1999: TCP NewReno Mecanismo Fast Recovery modificado na presença de ACKs parciais. 1º Semestre 2009/2010 Redes de Computadores 3.43 Estrutura do segmento TCP URG: urgent data (generally not used) ACK: ACK # valid PSH: push data now (generally not used) RST, SYN, FIN: connection estab (setup, teardown commands) Internet checksum (as in UDP) 32 bits source port # dest port # head len sequence number acknowledgement number UAP R S F rcvr window size not used checksum ptr urgent data Options (variable length) application data (variable length) counting by bytes of data (not segments!) # bytes rcvr willing to accept 1º Semestre 2009/2010 Redes de Computadores 3.44

23 Números de sequência e ACK s N os de sequência: número do primeiro byte de dados do segmento ACK s: número do próximo byte esperado no receptor cumulativos: um ACK confirma a recepção correcta dos bytes anteriores Segmentos fora de ordem dependente da implementação User types C host ACKs receipt of echoed C Host A Host B host ACKs receipt of C, echoes back C Exemplo com Telnet simples time 1º Semestre 2009/2010 Redes de Computadores 3.45 Round Trip Time e Timeout Determinação do timeout maior que um intervalo de ida e volta RTT (Round Trip Time) RTT é variável durante uma ligação TCP demasiado curto retransmissões desnecessárias demasiado longo reacção lenta a perdas de segmentos Estimação do RTT SampleRTT: intervalo de tempo medido entre o envio de um segmento e a recepção do ACK correspondente O valor medido de SampleRTT varia muito de segmento para segmento é necessário extrair um valor médio usando vários valores de SampleRTT 1º Semestre 2009/2010 Redes de Computadores 3.46

24 Round Trip Time e Timeout O esquema actual de determinação do RTO (Retransmit TimeOut ou simplesmente Timeout) foi incorporado com as modificações de 1988 (V. Jacobson e M. Karels), com o TCP Tahoe [ver Congestion Avoidance and Control, SIGCOMM, 8/1988] EstimatedRTT = (1-x)*EstimatedRTT + x*samplertt Média deslizante com pesos exponenciais, exponential weighted moving average a influência de um valor medido decresce exponencialmente valor típico de x: 0.1 Determinação do valor timeout EstimatedRTT + margem de segurança Grandes variações em EstimatedRTT -> grandes margens de segurança Timeout = EstimatedRTT + 4*Deviation Deviation = (1-x)*Deviation + x* SampleRTT-EstimatedRTT 1º Semestre 2009/2010 Redes de Computadores 3.47 Transferência fiável de dados d d i d Neste emissor TCP simplificado: event: data received from application above create, send segment transferência unidireccional sem controlo de fluxo sem controlo de congestionamento t wait for event event: timer timeout retransmit not-yet-aknowledge segment with smallest sequence number event: ACK received, with ACK # y ACK processing 1º Semestre 2009/2010 Redes de Computadores 3.48

25 Transferência fiável de dadosd sendbase = initial_sequence number nextseqnum = initial_sequence number loop (forever) { switch(event) event: data received from application above create TCP segment with sequence number nextseqnum start timer for segment nextseqnum pass segment to IP nextseqnum = nextseqnum + length(data) Emissor TCP simplificado event: timer timeout retransmit not-yet-aknowledge segment with smallest sequence number start timer mecanismo fast restransmit está simplificado; adiante, veremos os detalhes event: ACK received, with ACK field value of y if (y > sendbase){ sendbase = y if(there are currently any not-yet-aknowledged segments start timer } else { /* a duplicate ACK for already ACKed segment */ increment number of duplicate ACKs received for y if (number of duplicate ACKS received for y == 3) { /* TCP fast retransmit */ resend segment with sequence number y } } /* end of loop forever */ 1º Semestre 2009/2010 Redes de Computadores 3.49 Geração de ACK s - RFC 1122, RFC 2581 (sem a opção TCP SACK, que veremos adiante) Acontecimento chegada de segmento na ordem, tudo o resto já confirmado chegada de segmento na ordem, uma confirmação atrasada chegada de segmento fora de ordem com nº de sequência superior ao esperado Acção do receptor TCP Espera até 500ms pela chegada do próximo segmento. Se não chegar, envia ACK envia imediatamente um ACK cumulativo envia um ACK (duplicado), indicando o próximo byte esperado chegada de segmento que completa parcial ou totalmente um buraco existente t envia imediatamente ACK se o segmento segue o último bem recebido na ordem 1º Semestre 2009/2010 Redes de Computadores 3.50

26 Cenários de retransmissão Host A Host B Host A Host B timeout X loss timeout time lost ACK scenario time premature timeout, cumulative ACKs 1º Semestre 2009/2010 Redes de Computadores 3.51 Controlo de fluxo (mecanismo independente do controlo de congestionamento, que será abordado mais tarde) O emissor não excede a capacidade do receptor RcvBuffer = tamanho da memória de recepção RcvWindow = espaço livre na memória de recepção receptor: informa explicitamente o emissor do espaço livre na memória de recepção RcvWindow (campo no segmento TCP) emissor: mantém a quantidade de dados d transmitidos e ainda não confirmados menor que o mais recente valor recebido de RcvWindow 1º Semestre 2009/2010 Redes de Computadores 3.52

27 Gestão de ligações Estabelecimento em 3 passos (3- way handshake): 1: o cliente envia um segmento de controlo (TCP SYN) para o servidor especifica um nº de sequência inicial i i 2: o servidor recebe o SYN e responde com um segmento de controlo SYN ACK confirma a recepção do SYN reserva memória de recepção especifica um nº de sequência inicial i i (para os dados enviados pelo servidor) 3: o cliente confirma o estabelecimento da ligação e o nº de sequência inicial do servidor. Este segmento pode já transportar dados. 1º Semestre 2009/2010 Redes de Computadores 3.53 Gestão de ligações (cont.) 3-way handshake: Na realidade de é um processo 4-way handshake, a só que o Host B (servidor) aproveita o ACK para enviar o seu SYN. O processo em três passos é necessário para sincronização (e respectiva confirmação) do espaço de numeraçãoescolhido pelos extremos da ligação. Problemas com um hipotético estabelecimento de ligação do tipo 2-way handshake : - possibilidade d de existência i de pacotes duplicados d de uma ligação anterior (entretanto fechada) entre os mesmos extremos da nova ligação; - tentativa maliciosa de envio de informação para uma aplicação no sevidor (spoofing).porexemplo:umnócenviaumpedidodeligaçãoab,alegandoquese trata de A. B envia um ACK a A, que é rejeitado por este (e, eventualmente, pedindo abpara fechar aligação). gç Entre estes dois eventos, C poderia enviar dados para a aplicação em B. 1º Semestre 2009/2010 Redes de Computadores 3.54

28 Gestão de ligações (cont.) exemplos com um hipotético estabecimento em dois passos 1º Semestre 2009/2010 Redes de Computadores 3.55 Gestão de ligações (cont.) t) Fecho da ligação: 1: o cliente envia um segmento de controlo (TCP FIN) para o servidor close client server 2: o servidor recebe o FIN e envia uma confirmação. Envia separadamente um FIN para o cliente. close 3: o cliente recebe o FIN e envia um ACK. Entra no estado de timed wait respondendo com ACK s aos FIN s recebidos 4: o servidor recebe o ACK e fecha a ligação. time ed wait closed 1º Semestre 2009/2010 Redes de Computadores 3.56

29 Gestão de ligações (cont.) Fecho da ligação e a motivação para o estado TIMED_WAIT (ou TIME_WAIT): - Duranteafasedefechodaligação, gç oextremoque iniciou esta fase não pode transitar para CLOSED até ter esperado um intervalo de tempo equivalente a duas vezes o tempo máximo que um datagrama IP, atrasado, pode permanecer na rede (este mecanismo, na prática, é heurístico e o tempo de espera não tem correspondência real com o tempo máximo de atraso dos pacotes ). A questão prende-se com o cenário hipotético de um host enviar um ACK como resposta ao segmento FIN enviado pelo outro extremo, mas não saber se esse ACK foi correctamente recebido. Em consequência, o outro extremo pode eventualmente retransmitir o segmento FIN e este segundo segmento FIN ser atrasado na rede. Se a ligação passasse directamente para CLOSED, então outro par de processos de aplicação poderiam teoricamente abrir a mesma ligação e o segmento FIN da ligação anterior chegar e dar início ao fim da nova ligação. [Na prática, este processo tem sido satisfatório. Mas, na realidade, este problema semelhante ao problema dos três exércitos não tem solução ] 1º Semestre 2009/2010 Redes de Computadores 3.57 Gestão de ligações Cliente TCP Servidor TCP 1º Semestre 2009/2010 Redes de Computadores 3.58

30 Camada de Transporte Serviços da camada de transportet Multiplexagem/desmultiplexagem Serviço não orientado à ligação: UDP Transferência fiável de dados Serviço orientado à ligação: TCP transferência fiável controlo de fluxo gestão de ligações Controlo de congestionamento TCP 1º Semestre 2009/2010 Redes de Computadores 3.59 Controlo de Congestionamento - Introdução Congestionamento: informalmente: demasiadas fontes enviando demasiados dados, demasiado depressa, para uma rede com capacidade limitada Refere-se ao que se passa no interior da rede (não confundir com o problema de controlo de fluxo que tratámos atrás). Manifestações: perda de pacotes (excesso da capacidade de memória nos nós da rede) grandes atrasos (tempo de espera nas filas dos nós) 1º Semestre 2009/2010 Redes de Computadores 3.60

31 Causas e custos do congestionamento: cenário 1 dois emissores e dois receptores um nó com memória ilimitada sem retransmissões grandes atrasos para tráfego intenso existe um valor máximo para o throughput 1º Semestre 2009/2010 Redes de Computadores 3.61 Causas e custos do congestionamento: cenário 2 Tem-se sempre: λ in = λ out ( goodput ) se há retransmissões apenas quando há perdas: λ in >λ out se há retransmissões de pacotes atrasados (não perdidos) então λ in é maior que no caso anterior para o mesmo λ out Custos do congestionamento: para um dado goodput o trabalho nos nós é maior (retransmissões) há retransmissões desnecessárias: uma ligação transporta várias cópias de um pacote 1º Semestre 2009/2010 Redes de Computadores 3.62

32 Causas e custos do congestionamento: cenário 3 Quatro emissores caminhos origem/destino com mais de uma ligação retransmissões/ timeouts timeouts Custo de congestionamento t adicional: i quando um pacote é deitado fora num nó a capacidade gasta nos nós a montante para a sua transmissão é desperdiçada 1º Semestre 2009/2010 Redes de Computadores 3.63 Abordagens ao controlo de congestionamento t Dois tipos de abordagens: Controlo com intervenção da rede: os nós informam explicitamente os sistemas terminais do estado da rede enviando apenas um bit (como, por exemplo em SNA, DECbit, TCP/IP com ECN, ATM) enviando a taxa a que o emissor deve trabalhar (por exemplo, em redes ATM com o protocolo ABR) Controlo extremo a extremo (que é o caso do TCP com sinalização de perdas de pacotes): não há informação explícita fornecida pela rede o estado de congestionamento é inferido pela observação das perdas e também das variações do atraso na chegada dos ACKs 1º Semestre 2009/2010 Redes de Computadores 3.64

33 Controlo de congestionamento t em ATM-ABR ABR Protocolo (e serviço) ABR (Available Bit Rate): elastic service se as ligações origem/destino têm banda disponível: o emissor deve utilizar essa banda se as ligações origem/destino estão congestionadas: o emissor deve reduzir o seu ritmo de transmissão (até um mínimo garantido) Solução: Células/pacotes RM (Resource Management Cells): enviadas pelo emissor entrelaçadas com as células de dados campos nas células RM marcados pelos nós da rede NI bit: não aumentar o ritmo (capacidade próxima do máximo) CI bit: indicação de congestionamento (capacidade excedida) campo ER ( Explicit Rate): indicação explícita do valor do ritmo do emissor células RM devolvidas ao emissor pelo receptor 1º Semestre 2009/2010 Redes de Computadores 3.65 Controlo de congestionamento em ATM-ABRABR dois bytes em cada célula RM para o campo ER ( Explicit Rate ) um nó ( switch ) congestionado pode reduzir o valor inscrito no campo ER O ritmo de transmissão do emissor é o mínimo suportado pelos nós ao longo do caminho origem/destino um bit em cada célula de dados para o campo EFCI ( Explicit Forward Congestion Indication ) pode ser marcado em nós congestionados se as células de dados têm o EFCI bit marcado o receptor marca o bit CI da próxima célula RM 1º Semestre 2009/2010 Redes de Computadores 3.66

34 Controlo de congestionamento no protocolo TCP 1986: observação de uma série de colapsos devidos a congestionamento Conjunto de algoritmos/mecanismos introduzidos a partir de 1988 (itti (sintetizados no artigo de V. Jacobson e M. Karels, Congestion Avoidance and Control, SIGCOMM, 8/1988) : 1988: TCP Tahoe Princípio da conservação do número de pacotes na rede, como método de controlo de congestionamento; Novo mecanismo para cálculo de Timeout (RTO); Mecanismo RTO Exponential Backoff (de Karn); Introdução de janelas de emissor dinâmicas (referidas como cwnd ou congwind), de acordo com o estado de congestionamento; Inclusão das fases Slow Start e Congestion Avoidance; Mecanismo Fast Retransmit (primeira versão). 1º Semestre 2009/2010 Redes de Computadores 3.67 Controlo de congestionamento no protocolo TCP Controlo extremo a extremo (sem intervenção directa da rede) o ritmo de transmissão é limitado pelo tamanho da janela de congestionamento, t Congwin: JANELAS DINÂMICAS NO EMISSOR w segmentos, cada um com tamanho MSS, enviados num intervalo RTT: throughput = w * MSS RTT Bytes/sec 1º Semestre 2009/2010 Redes de Computadores 3.68

35 Controlo de congestionamento no protocolo TCP Teste de banda disponível ( probing for bandwidth ): idealmente: ritmo de transmissão tão grande quanto possível (isto é, Congwin tão grande quanto possível) e sem perdas; ausência de perdas: aumento gradual do tamanho da janela de congestionamento, Congwin perdas: diminuição i i de Congwin; reinício i da fase de teste t de banda, aumentando gradualmente o tamanho da janela. Distinguem-se duas fases: slow start congestion avoidance variáveis importantes: Congwin threshold: define o limiar entre a fase slow start e a fase congestion avoidance 1º Semestre 2009/2010 Redes de Computadores 3.69 Fase slow start no protocolo TCP Algoritmo Slowstart Host A Host B initialize: Congwin = 1 for (each segment ACKed) Congwin++ until (loss event OR CongWin > threshold) RTT Crescimento exponencial (por cada RTT) do tamanho da janela de congestionamento perdas: detectadas por timeout e/ou pela chegada de quatro ACK s (duplicados) do mesmo segmento time 1º Semestre 2009/2010 Redes de Computadores 3.70

36 Fase congestion avoidance / slow start Congestion avoidance /* slowstart is over */ /* Congwin > threshold */ Until (loss event) { every w segments ACKed: Congwin++ } threshold = Congwin/2 Congwin = 1 perform slowstart Em qualquer dos casos, após a detecção da perda por timeout ou por ACKs duplicados, o TCP Tahoe executa a fase Slow Start. Além disso, se a perda for detectada por ACKs duplicados, o segmento dado como perdido é retransmitido de imediato, sem esperar pelo timeout (mecanismo Fast Retransmit). 1º Semestre 2009/2010 Redes de Computadores 3.71 TCP Tahoe Para além do mecanismo modificado para cálculo de Timeout (RTO), das janelas dinâmicas, fases Slow Start e Congestion Avoidance e do esquema Fast Retransmit (mecanismos que já vimos anteriormente), o TCP Tahoe incorporou também: Mecanismo RTO Exponential Backoff (de P. Karn e C. Partridge, Estimating round-trip times in reliable transport protocols, SIGCOMM, 8/1987); Com este mecanismo, pretende-se resolver a seguinte ambiguidade: um pacote é transmitido; é disparado o timeout e o pacote é retransmitido; entretanto chega um ACK; o ACK pertence ao primeiro ou ao segundo pacote? (de notar que, para efeitos de amostragem do valor RTT, são situações muito diferentes) [a propósito ver, por exemplo, RFC2988]. Solução: não calcular um novo RTO até que o ACK se refira a um segmento que não foi re-transmitido (isto é, oemissor só colhe amostras de RTT de pacotes enviados id apenas uma vez, di deixandod de colher as amostras de RTT quando um pacote é retransmitido). Além disso, sempre que há uma retransmissão, opróximotimeout é ajustado para o dobro do anterior (daí o termo exponential backoff), em vez de tomar o último valor estimado. Isto segue um princípio geral de estabilidade, em que uma fonte deve ser cautelosa após uma perda por timeout (que traduz uma situação severa de congestionamento) e não reagir agressivamente. 1º Semestre 2009/2010 Redes de Computadores 3.72

37 Controlo de congestionamento: TCP Reno 1990: TCP Reno (4.3BSD Reno) Inclusão dos mecanismos: Fast Retransmit (modificado) e Fast Recovery [sobre estes mecanismos, ver por exemplo RFC2581, M. Allman, V. Paxson W. Stevens, publicado em Abril 1999] Fast Retransmit modificado: ao detectar perdas por ACKs duplicados, e após retransmitir de imediato o segmento dado como perdido, o TCP Reno não entra na fase Slow Start. Considera-se que a detecção por timeoutt é indicativa de um congestionamento t massivo. Neste casosea fonte recebe 3 ACKs (mesmo que duplicados), isso significa que houve pacotes que deixaram a rede e que provocaram o envio desses mesmos ACKs; portanto presume-se que o congestionamento é moderado. Fast Recovery: esta fase é activada logo após Fast Retransmit: oparâmetrossthresh é alterado para metade do valor de cwnd. Depois, cwnd toma o valor de ssthresh + 3*MSS (isto é, cwnd=cwnd / 2 + 3*MSS). Este aumento (inflação da janela) corresponde aos 3 ACKs duplicados, resultantes do número de segmentos que di deixaram a rede e que foram armazenados temporariamente t pelo receptor. Desta maneira o emissor pode continuar a enviar novos pacotes (aumentando a janela de MSS por cada ACK duplicado adicional), sem paragens excessivamente longas, até que o ACK do pacote retransmitido chegue. Este procedimento segue, genericamente, o princípio p da conservação do número de pacotes na rede. 1º Semestre 2009/2010 Redes de Computadores 3.73 Controlo de congestionamento: TCP Reno Fast Recovery (continuação): Quando todos os ACKs duplicados forem usados, o próximo ACK deverá ser o ACK causado pela retransmissão (que deverá confirmar todos os pacotes, se tiver occorrido apenas uma perda). Nesta altura o emissor deixa o Fast Recovery e cwnd toma o valor de ssthresh (que é de W/2, em que W é ovalor da janela quehavia sido armazenado imediatamente t antes de Fast Recovery, ou seja quando a perda foi declarada). Em qualquer q altura, na ocorrência de um timeout,, o emissor ingressa na fase Slow Start (após (p a retransmissão do segmento), tal como no TCP Tahoe. 1º Semestre 2009/2010 Redes de Computadores 3.74

38 Controlo de congestionamento: TCP Reno EXEMPLO: cenário de transmissão entre E e W, com perda dos segmentos 6 e perda dos ACKs dos segmentos 8 a 11 (RTT=7 ms, T xmt =1 ms, threshold=16, timeout=13 ms, número total de segmentos de dados=20). Neste exemplo a recuperação é feita por timeout. 1º Semestre 2009/2010 Redes de Computadores 3.75 Controlo de congestionamento: TCP Reno EXEMPLO: cenário ái de transmissão entreee e W, com perda do segmento16 (RTT=20 ms, T xmt =1 ms, threshold=8, timeout=30 ms, número total de segmentos de dados=25). Neste exemplo a recuperação é feita por fast retransmit. 1º Semestre 2009/2010 Redes de Computadores 3.76

39 Controlo de congestionamento: TCP Reno EXEMPLO: cenário de transmissão entre E e W, sem perdas de segmentos, mas em que o segmento 15 sofre um atraso adicional de 22 ms (RTT=20 ms, T xmt =1 ms, threshold=8, timeout=45 ms, número total de segmentos de dados=25). 1º Semestre 2009/2010 Redes de Computadores 3.77 Controlo de congestionamento: TCP Reno Observação: tal como o TCP Tahoe, otcp Reno lida mal com múltiplas perdas numa única janela: Exemplo com perda de dois segmentos na mesma janela (segmentos 1 e 3). Diagrama da esquerda: Tahoe; diagrama da direita: Reno. Em ambos os casos, no emissor acaba por disparar o timeout 1º Semestre 2009/2010 Redes de Computadores 3.78

40 TCP Reno: comportamento simplificado da janela do emissor (i.e., a figura não mostra os detalhes es relativos à inflação da janela nos períodos de fast recovery) SS CA time SS: Slow Start CA: Congestion Avoidance Fast retransmission/fast recovery 1º Semestre 2009/2010 Redes de Computadores 3.79 TCP - Et Extensions for high hihperformance [RFC 1323] Em 1993, foram introduzidas id algumas opções (implementação 4.4BSD4 TCP), ) com a designação Extensions for high performance [RFC 1323, 5/1992, V. Jacobson, R. Braden, D. Borman] Window Scale Option - permite janelas com tamanho superior a 2 16 (65 Kbytes). Indicado d para ligações com elevado produto débito*atraso (Long, Fat Pipes). O valor de débito*atraso (em que atraso é o RTT) representa a quantidade de informação que o emissor pode, em princípio, enviar até encher o pipe, por forma a obter o máximo desempenho. RTT measurements with timestamps melhoria na medição (amostragem) de valores de RTT. Protection against wrapped sequences - uso de numeração de sequência em conjunto com os timestamps (que, na prática, contribui com outros 32 bits para a numeração de sequência), prevenindo os problemas associados ao esgotamento do espaço de numeração (em particular, em ligações de grande atraso e débitos elevados). 1º Semestre 2009/2010 Redes de Computadores 3.80

41 TCP SACK (TCP with Selective Acknowledgments) 1996: TCP SACK [RFC 2018 e extensão em RFC 2883] (Ver também, por exemplo, K. Fall, S. Floyd, Simulation-based Comparisons of Tahoe, Reno, and SACK TCP, Computer Communication Review, V. 26 N. 3, July 1996, pp. 5-21) Motivação: reduzir os efeitos de perdas múltiplas de pacotes numa janela de emissão (que afecta tanto o TCP-Reno como TCP-NewReno). Habitualmente, a perda de múltiplos pacotes tem o efeito fi de fazer perder o ACK-based b d clock do TCP e conduzir a longos períodos de inactividade enquanto se recuperam as perdas. O mecanismo SACK é usado pelos extremos da ligação TCP para, opcionalmente, referir a recepção de blocos não contíguos de dados que não sejam cobertos pelo campo de confirmação ACK (Cumulative ACK). De notar que o campo ACK ésempreusado (independentemente da opção SACK ou não) e confirma, em qualquer caso, todos os bytes que foram recebidos até ao momento na ordem correcta (sem buracos ). Ao receber a informação àcerca dos blocos não contíguos de dados, o emissor pode de imediato reenviar os segmentos que não estão cobertos pelos blocos já referidos e cujo número de sequência seja inferior ao do maior já referido. Na prática, se os segmentos não cobertos pelos blocos referidos estiverem de facto perdidos, eles são retransmitidos sem esperar pelo timeout ou por ACKs duplicados. 1º Semestre 2009/2010 Redes de Computadores 3.81 TCP SACK (TCP with Selective Acknowledgments) Existem duas opções SACK: - A SACK permitted option, no cabeçalho do TCP, que ocupa 2 bytes no campo de opções. Deve ser enviada apenas nos segmentos SYN para sinalizar o facto de o emissor suportar a opção SACK. Esta opção será usada posteriormente apenas se ambos os extremos enviarem a SACK permitted option em cada um dos seus segmentos SYN (esta opção é codificada com os valores Kind=4 e Length=2 no campo de opções). - A própria SACK option, que tem tamanho variável e é então usada durante a ligação para confirmar os blocos não contíguos de dados (codificada com Kind=5 e Length=<variável> no campo de opções). Esta opção só pode ser usada durante a ligação se a SACK permitted option for negociada e activada com sucesso durante o estabelecimento da ligação. - De notar que a utilização da SACK option não altera o significado do campo Acknowledgment Number (cumulativo), que é sempre utilizado. 1º Semestre 2009/2010 Redes de Computadores 3.82

42 TCP SACK - SACK Option Head len Source Port # Destination Port # Sequence Number Acknowledgement Number Rcvr Window Size Checksum Ptr urgent data Kind = 1 Kind = 1 Kind = 5 Length? Left Edge of First Block Right Edge of First Block Left Edge of last Block Right Edge of last Block 1º Semestre 2009/2010 Redes de Computadores 3.83 TCP SACK (TCP with Selective Acknowledgments) Ao usar a SACK option, o receptor indica ao emissor a recepção com sucesso e armazenamento de uma série de blocos fora-de-ordem. Os blocos são descritos usando numeração absoluta por bytes, com cada bloco descrito por duas sequências: <extremo esquerdo do bloco K, i.e. o primeiro byte do bloco recebido com sucesso> <extremo direito do bloco K, i.e. o número de sequência do byte imediatamente a seguir ao último byte do bloco>. Dois blocos consecutivos indicam um buraco de dados perdidos entre eles. São usados, no campo de opções, 8*n+2 bytes para confirmação de n blocos distintos. O máximo número de blocos permitidos é 4 (o campo de opções pode ter até 40 bytes). Se a opção timestamp for usada, então apenas é possível sinalizar até 3 blocos. O receptor confirma sempre o segmento recebido mais recente no primeiro bloco SACK, juntamente com outros blocos se o espaço permitir. Isto permite ao emissor manter uma imagem (o mais actual possível) da memória do receptor. 1º Semestre 2009/2010 Redes de Computadores 3.84

43 TCP SACK (TCP with Selective Acknowledgments) Exemplo de SACKs enviados pelo receptor: admitamos que o extremo esquerdo da janela do emissor está em 5000 e que o emissor envia uma rajada de 8 segmentos, com 500 bytes de dados cada. Transm itter R eceiver Caso 1: Os primeiros 4 segmentos são recebidos mas os últimos 4 são perdidos. Neste caso, o receptor envia um ACK normal, com número de sequência 7000 (isto é, confirmando até ao byte 6999), sem a opção SACK : : : : x : : : : :8999 ACK 7000 x 1º Semestre 2009/2010 Redes de Computadores 3.85 TCP SACK (TCP with Selective Acknowledgments) Caso 2: O primeiro segmento é perdido, mas os restantes 7 segmentos são bem recebidos. Transm itter Receiver Neste caso, o receptor envia vários ACKs com número de sequência 5000 (isto é, confirmando a boa recepção, na ordem, até ao byte 5499), mas com a opção SACK especificando um bloco de dados (armazenados). [LE = Left Edge; RE = Right Edge] AC K 5000; LE 5500; RE: 6000 AC K 5000; LE 5500; RE: 6500 AC K 5000; LE 5500; RE: 7000 AC K 5000; LE 5500; RE: 7500 AC K 5000; LE 5500; RE: 8000 AC K 5000; LE 5500; RE: 8500 AC K 5000; LE 5500; RE: x : : : : : : : :8999 1º Semestre 2009/2010 Redes de Computadores 3.86

44 TCP SACK (TCP with Selective Acknowledgments) Caso 3: O segundo, quarto, sexto e oitavo (último) segmento são perdidos. Transm itter Receiver Neste caso, o receptor faz o seguinte: a) SACK não usado; b) Envia SACK confirmando 1 bloco não contíguo: LE=6000 e RE=6500; c) Envia SACK confirmando 2 blocos: 1) LE=7000 e RE=7500; 2) LE=6000 e RE=6500; d) Envia SACK confirmando 3 blocos: 1) LE=8000 e RE=8500; 2) LE=7000 e RE=7500; 3) LE=6000 e RE= (a) AC K 5500 (b ) A C K (c ) A C K (d ) A C K : : : : : : : : x x x x 1º Semestre 2009/2010 Redes de Computadores 3.87 TCP NewReno 1999: TCP NewReno [RFC 2582, S. Floyd et al., de 1999; a ideia de resposta a um ACK parcial foi inicialmente proposta por J. Hoe em 1995] Motivação: Reduzir os efeitos negativos de múltiplas perdas numa janela (verificados no TCP Reno e TCP Tahoe). Dado que, habitualmente, os pacotes são enviados em rajadas (devido, entre outras coisas, à natureza do protocolo de janela deslizante executado no TCP) as perdas afectam mais do que um pacote de uma só vez, tornando muito ineficiente os mecanismos Fast Retransmit/Fast Recovery. Embora o TCP NewReno se comporte melhor do que o TCP Reno, a opção TCP SACK é a que tem melhor desempenho num cenário de múltiplas perdas. Em muitos cenários, otcp NewReno também é afectado se não se usar a opção TCP SACK. A modificação proposta em RFC2582 destina-se se então a entidades TCP que não possam usar a opção TCP SACK (porque no caso de esta opção esxistir, o problema das múltiplas perdas fica, em princípio, praticamente resolvido). 1º Semestre 2009/2010 Redes de Computadores 3.88

45 TCP NewReno O esquema Fast Retransmit (no TCP Reno) assume que ocorreu apenas uma perda (esporádica) por janela. Vimos anteriormente que, se mais do que um segmento for perdido, isso pode resultar em timeouts para recuperar das perdas. Os esquemas Fast Retransmit / Fast Recovery invocados sucessivamente, conduzem a uma série de decrementos multiplicativos de ssthresh e cwnd, reduzindo muito o débito da ligação TCP. O TCP NewReno introduz uma pequena alteração face ao TCP Reno, através da ideia de ACKs parciais: quando existem múltiplas perdas numa janela, o ACK do pacote retransmitido confirma alguns, mas não todos os segmentos enviados antes de Fast Retransmit. 1º Semestre 2009/2010 Redes de Computadores 3.89 TCP NewReno No TCP Reno, o primeiro ACK parcial conduz o emissor para fora da fase Fast Recovery. No TCP NewReno, um ACK parcial é uma indicação de que se perderam mais pacotes e portanto o emissor retransmite o primeiro pacote não confirmado e mantém-se na fase Fast Recovery. Desta forma o emissor retransmite um pacote (perdido) aproximadamente por cada RTT até que todos os pacotes sejam retransmitidos (e vai transmitindo novos pacotes, se os tiver, através do mecanismo de inflação da janela), não invocando múltiplos Fast Retransmit numa única janela de dados. 1º Semestre 2009/2010 Redes de Computadores 3.90