SIN352 - Aula 14 - Camada de Transporte 4/5

#SIN352 #RedesDeComputadores #PER2 #AulaSincrona #CamadaDeTransporte

O remetente usa a temporização para saber quando ele precisa retransmitir

• Suponha que um determinado segmento foi perdido. Como o TCP irá fazer a retransmissão
dele?

É preciso ter uma ideia do tempo decorrido entre o envio de um segmento e

seu reconhecimento (ida e volta). Se eu souber esse tempo, ficaria mais fácil

saber quando retransmitir o segmento...

RTT

• RTT – Round Time Trip

• TCP irá utilizar amostras de RTT para encontrar um valor estimado de RTT;

• Após a amostra inicial, o TCP coleta uma nova amostra a cada valor estimado de RTT.

RTT – Média ponderada

• ValorEstimadoRTT = (1-alpha)*ValorEstimadoRTT + (alpha)*AmostraRTT

Onde: AmostraRTT representa as amostras mais antigas e ValorEstimadoRTT as

amostras mais novas;

• ValorEstimadoRTT = (0,875)*ValorEstimadoRTT + (0,125)*AmostraRTT

para Alpha = 0,125

Onde: AmostraRTT representa as amostras mais antigas e ValorEstimadoRTT as

amostras mais novas;

Variabilidade de RTT

• DesvioRTT = (1-beta)*DesvioRTT + (beta)*|AmostraRTT - ValorEstimadoRTT|

O valor estimado para beta é de 0,25.

RTT x tempo - grafico 11 minutos

Temporização da retransmissão
 • Dados os valores de ValorEstimadoRTT (média) e DesvioRTT (prever melhor com
menor erro) qual deve ser o valor utilizado para a retransmissão do TCP?

Esse valor deve ser maior ou igual ao ValorEstimadoRTT para evitar

retransmissões desnecessárias! Mas não pode ser muito maior, senão o TCP não o
retransmitiria rápido...

IntervaloTimeout = ValorEstimado + 4*DesvioRTT

Se o segmento não for reconhecido pelo destinatário dentro da janela

IntervaloTimeout, o TCP no remetente fará a retransmissão;

Valor inicial de 1 segundo ou definido pelo RTT dos pacotes

trocados durante o three-way handshake;

Quando um Timeout acontece, o valor de IntervaloTimeout é

duplicado para evitar problemas com congestionamento.

Importante: para retransmitir o TCP usa um tempo.

ele sabera que o outro recebeu quando receber uma mensagem de confirmação

considera-se a ida e a volta (RTT) e calcula-se uma amostra, conjunto de dados com
tempos médios

média móvel

Princípios da transferência confiável de dados

• Modelo do serviço e implementação do serviço: slide 16 - 29 minutos

Serviço de transferência confiável de dados

• Camada de rede:

• não garante a entrega de datagramas na ordem correta nem a integridade de seus

dados nos datagramas;

• datagramas podem transbordar dos buffers dos roteadores e jamais alcançar seu
destino;

• Bits dos datagramas podem ser corrompidos.

• Garante que a cadeia de dados que um processo lê a partir de seu buffer de recebimento
TCP:

• Não está corrompida;

 • Não tem lacunas;

• Não tem duplicações;

• Está em sequência

Serviço de transferência confiável de dados – Abordagem

• Duas etapas:

• Descrição simplificada de um remetente TCP que utiliza apenas controle de

temporizadores para se recuperar da perda de segmentos;

• Descrição de três cenários que envolvem reconhecimentos duplicados e

temporizadores de retransmissão.

Serviço de transferência confiável de dados – Cenário

• Três eventos importantes:

1. TCP recebe dados da camada de aplicação;

2. Esgotamento do temporizador (timeout);

3. Chegada de um ACK do destinatário

• Obs: SendBase é o número de sequência do mais antigo byte não reconhecido.

Descrição simplificada de um remetente TCP slide 21 - 34 minutos explica código

Construindo um protocolo de transferência confiável slide 22 a 33 - 35 minutos

• rdt1.0

um protocolo para um canal completamente confiável

primeira tentativa - recebe imput, pedido de transmissão de

dados por meio da aplicação, o algoritimo faz send (data).

desencadeou a função enviar dados, em um

leitura de cima para baixo, o sistema operacional vai criar o pacote com esses dados

e vai passar para a camada de baixo, para a

camada de rede que vai entregar esse pacote

No lado de quem espera, recebe o pacote,

extrai e entrega os dados para o socket

OBS: Não garantiu a transferência confiável, apenas recebe e manda

para a camada de rede.
 • rdt2.0

Traz a idéia do ACK e Check sum

reconehcimento positivo (ack) e negativos (nack) e detecção de erros

Quem manda a mensagem

recebe da camada de aplicação um imput, faz o pacote,

e passa para a camada de rede, vai para outro estado, epera a confirmação

se ele receber um nack ele continua esperando

se ele receber o pacote (ack) ele volta para a espera de

novos pacotes para serem enviados

PROBLEMA: Se o ack for perdido, como não tem

temporização vai ficar esperando para sempre

tentativa falha por isso

esse modelo de transmissão é do tipo pare e

espere (stop-and-wait), envia o pacote e não faz mais nada até receber a confirmação

Quem recebe a mensagem - slide 24 - 46 minutos

recebe um dado da camada de baixo (camada

de rede), verifica se não está corrompido, se estiver ele cria um pacote com um nak e manda o
nak informando que está corrompido

se recebe e não está corrompido desencapsula,

entrega para aplicação e devolve um ack

PROBLEMA FATAL: Se um ack ou nak estiver

corrompido? Para resolver esse problema tem-se algumas alternativas:

• Alternativa 1: o ser humano fatia no cenário

de perda das mensagens de confirmação?

• Alternativa 2: Adicionar número suficiente de

bits na soma de verificação.

• Resolve um problema para um canal

que pode corromper bits, mas não perde-los;

• Alternativa 3: O remetente reenvia o pacote

de dados corrente quando receber um pacote ACK ou NAK truncado.
 • Induz pacotes duplicados

• O destinatário ñão sabe se o último

ACK ou NAK que enviou foi bem recebido

• Assim, ele não sabe se um pacote

que chega contém novos dados ou se é retransmissão

SOLUÇÃO:

• Adicionar um novo campo ao pacote

de dados e fazer o remetente numerar seus pacotes de dados colocando número de sequência
nesse campo.

• rdt2.1

REMETENTE

a camada de transporte foi provocada pela

aplicação então vai chamar o enviar dados, controi o pacote com o sequencial 0, vai colocar os
dados, o checksum e entrega os dados para a camada de baixo

aí muda de estado e espera receber a

confirmação

primeiro cenário: pacote corrompido

ou nak então ele retransmite

ele sai do estado de espera de ack para

o estado de espera de mais dados, agora com o sequencial 1, quando ele recebe um pacote
que não está corrompido e é ack e é uma confirmação

nesse proximo estado ele espera ser

provocado pela aplicação, a aplicação provoca, desencadeia o rdt send pra enviar e faz
novamente a mesma coisa, só que agora com o sequencial 1, manda os dados e checksum e
pula para o proximo estado onde fica esperando a confirmação do ack ou nak 1

e muda novamente para outro estado

se receber a confirmação de ack e não corrompido

DESTINATÁRIO

destinatário espera que o dado chegue na

placa de rede, chegou precisa ser passado para a aplicação.

o dado chega certo, não corrompido, com

sequencial 0

extrai o pacote

entrega para a aplicação

constroi checksum
 manda um ack confirmando

sai do estado de espera do ack 0 e vai para o de

espera do ack 1

se receber pacote corrompido ele

informa um nak e continua esperando

se receber pacote que não está

corrompido mas está com outro sequencial ele entende que está fora de ordem, manda um
ack e espera por mais

passa para o proximo estado quando recebe

um pacote não corrompido e um sequencial correto

extrai o pacote

entrega para a aplicação

constroi checksum

manda um ack confirmando

• rdt2.2

rdt2.2 retira o nak fazendo um ack para o

ultimo pacote corretamente recebido

ack passa a fazer as duas coisas, se ack

tem valor 0, não recebeu, se 1 recebeu

REMETENTE

quem está mandando foi provocado pela

aplicação, chama a função rdt_sand(data), constroi o pacote com sequencial 0, os dados e
fazer o checksum (lacrar para mostrar que nao foi violado) e envia o pacote

espera a confirmação do pacote enviado,

esperando o ack 0, pois mandou o sequencial 0. Ele continua na espera se o pacote for
corrompido ou se receber um ack valendo 1, recebendo corrompido ou não ele manda que
recebeu, porém informa que foi corrompido também, aí retransmite

sai do estado de espera quando ele recebe o

pacote, não é corrompido e o ack recebido é exatamento o que ele estava esperando

vai para o estado de espera, porém agora com

os sequencial 1 e espera ser provocado novamente pela aplicação

espera a confirmação novamente e repete o

ciclo
 DESTINATÁRIO - 1:01 minutos

dados chegam na placa de rede, o sistema

operacional desencadeia uma interrupção ai o transporte recebe os dados

recebeu não corrompido e tem o sequencial

correto

extrai o pacote

entrega para a aplicação

constroi checksum

manda um ack confirmando

sai do estado de espera do ack zero e vai para a

espera do ack 1

permanece se receber corrompido ou

com numero sequencial diferente do esperado

OBS: implementa melhorias mas mesmo assim não

resolve pois precisa de um temporizador, para não ter que esperar toda vida

• rdt3.0

Considera que um pacote pode se perder

REMETENTE

aplicação manda os dados via socket, chega na

camada de transporte, recebe os dados

constroi o pacote

coloca sequencial 0, os dados e o

cheksum

manda o pacote e inicia o timer

cai no estado de espera da confirmação se o

pacote foi recebido

permanece se o pacote ta corrompido

ou de um ack diferente

se o timeout esgotar retransmite e

começa o timer novamente

sai da espera de confirmação e vai para a

espera de dados se a confirmação do pacote for o ack esperado e não estiver corrompido
 para o timer

para o rdt

espera o proximo sequencial

enquanto não receber os dados

permanece na espera

sai do estado quando receber os dados,

continua o ciclo

DESTINATÁRIO

faltou a imagem na aula

mesmo o rtd3.0 não é tão bom, pois só manda um pacote e

espera a confirmação, isso não é escalavel em termo de velocidade...

outra visão (tentativa 1.0 sem perda) slide 32 - 1:08 minutos

outra visão (tentativa havendo perda) slide 32 - 1:09 minutos

outra visão (tentativa ack perdido) slide 33 - 1:10 minutos

outra visão (tentativa temporização prematura) slide 33 - 1:11

minutos

um dos problemas do 3.0, não espera o suficiente,

manda novamente duplicando o pacote

DIFERENÇAS ENTRE AS VERSÕES

1.0 - considera que o canal nao tem erro, não perdia nada que mandava

2.0 - coloca checksum e ack e nak

2.1 - mantem ack e nak, mas, coloca sequencial

2.2 - retira o nak, pois, não é necessário uma vez que o ack pode fazer as duas
coisas, ainda sim possui problemas de envia e espera

3.0 - insere um timer, inclui tudo de melhor das tentativas anteriores, mesmo o
rtd3.0 não é tão bom, pois só manda um pacote e espera a confirmação, isso não é escalavel
em termo de velocidade...
• Ler as seções 3.4.1, 3.5.3 e 3.5.4;

principalmente RAT 1.0 a 3.0 e o conceito de temporização

• RFC 6298