unesp - IBILCE - SJRP Curso de Redes de Computadores 2010 · unesp - IBILCE - SJRP 2 Capítulo 3: Camada de Transporte Metas do capítulo: Compreender os princípios dos serviços

unesp - IBILCE - SJRP

1

Curso de

Redes de Computadores

2010

Adriano Mauro [email protected]

Capítulo 3

Camada de Transporte


2

Capítulo 3: Camada de Transporte

Metas do capítulo:

Compreender os

princípios dos serviços da

camada de transporte:

• Multiplexação/

desmultiplexação.

• Transferência confiável

de dados.

• Controle de fluxo.

• Controle de

congestionamento.

Instanciação e

implementação na

Internet.

O que veremos:

Serviços da camada de transporte.

Multiplexação/desmultiplexação.

Transporte sem conexão: UDP.

Princípios de transferência confiável de

dados.

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.


3

Comparação entre as camadas

Camada Transporte processos

Camada de rede hosts

• Protocolo da Camada de Transporte fornece

comunicação lógica entre processos,

rodando em hosts diferentes.

• Protocolo da Camada de Rede fornece

comunicação lógica entre hosts.

Camada de transporte repousa exatamente sobre a

camada de rede.

Esta distinção é sutil, mas MUITO importante!


4

Camada de Transporte X Camada de Rede (1)

Exemplo:

• 10 irmãos numa casa em São Paulo, SP.

• e 10 irmãos em outra casa em Manaus, AM.

• Os de SP são primos daqueles em Boa Vista.

• Escrevem cartas entre SP e AM semanalmente.

Em São Paulo:

• João recolhe as cartas, e as entrega ao correio.

Em Manaus:

• Maria recolhe as cartas, e as entrega ao correio.

Também recebem e fazem a distribuição local das cartas

que chegam.


5

Camada de Transporte X Camada de Rede (2)

Hosts (end systems) = Casas.

Processos = pessoas que trocam mensagens.

Mensagens da aplicação = cartas em envelopes.

Protocolo da camada de rede:

• Serviço postal (correio).

Protocolo da Camada de Transporte:

• João (de um lado) e Maria (do outro).


6

Serviços e protocolos de TRANSPORTE (1)

Provê comunicação lógicaentre processos de aplicação

executando em hosts

diferentes.

Protocolos de transporte

rodam em sistemas finais.

• Camada de rede: dados

transferidos entre hosts.

• Camada de transporte:

dados transferidos entre

processos.

aplicaçãotransporte

redeenlacefísica

redeenlacefísica


redeenlacefísica

redeenlacefísica

redeenlacefísica

redeenlacefísica

redeenlacefísica


7

Serviços e protocolos de TRANSPORTE (2)

Do ponto de vista da APLICAÇÃO a camada de

transporte permite enxergar os sistemas como se eles

estivessem fisicamente conectados.

• Mesmo que existam vários roteadores, links e

outros equipamentos no caminho.

A Camada de Aplicação não tem que se preocupar com a

infra-estrutura de interligação, usada para carregar as

mensagens.


8

Protocolos da camada de transporte (1)

Como já foi dito:

Protocolos de transporte

são implementados nos

sistemas das pontas (end

systems), e não nos

roteadores intermediários.

TRANSPORTE: Camada

4, superior à camada de

rede.


redeenlacefísica

redeenlacefísica


redeenlacefísica

redeenlacefísica

redeenlacefísica

redeenlacefísica

redeenlacefísica


9

Protocolos da camada de transporte (2)

Dois Serviços de transporte na Internet:

Entrega confiável, ordenada, ponto

a ponto: TCP.

• Controle Congestionamento.

• Controle de fluxo.

• Estabelecimento de conexão

(setup).

Entrega não confiável, (“melhor

esforço”), não ordenada, ponto a

ponto ou multiponto: UDP.


redeenlacefísica

redeenlacefísica


redeenlacefísica

redeenlacefísica

redeenlacefísica

redeenlacefísica

redeenlacefísica


10

Multiplexação/desmultiplexação (1)

MULTIPLEXAÇÃO: Juntar dados de múltiplos

processos de aplicações, encapsulando dados com

cabeçalho (usado depois para demultiplexação).


rede

MP2


rede

receptor

Ht

Hn segmento

segmento M


rede

P1M

M M

P3 P4

cabeçalhode segmento

dados da camada de aplicação


11


MULTIPLEXAÇÃO: Juntar dados de múltiplos

processos de aplicações, envelopando dados com

cabeçalho (usado depois para demultiplexação).

DEMULTIPLEXAÇÃO: entrega de segmentos

recebidos para os processos da camada de

aplicação corretos.


rede

MP2


rede

receptor

Ht

Hn segmento

segmento M


rede

P1M

M M

P3 P4




12


rede

MP2


rede


Segmento - Unidade de dados trocada entre entidades da

camada de transporte.

• Ou TPDU- Transport protocol Data Unit, ou 4-PDU (PDU da

camada 4).

• No exemplo abaixo: P1 com P3, e P2 com P4.

receptor

Ht

Hn segmento

segmento M


rede

P1M

M M

P3 P4




13


Multiplexação/demultiplexação:

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 bem

conhecido para aplicações

específicas (WKS): E-mail

na porta 25, telnet na porta

23, http na porta 80, e

assim por diante.

porta emissor porta receptor

32 bits

dados daaplicação

(mensagem)

outros campos

do cabeçalho

formato genérico de segmento

TCP/UDP


14

estaçãoA

Multiplexação/desmultiplexação: exemplos

servidor B

porta orig.: xporta dest: 23

porta orig:23porta dest: x

uso de portas:

aplicação simples de telnet

Cliente WWWestação A

servidor WWW B

Web clienthost C

IP orig: CIP dest: B

porta orig: xporta dest: 80

IP orig : CIP dest: B

porta orig: yporta dest: 80

Uso de portas : servidor WWW

IP orig: AIP dest: B

porta orig: xporta dest: 80


15

UDP: User Datagram Protocol [RFC 768]

Protocolo de transporte da Internet “mínimo”.

Best Effort: Serviço “melhor esforço”, resulta que segmentos UDP podem ser:

• Perdidos.

• Entregues à aplicação fora de ordem de envio.

Sem conexão:

• Não há “setup” UDP entre remetente e receptor.

• Tratamento independente de cada segmento UDP.

Por quê existe um UDP?

Elimina estabelecimento de

conexão (o que pode causar

retardo).

Simples: não se mantém

“estado” da conexão no

remetente/receptor.

Pequeno cabeçalho de

segmento. Mais simples.

Sem controle de

congestionamento: UDP

pode transmitir o mais

rápido possível.


16

Mais sobre UDP

Muito utilizado para aplicações de

meios contínuos (voz, vídeo)

• São tolerantes a perdas.

• São sensíveis à taxa de

transmissão.

Outros usos de UDP :

• DNS (servidor de nomes).

• SNMP (gerenciamento).

Transferência confiável com UDP:

deve incluir confiabilidade na

camada de aplicação.

• Recuperação de erro fica por

conta da aplicação!

porta origem porta dest.

32 bits

Dados de aplicação

(mensagem)

Formato de um sgmento UDP

comprimento checksum

Comprimento embytes do

segmento UDP,incluindo cabeçalho


17

Checksum UDP

Emissor:

Trata conteúdo do segmento

como seqüência de inteiros

de 16-bits.

Campo checksum zerado.

Checksum: soma (adição

usando complemento de 1)

do conteúdo do segmento.

Emissor coloca complemento

de um do valor da soma no

campo checksum de UDP .

Envia...

Receptor:

Computa checksum do segmento recebido

Verifica se checksumcomputado é zero:

• NÃO - erro detectado.

• SIM - nenhum erro detectado. Mas ainda pode ter erros?(Veremos mais adiante ….)

Meta: detectar falha no segmento transmitido.


18

Exemplo de cálculo do checksum (1)

Considere 3 palavras de 16 bits sendo transmitidas:

0110011001100110

0101010101010101

0000111100001111

A soma das duas primeiras palavras é:

0110011001100110

0101010101010101

1011101110111011

Adicionando a terceira palavra, a soma acima fica:

1011101110111011

0000111100001111

1100101011001010

Os complementos de 1 são obtidos convertendo

todos os 0’s para 1’s , e todos os 1’s para 0’s.

Ver RFC-1071 !


19

Lembrete 1: método PolinomialModo Polinomial ( “vai um”)(Este é o método realmente usado pelo UDP. Em caso de dúvida,consulte a seção 3.3.2 do livro texto d o curso – “ComputerNetworking: A Top-Down Approach Featuring the Internet” - James F.Kurose & Keith W. Ross).

Lembrar que:

0 + 0 = 0 = 00 (“vai zero”)1 + 0 = 1 = 01 (“vai zero”)

0 + 1 = 1 = 01 (“vai zero”)0 + 1 = 1 = 01 (“vai zero”)

1 + 1 = 2 = 10 (“vai 1”)1 + 1 + 1 = 3 = 11 (“vai 1”)

01 11 01 1 0 1 0 1

+ 0 1 1 1 0 0 0 0

1 1 0 0 0 1 0 1

11 1 0 01 01 1 0 1+ 1 1 0 0 1 1 0 0

1 0 0 1 0 0 0 1

Complemento de 1 = 0 1 1 0 1 1 1 0


Lembrete 2: “carry”

20


21


Assim o complemento de 1's da soma 1100101011001010

é 0011010100110101

Este valor se torna o checksum.

No receptor, todas as palavras de 16 bits são somadas,

incluindo o checksum.

Se não foram introduzidos erros no pacote, a soma no

receptor certamente deverá resultar em 1111111111111111.

Se um dos bits for zero, então algum erro foi introduzido no

pacote.

Pergunta para casa: 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 ??


22


Assim o complemento de 1's da soma 1100101011001010

é 0011010100110101

Este valor se torna o checksum.


Pseudo Header (1)

UDP (assim como o TCP) usa um pseudo

header no cálculo do checksum, com

informações do IP (16 bytes).

• Checksum usa os headers (pseudo header e header

UDP), e os dados do UDP.

Comprimento do UDP pode ser um número

ímpar de bytes.

• Algoritmo do checksum soma palavras de 16 bits.

• Solução: adicionar “pad” de zeros , no final, se

necessário.

• Pad não é transmitido.

23


Pseudo Header (2)

24

Pseudo header

IP (usado pelo UDP)

(16 bytes)

Header UDP

(8 bytes)

Violação da independência das camadas


25

Princípios de Transferência confiável de dados

Reliable Data Transfer

(RDT)


26

Princípios de Transferência confiável de dados

Reliable Data Transfer (RDT)

Importante nas camadas de transporte, enlace

No topo da lista dos 10 tópicos mais importantes em redes!

Características do canal não confiável determinam a complexidade

de um protocolo de transferência confiável de dados (RDT).


27

Transferência confiável de dados (RDT): como começar

emissor receptor

rdt_rcv(): chamada quando pacote

chega no lado receptor do canal.

deliver_data(): chamada por

rdt para entregar dados para

camada superior.

udt_send(): chamada por ambos

os lados para troca de pacotes de

controle. UDT representa um

unreliable data transfer.

rdt_send( ): chamada da camada superior, (Ex:

pela aplicação). Passa dados para entregar

à camada superior receptora


28

Transferência confiável de dados (rdt): como começar

Iremos:

Desenvolver passo-a-passo os lados remetente e receptor do

protocolo confiável RDT.

Vamos Considerar apenas fluxo unidirecional de dados.

• Mas a informação de controle flui em ambos sentidos!

Usar máquinas de estados finitos (FSM - Finite State Machine)

para especificar remetente e receptor.

estado1

estado2

evento causando transição de estadosações tomadas na transição de estado

ESTADO: quando o

sistema está num

“estado”, o próximo

estado é determinado

unicamente pelo próximo

evento.

eventoações


29

Rdt1.0: transferência confiável usando um canal confiável

Suposição 1.0: Canal é perfeitamente confiável.

• Não apresenta erros de bits.

• Não apresenta perda de pacotes.

FSMs separadas, para remetente e receptor:

• Remetente envia dados pelo canal subjacente.

• Receptor recebe dados do canal subjacente.

Evento que causou

a transição

Ações tomadas

quando ocorre um

evento


30

rdt2.0 - Modelo um pouco mais realista:

Bits num pacote podem ser corrompidos.

Falhas podem ocorrer nos componentes

físicos da rede:

• Por exemplo, quando um pacote é transmitido,

propagado ou “bufferizado”.

Entretanto, continuamos supondo que

todos os pacotes transmitidos são

recebidos na ordem em que são

enviados.

• Ainda que bits possam estar corrompidos.


31

Rdt2.0: canal com erros de bits

Canal subjacente pode inverter bits no pacote

• O checksum UDP pode detectar erros de bits.

A questão é: como recuperar dos erros?

• Confirmação (ACK): receptor avisa explicitamente

ao remetente que pacote chegou bem.

• Confirmação negativa (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 )


32

Mensagens de controle

Permitem o receptor informar ao emissor o

que foi recebido corretamente.

• E o que foi recebido com erro, exigindo

retransmissão.

Protocolos baseados em retransmissão são

chamados de Protocolos ARQ:

• Automatic Repeat reQuest.


33

Novas capacidades em rdt2.0

Três capacidades adicionais são exigidas em

protocolos de ARQ para lidar com a presença de

erros de bits:

• Detecção de erros: mecanismo para permitir que o

receptor identifique quando erros de bit ocorreram.

• Realimentação (feedback) pelo receptor:

mensagens de controle (ACK, NAK) trocadas entre

receptor e o emissor.

• Retransmissão: para corrigir os erros detectados.

Estes novos mecanismos estão presentes na

proposta de protocolo rdt2.0


34

rdt2.0: especificação da FSM - EmissorPossui 2 estados: Em um estado

aguarda dados da camada superior.

Em outro estado, aguarda ACK ou

NACK do receptor Aguarda dados da

aplicação

Aguarda ACK ou

NACK do receptor

Se recebe um ACK confirmando que o

dado atual foi recebido, retorna ao

estado de aguardar um pacote da

camada superior

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)

1

2

3


35

rdt2.0: especificação da FSM - Receptor

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.


36

rdt2.0: em ação (sem erros)

FSM do remetente FSM do receptor


37

rdt2.0: em ação (cenário de erro)

FSM do remetente FSM do receptor


Mas o RDT2.0 tem uma falha

fatal...

38


rdt2.0 tem uma falha fatal!

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?

Remetente usa ACKs/NAKs p/ ACK/NAK do

receptor?

• E se perder ACK/NAK do remetente?

Retransmitir?

• Pode causar retransmissão de pacote recebido certo!

39


40

rdt2.0 tem uma falha fatal!

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?

Remetente usa ACKs/NAKs p/ ACK/NAK do receptor?

• E se perder ACK/NAK do remetente?

Retransmitir?

• Mas pode causar retransmissão de pacote recebido certo!

Lidando com duplicação:

Emissor inclui número de

seqüência para cada

pacote.

Emissor retransmite

pacote atual se ACK/NAK

recebido com erro.

Receptor descarta pacote

duplicado.

Remetente envia um pacote,e então aguarda resposta do receptor.

Stop and wait


41

rdt2.1: EMISSOR, trata ACK/NAKs com erro

Insere No. de

seqüência 0 no pacote

Deve verificar

se ACK/NAK

recebido tinha

erro

Aguarda a chegada

do No. Seq. correto

1

2

3

4


42

rdt2.1: receptor, trata ACK/NAKs com erro

Deve checar se pacote

recebido é duplicado.

O estado indica se No. de

seqüência esperado é 0 ou 1Pacote corrompido

No. Seq. errado


43

rdt2.1: discussão (1)

Emissor:

Insere No. de sequência no pacote.

Bastam dois Nos. de sequência (0 ou 1).

Deve verificar se ACK/NAK recebido tem erro.

Duplicou o No. de estados

• Estado deve “lembrar” se o pacote “atual” tem

No. de sequência 0 ou 1.


44

rdt2.1: discussão (2)

Receptor:

Deve checar se pacote recebido é duplicado

• Estado indica se No. de seqüência esperado é

0 ou 1.

Receptor não tem como saber se último

ACK/NAK foi recebido bem pelo emissor.


45

rdt2.2: um protocolo sem NAKs

Mesma funcionalidade que

rdt2.1, mas só com ACKs.

Ao invés de NAK, receptor

envia ACK para o último

pacote recebido bem.

• Receptor deve incluir

explicitamente o No. de

seqüência do pacote

reconhecido.

ACK duplicado no remetente

resulta na mesma ação que

o NAK: retransmite pacote

atual.

FSM doEMISSOR

!


46

rdt3.0: canais com erros e perdas (1)

Nova suposição: além de corromper dados, o

canal também pode perder pacotes (dados ou

ACKs).

Como lidar com perdas?

• Ou seja, 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.


47

rdt3.0: canais com erros e perdas (2)

Abordagem: remetente aguarda um determinado

tempo pelo ACK em trânsito.

Exige uso de temporizadores (timers).

• Timeout esgotamento do timer.

Retransmite se nenhum ACK recebido neste tempo.

Se pacote (ou ACK) está apenas atrasado (não perdido):

• A retransmissão será duplicada.

• Mas uso de número de seqüência resolve este problema.

• Receptor deve avisar o número de seqüência do

pacote sendo confirmado.


48

rdt3.0: remetente

Esgotou o timer:

reenvia o anterior

Inicia o timer e aguarda

o ack


49

rdt3.0 em ação


50

rdt3.0 em ação


51

Protocolos “dutados” (pipelined)


Problema com protocolo stop & wait

Em longas distâncias: retardo fim-a-fim é grande.

Pacote em trânsito, ainda não confirmado.

52


53

Desempenho de rdt3.0 rdt3.0 funciona, porém seu desempenho é muito ruim.

Exemplo:

• Link de 1 Gbps (10**9 bits/seg);

• Pacote de 1 KByte (8K bits)

• retardo fim a fim de 15 ms, :

Ttransmissão

=8 kbits/pacote

10**9 b/seg= 8 microseg

Desempenho =8 microseg

30.016 mseg= 0,027 %

Pacote de 1KB a cada 30 mseg vazão de

33kByte/seg num enlace de 1 Gbps !

Protocolo limita uso dos recursos físicos!

Tempo de

ida e volta


54

Protocolos “dutados” (pipelined)

Dutagem (pipelining): remetente admite múltiplos

pacotes “em trânsito”, ainda não reconhecidos.

• Faixa de números de seqüência deve ser aumentada.

• Buffers no remetente e/ou no receptor.

Duas formas genéricas de protocolos “dutados”:

• Volta-N (GBN – Go Back N)

• Retransmissão Reletiva (selective repeat).


55

GBN - Go Back N (1)

Também conhecido como “Volta-N”.

Emissor: pode enviar múltiplos pacotes,

sem aguardar ACK do receptor.

Entretanto:

• Não pode haver mais do que um valor

máximo de N pacotes não confirmados

no canal.


56

GBN - Go Back N (2)

[0, send_base - 1] = Pacotes transmitidos e confirmados (verde)

[send_base, nextseqnum -1] = Pacotes enviados mas não confirmados (amarelo)

[nextseqn, send_base + N - 1] = Disponíveis para serem usados imediatamente,

assim que dados chegarem da camada superior (azul).

Sequence number (base + N) : não podem ser usados até que um pacote não

confirmado que esteja atualmente no duto tenha sido confirmado.

send_base = Seq. # do pacote mais antigo não confirmado no duto.

nextseqnum = Menor Seq. # não usado (Seq.# do próximo a enviar).


57

GBN - Go Back N (3) No Emissor: O intervalo de números de seqüê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 seqüência.

À medida que o protocolo opera, a janela se desloca sobre o espaço

de números de seqüência: sliding-window protocol

= Janela deslizante

Pergunta: por que limitar o número de pacotes não confirmados ?


58

GBN: FSM estendida do emissor

Chamada superior:

verifica se a janela está

cheia. Se não está,

forma o pacote e envia.

Se está cheia, recusa.

Recebe um ACK(n):

confirma que todos

pacotes até, e inclusive,

o No. de seqüência n

foram recebidos no

receptor: “ACK

cumulativo” pode

receber ACKs

duplicados.

Temporizador

Timeout(n): retransmite pacote n e

todos os pacotes com No. de

seqüência maiores na janela.


59


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.Temporizador: é um cronômetro

para o pacote mais antigo

transmitido, mas que ainda não foi

reconhecido


60


•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


61

GBN: FSM estendida do receptor

Receptor é muito simples:

Usa apenas ACK: sempre envia ACK para pacote recebido o.k. com o maior número de seqüência em ordem.

• Pode gerar ACKs duplicados

• Só precisa se lembrar do expectedseqnum

Pacote fora de ordem: • Descarta (não armazena) receptor não usa buffers !

• Manda ACK de pacote com maior No. de seqüência em ordem.

expectedseqnum =

expectedseqnum + 1


62

GBN

em ação

Janela = 4.

Envia de 0 a 3 e

o 2 se perde

Confirma os

pacotes 0 e 1

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.


63

GBN não é o TCP

GBN incorpora quase todas as técnicas que serão

encontradas nos componentes do TCP (visto mais adiante):

• Número de seqüência;

• Checksum;

• ACK cumulativos;

• Timeouts;

• Operação de retransmissão

Entretanto existem diferenças entre o TCP e o GBN.

Por exemplo: muitas implementações TCP fazem buffering

de segmentos recebidos corretamente, mas fora de ordem.

TCP é um híbrido de GBN e Repetição Seletiva (a seguir).


64

Problemas do GBN

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.

À medida em que a probabilidade de erro

do canal cresce, o duto fica lotado de

retransmissões desnecessárias.


65

Repetição Seletiva


66

Repetição seletiva

Evita retransmissões desnecessárias.

• O emissor retransmite apenas os pacotes que ele suspeita terem sido recebidos com erro pelo receptor.

Receptor confirma individualmente todos os pacotes recebidos corretamente.

• Armazena pacotes no buffer, conforme necessário, para posterior entrega em ordem à camada superior.

Emissor apenas re-envia pacotes para os quais o ACK não foi recebido.

• Timer de EMISSOR para cada pacote sem ACK.

Janela do emissor• N números de seqüência consecutivos.

• Outra vez limita Nos. de seqüência de pacotes enviados, mas ainda não reconhecidos.


67

Repetição seletiva: janelas de remetente e receptor

O emissor já terá

recebido confirmação

para alguns pacotes

da janela.


68

Repetição seletiva no emissor

Dados recebidos de acima. O emissor verifica o próximo número

de seqüência disponível para o pacote.

• Se o número de seqüê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.

Timeout. Temporizadores são usados para proteger contra perda

de pacotes.

• Somente um único pacote será transmitido no caso de timeout.

ACK recebido. Se um ACK for recebido, o emissor marca o

pacote como recebido.

• Se o número de seqüência do pacote for igual à send-base, então a

base da janela avança até o pacote com o menor número de

seqüência não-confirmado. Se houver pacotes não transmitidos, com

números de seqüência que caem agora dentro da janela, estes pacotes

são transmitidos.


69

Repetição seletiva no receptor (1)

Pacote com número de seqüência no intervalo [ rcv_base, rcv_base+N-1]

é recebido corretamente:

• Neste caso, o pacote recebido cai dentro da janela do receptor e um

pacote seletivo de ACK é retornado ao remetente. Se o pacote não

foi recebido previamente, ele é armazenado.

• Se este pacote tiver um número de seqüência igual à base da janela

da recepção (rcv_base), então este pacote, e os quaisquer pacotes

previamente armazenados e numerados em seqüência (começando

com o rcv_base) são entregues à camada superior.

• A janela de recepção é movida então para a frente pelo número total

dos pacotes entregues à camada superior.

Pacote com número de seqüê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.

Se não: Ignora o pacote.


70

Repetição seletiva no receptor (2)

Intervalo dentro da janela

[ rcv_base, rcv_base+N-1]

[ rcv_base-N, rcv_base-1 ]:

pacotes já confirmados anteriormente

Pacote com número de seqüê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.


71

Repetição seletiva - resumo

Dados de cima:

Se próximo No. de seqüência na

janela, envia pacote.

Timeout(n):

Reenvia pacote n.

Reinicia o temporizador.

ACK(n) em [sendbase,sendbase+N]:

Marca pacote n como “recebido”.

Se N for menor pacote não

confirmado, avança base da

janela ao próximo No. de

seqüência não confirmado.

• 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.

receptoremissor


72

Retransmissão seletiva em ação


73

Retransmissão seletiva em ação

Quando um pacote com um

número de seqüência de

rcv_base=2 é recebido, então

ele e os pacotes rcv_base+1 e

rcv_base+2 podem ser

entregues à camada superior.


Repetição

seletiva: dilema

74


75

Repetição

seletiva: dilema

Exemplo:

Nos. de seqüência : 0, 1, 2 e 3.

Tamanho de janela = 3.

Receptor não vê diferença entre

os dois cenários (a) e (b) !!!

Incorretamente passa dados

duplicados como sendo novos

em (a).

Pergunta: Qual a relação entre

tamanho de No. de seqüência e

tamanho de janela?

Um tamanho de janela que seja igual ao tamanho de numeração sequencial, menos 1, não vai funcionar.


76

TCP: Visão geral (1) RFCs: 793, 1122, 1323, 2018, 2581

É Peer-to-Peer (P2P):• Único emissor transmite para um único receptor.

Fornece fluxo de bytes ordenados e confiável:• Não estruturado em mensagens.

É dutado (pipelined):• Tamanho da janela ajustado por controle de fluxo e

congestionamento do TCP.

Usa Buffers de envio e recepção, e variáveis de

estado para cada conexão.

socket

door

TCP

send buffer

TCP

receive buffer

socket

door

segment

application

writes data

application

reads data


77

TCP: Visão geral (2) RFCs: 793, 1122, 1323, 2018, 2581

O tráfego é Full Duplex:

• Fluxo de dados bi-direcional na mesma conexão.

• MSS: é o tamanho máximo de segmento de dados.

(Falaremos de MSS mais adiante)

É orientado a conexão:

• Handshaking de 3 vias (troca de msgs de controle)

inicia estado de remetente, receptor antes de trocar

dados.

Tem o Fluxo controlado: o receptor não será

afogado.

1500 bytes, 536 bytes

ou 512 bytes


78

TCP: estrutura do segmento

No. porta origem No. porta dest

32 bits

dados da

aplicação

(tamanho variável)

número de seqüência

número de confirmação (ACK)

janela receptor

ptr dados urg.checksum

FSRPAUtam.cab.

semuso

Opções (tamanho variável)

URG: dados urgentes

(pouco usado)

ACK: No. ACK é válido

PSH = push: força

envio de dados

imediatamente.

RST, SYN, FIN:

gestão de conexão

(comandos de

estabelecimento,

liberação)

No. bytes que o

receptor quer

aceitar: Controle

de Fluxo.

Contagem

de dados

por bytes

(não segmentos!)

checksum

Internet

(como UDP)

Tamanho do header

em palavras de 32 bits

20 bytes fixos

no header


Header TCP

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 seqüência 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 identifica os bytes que foram recebidos e tratados sem erro pelo destino, bem como a seqüência do próximo byte esperado

Tamanho é representa o tamanho total do frame TCP Reservado é um campo ainda não utilizado FLAGS identifica as flags (syn, fin, psh, rst, ack, urg) 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 Urgent Pointer é um ponteiro para dados urgentes, contidos na área de dados.


80

Gerenciamento de conexões no

TCP


81

TCP: Gerenciamento de Conexões (1)

Lembrete: Remetente e receptor TCP estabelecem “conexão” antes

de trocar segmentos de dados.

Conexão é full duplex : fluxo de dados vai nos dois sentidos.

Inicializam variáveis TCP:

• Números de seqüência e confirmação.

• Buffers, informações de controle de fluxo (por exemplo RcvWindow) e temporizadores.

Cliente: é aquele que inicia a conexão.

• Active Open

Servidor: é aquele chamado pelo cliente.

• Passive Open.


82

TCP: Iniciando Conexão (1)

Inicialização em 3 passos (3-way handshake):

(1): Cliente envia segmento de controle SYN do TCP ao servidor.

• Bit SYN do TCP é ajustado como 1. (SYN=1; ACK=0)

• Cliente especifica No. de Seqüência inicial.

(2): Servidor recebe SYN, responde com segmento de controle SYN-

ACK

• Ajusta SYN=1 E ACK=1 (SYN=1; ACK=1)

• Confirma SYN recebido.

• Aloca buffers, especifica No. seq. inicial de servidor para o

receptor.

(3): Cliente recebe SYN=1; ACK=1, e responde com segmento de

controle ACK e começa a enviar dados. (SYN=0; ACK=1)


83

TCP: Iniciando Conexão (2)

(SYN=1; ACK=0)

(SYN=1; ACK=1)

(SYN=0; ACK=1)

Cliente confirma o

No. seq. do server,

e começa a enviar

dados seguindo

seu No. de seq.

Servidor confirma o

No. seq. do cliente,

e envia seu próprio

No. de seq.


Estabelecimento da Conexão

Origem

A

Destino

BSYN 1415531521:1415531521 (0) <mss 1024>

SYN 1823083482: 1823083482 (0) <mss 1024>

ACK 1415531522

ACK 1823083522


Encerramento da Conexão

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.


86

TCP: Fechando uma Conexão (1)

Encerrando uma conexão:

Passo 1: cliente envia

segmento de controle FIN ao

servidor.

Passo 2: servidor recebe FIN,

responde com ACK.

Também pede encerramento

da conexão, enviando FIN.

( Segue.... )

cliente servidor

fechar

fechar

fechada

esp

era

te

mpo

riza

da


87

TCP: Fechando uma Conexão (2)

Passo 3: cliente recebe FIN,

responde com ACK.

• Entre em “espera

temporizada” -

responderá com ACK a

FINs recebidos

Step 4: servidor, recebe ACK.

Conexão encerrada.

cliente servidor

fechando

fechando

fechada

esp

era

tem

pori

zada

fechada


Encerramento da Conexão

Origem

A

Destino

BFIN 1415531522:1415531522 (0) ACK 1823083522

ACK 1415531523

ACK 1823083523

FIN 1823083522: 1823083522 (0)

ACK 1415531523


89

TCP: Ciclo de vida do SERVIDOR

Ciclo de vida do servidor TCP


90

TCP: Ciclo de vida do CLIENTE

Ciclo de vida do cliente TCP


MSS e numeração de segmentos

91


MSS (Maximum Segment Size)

O MSS representa o tamanho do maior bloco de

dados que o TCP pretende enviar num único

segmento para o destino.

Para a maioria dos computadores o MSS é

ajustado automaticamente pelo sistema

operacional.

• 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)


Quanto maior o MSS, melhor

Em geral, quanto maior o MSS melhor o

desempenho da rede.

• Mais dados são enviados num único segmento.

• Desde que não ocorra fragmentação.

• Quanto maior a quantidade de dados enviados em um

único bloco, menor o overhead de headers TCP e IP.

• 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.


94

MSS e numeração de segmentos

Aplicação quer enviar 500.000 bytes de dados,

Em TCP com MSS = 1.000 bytes

Transmissão TCP: 500 partes de 1.000 bytes

1o. segmento último segmento

O No. de sequência do emissor é incrementado pelo No. de bytes enviados


95

TCP: Números de seqüência e ACKs

Nos. de sequência:

“número” do primeiro

byte de dados do

segmento.

ACKs: No. de

sequência do próximo

segmento esperado

(em bytes).

• ACK cumulativo.

P: Como receptor trata

segmentos fora da ordem?

• Especificação do TCP

é omissa - deixado ao

implementador.

• Maioria das vezes:

buferiza.

Host AHost B

Usuáriotecla‘C’

A reconhecechegadado ‘C’ecoado

B reconhecechegada de ‘C’, ecoa

‘C’ de volta

tempo

cenário simples de telnet


96

TCP: transferência confiável de dados no

TRANSMISSOR (1/2)

waitfor

event

waitfor

event

event: data received

from application above

event: timer timeout for

segment with seq# y

event: ACK received,

with ACK# y

create, send segment

retransmit segment

ACK processing

Passagem dos dados da aplicação ao

TCP, e transmissão de um segmento.

Se não chegar o ACK: Cada vez que o

TCP entrega um segmento ao IP

(abaixo), ele inicia um temporizador

para aquele segmento. Se este

temporizador expirar, o TCP responde

ao evento de timeout, re-enviando o

segmento que causou o timeout.

Chegada de um segmento

de reconhecimento (ACK)

vindo do receptor.


97

TCP: transferência confiável de dados no

TRANSMISSOR (2/2) – processamento do ack

waitfor

event

waitfor

event

event: data received

from application above

event: timer timeout for

segment with seq # y

event: ACK received,

with ACK # y

create, send segment

retransmit segment

ACK processing

Chegada de um ACK o

emissor deve determinar se o ACK

é um “first-time ACK” (para um

segmento o qual o remetente ainda

está esperando um ACK), ou uma

“duplicata de ACK”, que “re-

reconheça” um segmento para

qual o remetente já tenha recebido

ACK anteriormente.

Chegada de um ACK first-time

o emissor é informado que todos

os dados até (inclusive) o byte

que está sendo confirmado

foram recebidos no receptor.

O emissor atualiza sua variável

do estado do TCP que segue o

número de seqüência do último

byte que tenha sido recebido

corretamente (e em ordem), no

receptor.


ACKs duplicados

First time ack é sinal que está tudo ok.

Mas, o que acontece se o emissor recebe um

ACK duplicado ?

• Ou seja, uma “duplicata de ACK”, que “re-

reconheça” um segmento para qual o emissor já

tenha recebido ACK anteriormente.

Veremos em seguida como isso é usado pelo

TCP...

98


99

Retransmissão rápida (1/2)

Quando um receptor recebe um segmento com

um número de seqüência maior do que

próximo número de seqüência esperado, ele

detecta uma falha no fluxo de dados

• Ou seja: detecta um segmento faltante.

Uma vez que o TCP não usa NACK, o receptor

não pode emitir uma negativa de ACK de volta ao

emissor.• Ao invés disso, “re-reconhece” simplesmente o último byte

“em ordem” dos dados que ele recebeu corretamente.

• Isto é, ele gera um ACK em duplicata para o último byte

recebido ok.


Retransmissão rápida (2/2)

Se o emissor receber três ACKs

duplicados (ou seja, 4 ACKs idênticos)

para o mesmo segmento que ele enviou, ele

assume que foi perdido o segmento que

vem em seguida ao segmento que foi

confirmado 4 vezes.

• Neste caso, o TCP executa uma retransmissão

rápida re-envia o segmento faltante, mesmo

antes que o temporizador do segmento

expire [RFC 2581].

100


Entendendo os 3 “ACKs duplicados”

101

ACK xxxxxxx523

ACK xxxxxxx523

ACK xxxxxxx523

ACK xxxxxxx523Ain

da n

ão

ocorr

eu t

imeout

1o. ACK duplicado

2o. ACK duplicado

3o. ACK duplicado

Tim

er

A chegada de 4 ACKs idênticos antes de vencer o timer

daquele ACK, resulta na “retransmissão rápida”.


RFC 2581 - TCP Congestion Control

102

" 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."

http://www.faqs.org/rfcs/rfc2581.html


103

Geração de ACKs no TCP [RFCs 1122, 2581]

Evento Ação do receptor TCP

Chegada do segmento em ordem, com número de seqüência previsto: todos os dados até o No. de seq. previsto já

reconhecidos; nenhum “buraco” nos dados recebidos.

Promove ACK atrasado à Espera até 500ms

pela chegada de um outro segmento em

ordem. Se o próximo segmento não chegar

em ordem neste intervalo, emita um ACK do

anterior.

Chegada de um segmento em ordem com número de seqüência previsto. Um outro segmento em ordem aguardando transmissão de ACK. Nenhum “buraco” nos dados recebidos.

Emita imediatamente um único ACK cumulativo. Confirmando ambos os segmentos em-ordem.

Chegada do segmento fora de ordem com número de seqüência mais alto do que esperado à detectada falha na sequência.

Emita imediatamente o ACK duplicado, indicando o número de seqüência do próximo segmento esperado.

Chegada de segmento que completa parcial ou completamente uma falha nos dados recebidos.

Emita imediatamente o ACK, contanto que o segmento comece no fim mais baixo da falha.


104

TCP: cenários de retransmissão (1)

Estação A

perdatem

pori

zaçã

o

tempo cenário doACK perdido

Estação B

X


105


Timeout antes

da chegada do

ack do primeiro

segmento. Re-

envia

Recebe o ACK

do primeiro e host

A “acha” que é do

re-enviadoEste ACK do re-

envio do 1o.

Segmento é

desconsiderado

O ACK do

segundo

segmento chega

on-time


106


Indica que B

recebeu tudo

certo, até o 100

(aguarda o 120)

Recebe a indicação

que B recebeu tudo

certo, até o 100, e não

re-envia nada.

O ACK do

primeiro

segmento se

perde

Envia dois

segmentos de

uma vez e

aguarda


107

Controle de FLUXO no TCP


108

TCP: Controle de Fluxo (1)

buffering pelo receptor

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 emissor (lembrar que é Full Duplex).

Para emissor não esgotar os buffers do receptor

transmitindo demais, ou muito rapidamente.


109

TCP: Controle de Fluxo (2)RECEPTOR: explicitamente avisa o emissor da quantidade

de espaço livre disponível (que muda dinamicamente).

• Campo RcvWindow (janela) no segmento TCP .

EMISSOR: mantém a quantidade de dados transmitidos, porém ainda não reconhecidos, MENOR que o valor mais recente de RcvWindow.

(isso vale para cada lado da conexão)


110

Troca de informações sobre controle de fluxo TCP

(0) 4 Kb = Tamanho

do buffer do receptor.

(1) Aplicação

envia 2 Kb

(2) Receptor

confirma e avisa que

pode enviar mais 2

Kb.

(4) Receptor

confirma e pede

para aguardar

(buffer cheio) win=0(...) Emissor

aguarda...

(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)

(6) Receptor agora

pode enviar até 2

Kb; envia o 1 Kb que

falta.

(3) Aplicação

envia 3 Kb, mas

emissor TCP só

pode enviar 2 Kb


111

Tempo de resposta (RTT) e ajustes da

temporização de timeout

Retransmissão adaptativa


112

TCP: Tempo de Resposta (RTT) e timeout

P: Como escolher valor

do temporizador de

timeout do TCP?

Deve ser maior que o RTT.

• Note que o RTT pode

variar.

• Muito curto: temporização

prematura.

• Retransmissões são

desnecessárias.

• Muito longo: reação

demorada à perda de

segmentos.

P: Como estimar RTT?

RTTamostra: tempo medido entre

a transmissão do segmento e o

recebimento do ACK

correspondente.

• Ignora retransmissões, e

segmentos com ACKs

cumulativos

RTTamostra varia.

Necessita “ponderador” de RTT.

• Usa várias medições recentes,

não apenas o valor corrente (RTTamostra)

Atribuir mais peso às amostras

recentes do que às amostras antigas.


113

Mas, não é tão simples…

Ainda há a questão entre o RTT e o timeout.

• Necessário ajustar o timeout com o RTT.

• Não é algo simples.

• O TCP utilizava normalmente timeout = B*RTT.

Mas, neste caso a dificuldade é determinar “B”.

• Nas implementações iniciais, B era fixado em 2.

• Ou seja, duas idas e voltas (2 x RTT).

• Estimativa “empírica” (leia-se “chute”).

Mas, um valor constante era inflexível, e não atendia os casos em que a variação era maior.


Algoritmo original

114

• Medir RTTamostra para cada par segment/ACK

• Calcular a média ponderada do RTT:

• RTT_estimado = a*RTT_estimado + b*RTTamostra,

onde a+b = 1

• a: deve ser entre 0.8 and 0.9

• b: deve ser entre 0.1 and 0.2

• Ajustar timeout baseado no RTT_estimado

• TimeOut = 2 * RTT_estimado


115

Proposta de Van Jacobson (1)

1988: Van Jacobson propôs tornar Bproporcional à variação do RTT.

Portanto, uma grande variação significa um valor alto para B, e pouca variação significa um valor baixo.

• Na prática ele sugeriu usar o desvio médio do RTT como uma forma de estimar o desvio padrão.

• Não é exato, mas é uma aproximação razoável.

• Desvio médio é dado pela média aritmética dos desvios.

• Desvio = | valor médio - valor medido |


116

Proposta de Van Jacobson (2)

A maioria das implementações atuais usa este algoritmo

e define o intervalo de timeout (ajuste do temporizador)

como:

timeout = RTT + 4*DevRTT

A escolha do fator 4 é arbitrária.

Minimiza o número de retransmissões necessárias:

• Menos de 1% de todos os pacotes chegam com atraso de mais

de 4 vezes o desvio padrão.

Exercício:

Pesquisar e estudar algoritmo Jacobson/Karels.


117

Se você pensa que acabou… (1)

Temporizador de retransmissão não é o único usado pelo TCP.

Na verdade são 4 timers.

• Retransmissão (já visto)

• Persistência

• Keep-alive

• Time-wait


118

Temporizador de persistência

Temporizador de persistência:

• Para evitar impasse.

• Receptor envia pacote de tamanho de janela 0,pedindo para emissor aguardar.

• De tempos em tempos o emissor faz um teste para ver se pode enviar (devido a risco de perda do pacote de atualização do receptor)


119

Temporizador keep alive

Temporizador keep alive (“mantenha vivo”):

• Para verificar conexões inativas por muito tempo.

• Um lado verifica se o outro ainda está lá.


120

Temporizador Time Wait

Temporizador time wait (“tempo de espera”):

• É usado durante o encerramento de uma 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.


121

Controle de Congestionamento


122

Princípios de Controle de Congestionamento (1)

Congestionamento:

Informalmente: “trata-se de fontes enviando muitos

dados mais rapidamente do que a rede pode

suportar.”

• Diferente de controle de fluxo.

Retransmissão de pacotes trata o sintoma do

congestionamento da rede (que é a perda de

segmentos), mas não trata a causa do

congestionamento:

• Origens tentando enviar dados numa taxa muito alta.


Princípios de Controle de Congestionamento (2)

Como se manifesta:

• Perda (drop) de pacotes • Esgotamento de buffers em roteadores.

• Retransmissão de pacotes.• devido aos drops.

• Longos atrasos • Grande enfileiramento nos buffers dos roteadores.

123


124

Solução para o Congestionamento

Verdadeira solução para o congestionamento

é diminuir 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.

TCP tenta alcançar esse objetivo.

• Manipulando dinamicamente o

tamanho da janela.


125

O que o TCP faz para evitar

congestionamentos:

Quando uma conexão é estabelecida, escolhe um

tamanho de janela adequado.

• Veremos mais adiante como é esta escolha.

O receptor pode especificar uma janela a partir do

tamanho de seu buffer.

• Indica o quanto ele está disposto a receber.

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.


126

TCP: Controle de Congestionamento (1)

Deve-se entender que existem dois

problemas potenciais:

• Capacidade do receptor.

• Capacidade da rede.

Deve-se tratar cada um em separado.

Para isso, cada transmissor mantém duas janelas:

• Janela fornecida pelo receptor.

RcvWin

• Janela de congestionamento:

CongWin


127

TCP: Controle de Congestionamento (2)

Cada uma identifica o número de bytes que o

transmissor pode enviar

• pode enviar o valor mínimo das duas janelas.

Então, a quantidade máxima de dados não

confirmados que um host pode enviar em uma

conexão:

LastByteSent - LastByteAcked min{CongWin, RcvWin}


128

TCP: Controle de Congestionamento

Controle é fim a fim (sem apoio da rede).

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....


129

TCP: Controle de Congestionamento

A janela efetiva é o mínimo do que o

transmissor e o receptor consideram viável.

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.

Se o receptor disser: “envie 8KB”, e o

transmissor souber que rajadas de até 32 KB

passam pela rede sem problemas, ele enviará os

8 KB solicitados.


130

Como funciona o controle:

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...

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 isso causa congestionamento.

• Quando houver perdas: diminuir Congwin.

• Depois volta a à sondagem (aumentando) novamente.


131

Partida lenta e sondagem do congestionamento (1)

Conexão é estabelecida transmissor ajusta

a janela de congestionamento igual ao MSS

em uso.

• Em seguida, ele envia este segmento máximo.

• Se esse segmento for confirmado antes de

ocorrer um timeout, o transmissor:

• Adicionará o número de bytes de 1 segmento na

janela de congestionamento, de modo que ela tenha

capacidade equivalente a 2 segmento máximos.

• Enviará os 2 segmentos...

• ....

(continua...)


132

Partida lenta e sondagem do congestionamento (2)

À 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.

Na prática, cada rajada confirmada duplica a janela

de congestionamento atual: crescimento exponencial.


133

TCP: Partida lenta

A cada RTT ocorre um aumento exponencialno tamanho da janela. • Partida não tão lenta!

Algoritmo de Partida Lenta

inicializa: Congwin = 1

for (cada segmento c/ ACK)

Congwin++

until (evento de perda OR

CongWin > threshold)

Estação A

RT

T

Estação B

tempo

Veremos o que é isso a seguir...


Quando parar o crescimento?

Mas, quando parar o crescimento ?

Obviamente este crescimento terá de ser

interrompido em algum momento, devido a

congestionamento da rede ou capacidade do

receptor.

Para isso é usado o parâmetro de threshold.

Vejamos como...

134


135

Threshold

Algoritmo de controle de congestionamento

TCP utiliza um terceiro parâmetro limitante:

o threshold.

• Também chamado de “limiar” ou “patamar”.

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 um MSS para cada rajada.


136

Threshold e o timeout

Quando há um timeout, o threshold é atribuído à

metade da janela de congestionamento atual, e a

janela de congestionamento é reinicializada para 1

MSS.

Na prática, esse algoritmo diminui o tamanho da

janela de congestionamento à metade, e depois

retoma seu crescimento a partir daí.


137

TCP: Evitar Congestionamento (1)

(3) Quando há

timeout, congwin

volta para 1 MSS, e

threshold cai pela

metade

timeout

(2) Quando atinge

threshold, o

crescimento passa a

ser linear

(fase de “prevenção de

congestionamento”)

(2.1) Quando atinge o threshold o aumento é de um segmento máximo para

cada rajada em vez de um para cada segmento.

(1) Fase de

“partida lenta”


138

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


139

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.

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.

AADM / Additive-Increase, Multiplicative-Decrease (AIMD)

TCP conexão 1

Roteadorgargalo

capacidade R

TCP conexão 2


140

Capítulo 3: Sumário

Princípios por trás dos serviços

da camada de transporte:

• Multiplexação /

desmultiplexação

• transferência confiável de dados

• controle de fluxo

• controle de congestionamento

Instanciação e implementação na

Internet.

• UDP

• TCP

Próximo capítulo:

Saímos da “borda” da rede

(camadas de aplicação e

transporte)

Entramos no “núcleo”da

rede.


141


Exercício proposto:

Estudar a diferenças e semelhanças entre os

algoritmos TCP Reno e TCP Tahoe, entendendo

como eles atuam com relação à emissão de

ACKs e recuperação de falhas.

142


143

Documents

unesp - IBILCE - SJRP Curso de Redes de Computadores 2010 · unesp - IBILCE - SJRP 2 Capítulo 3: Camada de Transporte Metas do capítulo: Compreender os princípios dos serviços