Capítulo 3 Camada de Transporte

Transcrição

1 Curso de Redes de Computadores Adriano Mauro Cansian Capítulo 3 Camada de Transporte 1

2 Capítulo 3: Camada de Transporte Metas do capítulo: q q Compreender os princípios dos serviços da camada de transporte:. Transferência confiável de dados. Controle de fluxo. Controle de congestionamento. Implementação na Internet. O que veremos: q q q q q q q Serviços da camada de transporte. Multiplexação / desmultiplexação. Transporte sem conexão: UDP. Princípios de transferência confiável. Qual a ideia e como surgiu Transporte orientado a conexão: TCP Transferência confiável Controle de fluxo Gerenciamento de conexões Princípios de controle de congestionamento. Controle de congestionamento em TCP. 2

3 Cuidado com conceitos! Muito material errado ou ruim na Internet! (apesar de outros muito bons) 3

4 Comparação entre as camadas Camada Transporte à ligada a processos Comunicação lógica entre processos. Camada de rede à ligada a hosts Comunicação lógica entre hosts. Esta distinção é sutil, mas MUITO importante. 4

5 MANAUS Comparação entre camadas exemplo: Maria Rua dos Bichos, No. 32, Manaus, AM Correio João Rua dos Santos, No. 400, , S.Paulo, SP S.Paulo 5

6 Camada de Transporte X Camada de Rede (1) q Exemplo: 6 irmãos moram numa casa em São Paulo, SP. e 5 irmãos em outra casa em Manaus, AM. Os de S. Paulo são primos daqueles em Boa Vista. unesp - IBILCE - SJRP Escrevem cartas entre SP e AM regularmente. q Em São Paulo: Os irmãos de cada lado: João recolhe as cartas, e as entrega ao correio. q Em Manaus: Maria recolhe as cartas, e as entrega ao correio. E os dois Também recebem e fazem a distribuição local das cartas que chegam para os irmãos. 6

7 MANAUS Correio Rua dos Bichos, No. 32, Manaus, AM S.Paulo Rua dos Santos, No. 400, , S.Paulo, SP 7

8 Camada de Transporte X Camada de Rede (2) unesp - IBILCE - SJRP q Hosts (devices / end systems) = Casas. q Processos = pessoas que trocam mensagens. q Mensagens da aplicação = cartas em envelopes. q Protocolo da camada de rede: Serviço postal (correio). q Protocolo da Camada de Transporte: João (de um lado) e Maria (do outro). 8

9 Serviços e protocolos de TRANSPORTE (1) q Do ponto de vista da APLICAÇÃO a camada de transporte permite enxergar os sistemas como se eles estivessem fisicamente conectados. Comunicação lógica entre processos de aplicação executando em hosts diferentes. 9

10 Serviços e protocolos de TRANSPORTE (2) Dois Serviços de transporte: 1. Entrega confiável, ordenada, ponto a ponto: TCP. Conexão (setup). Controle Congestionamento. Controle de fluxo. aplicação transporte rede enlace física rede enlace física rede enlace física rede enlace física rede enlace física rede enlace física 2. Entrega não confiável, ( melhor esforço ), não ordenada, ponto a ponto ou aplicação transporte rede enlace física multiponto: UDP. 10

11 Multiplexação/desmultiplexação unesp - IBILCE - SJRP q MULTIPLEXAÇÃO: Juntar dados de múltiplos processos de aplicações, envelopando dados com cabeçalho. q DEMULTIPLEXAÇÃO: entrega de segmentos recebidos para os processos da camada de aplicação corretos. cabeçalho de segmento segmento dados da camada de aplicação Ht M Hn segmento P1 M aplicação transporte rede P3 receptor M M aplicação transporte rede P4 M P2 aplicação transporte rede 11

12 Fluxo de encapsumaneto 12

13 Fluxo de desencapsulamento 13

14 Encapsulamento / desencapsulamento 14

15 Portas são fundamentais Multiplex / demultiplex: q Baseadas em números de porta e endereços IP de remetente e receptor: Números de porta de remetente/receptor são enviados em cada segmento. Número de porta são conhecidas para aplicações específicas (WKS): na porta 25, telnet na porta 23, http na porta 80, e assim por diante. porta emissor 32 bits outros campos do cabeçalho dados da aplicação (mensagem) porta receptor formato genérico de segmento TCP/UDP 15

16 Os protocolos de Transporte UDP User Datagram Protocol 16

17 UDP: User Datagram Protocol [RFC 768] q Protocolo de transporte muito simples. q Best Effort: Serviço melhor esforço. Faz com que segmentos UDP possam ser: Perdidos. Entregues fora de ordem à aplicação. q Sem conexão: Não há setup entre remetente e receptor. Não há manutenção status (é stateless). Tratamento independente de cada segmento. q Sem controle de congestionamento ou de fluxo. 17

18 UDP: User Datagram Protocol [RFC 768] Por quê existe um UDP? q Elimina estabelecimento de conexão: Reduz delay de partida lenta. q Simples: não mantém estado : Stateless. q Pequeno cabeçalho de segmento: Mais simples = menos desperdício de dados (overhead) q Sem controle de congestionamento nem de fluxo: UDP pode transmitir o mais rápido possível que puder. 18

19 Mais sobre UDP q Muito utilizado para aplicações de mídia (voz, vídeo). São tolerantes a perdas. São sensíveis à taxa de transmissão. q Outros usos de UDP : DNS (servidor de nomes). SNMP (gerenciamento). q Transferência confiável com UDP: só pode incluir confiabilidade na camada de aplicação. Recuperação de erro fica por conta da aplicação! Comprimento em bytes do segmento UDP, incluindo cabeçalho porta origem comprimento 32 bits Dados de aplicação (mensagem) porta dest. checksum Formato de um sgmento UDP 19

20 Cálculo do Checksun (válido para o UDP e o TCP) 20

21 Checksum UDP - EMISSOR Finalidade: detectar falha no segmento transmitido. Emissor: q Trata o segmento como sequência de inteiros de 16-bits. q Checksum: é a soma (adição usando complemento de 1) do conteúdo do total do segmento. q Considera o campo checksum como zeros (para fazer o cálculo). q Inclui os dados carregados. (checksum do IP NÃO cobre dados visto mais adiante). Inclui um pseudoheader no cálculo (visto adiante). q Então o EMISSOR coloca complemento de um do valor da soma no campo checksum de UDP. q E então envia o segmento. 21

22 Pseudo Header (1) q UDP (*) usa um pseudo header no cálculo do checksum. Usa informações da camada IP (16 bytes). Checksum usa os headers (pseudo header e header UDP), e os dados do UDP. q Comprimento do UDP pode ser um número ímpar de bytes. Algoritmo do checksum soma palavras de 16 bits. Solução: adicionar preenchimento ( padding) de zeros, no final, se necessário, caso o número de bytes seja ímpar. Padding não é transmitido. (*) assim como o TCP) 22

23 Pseudo Header (2) Pseudo header IP (usado pelo UDP) (16 bytes) Header UDP (8 bytes) Explique por que ocorre uma violação da independência das camadas. (29/04/2017) 23

24 Checksum UDP - RECEPTOR Receptor (na chegada): q Soma os campos de header do segmento recebido, incluindo o valor que está no campo checksum. Como colocou o complemento de 1 no campo checksum, quando somar tudo tem que resultar num valor com todos os bits iguais a 1. q Verifica se o valor RESULTANTE é todo igual a 1: NÃO - erro detectado. SIM - nenhum erro detectado. Mas ainda pode haver erros? (Veremos mais adiante.) 24

25 Exemplo de cálculo do checksum (3) 25

26 Exemplo de cálculo do checksum (1) Considere 3 palavras de 16 bits sendo transmitidas: A soma das duas primeiras palavras é: Adicionando a terceira palavra, a soma acima fica: soma unesp - IBILCE - SJRP Ver RFC-1071! q Os complementos de 1 são obtidos convertendo todos os 0 s para 1 s, e todos os 1 s para 0 s

27 Exemplo de cálculo do checksum (2) unesp - IBILCE - SJRP Assim o complemento de 1's da soma q Este valor se torna o checksum. é

28 Exemplo de cálculo do checksum (2) unesp - IBILCE - SJRP Assim o complemento de 1's da soma q Este valor se torna o checksum. é q No receptor, todas as palavras de 16 bits são somadas, incluindo o campo checksum. q Se não foram introduzidos erros no pacote, a soma no receptor tem que resultar em uma vez que somou-se ao header o complemento de 1 da soma dele. q Se pelo menos um dos bits for zero, então algum erro foi introduzido no pacote. Pergunta exercício: Por que o UDP usa checksum, se a maioria dos protocolos data-link (inferiores), incluindo o popular Ethernet, também fornece verificação de erro?? 28

29 Lembrete 1: método Polinomial 29

30 Lembrete 2: carry 30

31 Exemplo de soma de verificação da Internet unesp - IBILCE - SJRP q nota Ao somar números, um carryout do bit mais significativo precisa ser somado ao resultado q exemplo: somar dois inteiros de 16 bits contorna soma soma de verificação

32 Princípios de Transferência Confiável de Dados Reliable Data Transfer (RDT) 32

33 Cenário para estudar Reliable Data Transfer (RDT) q Queremos tornar um canal não confiável num canal confiável. Características do canal não confiável determinam a complexidade de um protocolo de transferência confiável de dados (RDT). 33

34 Transferência confiável de dados (RDT) Como começar? unesp - IBILCE - SJRP rdt_send( ): chamada da camada superior, (Ex: pela aplicação). Passa dados para entregar à camada superior receptora deliver_data(): chamada por rdt para entregar dados para camada superior. emissor receptor udt_send(): chamada por ambos os lados para troca de pacotes de controle. UDT representa um unreliable data transfer (troca não confiável) rdt_rcv(): chamada quando pacote chega no lado receptor do canal. 34

35 Transferência confiável de dados (rdt): como começar Iremos: q Desenvolver passo-a-passo os lados remetente e receptor do protocolo confiável RDT. q Vamos Considerar apenas fluxo unidirecional de dados. Mas a informação de controle flui em ambos sentidos! q Usar máquinas de estados finitos (FSM - Finite State Machine) para especificar remetente e receptor. ESTADO: quando o sistema está num estado, o próximo estado é determinado unicamente pelo próximo evento. estado 1 evento causando transição de estados ações tomadas na transição de estado evento ações estado 2 35

36 Como iremos analisar: q Para entender a evolução das ideias sobre RDT, vamos fazer considerações sobre características que podem estar presentes no canal. Exemplos: canal pode entregar dados fora de ordem, inverter bits, perder bits, dentre outros. q Importante: entender que RDT ainda não é o TCP, mas é de onde ele veio. Trata-se de como o TCP evoluiu. 36

37 RDT 1.0: transferência confiável usando um canal confiável q Suposição 1.0: o canal é perfeitamente confiável. Não apresenta erros de bits. Não apresenta perda de pacotes. q FSMs separadas, para remetente e receptor: Remetente envia dados pelo canal subjacente. Receptor recebe dados do canal subjacente. Evento que causou a transição Observação: Isso não existe!! Ações tomadas quando ocorre um evento 37

38 RDT Modelo um pouco mais realista: q Bits num pacote podem ser corrompidos. Falhas podem ocorrer nos componentes físicos da rede: Por exemplo, quando um pacote é transmitido, acontece inversão de 1 bit. q Entretanto, continuamos supondo que todos os pacotes transmitidos são recebidos na ordem em que são enviados. Ainda que bits possam estar corrompidos. 38

39 Rdt2.0: canal com erros de bits unesp - IBILCE - SJRP q Canal pode inverter bits no pacote. O checksum pode detectar erros de bits. q A questão é: como recuperar dos erros? 39

40 Rdt2.0: canal com erros de bits q Canal pode inverter bits no pacote. O checksum pode detectar erros de bits. q A questão é: como recuperar dos erros? Uma boa ideia: usar mensagens de controle. Confirmação (ACK): receptor avisa explicitamente ao remetente que pacote chegou bem. Negativa de Confirmação (NAK): receptor avisa explicitamente ao remetente que pacote tinha erros. Emissor retransmite pacote ao receber um NAK ( Lembrar de cenários humanos usando ACKs, NAKs ) 40

41 Mensagens de controle q Permitem o receptor informar ao emissor o que foi recebido corretamente. E o que foi recebido com erro, exigindo retransmissão. q Protocolos baseados em retransmissão são chamados de Protocolos ARQ: Automatic Repeat request. Requisição Automática de Repetição. 41

42 Novas capacidades em RDT 2.0 q 3 capacidades adicionais são exigidas em protocolos de ARQ para lidar com a presença de erros de bits: 1. Detecção de erros: mecanismo para permitir que o receptor identifique quando erros de bit ocorreram. 2. Realimentação (feedback) pelo receptor: mensagens de controle (ACK ou NAK) devem ser trocadas entre receptor e o emissor. 3. Retransmissão: para corrigir os erros detectados. Estes novos mecanismos estão presentes na proposta de protocolo rdt

43 rdt2.0: especificação da FSM - Emissor Aguarda dados da aplicação 1 Possui 2 estados: Em um estado aguarda dados da camada superior. Em outro estado, aguarda ACK ou NACK do receptor Aguarda ACK ou NACK do receptor 2 Se recebe um NACK, re-envia o último pacote atual, e retorna a aguardar um ACK ou NACK. Não pode aceitar dados da camada superior (stop-and-wait) 3 Se recebe um ACK confirmando que o dado atual foi recebido, retorna ao estado de aguardar um pacote da camada superior 43

44 rdt2.0: especificação da FSM - Receptor unesp - IBILCE - SJRP Possui apenas 1 estado: ao receber um pacote, responde com ACK ou NACK, dependendo se o pacote está ou não corrompido. Pacote recebido apresenta erro. Emite um NACK, e retorna ao estado de aguardar. Pacote recebido está íntegro. Emite um ACK, confirmando e retorna ao estado de aguardar. 44

45 rdt2.0: em ação (sem erros) FSM do remetente FSM do receptor 45

46 rdt2.0: em ação (cenário de erro) FSM do remetente FSM do receptor 46

47 Mas o RDT 2.0 tem um problema fatal... 47

48 RDT 2.0 tem uma falha fatal: q O que acontece se ACK ou NACK com erro? Emissor não sabe o que aconteceu no receptor! Não se pode apenas retransmitir: há possibilidade de pacotes duplicados. O que fazer? q Emissor usaria ACKs / NAKs para ACK / NAK do receptor? E se corromper ACK/NAK do remetente? q Retransmitir? Pode causar retransmissão de pacote recebido certo! 48

49 RDT 2.0 tem uma falha fatal! q q O que acontece se ACK ou NACK com erro? Remetente não sabe o que aconteceu no receptor! Não se pode apenas retransmitir: há possibilidade de pacotes duplicados. O que fazer? q Remetente usa ACKs/NAKs p/ ACK/NAK do receptor? E se perder ACK/NAK do remetente? q Retransmitir? Mas pode causar retransmissão de pacote recebido certo! Lidando com duplicação: q Emissor inclui número de sequência para cada pacote. q Emissor retransmite pacote atual se ACK / NAK for recebido com erro. q Receptor descarta pacote duplicado. Stop and wait Remetente envia um pacote, e então aguarda resposta do receptor. 49

50 RDT 2.1: EMISSOR como trata ACK/NAKs com erro 1 Insere No. de sequência 0 no pacote 2 4 Aguarda a chegada do No. Seq. correto 3 Deve verificar se ACK/NAK recebido tinha erro 50

51 RDT 2.1: RECEPTOR como trata ACK/NAKs com erro Pacote corrompido Deve checar se pacote recebido é duplicado. O estado indica se No. de sequência esperado é 0 ou No. Seq. errado 51

52 RDT 2.1: discussão (1) EMISSOR: q Insere No. de sequência (seq#) no pacote. q Bastam dois Nos. de sequência (0 ou 1). q Deve verificar se ACK/NAK recebido tem erro. q Duplicou o No. de estados (compare com RDT 2.0): Tem que lembrar se o pacote atual tem o número de sequência 0 ou 1. Aqui surge uma das primeiras características do TCP: manutenção de status (statefull protocol). 52

53 rdt2.1: discussão (2) RECEPTOR: q Deve checar se pacote recebido é duplicado. Estado indica se No. de sequência esperado é 0 ou 1. q Receptor não tem como saber se último ACK/NAK foi recebido bem pelo emissor. Ele não tem como ter contato direto com o emissor, a não ser por intermédio da indicação de pacotes trocados. 53

54 Exercício: RDT 2.2: um protocolo sem NAKs Fica como exercício fazer esta abstração sem NAK q Mesma funcionalidade que RDT 2.1, mas apenas com ACKs. q Ao invés de NAK, receptor envia ACK para o último pacote recebido corretamente. EMISSOR Receptor deve incluir explicitamente o No. de sequência do pacote confirmado.! q ACK duplicado no emissor resulta na mesma ação que o NAK: retransmite pacote atual. 54

55 RDT 3.0: canal com erros e perdas (1) unesp - IBILCE - SJRP Nova suposição: além de corromper dados, o canal também pode perder pacotes. Pode perder dados ou ACKs. Só vamos usar ACKs e não mais NAKs. q Como lidar com perdas? Como detectar perda de pacotes? O que fazer quando pacotes são perdidos? Checksum, No. de sequência, ACKs, e retransmissões podem ajudar, mas não serão suficientes. 55

56 rdt3.0: canais com erros e perdas (2) q Solução: emissor aguarda o ACK que está em trânsito, por um determinado tempo. q Exige uso de temporizadores (timers). Se há evento de Timeout à esgotamento do timer: Retransmite se nenhum ACK for recebido neste tempo. q Mas: se pacote (ou o ACK) está apenas atrasado (não perdido): A retransmissão será duplicada. Mas o uso de número de sequência resolve este problema. Receptor deve avisar o número de sequência do pacote que está sendo confirmado. 56

57 RDT 3.0: EMISSOR Inicia o timer e aguarda o ack 1 2 Esgotou o timer: reenvia o anterior 57

58 RDT 3.0 em ação (1) 58

59 RDT 3.0 em ação (2) Descarta pkt1 duplicado Descarta pkt0 duplicado 59

60 RDT últimas palavras q Terminamos os estudos da criação dos protocolos RDT e das ideias que deram origem a eles. Eles serão a base para o TCP, mas ainda não são o TCP. q Em seguida veremos agora os protocolos dutados, que se juntarão ao RDT para formar o TCP. É importante entender bem as ideias do RDT, para poder prosseguir. 60

61 Protocolos dutados (pipelined) 61

62 Problema com protocolo stop & wait q Em longas distâncias: retardo fim-a-fim é grande. q Pacote pode estar em trânsito, e ainda não foi confirmado. q O emissor fica bloqueado até receber o ACK do pacote anterior. 62

63 Desempenho de rdt3.0 q RDT 3.0 funciona, porém seu desempenho é muito ruim. q Exemplo - considere: Link de 1 Gbps (10**9 bits/seg); Pacote de 1 KByte (8K bits) Retardo fim-a-fim de 15 ms : T transmissão = 8 kbits/pacote 10**9 b/seg = 8 microseg Tempo de ida e volta = 30 ms + 16 microseg Desempenho = 8 microseg mseg = 0,00027 = 0,027 % Pacote de 1KB a cada 30 mseg vazão de 33 Kbyte / seg num enlace 1 Gbps. Conclusão: Protocolo limita uso dos recursos físicos. 63

64 Protocolos dutados (pipelined) Dutagem (pipelining): emissor admite múltiplos pacotes em trânsito, ainda não confirmados. unesp - IBILCE - SJRP Faixa de números de sequência deve ser aumentada. Exigirá Buffers no remetente e/ou no receptor. q Duas formas genéricas de protocolos dutados : Volta-N (GBN Go Back N) Retransmissão Reletiva (SR - Selective Repeat). 64

65 GBN - Go Back N (1) q Também conhecido como Volta-N. Permite o EMISSOR enviar múltiplos pacotes, sem aguardar ACK do receptor. q Entretanto: Não poderá haver mais do que um valor máximo de N pacotes não confirmados no canal. 65

66 GBN - Go Back N (2) send_base = Seq. # do pacote mais antigo não confirmado no duto. nextseqnum = Menor Seq. # não usado (Seq.# do próximo a enviar). [0, send_base - 1] = Pacotes transmitidos e confirmados (verde) [send_base, nextseqnum - 1] = Pacotes enviados mas não confirmados (amarelo) [nextseqnum, send_base + N - 1] = Disponíveis para serem usados imediatamente, assim que dados chegarem da camada superior (azul). Sequence number (send_base + N) : não podem ser usados até que um pacote não confirmado que esteja atualmente no duto tenha sido confirmado (brancos). 66

67 GBN - Go Back N (3) q No EMISSOR: O intervalo de números de sequência para pacotes transmitidos, mas ainda não confirmados, poder ser visto como uma janela (window) de tamanho N sobre o intervalo de números de sequência. q À medida que o protocolo opera, a janela se desloca sobre o espaço de números de sequência: sliding-window protocol = Janela deslizante. Pergunta: por que limitar o número de pacotes não confirmados? (exercício) 67

68 GBN: FSM estendida do EMISSOR (1/3) Recebe um ACK(n): confirma que todos pacotes até, e inclusive, o No. de sequência n foram recebidos no receptor: ACK cumulativo pode receber ACKs duplicados Chamada superior: verifica se a janela está cheia. Se não está, forma o pacote e envia. Se está cheia, recusa. Temporizador Timeout(n): retransmite pacote n e todos os pacotes com No. de sequência maiores na janela. 68

69 GBN: FSM estendida do EMISSOR (2/3) Se ocorrer um esgotamento do temporizador, o emissor reenvia TODOS os pacotes que tinham sido previamente enviados, mas que ainda não tinham sido reconhecidos. 2 Temporizador: é um cronômetro para o pacote mais antigo transmitido, mas que ainda não foi reconhecido 69

70 GBN: FSM estendida do EMISSOR (3/3) Se for recebido um ACK, e ainda houver pacotes enviados mas ainda não confirmados, o timer será reiniciado. Se não houver nenhum pacote pendente (aguardando confirmação), então o timer é desligado. Temporizador: é um cronômetro para o pacote mais antigo transmitido, mas que ainda não foi reconhecido 70

71 GBN: FSM estendida do RECEPTOR Receptor é muito simples: q Usa apenas ACK: sempre envia ACK para pacote recebido o.k. com o maior número de sequência em ordem. Pode gerar ACKs duplicados Só precisa se lembrar do expectedseqnum q Se recebe Pacote fora de ordem: expectedseqnum = expectedseqnum + 1 Descarta (não armazena) receptor não usa buffers. (TCP usa!) Manda ACK de pacote com maior No. de sequência em ordem. 71

72 GBN em ação Confirma os pacotes 0 e 1 Janela = 4. Envia de 0 a 3 e o 2 se perde Pacote 2 se perdeu. Descarta o 3 e pede o 2 (confirma o 1). Descarta o 4 e o 5, e continua pedindo o 2. Timeout do ack de 2. Retransmite o 2. 72

73 GBN não é o TCP q GBN incorpora quase todas as técnicas que serão encontradas nos componentes do TCP (visto mais adiante): Número de sequência. Checksum. ACK cumulativos. Timeouts. Operação de retransmissão. q Entretanto existem diferenças entre o TCP e o GBN. q Por exemplo: implementações TCP fazem buffering de segmentos recebidos corretamente, mas fora de ordem. q TCP é um híbrido de GBN e Repetição Seletiva (a seguir). 73

74 Problemas do GBN q GBN tem problemas de performance. Se o tamanho da janela é grande e o atraso da rede também é grande, muitos pacotes podem estar no duto. Um único erro em um segmento resulta na retransmissão de um grande número de segmentos, a maioria desnecessários. q À medida em que a probabilidade de erro do canal cresce, o duto fica lotado de retransmissões desnecessárias. 74

75 Repetição Seletiva 75

76 Repetição seletiva (1/2) q Evita retransmissões desnecessárias. q Emissor: retransmite apenas os pacotes que suspeita terem sido recebidos com erro pelo receptor. q Receptor: confirma individualmente todos os pacotes recebidos corretamente. Armazena pacotes no buffer, se necessário, para posterior entrega em ordem à camada superior. 76

77 Repetição seletiva (2/2) q Uma vez que o emissor apenas re-envia pacotes para os quais o ACK não foi recebido à Complica um pouco: É necessário um Timer de EMISSOR para cada pacote sem ACK. q Janela do emissor: N números de sequência consecutivos. Deve limitar os Nos. de sequência de pacotes enviados, mas ainda não reconhecidos. 77

78 Repetição seletiva: janelas de remetente e receptor O emissor já terá recebido confirmação para alguns pacotes da janela. 78

79 Repetição seletiva no EMISSOR (1/2) q Dados recebidos de acima: Emissor verifica o próximo No. sequência disponível. Se o No. de sequência estiver dentro da janela do emissor, os dados são empacotados e enviados; Caso contrário são bufferizados ou devolvidos à camada superior para transmissão posterior. q Timeout: temporizadores são usados para proteger contra perda de pacotes. Somente um único pacote será transmitido no caso de timeout. 79

80 Repetição seletiva no EMISSOR (2/2) q ACK recebido: emissor marca o pacote como recebido. Se o número de sequência do pacote for igual à send_base, então a base da janela avança até o pacote com o menor número de sequência não-confirmado. Se houver pacotes não transmitidos, com números de sequência que caem agora dentro da janela, estes pacotes são transmitidos. 80

81 Repetição seletiva: janelas de emissor e receptor O emissor já terá recebido confirmação para alguns pacotes da janela. 81

82 Eventos de SR no receptor (1) 1.) Pacote com número de sequência no intervalo [ rcv_base, rcv_base+n-1] é recebido corretamente: Neste caso, o pacote recebido cai dentro da janela do receptor. Um ACK seletivo é retornado ao remetente. Se o pacote não foi recebido previamente, ele é armazenado. unesp - IBILCE - SJRP Se este pacote tiver um número de sequência igual à base da janela da recepção (rcv_base), então este pacote, e os quaisquer pacotes previamente armazenados e numerados em sequência (começando com o rcv_base) são entregues à camada superior. A janela de recepção é movida então para a frente pela quantidade do número total dos pacotes entregues à camada superior. 2.) Pacote com número de sequência é recebido dentro de [ rcv_base-n, rcv_base-1 ]: Neste caso, um ACK deve ser gerado, mesmo que este seja um pacote que o receptor já tenha confirmado previamente. 3.) Caso contrário: Ignora o pacote. 82

83 Eventos de SR no receptor (2) unesp - IBILCE - SJRP 4.) Pacote com número de sequência é recebido dentro de [ rcv_base-n, rcv_base-1 ]: Neste caso, um ACK deve ser gerado, mesmo que este seja um pacote que o receptor já tenha confirmado previamente. [ rcv_base-n, rcv_base-1 ]: pacotes já confirmados anteriormente Intervalo dentro da janela [ rcv_base, rcv_base+n-1] 83

84 Repetição seletiva - resumo unesp - IBILCE - SJRP emissor Dados de cima: q Se próximo No. de sequência na janela à envia o pacote. Timeout(n): q Reenvia pacote n. q Reinicia o temporizador. ACK(n) em [sendbase,sendbase+n]: q Marca pacote n como recebido. q Se N for menor pacote não confirmado, avança base da janela ao próximo No. de sequência não confirmado. receptor Pacote n dentro de [rcvbase, rcvbase+n-1]: Envia ACK(n). Fora de ordem: buffering. Em ordem: entrega (tb. entrega pacotes em ordem do buffer), avança janela p/ próximo pacote ainda não recebido. Pacote n em [rcvbase-n,rcvbase-1] ACK(n), mesmo que já tenha enviado antes. Senão: Ignora. 84

85 Retransmissão seletiva em ação perde pkt2 unesp - IBILCE - SJRP Timeout pkt2 Janela se move depois de recebidos ack0 e ack1 buferizados 85

86 Retransmissão seletiva em ação perde pkt2 unesp - IBILCE - SJRP Timeout pkt2 Janela se move depois de recebidos ack0 e ack1 buferizados Completa com o pkt2 que faltava, entrega 2,3,4,5 à 86 camada superior, e envia ack2.

87 Repetição seletiva: dilema unesp - IBILCE - SJRP Exemplo: q Nos. de sequência: 0, 1, 2 e 3. q Tamanho de janela = 3. q Exercício: Qual a diferença entre os dois cenários (a.) e (b.) para o receptor? 87

88 Repetição seletiva: dilema unesp - IBILCE - SJRP Exemplo: q Nos. de sequência : 0, 1, 2 e 3. q Tamanho de janela = 3. q Receptor não vê diferença entre os dois cenários (a.) e (b.)!!! Pergunta / exercício: Qual a relação entre tamanho de No. de sequência e tamanho de janela? Um tamanho de janela que seja igual ao tamanho de numeração sequencial, menos 1, não vai 88 funcionar.

89 O TCP A implementação do TCP 89

90 TCP: Visão geral (1) RFCs: 793, 1122, 1323, 2018, 2581 unesp - IBILCE - SJRP q Processo-a-processo: Peer process fala diretamente com outro peer process. q Entrega fluxo de bytes ordenados e confiável: q Dutado (pipelined): Tamanho da janela ajustado por controle de fluxo e congestionamento do TCP. q Usa Buffers de envio e recepção, e variáveis de estado para cada conexão. 90

91 TCP: Visão geral (2) RFCs: 793, 1122, 1323, 2018, 2581 q O tráfego é Full Duplex: unesp - IBILCE - SJRP 1500 bytes, 536 bytes ou 512 bytes Fluxo de dados bi-direcional na mesma conexão. MSS: é o tamanho máximo de segmento de dados. (Falaremos de MSS mais adiante) q É orientado a conexão: Handshaking de 3 vias (troca de msgs de controle) inicia estado de remetente, receptor antes de trocar dados. q Tem o Fluxo controlado: o receptor não será afogado. 91

92 TCP: estrutura do segmento URG: dados urgentes (pouco usado) Tamanho do header em palavras de 32 bits ACK: No. ACK é válido RST, SYN, FIN: gestão de conexão (comandos de estabelecimento, liberação) checksum Internet (como UDP) No. porta origem 32 bits No. porta dest número de sequência (SEQ#) número de confirmação (ACK#) tam. sem cab. uso U A P R S F checksum janela receptor ptr dados urg. Opções (tamanho variável) dados da aplicação (tamanho variável) PSH = push: força envio de dados imediatamente. Contagem de dados por bytes (não segmentos!) No. bytes que o receptor quer aceitar: Controle de Fluxo. 20 bytes fixos no header 92

93 Header TCP q q q q q Porta Origem e Porta Destino identificam o processo de aplicação que está enviando dados e o processo de aplicação que irá receber os dados. Número de sequência (SEQ#) identifica os bytes enviados. Na prática ele é a identificação do primeiro byte de dados contido no segmento enviado. Os demais são seqüenciados a partir deste byte. Acknowledgement (ACK#) identifica os bytes que foram recebidos e tratados sem erro pelo destino, bem como a sequência do próximo byte esperado. Tamanho header : número decimal de palavras de 32 bits do header TCP tipicamente contém valor 5 (4 bits). Reservado é um campo ainda não utilizado (6 bits) à veja exercício no final deste material q FLAGS identifica as flags especiais de operação ( U-urg A-ack P-push, R-rst S-syn F-fin ) q q Window identifica o tamanho da janela para o controle de fluxo Checksum destina-se a verificação de erros de transmissão. É calculado usando o pseudo header, o header TCP e também a área de dados. q Urgent Pointer é um ponteiro para dados urgentes, contidos na área de dados (caso bit U setado para 1).

94 TCP: Gerenciamento de Conexões 94

95 TCP: Gerenciamento de Conexões (1) q Emissor e receptor TCP estabelecem conexão antes de trocar dados. q Full duplex: fluxo de dados segue nos dois sentidos. q Inicializam variáveis TCP: Números de sequência e confirmação. Buffers, informações de controle de fluxo (por ex. RcvWindow) e temporizadores. q Cliente: é aquele que inicia a conexão. Active Open q Servidor: é aquele chamado pelo cliente. Passive Open. 95

96 TCP: Iniciando Conexão (1) Inicialização em 3 passos (3-way handshake): (1): Cliente envia segmento de controle de início de conexão TCP ao servidor. Bit SYN do TCP é ajustado como 1 e Bit ACK como 0. (SYN=1; ACK=0) Cliente envia seu No. de Sequência inicial Seq#C1 (32 bits) (2): Servidor recebe (SYN=1, ACK=0) e Seq#C1 Responde com pacote setando bits SYN=1 E ACK=1 Confirma SYN# do cliente recebido setando ACK# = (Seq#C+1). Envia seu Seq#S1 (No. Seq. inicial do servidor) Aloca buffers, especifica No. seq. inicial de servidor para o receptor. (3): Cliente recebe SYN=1; ACK=1 à responde com segmento ACK confirmando o número de sequencia recebido e começa a enviar dados. (SYN=0; ACK=1) 96

97 TCP: Iniciando Conexão (2) unesp - IBILCE - SJRP (SYN=1; ACK=0) (SYN=1; ACK=1) Servidor confirma o No. seq. do cliente, e envia seu próprio No. de seq. (SYN=0; ACK=1) Cliente confirma o No. seq. do server, e começa a enviar dados seguindo seu No. de seq. 97

98 Estabelecimento da Conexão Cliente A SYN : (0) <mss 1024> Server B SYN : (0) <mss 1024> ACK , ACK

99 Exemplo captura de pacotes: svr4 % telnet bsdi.discard Trying Connected to bsdi. Escape character is '^]'. ^] #type Control, right bracket to talk to the Telnet telnet> quit #terminate the connection Connection closed. Extraído de: TCP/IP Illustrated Vol.1 Richard Stevens 99

100 Listen SYN RCV - Established 100

101 TCP: Números de sequência e ACKs q q q Nos. de sequência: é o número do primeiro byte de dados do segmento. ACKs: No. de sequência do próximo segmento esperado (em bytes). ACK cumulativo. Como receptor trata segmentos fora da ordem? Especificação do TCP é omissa - deixado ao implementador. Host A Usuário tecla C A reconhece chegada do C ecoado Conexão já em andamento Seq=42, ACK=79, data = C Seq=79, ACK=43, data = C Seq=43, ACK=80 Host B B reconhece chegada de C, ecoa C de volta tempo Maioria das implementações: buferiza. cenário simples de telnet 101

102 ACKs duplicados q First time ack é sinal que está tudo ok. q Mas, o que acontece se o emissor recebe um ACK duplicado? re-reconhece um segmento para qual o emissor já tenha recebido ACK anteriormente. q Veremos em seguida como isso é usado pelo TCP

103 Lidando com ACKs duplicados e retransmissões. unesp - IBILCE - SJRP q No TCP os segmentos são enviados em paralelo (pipeline). q Os ACKs são cumulativos. A chegada de um ACK confirma anteriores. q TCP usa único timer de retransmissão. É um timer para o segmento mais antigo sem ACK. q Retransmissões são disparadas por: Eventos de timeout. ACKs duplicados. q Inicialmente, para facilitar o entendimento, vamos considerar um emissor TCP simplificado: Ignorar controle de fluxo e controle de congestionamento. Serão vistos mais adiante.

104 Eventos de emissor TCP (1) unesp - IBILCE - SJRP q Quando dados são recebidos da aplicação: Cria segmento com seq# O número seq# é número da cadeia de bytes do primeiro byte de dados no segmento. Inicia timer, se ainda não tiver iniciado. É um timer para o segmento mais antigo sem ACK. Intervalo de expiração: Time-Out-Interval

105 Eventos de emissor TCP (2) EVENTOS: 1.) Evento Timeout: q Retransmite segmento que causou timeout. q Reinicia timer. 2.) ACK recebido: q Confirma o seguimento corrente, e todos os demais segmentos anteriores ainda sem ACK. Atualiza aqueles que sabidamente foram recebidos. Receptor não enviaria um ACK se não tivesse enviado os anteriores. q Reinicia timer (se houver segmentos pendentes)

106 TCP: cenários de retransmissão (1) Envia dois segmentos de uma vez, e aguarda. O ACK do primeiro segmento se perde. Recebe a indicação que B recebeu tudo certo, até o 100, e não re-envia nada. Indica que B recebeu tudo certo, até o 100 (aguarda o 120) Cenário ACK cumulativo 106

107 TCP: cenários de retransmissão (2) Hosp. A Hosp. B Hosp. A Hosp. B Seq = 92, 8 bytes dados timeout SendBase = 100 tempo Seq = 92, 8 bytes dados X loss ACK = 100 Seq = 92, 8 bytes dados ACK = 100 Cenário de ACK perdido Sendbase = 100 SendBase = 120 SendBase = 120 Seq = 92 timeout Seq = 92 timeout tempo Seq = 100, 20 bytes dados Seq = 92, 8 bytes dados Timeout prematuro

108 TCP: cenários de retransmissão (3) Host A Host B Seq = 92, 8 bytes dados timeout Seq = 100, 20 bytes dados X perda ACK = 100 SendBase = 120 ACK = 120 Chegada dentro do timer: indica que B recebeu tudo certo, até o 100, e está aguardando o 120 tempo Cenário ACK cumulativo

109 Tratando segmentos faltantes: ACKs repetidos (1) q Quando um receptor recebe um segmento com um número de sequência maior do que próximo número de sequência esperado, ele detecta uma falha no fluxo de dados Detecta segmento faltante. q TCP não usa NACK: O receptor não pode emitir não-ack para o emissor. Ao invés disso: re-reconhece o último byte em ordem dos dados que ele recebeu corretamente. Isto é, ele gera um ACK em duplicata para o último byte recebido corretamente. 109

110 Tratando segmentos faltantes: ACKs repetidos (2) q Período de timeout é relativamente grande: Pode haver longo atraso antes de reenviar pacote perdido. q É necessário detectar segmentos perdidos por meio de ACKs duplicados Emissor geralmente envia muitos segmentos um após o outro. Se um segmento for perdido, provavelmente haverá muitos ACKs duplicados para esse segmento. Isso é tratado com a retransmissão rápida.

111 Retransmissão rápida (1) q Se o emissor receber três ACKs duplicados (ou seja, 4 ACKs idênticos) para o mesmo segmento que ele já enviou: Assume que foi perdido o segmento em seguida ao segmento que foi confirmado 4X O TCP executa uma retransmissão rápida. Re-envia o segmento faltante, mesmo antes que o temporizador esgote Definido pelo RFC

112 Entendendo os 3 ACKs duplicados (1) unesp - IBILCE - SJRP ACK xxxxxxx523 Timer Ainda não ocorreu timeout ACK xxxxxxx523 ACK xxxxxxx523 ACK xxxxxxx523 1o. ACK duplicado 2o. ACK duplicado 3o. ACK duplicado A chegada de 4 ACKs idênticos antes de vencer o timer do ACK, resulta na retransmissão rápida. 112

113 Entendendo os 3 ACKs duplicados (2) Hosp. A Hosp. B timer timer ACKs duplicados três vezes seq # x1 seq # x2 seq # x3 seq # x4 seq # x5 reenvia seq X2 X ACK x1 ACK x1 ACK x1 ACK x1 timeout tempo

114 Algoritmo de retransmissão rápida: event: ACK received, with ACK field value of y if (y > SendBase) { SendBase = y if (there are currently not-yet-acknowledged segments) start timer } else { increment count of dup ACKs received for y if (count of dup ACKs received for y = 3) { resend segment with sequence number y } ACK duplicado para segmento já com ACK retransmissão rápida

115 RFC TCP Congestion Control unesp - IBILCE - SJRP " The TCP sender SHOULD use the "fast retransmit" algorithm to detect and repair loss, based on incoming duplicate ACKs. The fast retransmit algorithm uses the arrival of 3 duplicate ACKs (4 identical ACKs without the arrival of any other intervening packets) as an indication that a segment has been lost. After receiving 3 duplicate ACKs, TCP performs a retransmission of what appears to be the missing segment, without waiting for the retransmission timer to expire." 115

116 Resposta de ACKs no TCP [RFCs 1122, 2581] 116

117 Encerramento da Conexão q Half Close Conexões TCP são full-duplex. Cada lado da conexão deve finalizar a conexão de forma independente. Quando um dos lados envolvidos recebe uma solicitação de finalização, deve enviar a notificação para a aplicação. Uma aplicação após receber o pedido de finalização ainda pode mandar dados.

118 TCP: Fechando uma Conexão Encerrando uma conexão: 1: cliente envia segmento de controle FIN ao servidor. 2: servidor recebe FIN, responde com ACK. Também pede encerramento da conexão, enviando FIN. 3: cliente recebe FIN, responde com ACK. Entre em espera temporizada - responderá com ACK a FINs recebidos 4: servidor, recebe ACK. Conexão encerrada. fechar espera temporizada fechada cliente 1 3 FIN ACK FIN ACK servidor 2 fechar 4 118

119 Half-close captura de pacotes: svr4 % telnet bsdi.discard Trying Connected to bsdi. Escape character is '^]'. ^] #type Control, right bracket to talk to the Telnet telnet> quit #terminate the connection Connection closed. Extraído de: TCP/IP Illustrated Vol.1 Richard Stevens 119

120 Half-Close / Time-wait detalhado 120

121 TCP: Ciclo de vida do SERVIDOR unesp - IBILCE - SJRP Exercício: estudar o ciclo de vida do servidor TCP 121

122 TCP: Ciclo de vida do CLIENTE unesp - IBILCE - SJRP Exercício: estudar o ciclo de vida do cliente TCP 122

123 Exercício: Estudar as transições de estado do TCP 123

124 Exercício: Estudar as transições de estado do TCP unesp - IBILCE - SJRP 124

125 TCP: RTT e timeout - Timer adaptativo. - Outros timers. 125

126 RTT e timeout adaptativo do TCP (1) Como definir o valor de timeout do TCP? q Deveria ser maior que RTT. Mas RTT varia bastante. q Se for muito curto: ocorre timeout prematuro. Resulta em retransmissões desnecessárias q Se for muito longo Resulta em baixa reação a perda de segmentos. Então: Como estimar o RTT (EstimatedRTT)?

127 RTT e timeout adaptativo do TCP (2) Como estimar o RTT (EstimatedRTT)? q SampleRTT: tempo medido da transmissão do segmento até receber o ACK. q Assim, o SampleRTT vai variar. É bom que o RTT estimado seja mais estável possível. Usa-se a média de diversas medições recentes, e não apenas SampleRTT atual.

128 RTT e timeout adaptativo do TCP (3) EstimatedRTT = (1 - α)*estimatedrtt + α*samplertt Média exponencial ponderada móvel. Influência da amostra mais antiga diminui exponencialmente rápido. Dá mais peso às medidas mais recentes. Valor típico: α = 0,125 (determinado empiricamente)

129 Relação entre RTT amostra e RTT estimado

130 RTT e timeout adaptativo do TCP (4) Mas o Timeout ainda é definido da seguinte maneira: q EstimatedRTT deve oferecer mais margem de segurança. Oferecer maior margem de segurança se há grande variação em SampleRTT. Então é necessário considerar quanto varia o SampleRTT. Primeira estimativa do quanto SampleRTT se desvia de EstimatedRTT é DevRTT: DevRTT = (1-β)* DevRTT + β* SampleRTT - EstimatedRTT (geralmente β = 0,25, definido empiricamente) e depois definir intervalo de timeout: TimeoutInterval = EstimatedRTT + 4*DevRTT Exercício: Pesquisar e estudar algoritmo Jacobson / Karels.

131 Se você pensa que acabou (1) q Temporizador adaptativo de retransmissão não é o único usado pelo TCP. q Na verdade são 4 timers. Timer Retransmissão adaptativo (visto) + 1. Timer de Persistência. 2. Timer Keep-alive. 3. Timer Time-wait. 131

132 1. Timer de persistência q É usado para evitar impasse. Receptor envia pacote de tamanho de janela 0, pedindo para emissor aguardar. (Mais adiante ficará mais claro o que significa um tamanho de janela zero ) Emissor faz um teste de tempos em tempos, usando o timer de persistência, para ver se pode voltar a transmitir (devido a risco de perda do pacote de atualização do receptor). 132

133 2. Timer keep alive q Temporizador keep alive ( mantenha vivo ): Para verificar conexões inativas por muito tempo. Um lado verifica se o outro ainda está lá. 133

134 3. Temporizador Time Wait q Temporizador time wait ( tempo de espera ): Usado para encerramento de sessão. É ajustado para 2 vezes o tempo de vida máximo de um pacote (TTL - Time to Live). Tenta garantir que quando uma sessão for encerrada, todos os pacotes criados por ela já tenham sido entregues. 134

135 MSS e numeração de segmentos 135

136 MSS (Maximum Segment Size) q O MSS representa o tamanho do maior bloco de dados que o TCP permite enviar num único segmento. Para a maioria dos computadores o MSS é ajustado automaticamente pelo SO. Default (obrigatório): 536 bytes. (20 bytes IP, 20 bytes TCP, para um total de 576 bytes). Ethernet padrão: 1460 bytes. (20 bytes IP, 20 bytes TCP, para um total de 1500 bytes)

137 Quanto maior o MSS, melhor q Em geral: quanto maior o MSS, melhor o desempenho da rede. Mais dados são enviados num único segmento. Quanto maior a quantidade de dados enviados em um único bloco, menor o overhead de headers TCP e IP. Desde que não ocorra fragmentação. (Trataremos fragmentação no protocolo IP; associado ao MTU) O MSS está limitado pelo MTU, que está limitado pela tecnologia ou protocolo da camada de enlace. Esta relação será discutida mais adiante, junto com a discussão sobre MTU na camada de rede.

138 MSS e numeração de segmentos Aplicação quer enviar bytes de dados, Num TCP com MSS = bytes Transmissão TCP: 500 partes de bytes 1o. segmento último segmento O No. de sequência do emissor é incrementado pelo No. de bytes enviados 138

139 Controle de FLUXO no TCP 139

140 TCP: Controle de Fluxo (1) Para emissor não esgotar os buffers do receptor, transmitindo demais, ou muito rapidamente. RcvBuffer = tamanho do Buffer de recepção. RcvWindow = informa ao emissor quantidade de espaço vazio no buffer do receptor. Este valor é mantido como variável em cada lado da conexão (lembrar que é Full Duplex). buffering pelo receptor 140

141 TCP: Controle de Fluxo (2) q RECEPTOR: explicitamente avisa o emissor da quantidade de espaço livre disponível (que muda dinamicamente). Campo RcvWindow (janela) no segmento TCP. q EMISSOR: mantém a quantidade de dados transmitidos, porém ainda não reconhecidos, MENOR que o valor mais recente de RcvWindow. (para cada lado da conexão) 141

142 Troca de informações sobre controle de fluxo TCP (1) Aplicação envia 2 Kb (0) 4 Kb = Tamanho do buffer do receptor. (3) Aplicação envia 3 Kb, mas emissor TCP só pode enviar 2 Kb (...) Emissor aguarda... (2) Receptor confirma e avisa que pode enviar mais 2 Kb. (4) Receptor confirma e pede para aguardar (buffer cheio) win=0 (6) Receptor agora pode enviar até 2 Kb; envia o 1 Kb que falta. (5) Aplicação lê 2 Kb do TCP ; Receptor TCP avisa que pode enviar mais 2 Kb (reconfirma o último recebido e envia janela de 2048) 142

143 Controle de Congestionamento 143

144 Princípios de Controle de Congestionamento (1) Congestionamento: q Trata emissor enviando dados mais rapidamente do que a rede pode suportar. Atenção! É diferente de controle de fluxo. Retransmissão de pacotes trata o sintoma do congestionamento da rede: perda de segmentos. Mas não trata a causa do congestionamento: Origens tentando enviar dados numa taxa muito alta, na qual a rede não está suportando. 144

145 Princípios de Controle de Congestionamento (2) unesp - IBILCE - SJRP q Como se manifesta: Perda (drop) de pacotes Esgotamento de buffers em roteadores. Retransmissão de pacotes. Devido aos drops. Longos atrasos Grande filas nos buffers dos roteadores. 145

146 Solução para o Congestionamento unesp - IBILCE - SJRP q Solução para o congestionamento: reduzir a taxa de transmissão de dados. Não inserir novos pacotes na rede, até que os antigos tenham saído. Ou seja, até que os antigos tenham sido entregues. q TCP à tenta alcançar esse objetivo. Manipulando dinamicamente o tamanho da janela. 146

147 Controle de congestionamento TCP: busca por largura de banda adequada Busca por largura de banda: Aumenta taxa de transmissão no recebimento do ACK até ocorrer perda. Depois diminui taxa de transmissão, quando ocorre perda. Aumentar com ACK ok, e diminuir na perda, pois largura de banda disponível está mudando, dependendo de outras conexões na rede. taxa de emissão ACKs sendo recebidos, de modo que aumenta taxa X X X X X perda e diminuição de taxa comportamento dente de serra do TCP tempo Com que velocidade aumentar/diminuir? Veremos detalhes a seguir

148 O que o TCP faz para evitar congestionamentos: q Quando uma conexão é estabelecida, um lado escolhe um tamanho de janela adequado. Veremos mais adiante como ocorre a escolha. q O receptor especifica uma janela a partir do tamanho de seu buffer. Indica o quanto ele está disposto a receber. q Se o transmissor se mantiver dentro do tamanho da janela, não haverá problemas causados pela sobrecarga dos buffers no receptor. Mas eles ainda podem ocorrer devido a congestionamentos internos na rede. 148

149 TCP: Controle de Congestionamento (1) q Existem dois problemas potenciais: Capacidade do receptor. Capacidade da rede. q Deve-se tratar cada um em separado. q Para isso, cada transmissor mantém duas janelas: Janela fornecida pelo receptor. RcvWin Janela de congestionamento: CongWin Vejamos 149

150 TCP: Controle de Congestionamento (2) q Cada uma identifica o número de bytes que o transmissor pode enviar. Pode enviar o valor mínimo das duas janelas. q Então, a quantidade máxima de dados não confirmados que um host pode enviar em uma conexão deve ser: LastByteSent - LastByteAcked min{congwin, RcvWin} 150

151 TCP: Controle de Congestionamento q Controle é fim a fim (sem apoio da rede). q Taxa de transmissão é limitada pela tamanho da janela de congestionamento Congwin: Congwin A janela efetiva é o mínimo do que o transmissor e o receptor consideram viável. Veremos exemplo a seguir

152 TCP: Controle de Congestionamento q A janela efetiva é o mínimo do que o transmissor e o receptor consideram viável. Exemplos: 1. Se o receptor disser: envie 8KB, mas... se o transmissor souber que qualquer rajada com mais de 4 KB poderá congestionar a rede, ele enviará apenas 4 KB. 2. Se o receptor disser: envie 8KB, mas... Se o transmissor souber que rajadas de até 32 KB passam pela rede sem problemas, ele enviará os 8 KB solicitados. 152

153 TCP: Controle de Congestionamento q A janela efetiva é o mínimo do que o transmissor e o receptor consideram viável. Exemplos: 1. Se o receptor disser: envie 8KB, mas... se o transmissor souber que qualquer rajada com mais de 4 KB poderá congestionar a rede, ele enviará apenas 4 KB. 2. Se o receptor disser: envie 8KB, mas... Se o transmissor souber que rajadas de até 32 KB passam pela rede sem problemas, ele enviará os 8 KB solicitados. 153

154 Como funciona o controle: q Sondagem para banda a ser usada: Transmitir o mais rápido possível sem perder pacotes (ou seja, Congwin ajustado ao máximo possível) Aumentar Congwin até perder pacotes à vai causar congestionamento. Quando houver perdas: diminuir Congwin. Depois volta a à sondagem, aumentando novamente. q q Duas fases 1. Partida lenta. 2. Prevenção de congestionamento. Variáveis importantes: congwin. threshold: define limiar entre fases de partida lenta e controle de congestionamento. Também chamado de patamar. Tudo explicado a seguir.. 154

155 Partida lenta e sondagem do congestionamento (1) q Conexão é estabelecida transmissor ajusta a variável congwin igual ao MSS. Em seguida, ele envia este segmento. Se esse segmento for confirmado antes de ocorrer um timeout, então o transmissor: Adicionará o número de bytes de 1 MSS na janela de congestionamento, de modo que ela tenha capacidade equivalente a 2 MSS. Ou seja: congwin++ Enviará os 2 segmentos... (continua...) 155

156 Partida lenta e sondagem do congestionamento (2) q À medida que cada um desses segmentos for confirmado, a janela de congestionamento é aumentada em um tamanho deste segmento máximo, de tal forma que - quando ambos forem confirmados - a janela terá agora 4 vezes o valor inicial. Quando a janela de congestionamento chegar a n segmentos, e se todos os n segmentos forem confirmados a tempo, a janela de congestionamento será aumentada pelo número de bytes correspondentes aos n segmentos. q Cada rajada confirmada duplica a janela de congestionamento atual: crescimento exponencial. q Chamado de partida lenta (slow start). 156

157 TCP: Partida lenta Algoritmo de Partida Lenta Estação A Estação B inicializa: Congwin = 1 for (cada segmento c/ ACK) Congwin++ until (evento de perda OR CongWin > threshold) RTT um segmento dois segmentos quqtro segmentos Veremos o que é isso a seguir... q A cada RTT ocorre um aumento exponencial no tamanho da janela. Partida não é tão lenta! tempo 157

158 Quando parar o crescimento? q Mas, quando parar o crescimento? Obviamente à este crescimento terá de ser interrompido em algum momento, devido a congestionamento da rede ou capacidade do receptor. q Para isso é usado o parâmetro de threshold. q Vejamos como

159 Threshold q Controle de congestionamento TCP utiliza um terceiro parâmetro limitante: threshold. Também chamado de limiar ou patamar. q Threshold definido inicialmente como 64KB. O crescimento exponencial é interrompido quando o threshold é alcançado. Então o crescimento passa a ser linear. Quando atingir o threshold, a variável congwin passa a aumentar de 1 MSS para cada rajada. 159

160 Threshold e o timeout q Quando há um timeout, o threshold é atribuído à metade da janela de congestionamento atual, e a janela de congestionamento é reinicializada para 1 MSS. q O algoritmo reduz o tamanho da janela de congestionamento à metade, e depois retoma seu crescimento a partir daí. (Ficará mais fácil de entender no gráfico a seguir) 160

161 TCP: Evitar Congestionamento (1) (2) Quando atinge threshold, o crescimento passa a ser linear (fase de prevenção de congestionamento ) timeout (3) Quando há timeout, congwin volta para 1 MSS, e threshold cai pela metade (1) Fase de partida lenta (2.1) Quando atinge o threshold o aumento é de um segmento máximo para cada rajada em vez de um para cada segmento. 161

162 TCP: Evitar Congestionamento (2) Evitar congestionamento /* partida lenta acabou */ /* Congwin > threshold */ Until (event de perda) { cada w segmentos reconhecidos: Congwin++ } threshold = Congwin/2 Congwin = 1 faça partida lenta. timeout 162

163 Comportamento do TCP Congestion Control Time (seconds) 163

164 Exercício TCP Reno x TCP Tahoe: unesp - IBILCE - SJRP q Existem diferentes implementações de controle de congestionamento. 1. Estudar a diferença entre TCP Reno e TCP Tahoe. 2. Entender a diferença entre retransmissão rápida (Fast Retransmit) e recuperação rápida (Fast Recovery). Responda: como isso isso impacta o controle de congestionamento? 164

165 AADM / Additive-Increase, Multiplicative-Decrease (AIMD) q Desconsiderando a fase de partida lenta: TCP usa AADM : Aumento Aditivo, Decremento Multiplicativo Aumenta janela em 1 a cada RTT. Diminui janela por fator de 2 quando um evento de perda acontece. Justeza do TCP Meta de justeza: se N sessões TCP compartilham o mesmo enlace, cada uma deve ganhar 1/N da capacidade do enlace. TCP conexão 1 TCP conexão 2 Roteador gargalo capacidade R 165

166 ECN - Explicit Congestion Notification flags (RFC-3168) unesp - IBILCE - SJRP NS (1 bit): ECN-nonce concealment protection (*) experimental: see RFC CWR (1 bit): Congestion Window Reduced (CWR) flag is set by the sending host to indicate that it received a TCP segment with the ECE flag set and had responded in congestion control mechanism (added to header by RFC 3168). ECE (1 bit): ECN-Echo has a dual role, depending on the value of the SYN flag: If the SYN flag is set (1), that the TCP peer is ECN capable. If the SYN flag is clear (0), that a packet with Congestion Experienced flag set (ECN=11) in IP header was received during normal transmission (added to header by RFC 3168). This serves as an indication of network congestion (or impending congestion) to the TCP sender. (*) O NS ainda é experimental e não aparece em algumas representações 166

167 ECN - Explicit Congestion Notification flags (*) O NS ainda é experimental e não aparece em algumas representações 167